RULE 01
The announcement is part of the scope
We now ask how, when and by whom the deployment will be communicated, and we help write it. If the answer is "in the monthly all-hands," we ask what else is on that agenda.
The agent hit every accuracy target we set. The reps stopped using it anyway. This is the deployment that taught us adoption is decided before the software is built.
Eighteen reps at a professional services firm. Call recordings going nowhere, CRM records written from memory on Friday afternoons, a sales director who could describe the problem precisely and had budget to fix it. On paper this was our best-qualified engagement of the year.
We built Call-to-CRM. Five weeks, on time. In shadow mode it extracted stage, next steps and objections at an accuracy the sales director described as better than what his reps were writing themselves — which, to be fair, was a low bar he set, not us.
Launch week went well. Draft acceptance hit 89% by week two, meaning nine in ten agent-drafted CRM updates were confirmed with no edit at all. Reps were saving somewhere around three hours a week each. Two of them said unprompted that it was the first internal tool in years that made their job easier.
By week six, two reps out of eighteen were still opening it.
Gradual decline suggests a product problem. A cliff suggests an event. This was a cliff, and it has a date.
In week four the company held an all-hands. Two things were on the agenda: a review of commercial headcount going into the next financial year, and a short celebratory update on the new AI tooling in the sales team. They were consecutive items. Someone senior, meaning it warmly, said the automation showed how much more the team could achieve at its current size.
That sentence was intended as praise. In a meeting about headcount, it was heard as a plan.
Nobody complained. Nobody raised a ticket. The reps simply went back to writing their own CRM notes — which, conveniently, is the version of the work that visibly requires a person. We didn't learn any of this from the client. We learned it eight weeks later from a rep who'd since left and had no reason to be diplomatic about it.
The uncomfortable part: the tool was working because it made the reps' output look effortless. In an organisation where effort was suddenly the thing being counted, that was a liability. The agent's success was the reason to stop using it.
It would be convenient to file this as a client communications failure. Three things were ours.
We scoped systems, data and accuracy targets in detail. We spent no time at all on how eighteen people would first hear about this thing. That's an omission, not bad luck — we'd deployed enough times to know the answer mattered.
Our champion was enthusiastic and had budget, which made him easy to work with and a poor proxy for the people who'd use it. The reps first encountered the agent as something already decided. That framing was set weeks before the all-hands.
We saw week five in the dashboard. We flagged it in a status update as a number requiring attention and moved on. What was needed was a phone call to three reps that afternoon. A falling adoption curve is not a metric to report; it's an alarm.
Every client since has been subject to these, whether they wanted them or not.
We now ask how, when and by whom the deployment will be communicated, and we help write it. If the answer is "in the monthly all-hands," we ask what else is on that agenda.
Not the department head describing their team's work. The people doing it, in the first Sprint session, before anything is designed. They also hear about it first, from us, in that room.
Every deployment now ships with a plain statement of what the system does not record, score or report on. Silence on that question is always filled with the worst available assumption.
Any week-on-week drop above a threshold means someone from our team speaks to three users within forty-eight hours. Usage data tells you that something is wrong and never what.
You cannot compel someone to use a tool that makes their work easier. You can compel attendance at training, you can put it in a process document, and people will still route around it if they believe it's aimed at them rather than built for them.
This is why we're wary of engagements where the executive sponsor is enthusiastic and the intended users haven't been consulted. That configuration produces a fast sale and a poor deployment, and we've now been on the wrong side of it.
It's also why we won't build rep scorecards or sentiment grading into a sales agent by default. Not because those things are always wrong, but because the moment a team suspects the tool is watching them, every other benefit stops mattering. If you want that capability, it's a deliberate decision you make and communicate — not a feature we quietly include.
The client, for what it's worth, never blamed us. They paid the invoice and the agent is still deployed, running on two people's accounts. Which is arguably worse than if it had broken.
We now raise the adoption question on day one, because of this deployment. If your situation has the same shape, we'd rather say so before you spend anything.