--- title: "Everything That Happens Before the Rep Reads the Lead" description: "When a designer orders a sample, a lead arrives, and somebody has to work out who they are, where they are, what they asked for and what to say. I built a system for a sales rep that does all of that in the minutes after the lead lands, then hands the rep a draft to read. Nothing is sent without them." url: "https://angstromsys.com/blog/before-the-rep-reads-the-lead/" published: 2026-10-30 author: "Andrew Kaiser" tags: ["AI Agents","Sales","Build in Public"] --- # Everything That Happens Before the Rep Reads the Lead When an architect or interior designer orders a sample of a manufacturer's product, a lead arrives. For the sales rep who covers that territory, the lead is a stranger with a name, an email address and a product code. The job is to turn that stranger into a relationship. Before the first email, there is a lot of work. Who is this person, and which firm are they at? Have we met that firm before, under a slightly different name? Where are they, and who else is nearby? What did they ask for, and for what kind of project? What should the email say, and what must it not say? That work is the part nobody has time for. So leads sit, and a lead that sits goes cold. I built a system for a sales rep that does all of it in the minutes after a lead lands. By the time the rep opens it, the research is done and a draft is waiting. --- ## A lead arrives The rep forwards the lead email to one address. That is the only step they take. Everything below happens on its own, in the background, usually within a few minutes. **The email is kept exactly as it arrived.** Before anything reads it, the original is stored. If the way it gets read improves later, it can be read again from the original, and nothing is lost. **The requester becomes a person at a firm.** This is harder than it sounds, because the same firm turns up differently in different places. "St. Paul" in one, "Saint Paul" in another. A name cut off at thirty characters. Branch offices that are really separate firms. The system tries the firm's own ID first, then the email domain, then the name and city, then the phone number. When the only match is a firm with the same name in a different city, it doesn't guess. It puts a suggestion in front of the rep to confirm or reject. **The firm gets a pin on a map.** **What they asked for is lined up:** the products and colors, and the project they're for, with its type, its phase and when it's expected to be finished. **An intro email is drafted in the rep's voice.** The model is given three intros the rep wrote by hand, as examples of tone. It gets the facts from a copy of the product reference that is safe for clients. Pricing and internal notes are cut out of that copy before the model ever sees it. **Then code checks the draft.** If it mentions price or cost, names another brand, mentions warranty terms, makes a health claim, uses a product code that isn't in the catalog, or runs long, it is held, and the reason is shown next to it. The checks are deliberately broad. A false alarm costs the rep one glance. A missed one could cost a client relationship. **Nothing is sent.** The rep reads the draft, changes what they want, and sends it themselves. All of that is research a person would otherwise do by hand, one lead at a time. The system does it in minutes, and the person still makes the only decision that matters. ## Who to call first There is a second source, and on its own it's routine. In this industry a sale is really won when an architect names your product in a project's specification, the document the building is built from. Once a month, the rep gets a report from the platform architects use to write those specifications. It lists the firms in the territory, how many specifications each one wrote, and how many of them named the brand. Sample requests say who is curious. The specification report says who decides. Put side by side, firm by firm, they say something neither says alone. One firm had requested samples more than twenty times and had never named the brand in a specification. That is a firm that keeps looking and keeps choosing something else, or one that never got the right conversation. Either way, it's the first call to make. In either source on its own, it's noise: one more requester in a stream of requests, one more row in a monthly spreadsheet. So the firm list opens on that comparison. Its default view is the firms that wrote ten or more specifications in two years and never named the brand, sorted by how many samples they've requested. The top of that list is where interest and opportunity overlap, and it's where the rep's week starts. This only works because of the matching described above. The two sources spell the same firm differently, and a comparison is only as good as the join underneath it. One more detail mattered more than it looks: a firm missing from the specification report is shown as unknown, not as zero. "Has never named us" and "we don't know" call for different conversations, and a system that blurs them sends the rep into the wrong one. ## The rest of the week, in one place The lead is the start. The same system holds everything else the rep needs, so there is one place to look instead of six. **A map for planning trips.** Every firm is a pin. When the rep has one visit booked, the map shows which other firms are nearby and worth a stop. **The whole catalog, without the website.** The manufacturer's public catalog is copied into the system every week and can be narrowed by look, product line, color and finish. No clicking through product pages to answer a question in a parking lot. **A product chat.** The rep can ask a question in plain language, something like "a warm wood grain for a clinic's front desk, nothing too orange." The model searches the catalog itself, pins good candidates to a shortlist, and turns the shortlist into text the rep can send to a client. That text goes through the same checks as an intro. **Sample libraries, and when they're due.** Many firms keep a library of a manufacturer's samples, which the rep is supposed to refresh on a cycle. The system knows which firms have one, what's in it, and when it's next due. Before a visit it produces a packing list: designs added to the catalog since the last refresh to bring, and discontinued ones to take out. It knows what changed because it watches the catalog every week and notes when designs appear and disappear. If a weekly copy suddenly loses dozens of designs at once, it treats that as a bad download, not a mass discontinuation. ## Logging without logging Every sales team has the same problem. Management needs to know what reps did this week, so reps are asked to log it. Logging is a chore, so it happens late or not at all, and the weekly numbers become fiction. The constraint I designed to was simple: **logging has to take a few seconds on a phone in a parking lot.** Otherwise it won't happen. Most of the time, it doesn't take any: - **Copy the system on a client email,** and it's logged as an email to that client. If there was a draft intro waiting for that person, it's marked as sent. - **Add the system to a calendar invite,** and it becomes a planned visit. If the invite moves, the visit moves. If it's canceled, so is the visit. - **Someone new on an email** becomes an unconfirmed contact at their firm, waiting for the rep to confirm. An unconfirmed name never reaches a report. For the rest, there's one button: what kind of contact, which firm, any samples left, and a follow-up date, which becomes a task in the same tap. Then the weekly report writes itself. It's the report the rep already sends, in the same shape, but every number in it is counted from what was logged, fresh each time it's opened. The rep's own edits and notes are kept separately, so recounting never overwrites them. The model writes one line, the summary at the top. Code counts everything else. I'd rather a model never be the source of a number someone is judged on. ## What I got wrong **An undo that didn't undo.** Logging a library refresh also moves the library's next due date. The first version's Undo deleted the logged visit but left the date moved. Undo has to reverse everything an action did, not just the record of it. **Undo in the wrong place.** The rep removed a row from the weekly report by accident. The way to bring it back was one small line, under a different table. Nothing was lost, but it took me an hour to prove that. Now every removal shows an Undo right where it happened. **Assuming the week.** I built the report for Monday to Sunday. The company reports Friday to Thursday. It's a small fix, and exactly the kind of thing you only learn by asking the person who sends the report. ## What it means for a business Swap "sample request" for whatever arrives in your business: a quote request, an RFQ, a service call, an inbound inquiry. The shape is the same. Something arrives, and before anyone can reply well, someone has to work out who it is, find the context, and decide what to say. That middle work is where AI earns its keep, and it's also where most of the time goes. Do it in the minutes after the request arrives, and hand the person a finished starting point. Then keep three rules: - **The person sends.** The system prepares; it never acts on a client relationship by itself. - **Code checks what the model writes.** Your rules about what may never be said are enforced, not requested. - **Code counts.** Numbers people are measured on come from the record, not from a model's summary. There's a second lesson in the firm list. Most businesses already have two lists that nobody puts side by side: who shows interest, and who buys. Quote requests and orders. Website inquiries and signed contracts. Trade-show badges and accounts. Each one alone is routine. Joined on the customer, they show who is interested and not buying, and that is the most valuable list a salesperson can have. And the record is only as true as logging is easy. If you want honest numbers from a sales team, make logging the byproduct of work they were already doing. ## Where it stands It's in daily use: the lead handling, the firm comparison, the map, the catalog, the product chat, the libraries, the logging and the weekly report. Two things aren't built yet. A calendar feed the rep could subscribe to was deliberately left out, because it would need a link that works without signing in. Backups run nightly but sit on the same machine, and getting a copy somewhere else is the next job. --- *If leads, requests or quotes sit in an inbox in your business while someone finds the time to research them, that is a good place for [a walkthrough](https://angstromsys.com/walkthrough/) to start.*