Skip to content
Book a stack review
Writing

AI SDRs don't have a quality problem, they have a data problem

AI outreach reads like slop not because the model is bad, but because the data layer upstream of it is. Filter before you enrich, verify before you send.

3 min read
  • #data-quality
  • #ai
  • #enrichment

The loudest complaint in B2B sales right now is that AI-written outreach is garbage. The “hope this finds you well” openers. Three paragraphs of confident nothing. The personalization that names your company and gets your product wrong. AI sales agents are the trending category, and the backlash is louder than the launches.

Everyone blames the model.

The model isn’t the problem. The models are good. A current LLM, given a name, a title, a company, and one true fact, writes a better cold email than most SDRs. The bottleneck was never the writing. The bottleneck is what you feed it.

An LLM is a function. Its output is bounded by its input. Feed it a contact whose title changed nine months ago, a firmographic pulled from a database that hasn’t refreshed since the last funding round, a company description that’s a year stale, and an email address that may or may not exist, and it will produce a fluent, confident email about a person who no longer does that job at a company that no longer looks like that. The model isn’t lying. It’s reasoning faithfully over bad data. That’s the worst kind of error, because it sounds right.

This is the part nobody wants to hear, because it’s upstream of the tool they bought. The AI SDR vendors sell the model and the workflow. The data layer is your problem, and it’s where the slop is manufactured: stale enrichment, wrong contacts, unverified addresses, firmographics that drift, job titles that mutate. The model dresses all of it up in clean prose and puts a send button on it.

Garbage in, garbage out, but with confidence and a send button.

The fix is not a better model. There is no model good enough to rescue a prompt stuffed with rotten inputs. The fix is a data layer that does three things most teams skip: filter before you enrich, verify before you send, and ground every claim the model makes in a fact you actually gathered.

Filtering first is an order-of-operations problem. The cheap operations (does this company fit our profile? is it already in the CRM? is it a competitor?) belong upstream of the expensive ones (enriching contacts, finding emails). Most teams enrich everything and filter later, because enriching feels like progress. It isn’t. It’s spending dollars to learn what pennies would have told you.

Verification is the seam between data and sending. An email address that isn’t verified is not an asset; it’s a liability. A bounce hurts your sender reputation, and sender reputation is a domain-level property, not a campaign-level one. The worst case is the catch-all domain, the one that accepts every address, because you cannot tell whether the mailbox exists. Sending to catch-alls means mailing dead addresses and spam traps, and the damage lands on your domain, not on the contact. The correct action on a catch-all is to throw it away, not to hope.

Grounding is the constraint that separates a system from a slot machine. Every claim the model makes should point at a fact you collected. If there is no fact, the model returns nothing. No fact, no email. It sounds rigid because it is. The alternative is the model inventing a pain point to make the email work, which is the exact failure mode everyone is complaining about.

None of this is a model problem. It’s a pipeline problem. The teams whose AI outreach reads like a human wrote it, about a company a human researched, are not running better models. They’re running better data, and the model is the easy part sitting on top.

If your AI SDR is producing slop, don’t audit the prompt. Audit what’s in the prompt.

If your AI outreach reads like slop, the model isn’t where to look; the data layer upstream of it is. I build that layer for a living. Worth a 30-minute look at your stack? → Book a call.

Like the cut of this?

I write about GTM infrastructure like an engineer, because I am one.

Book a 30-minute stack review

← Back to all writing