An AI sales development representative is sold as an employee. That framing is the source of most of the disappointment in the category, because it invites the buyer to compare the software to a person and then to feel cheated when it turns out to be software.
A more useful question is which parts of the SDR job are actually being automated. The job is not one thing. It is roughly eleven tasks with wildly different amounts of judgement in them, and a language model is excellent at some, useful with supervision at others, and structurally incapable of the rest.
Here is the breakdown, with the reasoning for each call.
The SDR job, broken into eleven tasks
- Building the target list
- Researching an account before writing
- Deciding the angle for this specific account
- Writing the first email
- Writing follow ups against what happened
- Scheduling and timing the sequence
- Handling a simple reply, such as a scheduling request
- Handling a real objection
- Qualifying: deciding whether this is worth anybody's time
- Logging what happened into the CRM
- Knowing when to stop
The four that automate cleanly
Researching an account. Reading everything connected, extracting what is relevant, keeping the source line for each fact. This is retrieval and summarisation, which is what these systems are genuinely good at, and it is the single largest time sink in the job. One caveat that decides everything downstream: the research is only trustworthy if a fact without a source stays empty instead of being filled in with something plausible.
Writing the first draft. Not the final email, the draft. A structured, correctly lengthed, appropriately toned first version. This has been solved for a while, and it is also the least valuable of the four, because the draft is not the hard part. Deciding whether what it says is true is the hard part.
Scheduling and timing. Purely mechanical. Send at a sensible local hour, widen the gaps, stop on reply, stop on bounce, respect the cap. There is no judgement in any of it and it is the part humans do worst, because it depends on remembering something four days later.
Logging to the CRM. The activity is derivable and the note is derivable from the thread. This is covered in more detail in our piece on CRM data entry, but the short version is that the note automates well and the judgement fields do not.
The four that are assistable
Meaning: a machine can produce a good first version, and a person has to remain accountable for it.
Choosing the angle. A model can propose an angle from what it found, and it will often propose a reasonable one. It cannot know that this particular buyer has been burned by exactly this pitch before, or that their competitor just bought your product and mentioning it would be a mistake. Angle selection is where product knowledge and market context live, and neither is in the training data about this account.
Follow ups. Assistable, with a specific condition: the follow up has to be written against what actually happened in the thread, not generated from a template with a slot. A model that can see the thread writes a decent step two. A model filling a template writes the invented consensus, because a slot has to contain something.
Simple replies. "Can we do Thursday instead" is safely handled by software. The problem is that no classifier is perfect at distinguishing a simple reply from a complicated one, and the cost of the two errors is asymmetric. Handling a complicated reply as though it were simple is how you lose a deal to a machine's cheerful non sequitur. Default to handing replies to a person.
Building the list. Filters, firmographics and signals are mechanical. Deciding that a segment is worth attacking at all is a commercial judgement, and it is usually the highest leverage decision in the entire function.
The three that are not
Handling a real objection. A prospect who says "we tried something like this in 2024 and it did not stick" is not asking for information. They are testing whether you understand why it did not stick. That conversation requires knowing things that are not written down anywhere, and getting it wrong in an automated reply is worse than not replying at all.
Qualifying. Qualification is a person taking responsibility for an opinion about whether this is worth pursuing. A model can score fit against criteria you defined, which is useful, and that score is a prompt for a decision rather than the decision. The moment a machine's fit score silently removes accounts from the pipeline, you have automated your own strategy without noticing.
Knowing when to stop. Not the mechanical stop conditions, which automate perfectly, but the judgement one: this account is polite and going nowhere, this thread has become a nuisance, this person is interested but at the wrong time and should be left alone for six months. Getting this wrong is how a sequence generates complaints, and it is exactly the judgement a system optimising for activity does not have.
What that means for headcount
Four automatable, four assistable, three not. That is not a person replaced. It is roughly the front half of the job, and it happens to be the half that consumes the most hours and produces the least differentiation.
The honest framings, depending on where you are:
- No SDR yet. You get pipeline you would not otherwise have, at a cost far below a hire, and you personally remain the qualification and objection layer. This is the strongest case.
- One or two SDRs. They stop spending mornings on research and first drafts and start spending them on conversations. Output per person rises. Headcount does not fall.
- A large SDR team. The gain is consistency more than time: every draft checked the same way, every note written, every sequence stopping when it should. That is a quality argument, and it is a much better one than the cost argument.
Anyone selling you the fourth framing, that headcount goes to zero, is describing the demo rather than the job.
How the category usually fails
Three failure modes, in the order you will encounter them.
Confident wrongness. The agent writes something specific and untrue about an account, it goes out, and the buyer notices. This is not a rare edge case. It is the expected behaviour of a system that must produce a sentence for every slot and has incomplete information about most accounts. The only structural fix is for the system to be allowed to say it does not know, and for a claim without a source to stop the send rather than soften it.
Volume without a ceiling. An agent given a target rather than a cap will pursue the target. If the target is meetings and the lever is volume, the volume goes up until something breaks, and the thing that breaks is the sending reputation of the domain your invoices go out from.
No record. Three months in, somebody asks what was sent to a specific account and why. If the answer requires reconstructing it from a mail server and an activity log, you do not have an audit trail, you have archaeology.
What to buy, and in what order
If you are evaluating the category, the order that saves the most money is:
- Fix activity logging first. It is cheap, it is boring, and everything downstream reads from it.
- Automate research and first drafts, with the source requirement in place. This is the largest time saving available and the easiest to verify in a trial.
- Automate follow ups only once you have watched a few weeks of drafts and trust what they contain.
- Automate replies last, if at all.
Our own version of that first pair is on the sales automation tools page, and the reasoning behind holding a draft rather than sending it is on how it works. The short version of this entire article: automate the research, supervise the writing, and keep the judgement.