AI SDR vs human SDR — what to automate and what to keep human

The useful dividing line is not repetitive versus creative work. It is reversibility: can a wrong output be taken back before anyone outside your company is affected by it? Building a list, enriching a record, deciding the send order and classifying an inbound reply are all recoverable — you fix them and nobody knew. Sending a message under a named person's signature, answering an objection and agreeing a commercial term are not. Automate the first group aggressively. Put a human on the second group, and be specific about where the boundary sits in your own process.

The SDR job is seven operations, not one role

The argument gets muddy because "SDR" is a job title covering work with wildly different risk profiles. Decompose it first and the automation question mostly answers itself.

• Source. Find companies and people who plausibly match a profile.
• Enrich. Attach the fields you will filter and personalise on — title, headcount, country, a verified address.
• Prioritise. Decide who gets touched this week and in what order.
• Compose. Write the specific first message to a specific person.
• Dispatch. Send it, at the right time, within whatever caps apply, across whichever channel.
• Classify. Read what comes back and sort it into replied, out of office, bounced, unsubscribed, not interested.
• Respond and commit. Answer the question, handle the objection, agree a time, say what your product does and does not do.

Four of these — source, enrich, prioritise, dispatch — produce artefacts that live inside your own systems until you choose to act on them. A bad enrichment is a row you delete. A bad priority order is a re-sort. Nothing has left the building.

Classify sits awkwardly in the middle: the classification itself is internal, but it usually triggers something external. Compose and respond are the two that put words under your name in front of a stranger, and respond is worse than compose because it happens inside a live conversation where the other person is paying attention.

If you take one structural idea from this: automation risk tracks the *externality* of the output, not the tedium of the input. The most boring task in the list — dispatch — is genuinely safe to automate. The most boring-seeming judgement — deciding a two-line reply is "not interested" rather than "interested but busy" — is where automated systems quietly destroy pipeline.

The two questions that decide every operation

For each of the seven, ask two things in this order.

Can the output be retracted before it reaches a person outside the company? If yes, automate it and check the results in aggregate. If no, you need either a human in the path or a constraint so tight that the worst output is still acceptable.

Does the output carry a named person's identity? A message signed by your head of sales is a statement by your head of sales. That is different from a form-letter notification, and recipients treat it differently — which is exactly why signed outreach works and why an automated signature is a liability rather than a convenience.

Applied to the seven, you get a clean split. Source, enrich, prioritise and dispatch: yes to retraction, no to identity, automate. Classify: yes to retraction, but the downstream action is not retractable, so automate the label and constrain the action. Compose: partially retractable if a person reviews the draft, and it carries identity, so draft automatically and gate the send. Respond and commit: neither retractable nor anonymous, so keep it human.

That is the whole framework. Everything below is what happens when you actually run it.

What the machine is genuinely better at, and it is not writing

The common claim is that AI wins on personalisation. The evidence for that is thin, and there is a more defensible claim available: AI wins on consistency under volume, which is a different property.

A person building a list applies the filter slightly differently at row 400 than at row 40. A person deciding "does this title match my profile" gets tired. A person choosing send order optimises for whoever they remember. Software does not vary, which means its errors are systematic and therefore findable. A human's errors are random and therefore invisible in aggregate.

This has a practical consequence worth planning around: when an automated pipeline is wrong, it is wrong the same way ten thousand times, so a sample of thirty rows will find the fault. When a human pipeline is wrong, a sample of thirty rows tells you almost nothing. Automate the operation, then audit the sample — that combination is stronger than either half.

Where automation is weakest is the thing it appears strongest at. A model given no specific context about a prospect will still produce fluent, confident, entirely generic prose, because that is what language models do with insufficient input. The fix is context, not model choice, which is the argument developed in full in writing AI replies that sound like you. Personalisation is a data problem wearing a writing problem's clothes.

Price both sides yourself, because the vendor comparison is not yours

Vendor pages compare an annual subscription against a fully loaded SDR salary and stop there. Build your own version, because the interesting costs are the ones neither column shows.

Here is a worked example. Every number in it is illustrative — substitute yours. Take a two-person founding team in India hiring their first SDR at ₹6,00,000 a year, plus roughly ₹1,00,000 of tooling and ₹40,000 of employer costs, giving about ₹7,40,000 fully loaded, or ₹61,700 a month. Assume a three-month ramp at 40% output. Over year one that is roughly ₹7,40,000 for about 9.6 months of full-rate output — an effective ₹77,000 per productive month.

Now the automated side. A subscription, model tokens, and the part everyone omits: review time. If a founder reviews 40 drafts a day at 45 seconds each, that is 30 minutes a day, about 11 hours a month. Price the founder's hour at whatever you actually believe it is worth and the review line is frequently larger than the subscription line.

Two conclusions fall out of that arithmetic and both are stable across most sets of numbers you might substitute. First, automation does not remove the human cost, it *relocates* it from composition to review, and review scales with volume just like composition did. Second, the cheapest lever is usually reducing how many drafts need review at all, not reducing the cost per draft. If you want to model the tooling half against your current stack, the outbound stack cost calculator does that part.

The five failure modes, and how each one is diagnosed

Every automated prospecting system fails in one of five ways. Each has a distinct symptom, and confusing them wastes weeks.

1. The filter is wrong, so the list is wrong. Symptom: replies say "you have the wrong person" or "we do not do that". Diagnosis: pull 30 enrolled rows at random and check each against the written profile by hand. If more than two or three do not match, stop sending and fix the filter. This is the most common failure and the cheapest to fix.

2. The context is empty, so the copy is generic. Symptom: high delivery, low reply, and drafts that read fine but say nothing specific. Diagnosis: take ten sent messages and count how many contain a fact that could only apply to that recipient. If the answer is under half, the model was given nothing to work with.

