ChatGPT
Claude
Google AI
Copilot
A sales agent that drafts follow-up emails usually passes its build review and then shows a flat usage chart. The build was fine. The reps write follow-ups from their phone between meetings, and a well-grounded draft sitting in a CRM tab they open twice a day does not change that.
This is the pattern that separates sales deployments from service ones, and it is not a technical difference. Service agents fail on knowledge quality: the answer is wrong, contradictory or missing, and the remedy is remediation you can scope. Sales agents fail on adoption: the answer is perfectly good and nobody asked for it. Both arrive at a steering committee looking like a failed AI project. Only one of them is.
Sales candidates need a fourth test
Scoring an Agentforce candidate normally runs on three axes: business value, data readiness, and the cost of being wrong. That holds up well for service, where the agent runs in a channel the customer is already using and the binding constraint is whether the correct answer can be retrieved. The full version of that scoring is in Agentforce use cases that survive a business case.
Sales needs a fourth axis, and it vetoes as hard as the other three: workflow fit. Is this where the rep actually works?
The question sounds soft and is not. It has a factual answer you can obtain in an afternoon by sitting behind three reps and watching. Where do they read email. Where do they take notes. What do they have open during a call. What do they do in the twenty minutes before a first meeting, and what do they do in the ten minutes after. A capability that lands inside those surfaces gets used without a change programme. A capability that requires a rep to navigate somewhere else, at a moment when they were not already navigating, does not, and no amount of enablement fixes it.
What genuinely helps
The wins share one property. They remove work the rep is already doing rather than adding a task, and the rep can tell within a single use whether it saved them time.
Call preparation. Before a meeting a good rep spends fifteen to thirty minutes assembling context: the last three interactions, open cases, what was promised, who else at the account has been active, what changed since the previous conversation. That assembly is retrieval across records the organisation already holds, which makes data readiness high by construction. It is also the most consistent adoption success we see, because the rep asks for it at a moment when they are already looking for exactly that information.
Research summarisation. Long email threads, meeting transcripts, and multi-year account histories are all cases where the rep needs the shape of something rather than the whole of it. Summarising is forgiving, because the rep reads the summary against material they partly know, and a slightly imperfect summary is still faster than reading forty messages.
CRM hygiene. Proposing updates from activity that already happened is genuinely valuable and quietly political, which is why the next sections deal with it separately. The safe version is narrow: log the activity, attach the contact, fill the firmographic gap, flag the opportunity with no activity in three weeks. None of that is a number anyone defends in a review.
Follow-up drafting. This one works or fails entirely on placement. A draft that appears where the rep composes email is used. The same draft, produced to the same standard, sitting on a CRM record the rep visits after the email has already gone, is not. Salesforce sets out the capability well in its AI sales agent guidance, and the guidance is not the hard part. Placement is.
What reps route around
The failures are more consistent than the successes, and they fall into a small number of recognisable shapes.
| Pattern | What it looks like | Why reps drop it |
|---|---|---|
| Adds a step | A new tab, screen or approval before the work can proceed | The rep can finish the task without it, so they do |
| Writes to a measured field | Stage, close date, amount or forecast category changed automatically | The rep now audits every record instead of trusting any |
| Wrong surface | Correct output produced somewhere the rep is not | Never encountered, so never evaluated |
| Asks for input first | The rep must supply context before getting value | The context assembly was the work being avoided |
| Slower than the habit | The draft takes longer to fix than to write from scratch | Habit wins on the second attempt, permanently |
| Right answer, wrong moment | An insight delivered after the decision was made | Correct and useless, which reads as noise |
The third and sixth rows are the ones that surprise sponsors. A capability nobody encounters cannot be judged on quality, and a programme reporting carefully on output accuracy while adoption sits in single digits is measuring the wrong thing with great rigour.
Why "the rep can just check it" is not a control
This sentence appears in almost every sales AI design review, usually as the answer to a risk that has just been raised. It is not a control, for three separate reasons.
The first is economic. Checking costs attention, and attention is the thing the agent was supposed to save. If a rep must read a drafted email as carefully as they would have written it, the draft saved typing and nothing else. That is a real benefit and a small one, and it will not survive a busy quarter.
The second is behavioural. Review quality decays as accuracy improves. An agent that is right nine times out of ten trains the reviewer to skim, and the tenth case is the one that mattered. This is the same complacency problem that appears wherever a person is asked to supervise something usually correct, and it gets worse as the system gets better. A control that weakens as the underlying capability strengthens is not a control.
The third is structural. Review only works when the reviewer can see what changed and can tell right from wrong at a glance. A drafted email meets that bar: the rep reads it and knows. A silently updated close date does not. By the time it surfaces anywhere it surfaces as a fact in a pipeline report, and nobody is reviewing it as an agent output because it no longer looks like one.
Where the downside is real, the fix is not better review. It is either narrowing what the agent may do, or making the output land somewhere a human has to act on it anyway. A proposed change that requires one deliberate click is a control. A completed change with a notification is not.
Records reps are measured on
Sales data is political in a way service data is not, and this is the piece most often missed by teams arriving from a service deployment.
A case field is descriptive. It records what happened. An opportunity stage is partly a forecast commitment, and reps manage it deliberately: they hold a deal at an earlier stage because they do not want it in this quarter's number, or advance it because a manager asked. Whatever you think of that behaviour, it is real, and an agent that overwrites those fields from inferred signals is not correcting data. It is overruling a judgement the rep will be asked about on Friday.
The result is predictable and expensive. The rep starts checking every record the agent touched, which costs more time than the agent saves, and the trust loss generalises. Once a rep has decided the agent interferes with their pipeline, they do not selectively distrust the stage updates. They stop using the call preparation as well, and that capability was working.
The workable line is simple. Agents may write freely to fields nobody is compensated or reviewed on: activity logs, contact roles, firmographics, next-step text, engagement flags. Fields that appear in a forecast get proposals, not writes.
Where the capability should live
Placement is a design decision made before anything is built, and getting it right is far cheaper than the remedies people reach for afterwards.
If reps live in email and calendar, the capability belongs where those live, which in a Salesforce context usually means the integration surfaces of Sales Cloud rather than a record page nobody opens. If reps run their day from a list view, the capability belongs on the list view. If they work from a phone between meetings, a desktop-only experience is a decision not to be used before lunch, which is exactly when preparation matters.
The wrong answer is to build in the convenient place and then fund enablement to change where reps work. Enablement can teach a rep how to use something. It cannot make them navigate somewhere new at a moment when they are under time pressure and have an adequate alternative already open.
SDR agents and the volume trap
Prospecting agents deserve separate treatment, because they are the most heavily marketed sales use case and the one where the fourth axis behaves differently.
An outbound agent that researches, drafts and sends at volume does not have an adoption problem in the usual sense, because no rep has to choose to use it. The risk moves instead to error cost, and the cost is reputational rather than operational. A wrong service answer reaches one customer who is already in a conversation with you and has a reason to come back. A wrong outbound message reaches a prospect with no relationship, no context, and a low threshold for deciding your company sends careless email.
The pattern that works is narrow. Let the agent do the research and the drafting, which is where the time goes, and keep a person on the send for anything targeting a named account. The volume argument for full automation is real and it applies to segments where a poor first impression is genuinely cheap. It rarely applies to the accounts a sales team actually cares about, and those are the accounts the business case was written on.
Measuring whether it landed
Report usage before quality, because quality measured on an unused capability is a measurement of nothing.
The first number that matters is the share of eligible moments where the capability was used: calls with a preparation summary generated, follow-ups sent from a draft, proposed CRM updates accepted or dismissed. Then look at acceptance rate on proposals and edit distance on drafts, which together tell you whether the output is good enough to keep. A high acceptance rate with low usage means you built something good in the wrong place. Low acceptance with high usage means the placement is right and the grounding is not, which is a far easier problem to fund.
Track all of it by rep rather than in aggregate. Sales adoption is almost never evenly distributed, and the aggregate hides the pattern that explains everything: a handful of reps use it constantly, most tried it twice, and the difference between the two groups is usually how they work rather than how they feel about AI. The comparison between agent-led and rule-based approaches to the same tasks is set out in Agentforce versus Salesforce automation.
When adoption stalls
The instinct is to improve the agent. Better prompts, more grounding, a wider intent set. That is the correct response to a low acceptance rate and the wrong response to low usage, and confusing the two costs a quarter.
Go and watch three reps instead. Not a survey, and not a feedback session, both of which produce polite answers about wanting more training. Watch where the capability sits relative to where their hands already are. In most stalled sales deployments the answer is visible in under an hour, and it is a placement problem with a placement fix.
The harder case is a deployment that has already lost front-line trust, usually through an unreviewed write. That is recoverable, and it does not recover through improvement. Narrow the agent back to the capabilities reps liked, remove the offending write entirely rather than wrapping it in a confirmation, and let it run there while trust rebuilds. Sequencing and governance for that rebuild are covered in Agentforce implementation best practices.
The test that predicts the outcome
Sales AI is not held back by capability. Drafting, summarisation and retrieval all work well enough for this class of work, and sales automation has been narrowing the manual surface for years without needing an agent to do it. What decides the outcome is whether the capability appears in the path a rep was already walking.
So the most useful question in a sales AI design review is not what the agent should do. It is where the rep will be standing when it happens, and whether they would have been standing there anyway.
