From 10 minutes to 15 seconds: what an SDR pre-call brief looks like when an agent writes it

An SDR on the team used to spend 5 to 10 minutes before every call. Open the CRM, Google the company, click through the website to work out what software they run, scan the reviews, find a meeting slot, paste a summary into a doc. Multiply by 30 leads a month, then by four SDRs. That was the pre-call tax, and nobody ever put it on a dashboard.

Now it is one chat message. They type “prep call” plus a lead name, or paste the CRM record link. Fifteen seconds for a fast brief. Around two minutes for a full synthesis with talking points, discovery questions, objection prep and three suggested meeting slots. Across the team that is double-digit hours back every month, against a two-figure monthly infra bill.

Nothing in the pipeline is tied to one stack. Swap the chat tool, swap the CRM, swap the enrichment API and the shape holds. It is under 2,000 lines of Python running on one machine, no framework, no vector database, no worker fleet.

Where this one runs

The team sells into hospitality across DACH: small and mid-sized restaurants, cafes, operators of that size. Two choices in the pipeline come straight from that context and will not map one to one elsewhere.

The anchor field for validating enrichment is the phone number, because prospects in this market almost always have one listed. Sell into enterprise SaaS and your anchor is the domain. The displacement signal, meaning what the prospect runs today, comes from inspecting the website for the point-of-sale system. In enterprise SaaS the equivalent is the MarTech or data stack. Same pattern, different sensor.

Build time was about four days scattered between other work. The goal was not the prettiest classifier. It was something the team would use by Monday.

Three findings that shaped the build

Generic business names are the silent killer of enrichment pipelines. CRM records carry placeholders like “Pizzeria” or “Kebab Shop” because the inbound source dropped the real name. Enrichment APIs happily match on the name and hand back the highest rated business of that type in the city. An SDR asked for a brief on a lead called “Pizzeria” in a northern German city. He got the city’s top rated pizzeria, 2,868 reviews, owner name, phone, the works. He called the number. Wrong business. The brief was confidently, persuasively wrong.

The fix is a list of generic names, and for any record on that list a phone match against the CRM number before we trust the enriched record. No match, we discard the enrichment entirely rather than surface it with a caveat. It works with any provider that returns a phone number. For every enrichment source, define the anchor field and require a match on it. The confidence of the wrong answer is what burns you.

A CRM record link is an intent signal, not a lookup. Teammates started pasting record URLs with messages like “gimme info on this lead”. The keyword classifier caught “info”, routed to the fast path, and returned a thin echo of the record they already had open. Someone holding the record is not asking for background, they are asking for a next action. A regex for record URLs now runs before any keyword match and upgrades the route regardless of the verb. The pattern generalizes across Salesforce, HubSpot and Pipedrive URL shapes. Read signals in priority order, not in flat pattern order.

Parallelize the right things and sequence the rest. Version one ran everything in sequence at about 30 seconds end to end, which was long enough that SDRs would start the call before the brief arrived. Only one real dependency exists: the website scrape needs a URL, and the freshest URL comes from the enrichment call. So the CRM lookup goes first because it feeds phone, city and ICP to everything else. Then enrichment, news and slot search run in a four worker thread pool. The scrape fires when enrichment returns. Thirty seconds down to fifteen, with one synchronization point and no async ceremony.

A week in production

Just over a hundred queries across four SDR channels in the first week. CRM not-found sat around 15 percent, enrichment no-match around 8 percent, and phone mismatches caught around 3 percent. Before the anchor-field fix those last ones were silent failures, which is the failure mode I care about most.

On cost, the time returned paid the infra back roughly twelve times over at a DACH loaded-SDR rate, before touching conversion. Conversion is where the larger money sits and I am not measuring it rigorously yet. A call that opens with “I saw you are opening a second location in autumn, and your current system does not handle multi-location well” lands differently from “quick 30 minutes next week”. The anecdotes from the first weeks are consistent. Consistent anecdotes are not evidence, and I would rather say that than quote a number I cannot defend.

The part that generalizes

Manual research is expensive enough that SDRs ration it. Low priority leads get a worse first touch because someone decided they were not worth ten minutes. That is a quiet selection bias baked into the top of the funnel, and it never appears in any report. At 15 seconds a brief, the rationing stops and the quality floor moves up across every lead, not just the ones that looked promising.

The second thing that carries: put the agent where the work already happens. SDRs live in a chat window. A separate dashboard means a tab, a login, a record search and a copy-paste, which is enough friction to kill adoption in a fortnight. Meet the operator on the surface they are already on, not the one you wish they would adopt.

Everything else is a swap. Chat tool, CRM, enrichment provider, search layer, calendar, agent runtime. The three patterns above carry across all of them.

What did not work

The generic-name bug shipped before we caught it, and we only caught it because an SDR called the wrong business. For any enrichment source, build the validation layer before the happy path.

The classifier was under-tuned for record URLs and it took a real miss to surface that. Enumerate your intent signals upfront: keywords, link patterns, attachments, mentions. Not keywords alone.

LinkedIn enrichment is still manual. The scraping latency blew the 15 second budget, so it stayed out of version one. The right answer is probably a second async path that patches the brief 20 seconds later.

And there is still no feedback loop. SDRs cannot rate a brief inline, so quality is measured in anecdotes rather than grades. A thumbs reaction writing into a feedback store would let us tune the synthesis prompt against real data. It is on the list and it has been on the list for a while.

If you are running SDRs on Slack and HubSpot, or Teams and Salesforce, and want to compare notes on the classifier or the anchor-field trick, reach out.