3. The classifier is over-confident, so conversations die silently. Symptom: pipeline that used to exist does not, and nobody can say when it stopped. Diagnosis: read a week of inbound labelled "not interested" by hand. This one is invisible in every dashboard, because a wrongly closed conversation looks identical to one that never existed.

4. The volume outran the reputation. Symptom: delivery falls even though nothing about the copy changed. Diagnosis: check authentication and complaint rate before touching the message. Google's bulk sender requirements, enforceable since 1 February 2024, ask senders of more than 5,000 messages a day to a Gmail address for both SPF and DKIM plus DMARC on the sending domain, and to keep the spam rate reported in Postmaster Tools below 0.3%. Microsoft applied a comparable bar to Outlook.com, Hotmail.com and Live.com from 5 May 2025, rejecting non-compliant high-volume mail with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Neither system cares whether a model or a person wrote the message.

5. Nobody owns the output. Symptom: the system runs, numbers appear, and no individual can explain any specific decision. Diagnosis: ask who reviewed the last hundred sends. If the answer is "the automation", you have a governance failure that will surface as a customer complaint rather than as a metric.

Autocloz's free plan covers 5 users and 10 mailboxes with warmup and DMARC monitoring included, and its AI runs on your own OpenAI, Anthropic or Groq key with no per-lead metering — start free if you want to run the split above on your own list rather than on a vendor's example.

What the shipped defaults say about where the line sits

Product defaults are an argument about risk, and it is worth reading them that way when you evaluate any tool in this category. Autocloz's email autopilot ships with automatic enrolment, automatic personalisation, mailbox rotation, a bounce-triggered pause and a send window all switched on — those are the reversible operations. The rule that would dispatch AI-written replies without a human reading them ships off, and so do the LinkedIn and calling channel automations, because a LinkedIn account restriction and a badly timed call are both hard to undo.

The caps that ship alongside them are the more honest control: 250 actions a day per workspace, a pause when bounces cross 3%, a 24-hour cooldown after a reply, and a 09:00–17:00 send window. A cap is a stronger safety property than a switch, because it bounds the damage of every rule at once rather than turning one rule off.

There is a limit worth knowing before you rely on that window. The quiet-hours evaluation resolves its timezone from the campaign override, then the workspace default, then the sending account's timezone — not the recipient's. A workspace set to Asia/Kolkata sending to California is quiet by its own clock and not by theirs. If you sell across timezones, segment by region and set the override per campaign rather than assuming the window follows the prospect.

Read the vendor's claim the way a regulator would

The AI SDR category makes strong claims, and at least one regulator has already treated such claims as actionable. On 25 September 2024 the US Federal Trade Commission announced Operation AI Comply, bringing five enforcement actions against companies it alleged had used artificial intelligence to further deceptive or unfair conduct — including DoNotPay, which the FTC said had advertised an "AI lawyer" without testing its output against a human lawyer's. Then-Chair Lina Khan's framing was that there is no AI exemption from the laws already on the books.

Three questions worth asking any vendor in this category, and worth answering honestly if you are the vendor:

• What exactly does the model decide, and what does a rule decide? Much of what is sold as autonomous is a filter with a language model attached to the last step.
• What happens when the model is wrong? If the answer is "it rarely is", the system has no failure design.
• Who is named on the message? If your domain and your employee's name are on it, the accountability is yours regardless of what generated it.

The comparison worth reading on the architectural difference between an autonomous agent and a human-gated one is on the Autocloz and 11x comparison, which sets out both designs rather than only one.

What changes between one person and ten

At one person, the human-in-the-loop design costs almost nothing, because the person reviewing is the person who would have written it. Review is faster than composition, so you are strictly ahead.

At ten, three things break that were invisible at one.

Review becomes a queue, and queues need an owner. Four hundred drafts a day across ten reps is nobody's job unless you make it somebody's job. The usual failure is that review quietly stops happening while the switch still says it is on. Putting every channel's replies in one shared inbox is the mechanical half of the fix; naming an owner is the other half.

Consistency stops being free. Ten people writing their own context paragraphs produce ten different products. Write the context once, at workspace level, and let reps add to it rather than replace it.

The caps become shared. A per-workspace daily cap divided across ten reps is not a per-rep cap, and the tenth rep to press send is the one who discovers this. Decide the split deliberately rather than letting arrival order decide it. The broader question of which automations survive a bigger team is worked through in the sales automation guide, and if you are still defining the role itself, what an SDR actually does is the better starting point.

What Autocloz does not automate for you

The limits here are deliberate and knowing them is what stops a surprise in front of a customer.

It does not send AI-written replies without a human click. The rule exists, it ships switched off, and turning it on is a decision you make rather than a default you inherit.

It does not decide who your customer is. The autopilot matches against a profile you write — titles, industries, locations, headcount range — and a vague profile produces a vague list. The matching is literal: industry is an exact string comparison, so "SaaS" and "saas" are different values, and a company row with no headcount recorded passes a headcount filter rather than failing it. Both behaviours are defensible and both will surprise you once.

It does not verify that what you told it is true. If the workspace context says something inaccurate about your pricing, every draft repeats it confidently. That paragraph is a source of truth you own.

It does not make a bad offer work. No automation, and no model, fixes a message going to people who have no reason to care. If reply rates are flat, the list and the offer are the first two places to look, and neither is a software problem.

And it will not tell you the reply rate you should expect, because no standards body publishes one and every figure in circulation comes from a vendor measuring its own customers. Build the instrument on your own sends instead; what counts as a good reply rate covers how to do that without fooling yourself.