The numbers below come from an illustrative composite drawn from several firms, not a single client. The pattern is real. The figures are there to make it countable.
Thirty-eight quotes in a spreadsheet
Picture a mid-sized building-materials distributor in Beirut. Three weeks ago it launched an AI tool that drafts customer quotes. The launch dashboard looks excellent: every member of the sales team has logged in, and most of them logged in several times.
Then the owner asks a different question. Of the last 120 quotes that went out, how many were built in the tool? The answer is 82. The other 38 were built in an Excel sheet pinned to the sales manager's desktop, the same sheet the tool was bought to replace.
The owner now has two options. The first is a mandate: from Monday, every quote goes through the tool. It is cheap this afternoon, takes one message, and will produce a better-looking dashboard by Friday. The second is a diagnosis: find out why 38 quotes went around the tool, and fix what the answer says. It costs a few hours a week for a month.
In the launches I have watched, the mandate nearly always wins, and nearly always produces the same result. The quotes move into the tool on paper while the real work moves to a private sheet, a phone note, or a message to a colleague. The leak does not close. It goes out of sight.
Why a workaround is a requirement in disguise
A staff workaround is a job the tool does not do. Nobody builds a side spreadsheet for fun. Someone builds it because a customer, a supplier, or a habit forced a step that the official system could not handle, and the deadline was that afternoon.
In a quoting tool, the usual jobs hiding inside a side sheet are easy to name. A long-standing customer has a discount tier that was agreed by handshake and exists nowhere in the system. A supplier changes a price by phone in the morning, and the catalogue will not reflect it until next week. A salesperson converts between pallets, bags, and square metres in their head, and the tool asks for only one of them.
Each of these is a requirement, written by the people who know the work best, in the most honest form available: behaviour. It is cheaper than any workshop and more truthful than any survey, because nobody is trying to be polite to it.
This is why I distrust login counts. A login shows that someone had access. It says nothing about whether the finished output passed through the tool. Output share is the measure that matters: of everything we sent out, what fraction was made where we said it would be made?
If you have already handed the tool to its operators with a proper package, that is a separate and earlier job, and I wrote about it in the handoff nobody documents. This post is about what comes after go-live, when you read what the staff actually do. The wider point, that a launch succeeds or fails in its final stretch, is the subject of the last mile is the strategy.
The five-step workaround audit
You need a notebook, one afternoon a week, and no technical skill. I run it for thirty days after go-live, on one team at a time.
- Find the leak. For one week, count the finished outputs (quotes, replies, reports) that did not pass through the tool. Look for a number, not a feeling. "Some people still use the old sheet" is a feeling. "38 of 120" is a number you can improve.
- Sit beside, do not survey. Ask three people to show you the last thing they made the old way, and watch it happen. Look for the step they refuse to give up, because that step is usually the missing feature.
- Name the job. Write each workaround as "I use X because the tool cannot Y," in the staff member's own words. Look for sentences that repeat. Workarounds cluster, and two to four root causes usually explain most of the leakage.
- Sort into three bins. Each item either gets added to the tool, changes the process, or is left alone on purpose, with a written reason. Cap the list at three fixes per fortnight. Look at your team's real capacity to change, not at the length of the list. In a small firm, three fixes that land beat fifteen that half-land.
- Re-measure the leak. Count again at day 14 and day 30, using the same method as step one. Retire the side sheet publicly only when its share is close to zero, and say so to the team, so nobody has to guess whether it is still allowed.
What the audit found in the composite
In the distributor's case, sitting beside three salespeople took one afternoon, and the story was short. The sales manager's sheet did three things the tool did not. It carried customer-specific discount tiers. It let her type in a supplier price that had changed that morning. And her quotes took four fields, where the tool's first screen asked for nine.
The three fixes followed directly. The tier discounts were pre-loaded into the tool. A "price changed today" override field was added, with an expiry so that a one-off figure could not quietly become the permanent price. The first screen was cut from nine fields to four, with the rest moved behind an optional section.
In this illustration, side-sheet use fell from 38 of 120 quotes to 9 of 120 by week 6. The remaining nine were mostly unusual jobs that the team decided, deliberately, to keep outside the tool for now. That is an acceptable result, because it is a decision and not a leak.
Notice what did not happen. Nobody was told to try harder, and nobody needed more training. The tool got closer to the work.
What not to do
Three habits undo the audit before it starts.
- Do not ban the spreadsheet on day one. The sheet is carrying real work. Remove it and you remove the evidence, and the work goes somewhere you cannot see.
- Do not count logins. They will reach 100 percent in the first week and tell you nothing after that.
- Do not ask "why aren't you using it?" People answer that question defensively, or with whatever sounds reasonable. Ask "show me the last quote you built" and let the screen answer.
There is a quieter point under all three. When a workaround is treated as a discipline problem, staff learn to hide it. When it is treated as a requirement, staff learn that pointing at a gap gets the gap fixed, and they start to tell you about the next one before it grows.
Where to start this month
Pick one team that has launched, or is about to launch, a new tool. Count the leak this week, and ask to see the last thing built the old way. You will know within days which three fixes decide whether the launch survives.
I write about this stage of adoption in my books, Applied AI and The E-mployee Operating Model.
Related evidence: The Hidden Technical Debt in Machine Learning Systems paper argues it is dangerous to treat quick machine-learning wins as free, and names ongoing maintenance risk factors including boundary erosion, entanglement, hidden feedback loops and undeclared consumers. (the Hidden Technical Debt in Machine Learning Systems paper)
The Stanford Digital Economy Lab reports that employment declines are concentrated in occupations where AI usage primarily substitutes for human tasks, while employment is flat or rising where AI usage primarily complements workers, and the authors present these as early descriptive indicators rather than causal estimates. (Stanford Digital Economy Lab employment research)
