AI adoption stalls after launch because go-live is the day the project team stops watching the tool, and the tool still needs watching. Five things then go wrong. The tool sits outside the daily workflow. Nobody owns it. Exceptions have no route to a person. Nobody counts how often it is used. The first wrong answer goes unexplained. Each of the five shows up in a weekly number long before anyone says the tool has failed.
This note is for an owner or department head who rolled out an AI tool and now watches usage drop. It covers chat assistants and agents that work through a queue of cases, because the causes are the same for both. The company below is invented. I have no client projects to show yet and I won't make one up. I also quote no adoption statistics. A percentage without a year and a sample behind it tells you nothing about your company.
What does an AI tool nobody uses after launch look like?
Take an invented freight forwarder with 45 staff. Its dispatch team answers about 400 shipment status emails a week. An agent drafts the replies from the tracking data, and a dispatcher reads each draft before sending it. The drafts appear in a web console that came with the tool.
In the first week after go-live the dispatchers open 290 of the 400 drafts and send 230 of them. In week four they open 110 and send 70. Nobody decided to stop. The agent drafted 400 replies in both weeks, so its own dashboard shows no change. The drop is only visible in the count of drafts opened and sent, and nobody was looking at that count.
Why does usage fall in the weeks after go-live?
Because several conditions that held during the project end on the same day. During the pilot someone reminded people to use the tool and fixed the odd cases by hand. After go-live that is nobody's job.
The tool sits outside the daily workflow
The dispatchers work in their mail client. The drafts sit in a second browser tab. On a calm day, opening the tab costs ten seconds. On a day with a truck stuck at the border, nobody opens it. A habit that breaks on a few busy days in a row does not come back on its own.
The fix is to put the output where the work already happens. A draft belongs in the mail client, as a draft. A proposed value belongs in the field of the ERP screen where the clerk would have typed it. If the tool you bought can't do that, treat the extra tab as a cost and count it.
Nobody owns it after the project team leaves
A project has a lead and a weekly meeting. Both end at go-live. The lead moves to the next project. IT keeps the server running, which is a different job from keeping the tool useful.
So when a dispatcher asks why the agent promised a delivery date the carrier never gave, there is nobody to ask. The tool needs one named person in the department who may change its rules and has an hour a week in the calendar for it. What that person needs in hand is in what a handover contains. The short version is instructions in files the team can edit, with a record of which version produced which answer.
Exceptions pile up without a route to a person
The agent handles the standard shipment well. Then comes a split delivery, or a consignment held at customs, and the draft is vague or wrong. The dispatcher can't tell in advance which drafts are the odd ones, so she starts checking every draft against the tracking system. From then on the draft saves her nothing, and she stops opening it.
A tool earns trust when it says "I can't place this one" and hands the case to a named person with the reason attached. How to build that route, and how to keep it from turning into a second inbox, is in designing an escalation queue.
No one measures use
The vendor dashboard counts what the tool produced. It does not count what people did with the output. Without a weekly count of drafts opened and sent, the drop from 230 to 70 stays invisible. The owner hears about it months later, when someone mentions in a meeting that they stopped using the thing a while ago.
The first wrong answer goes unexplained
One wrong answer gets retold at lunch. A hundred right ones do not. That does little harm if someone can say within a day why the tool answered that way and what was changed. If nobody can, the team's summary becomes "it makes things up", and a summary like that outlasts the bug.
The explanation needs a log that shows what input the tool had for that case, and a person who reads it. Then the fix has to reach the same people who heard about the mistake.
How do you see early that an AI tool is going unused?
Look at four numbers every week, for one workflow at a time.
- Share of cases that went through the tool. Cases where a person accepted the tool's result, divided by all cases of that type. Take the total from the system of record and not from the tool, the way I describe in counting where a week goes. For the forwarder that is 230 of 400 in week one and 70 of 400 in week four.
- Share of outputs used as they came. Of the drafts people opened, how many went out with small edits or none. For the forwarder it falls from 230 of 290 to 70 of 110. A falling share points at quality or at exceptions.
- Open exceptions and the age of the oldest one. If the oldest unanswered exception is nine days old, the route to a person is broken.
- Days from a reported wrong answer to its explanation. Count from the report to the day the team heard what was changed.
Read them as a trend over four weeks. A single week tells you little, because a holiday or a quarter end moves every number. I give no target values, because the right level depends on the workflow. A share that falls three weeks running is the signal.
Count per workflow and per team. A ranking of who used the tool how often turns a usage count into monitoring of individuals, and people who feel watched avoid the tool for that reason alone.
What should you do in the first 30 days after go-live?
Days 1 to 7. Name the owner and tell the team who it is. Say where a wrong answer gets reported, and make that one place. Start the weekly count with the four numbers above. Then sit next to two people for an hour each and watch at which point of their work the tool comes in, or doesn't.
Days 8 to 14. Fix the largest reason people bypass the tool. The hour of watching will have shown it. If it is the extra tab, move the output. If it is one type of case the tool gets wrong, take that type out of scope for now and say openly that people handle it by hand.
Days 15 to 21. Go through every exception and every reported wrong answer with the team, on the real cases. Three weeks in, people have questions they could not have had before go-live, which is why the handover note puts its second workshop at this point. Change the rules that turned out too strict or too loose, and tell the team what you changed.
Days 22 to 30. Put the four weeks of numbers side by side and decide. If the share of cases through the tool is steady or rising, keep the scope. If it falls, narrow the scope to the slice the tool handles cleanly and leave the rest with the people who already do it. Write the decision down with the numbers, so the next review starts from a record.
What if the tool has already stalled?
Skip the relaunch meeting. A second announcement without a change confirms to the team that nothing changed.
Ask five people who stopped using the tool for the last case where they tried it and gave up. Sort the answers by the five causes above and fix the cause with the most answers. Then restart with a narrow slice of cases and the weekly count from day one.
If the answers themselves were wrong, put the tool back into shadow mode for that slice. It keeps doing the work and writes nothing. You compare its output with what your people did before you switch it on again.
Sometimes the finding is that the workflow was the wrong one to start with. It has too few cases a week, or too many of them are odd. Then the tool should go, and ranking what to automate first is the better use of the next month.
Bring four weeks of numbers to a scoping call
If you have a tool that stalled, bring the four numbers for the last four weeks, or as many of them as you can get, to a thirty-minute scoping call. Add five cases that people handled by hand although the tool was there. On the call you describe the work your team does by hand, and we ask which systems it passes through and how often it runs. You leave with our opinion on whether agents help here. If the answer is no, you hear it on the call.
Our agent build takes one workflow from shadow mode into production on the software you already run.