System adoption: why go-live is not the end
An internal system is only deployed when the numbers your leadership uses are born inside it. Go-live is where measurement starts, not where the project ends. Real adoption is measured with four indicators: active use per workflow, parallel work in spreadsheets, quality of the data being entered, and time until information reaches the decision-maker.
Why does "deployed" not mean "adopted"?
Because deployment is a technical milestone and adoption is a behavior. The system goes live on a date. The habit of working inside it, feeding it correct data and trusting what it shows gets built, or does not, over the months that follow. Most companies celebrate the date and never measure the behavior.
The bill for that oversight is high. WalkMe's 2026 global study, run with 3,750 executives and employees, calculates that companies lose 51 workdays per employee per year to technology friction, even with record investment in AI. These are tools that were paid for, deployed, and are now slowing the work down instead of speeding it up.
The most revealing part is the size of the leadership blind spot. In the previous edition of the same study, executives estimated an average of 37 applications in use across their organizations. The real figure, pulled from telemetry across 1.5 million users: 625. The people deciding on technology can see 6% of what the operation actually uses. Without measurement, the conversation about adoption is one guess against another.
And the guess tends to be optimistic. In Zylo's shelfware data, 53% of SaaS licenses go unused or see too little use to justify the spend, an average waste of USD 19.8 million a year across the organizations the company tracks. Half of what gets bought never turns into work.
What is the most reliable signal of low adoption?
The parallel spreadsheet. When someone on the team keeps their own tracker outside the system, they are telling you, through behavior, that the system lost a head-to-head contest: the official tool against one the user built in twenty minutes. No satisfaction survey delivers a verdict that honest.
The pattern is not limited to spreadsheets. Group chats carrying operational records, notebooks, email threads that function as forms — each one is a requirement the system failed to meet, with an address and an owner. The parallel tracker is the most legible artefact of the problem, but any workaround counts.
The wrong reading of that signal is to treat it as indiscipline. The right reading is to treat it as project information: the parallel tracker shows exactly which step of the flow the system does not solve, because that is where the user felt the need to build an alternative.
How do you measure real adoption with four indicators?
Measure behavior per workflow, not access per user. Four indicators are enough to start, and none of them requires sophisticated tooling.
First, active use per critical workflow. Do not ask how many people logged in. Ask how many of the month's orders, service tickets or support cases were recorded inside the system, end to end. The difference between those two questions is the difference between presence and work.
Second, the parallel-work rate. Count the trackers circulating outside: spreadsheets, chat groups holding operational records, notebooks, emails working as forms. Each one is a requirement the system did not meet.
Third, the quality of the data going in. Mandatory fields filled with "xxx", generic dates, duplicate records. When a user fills something in only so the system will let them through, they are performing a ritual, not recording the operation. Bad data going in today is a useless report six months from now.
Fourth, time to information. How long passes between something happening in the operation and it being visible to whoever decides? If the manager still calls to check the number before the meeting, adoption has not completed, however good the dashboard looks.
A hypothetical but realistic scenario gives it scale. A mid-sized distributor rolls out a service-ticket system. Three months after go-live, the access report shows 90% of the team logging in weekly and the project is declared complete. Measured per workflow, the picture changes: 60% of tickets are born in a chat thread and typed into the system at the end of the day, by a single person, with half the fields empty. The system has become a dead archive fed out of obligation. By the login indicator, a success. By the four indicators, a project that stopped halfway.
What do you do when the measurement shows low adoption?
Diagnose before you train. The common reflex is to respond with more training and more pressure, and that reflex almost always misses. In the same WalkMe study, 79% of executives declared themselves confident in their transformation targets while only 28% of employees felt adequately trained. The gap between those two numbers rarely closes with one more workshop, because the cause is usually not a lack of instruction.
The cause is usually design. A screen that asks for data in a different order from how the work happens. A mandatory field the operator has no way of knowing at the moment of entry. A process that works at a desk and breaks in the field, where there is no connectivity. These are architecture decisions, and that is why the sentence we repeat to clients applies here too: you do not have a technology problem, you have an architecture problem. A system designed from the real flow gets adopted without a campaign.
Two of our projects illustrate the point by contrast. In Reatop's hospital waste management system, recording happens where the work happens: a mobile app with offline use, because requiring a connection inside a hospital would be an invitation for the operation to go back to paper. In UniTrust's brokerage system, in production since 2022, adoption holds because the system evolves alongside the operation instead of freezing at the first day's design. And in the control system for a public transport operation, what blocked adoption was not a missing function, it was the interface: the existing platform was preserved and what changed was the experience of the people operating it every day. Rewriting from scratch would have cost more and solved less.
The practical path has three steps. Pick one workflow with low adoption and watch whoever operates it, at their workstation, with no slides and no judgment. Correct the system's design from what you saw, one change at a time, telling the person who asked for it. Then repeat the four indicators the following month, because adoption is a curve, not an event.
Frequently asked questions
My team resists change. Won't measuring adoption just confirm what I already know?
It will show you something more useful: exactly where the change loses to the habit. Generic resistance is not actionable; a specific step of the flow where 60% of the work escapes into a chat thread is. In practice, teams labeled resistant adopt the part of the system that works well and abandon the part that gets in the way. Measurement separates the two.
I can't justify time and investment in instrumentation right now. Where do I start?
With the four indicators on a single page, updated once a month, for one critical workflow. Counting tickets recorded end to end and listing parallel trackers takes hours, not a project. The return is having, for the first time, an adoption number to bring to leadership instead of impressions, and the ruler to know whether the next fix worked.
Won't measuring system usage feel like surveillance to the team?
That depends on what you measure and what you do with the result. Measuring a flow is different from measuring a person: the indicator is "how many tickets were born in the system", never a ranking of who logs in most. And the result has to come back as a fix to the system, not as pressure on an individual. When the first consequence of measurement is that the system becomes easier to use, the team starts pointing out the problems on its own.
The next step
If your system is past go-live and you cannot say, with a number, how much of the operation lives inside it, that survey is a good place to start. And if you would rather do it with company, the Operational Architecture Diagnostic is a 30-minute conversation where we map your critical workflows and where adoption is leaking. No commitment beyond the conversation: get in touch.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic