Breakdown
Nobody Told Them What They Would Be Doing Instead
Quiet non-adoption may start as a scoping gap long before go-live.
When someone does the work the old way and then types the result into the new system, do not assume you have a training problem. One thing worth checking is whether anyone ever defined what their work should become once the system took over part of it.
You bought the system. Two training sessions, an email with the go-live date, a clean cutover on paper. Four months later the weekly numbers still arrive in your inbox as a spreadsheet attachment from the same person, and when you ask about it, they tell you yes, they are using the new system.
What is actually happening in that spreadsheet
They are using it. The record in the system is accurate and current. What is not true is that the system produced it. They pull the figures the way they always have, check them the way they always have, and then spend twenty minutes at the end of the week retyping the result into the new tool so the record looks right.
This person is not behind on training. Ask them anything about the new system and they will answer correctly, including the parts your operations lead is still fuzzy on. They are not being difficult, they are not slow, and they have never once pushed back in a meeting. They understood the tool. They understood it early, in the part that mattered to them.
A basic usage report may not tell the difference. Entering data into a system after doing the work by hand looks identical to adoption. Logins are steady, records are complete, the dashboard is green, and the work has not moved an inch.
The half of the decision nobody wrote down
Every implementation makes some decision about what the technology carries, whether anyone names it explicitly or not. That half gets written down carefully, because it becomes the requirements list, the scope, the invoice. The other half of the same decision is what the person carries afterward, and that half tends to go unrecorded.
Say the weekly reconciliation was their job. Doing it accurately, catching the one figure that looked wrong, knowing which branch always reports late, that was a real part of why they were valuable here. Now the system does the arithmetic. What is the sentence that describes their work on Monday? Not a category like higher-value activity. An actual sentence, with actual work in it.
If nobody said that sentence out loud, the person is left to interpret what the change means for their role. Maintaining the old spreadsheet can become a rational hedge against a conclusion nobody has bothered to deny. It costs them a few hours a week and it keeps the part of the job that only they can do visibly alive. This is the same gap that shows up when the process lives in somebody’s head and was never written down, except here the person has a reason to keep it that way.
That is why this belongs in the scoping conversation rather than the change management one. Deciding what technology should carry and what stays with a person is not finished when you have listed the tasks moving over. It is finished when you can describe what the person does with the hours you just handed back.
What gets tried first
The standard sequence is another training session, then a named champion on the team, then a soft mandate that the spreadsheet is no longer the source of record. Sometimes it ends with removing access to the shared drive, which feels decisive.
None of those necessarily touch the underlying issue. Training explains the tool, but the tool may not have been the real source of confusion. Taking away the spreadsheet may remove the artifact without resolving the reason it existed.
The other move is to decide the software is the problem and start looking at alternatives. That happens more than it should, and it produces the same outcome twice, because the vendor was never the issue. It is worth noticing how closely this resembles a pilot that went well and changed nothing. In both cases the technology worked and the work stayed where it was.
How to check whether the answer exists
Do not start by asking the person why they will not let go of the spreadsheet. You will get a polite answer about wanting a backup during the transition, and it will sound reasonable enough to end the conversation.
Start with yourself and whoever sponsored the rollout. Write down, in one sentence, what this person does now that the system does the reconciliation. Then run three checks on that sentence. Is it specific work rather than a category. Does it use something they are genuinely good at. Would you be comfortable saying it to them directly, on Monday, without softening it.
If the sentence does not exist, stop treating this as resistance. You shipped a tool with an open question attached to it, and the person absorbed the question because nobody else would. That is a scoping defect, and it was present before go-live. It is the kind of thing a proper look at the work surfaces early, which is most of what clarifying the right path is for.
If the sentence does exist, say it. Then ask one question and let it sit: what would have to be true for you to stop keeping the spreadsheet. The answer may be surprisingly concrete. They do not trust the month-end figure yet. They still get asked questions the system cannot answer. Nobody has told them what happens to their role in the next budget.
Before the next tool goes in, name three things and write them down together: the work it absorbs, whose work that was, and what that person does instead once it works. The third one is easy to skip, and it can have an enormous effect on whether anything actually changes. Double entry is not always a symptom of poor training. It is what an unanswered question looks like on a dashboard that says everything is fine.
How we architect AI systems
How we architect AI systems
About the author
Missy Ross
Missy Ross is the Founder and AI Architect of Vero Dawn, an AI architecture and solutions company that helps businesses see what could work better, determine the right solution, and bring it to life. Before founding Vero Dawn she spent 21 years in internal audit across banking and manufacturing, at Audit Director level.