Why New Systems Go Unused — and How to Fix Adoption

When people say a new business system "was introduced but isn't being used on the ground," this usually falls into one of two patterns. The first is hollow use: staff log in but only touch a fraction of the features, still relying on Excel or paper forms alongside the system. The second is abandonment: staff never log in at all and simply drift back to the old way of working.

The short answer is that the single biggest cause of poor adoption is doing nothing after go-live. A system rollout doesn't end at contract signing or acceptance testing — it only pays off once there is a deliberate plan and structure for embedding it in daily work. This article walks through why systems stop being used, then lays out concretely what to do before go-live, in the first 90 days after go-live, and once the system has settled into daily operations.

Adoption problems look different from company to company, but in practice they tend to trace back to a handful of recurring causes. The five most common are:

- Requirements defined without the front line: When the IT department or management sets requirements alone without incorporating input from the people who will actually use the system, the resulting screens and input fields don't match real workflows, and staff abandon the system as too hard to use
- Incomplete data migration: If migration from the old system or paper ledgers is incomplete, staff can't trust the numbers in the new system and keep double-checking against the old method in parallel
- Missing training: Handing out a manual without holding training sessions or setting up a place to ask questions means staff who get stuck on basic operations simply stop using the system
- Old methods left running in parallel: Unless the use of Excel or paper forms is explicitly retired alongside the new system, staff drift back to what they're used to, and the two methods keep coexisting indefinitely
- No clear owner: If nobody is assigned responsibility for driving adoption after go-live, problems that come up get left unaddressed and frustration on the ground simply accumulates

Missing training in particular is an easy cause to overlook, and as described in AI Adoption Failure Patterns: Six Common Ways Tools End Up Unused, it's a failure pattern that shows up regardless of what kind of system is being introduced.

Preparing for adoption can't wait until the system is finished — it's too late by then. From the kickoff stage onward, the people who will actually use the system on a daily basis need to be involved in defining requirements, and the screen design needs to be checked against real workflows.

At the acceptance stage, it isn't enough to confirm the system works to specification — it's worth also confirming that front-line staff can walk through a full set of operations using real business data. As explained in What Is "Acceptance Testing"? What to Check at Delivery, acceptance is both a contractual milestone with the development vendor and the last real opportunity to confirm the system is actually usable on the ground. If the underlying workflow itself is undocumented and depends on individual staff knowledge, it helps to run Digitalizing Manuals and Standard Operating Procedures alongside the system rollout, so operating instructions for the new system can be built on top of a properly documented process.

The 90 days immediately following go-live are the period that determines whether adoption succeeds or fails. Laying out what needs to happen at each stage helps prevent things from falling through the cracks.

Making a system stick requires a structure for the operating phase, separate from the project team that ran the rollout itself. At minimum, the following roles should be assigned:

- Adoption owner: Holds ultimate responsibility for adoption progress and reports it to management
- Department lead (a point person per team): Collects questions from staff and handles simple how-to questions on the spot
- Support contact: A single point of escalation to the developer or vendor
- Data steward: Regularly checks for data-entry rule violations and data quality issues

It also helps to start planning the adoption phase in parallel with the later part of the development schedule described in How Long Does System Development Take?, rather than waiting until after go-live to think about it.

Driving adoption comes with real costs. The figures below are rough guidelines only — actual costs vary by company size, system complexity, and the support provider.

These figures are only a general guide — actual costs depend on the scale of the system being introduced and the internal structure supporting it.

Adoption should be tracked with numbers rather than gut feeling. The most useful metrics include:

- Login rate: What share of intended users are logging in regularly
- Data entry / usage rate: Whether required information is being entered and updated on schedule
- Old-method survival rate: Whether Excel or paper forms have truly been retired, or are still lingering in pockets
- Support request trend: Whether requests, high right after go-live, are declining over time
- Error / rework rate: Whether data-entry mistakes and rework are trending down

- Did front-line staff take part in defining requirements?
- Did front-line staff walk through operations with real data during acceptance testing?
- Was training held for all users within two weeks of go-live?
- Is there a weekly (or more frequent) forum for handling questions?
- Has a clear deadline been set for retiring old methods (Excel, paper)?
- Has a single adoption owner been assigned?
- Has a department lead been appointed for each team?
- Is there a mechanism to review login and usage rates monthly?
- Is a 90-day adoption review scheduled?
- Is there a plan for individually following up with staff who are lagging behind?