The Tuesday afternoon test
A claims handler with forty-one items in her queue and a call waiting will not explore your assistant. She will use it if it makes the next ninety seconds easier and abandon it permanently if it costs her two minutes once. That is the entire adoption problem, and it is not solvable with training material.
We have started running a specific exercise in week one of any rollout: sit next to three people during their worst hour of the week and watch what they do. Not a workshop, not a survey. On one deployment that hour explained a twelve per cent usage rate in about four minutes — the assistant lived in a separate tab, and switching tabs meant losing the position in the queue.
People do not abandon a tool because it is worse than the alternative. They abandon it because it cost them time once, on a day they had none.
Six patterns that held up
These are the ones that survived across five deployments in different industries. None of them are novel; all of them get skipped under delivery pressure.
Training is what you do when the design failed
I am wary of writing this because it sounds glib, but the correlation is hard to ignore: the deployments that needed the most enablement material were the ones with the worst interfaces. A well-placed assistant needs about one sentence of explanation. A badly placed one needs a deck, a champions network and a monthly nudge, and it still stalls at twenty per cent.
That does not mean skip enablement. It means read heavy training requirements as a design signal. When someone asks for a forty-minute session on how to phrase requests, the honest response is to fix the phrasing problem in the product.
Weekly returning users, not queries
Query volume is the vanity metric of this field. It spikes on launch, spikes again after any all-hands mention, and tells you nothing about whether the tool has entered anybody’s routine. We track weekly returning users as a share of the eligible population, and depth per user — whether people who came back once are now using it for three things.
The second number is where the interesting failures show. A steady population using one narrow feature usually means the assistant solved exactly one problem well and the rest of it is invisible. That is a discoverability issue with a specific fix, and you would never see it in a query count.
Query volume measures curiosity. Weekly returning users measures whether the thing became part of somebody’s job.
What the first ninety days should contain
Pick one workflow and one team, ideally a team with a visible pain and a manager who will say so publicly. Instrument abandonment before you instrument anything else — where people stop mid-interaction is the highest-value data you will get, and almost nobody captures it.
Then ship weekly, visibly, in response to what those users said. The credibility that buys is worth more than any feature on the roadmap. Teams that see their own complaint fixed in seven days become the reason the second department asks for access, and that is the only adoption engine that has ever worked for us.
The pattern behind the patterns
Every one of these comes back to the same thing: the assistant was designed for the demo, where someone has time and goodwill, instead of for Tuesday afternoon, where they have neither. Design for the bad day and the good day takes care of itself.
Bring us into a rollout