Four Months of Production Data: What Adoption Actually Looks Like
Across the first four months of a system running a real operation, activity went from 828 actions to 9,689 while users went from 5 to 20 — twelve times the work at the same effort per person. Two of the three most useful findings would have been invisible to anyone who shipped it and left.
The shape of the four months
| Month | Total actions | People |
|---|---|---|
| One | 828 | 5 |
| Two | 1,462 | — |
| Three | 5,182 | — |
| Four | 9,689 | 20 |
Twelve times the activity. Four times the people. Actions per person: flat.
Twelve times the work at the same effort per person. That is the entire argument for building it properly.
36% of everything was somebody looking something up
Over a third of all activity was retrieval — finding out a price, a status, a history, a rule. Not creating anything, not deciding anything. Finding out.
The important part is what that activity replaced. Before the system, each of those was an interruption to whoever knew the answer. Search that answers a simple question is not a convenience feature; it is the removal of a tax on the most experienced person in the building, and it was the single largest category of use.
62% of activity came from one person
Adoption is never even. One person accounted for nearly two thirds of everything.
The consequence is design-level. Build for the average of that distribution and you are building for somebody who does not exist. The heavy user needs speed, keyboard paths and density. The occasional user needs obviousness and forgiveness. Averaging the two produces an interface that serves neither, which is how a system ends up used by exactly one enthusiast.
Money changed what was allowed to stay probabilistic
The system did work that touched commission. The moment it did, that path had to become deterministic — not because the AI was inaccurate, but because a number affecting someone's pay has to be reproducible and explainable, by a human, months later.
The workable division was narrow and worth stating plainly: the AI explains and flags; it does not decide. Anything touching pay, price or contract stays deterministic and auditable. Judgement, drafting and summarising can be probabilistic because a person reviews them before they count.
Why none of this comes from shipping
All three findings arrived from operating the system, not from building it. Nobody predicts that a third of usage will be lookups, or that one person will carry two thirds of the load, or exactly where the line between probabilistic and deterministic has to fall. Those come from watching real traffic for months.
That is also the argument for staying on after launch. The specification tells you what people said they would do. The activity log tells you what they did.
What to instrument from day one
- Every action, with who and when. Cheap on day one, impossible to reconstruct later.
- Per-person totals, not just totals. The distribution is the finding; the sum hides it.
- Absence, not just errors. A job that stopped three weeks ago without throwing anything is the failure nobody reports.
When this does not apply
These numbers come from one system in one industry with twenty users. They are a demonstration of what operating data reveals, not a benchmark to compare yourself against. The transferable part is the method: log everything from the first day, read the distribution rather than the total, and be suspicious of any figure that only makes sense as an average.
Which rung is your system actually on?
The Platform Readiness Review is seven days and $2,500. A map of what you have built, where the core-versus-configuration boundary really falls, the assumptions that break when a second business signs, and a 90-day plan including what to postpone. If it is not ready to be productized, we say so and you keep the map.