Deployed is not adopted
A platform gets bought. It gets deployed. It gets configured. It gets trained on. And then, six to twelve months later, a closer look reveals that a meaningful fraction of the team has quietly routed around it. They are using a shared inbox, an offline spreadsheet, a private CRM in their own head. The platform is technically live. Operationally, it has become a place where data goes to be officially recorded, not a place where work actually happens.
This pattern is not unusual. It is the default outcome of how most enterprise software is sold and implemented. The framing in the industry continues to centre on deployment, configuration, and feature parity, as if the journey ends the moment the system goes live.
We think it begins there.
How systems get rejected quietly
A system isn't usually rejected loudly. Almost no one in an organisation has the political budget to say, eight months after a major implementation, that the platform isn't being used. So the rejection happens in another form. It happens in workflow.
When a system requires too much friction to update, people update it less, and they make decisions on stale data. When a system imposes a logic that doesn't match how a particular team actually works, that team builds a parallel one. None of this is malicious. It is what competent people do when the system in front of them is in the way.
Over time, these workarounds harden. The system stays in place because removing it would be politically expensive. The workarounds stay in place because they are what actually keep things running. The organisation now has two systems: the official one in the dashboard and the real one in the heads and inboxes of the people doing the work.
This is what we mean when we say a system can be technically live and operationally invisible.
What adoption actually looks like
Adoption is a word that gets used loosely. In most vendor decks, it means logins. In most procurement reviews, it means contractual completion. These are proxies. They tell you something happened. They do not tell you whether the system is doing the work it was bought to do.
Real adoption is a different signal. It looks like a salesperson updating a deal stage during a customer call, not at the end of the week. A support team checking the customer record before responding, not after. A marketer trusting the segmentation data enough to launch a campaign on it without rebuilding the audience in a side spreadsheet. It looks, in short, like the system being where decisions get made, not where decisions get filed.
You can measure this. It just requires asking different questions. Not "did people log in", but "did people choose this system over the alternative they had two months ago". The answers tend to be more sobering than the dashboard would suggest.
Why this changes how we work
Adoptability isn't a feature you add. It is the result of decisions made before, during, and long after deployment. Most of those decisions concern fit, not function.
This is why we have always preferred proofs of concept to demos. A demo shows you what a system can do under controlled conditions. A POC shows you what it does inside the actual workflow of the actual team that will use it. The first is theatre. The second is evidence. The systems that survive the second tend to be the ones that get used a year later.
It is also why we treat adoption as the defining metric of whether a deployment has succeeded. Not the go-live date. Not the percentage of users trained. Whether the system has become how the work gets done.
The rest is just dashboards.
