Why your employees are not using the new system

A familiar scenario. A company signs a contract for a new system. Analysis, data migration, testing, training, handover. Six months later the sales rep is sending quotes from a personal Excel workbook, production keeps its schedule on a shared drive, and the accountant exports the data to process it somewhere else.

The system is running, the integrations are moving data, the supplier delivered what the brief asked for. It is still a failure. It simply does not show up as an outage, it shows up as silence.

Implementation is the moment the software runs. Adoption is the state in which the organisation uses it. Most of the value companies lose sits between those two points, and the budget rarely has a line item for it.

Why people are still working in Excel six months on

On go-live day, Excel beats the new system on everything the user actually cares about: no learning cost, instant feedback, any structure you like, mistakes that leave no trace. The new system offers consolidated data, an audit trail and visibility for management. Those are benefits for the company, not for the person who has to get the orders out by the end of the day.

The most useful diagnostic is a single sentence: if an employee needs Excel alongside the system in order to use the system, the problem may not be the employee. A shadow spreadsheet is not born of laziness, keeping it up to date costs time and carries risk. Anyone who maintains one anyway is arguing that the system on its own is more expensive than the system plus an extra spreadsheet. Every such file is a formal complaint about the interface and the cheapest user research a company will ever get.

In the 1989 paper that underpins the Technology Acceptance Model, Fred Davis writes that performance gains are often blocked by the unwillingness of users to accept and use the systems available to them. Across his two studies with 152 users, perceived ease of use came out as a likely cause of perceived usefulness: what is hard to operate does not look useful. The sample is small and the paper is old, so this is a direction of relationship rather than a prediction.

Adoption is the denominator of the return

The cost is fixed and known on the day of signature. The benefit appears only once somebody is genuinely working in the system. A system with zero adoption returns zero, whatever it cost. A system with half adoption returns less than half: the company pays for the licences and for maintaining the shadow processes at the same time, and it still has no single source of truth.

The 2026 ERP report from Panorama Consulting Group paints the same picture, drawing on a survey of 170 organisations with median annual revenue of $200.5 million. It finds that ERP problems most often come down to unclear process ownership, weak user adoption and a lack of alignment on goals. The real challenge is not choosing a supplier, it is getting the organisation to work differently once the system is live.

You can price that silence with a simple multiplication: time times frequency times headcount times cost. Take an operation that now takes longer in the new system than it did before, and multiply the difference by the number of repetitions per day, the number of people doing it and the hourly cost. The result is the sum the company pays every single day for one decision in the interface design, and it is also the ceiling on a sensible budget to fix it. I worked through the same arithmetic in the piece on why good design is not decoration, but a way for a company to save time and money.

Why bad internal software was tolerated for so long

Consumer software fights for every click, because the user can walk away. Internal software has a captive user and is bought by someone who does not work in it. The selection criteria are a feature matrix, price, references and integrations. Nobody adds a row to that scorecard for how long it takes a new joiner to enter their first order, and the supplier optimises for whatever gets scored.

Nielsen Norman Group describes complex enterprise applications as tools for the unstructured goals of highly trained specialists who invest a great deal of attention and time in their work, and who therefore need dependable undo and error recovery. It also points to the paradox of the active user: people start using something before they try to understand it. That is an argument against training as the main lever for adoption.

Change management, training and cognitive load

Change management prepares an organisation for a change in the way it works. It is not a mass email and a two-hour session the week before go-live. In a study with more than 2,600 practitioners, Prosci correlated the quality of change management with meeting project objectives: with an excellent programme, 88% of projects met or exceeded their objectives, with a poor one, 13% did. This is correlation rather than an experiment, but the gap is too wide to wave away. Meanwhile Panorama Consulting Group reports that fewer than a quarter of organisations described their focus on change management as intense.

The other half of the problem is cognitive load, the amount of mental resource it takes to operate the system. Nielsen Norman Group splits it into intrinsic load, which belongs to the task itself, and extraneous load, which consumes attention without helping anyone understand the content. Internal systems carry plenty of the extraneous kind: crowded screens, fields that make no sense for the role in question, labels lifted from the data model instead of the language the business uses. Training does not remove it, and the company pays for it again with every new hire. Design removes it once.

Writing in Harvard Business Review, researchers from Gartner report that the average employee went through ten planned company changes in 2022, compared with two in 2016, and replacing a legacy system is one of the change types listed. Your project is not competing with doing nothing, it is competing with nine other changes.

Resistance to change, or genuinely bad software

This is where companies make the most expensive mistake of the whole project. When people do not use the system, management reads it as resistance to change and applies more pressure and more training. If the software really is bad, pressure will not lift adoption, it will only push the shadow spreadsheets out of sight, and the company loses even the information that a problem exists. Telling the two situations apart is not expensive.

Where the resistance sits. If it is spread thinly across the whole company, it is probably about change. If it is concentrated in one role, it is about design: that role is the one whose workflow the system does not support.
How the objection is phrased. “I do not want this” is an attitude. “I cannot see where to record an order when the customer pays a deposit and the invoice goes to a third company” is a bug report.
Who is refusing. If it is your highest performers going back to Excel, the very people who would gain most from any speed-up, the attitude hypothesis is weak.
What time on task says. Measure the same operation before go-live and after it. If it now takes longer, the resistance is rational.

Nielsen Norman Group adds a counterintuitive finding: slips hit the people who perform a task routinely hardest, because well practised work receives less of our attention. It also offers a line worth pinning to the wall of every meeting about internal systems: if the error was that easy to make, the designer is to blame. A rise in error rates among senior users after go-live is not a signal about competence, it is a signal about the interface.

Design needs the users, not only their managers

A manager describes the process as it is supposed to look. The user knows how it actually looks. The difference is the exceptions: the customer who wants split invoicing, the supplier who sends a PDF instead of data. The happy path looks much the same everywhere. The money and the friction live in the exceptions, which the manager does not handle and therefore does not know.

McKinsey offers a figure from its survey of digital transformations: where employees themselves come forward with ideas about where digitisation could help, respondents are 1.4 times more likely to report success, and redefining roles and responsibilities in line with the goals of the transformation raises the likelihood of success by a factor of 1.5. Involving people is not a cultural gesture, it is a variable in the equation.

The method is cheap: spend half a day sitting next to people in different roles and watch where they hesitate and what they work around. None of it comes up in a workshop, because after a while nobody is conscious of their own workarounds.

The honest conclusion is often uncomfortable for the supplier. Sometimes the answer is to build nothing at all: retire the process, configure the tool the company already pays for properly, or buy two modules fewer. A marginal process with a handful of cases a month belongs in a spreadsheet with a named owner, because development would never pay for itself there. The order of the steps is not accidental: eliminate, simplify, automate, extend. Custom development earns its place where a process is a competitive advantage or a bottleneck, not wherever a spreadsheet happens to exist. I expanded on this in the piece arguing that a company is one product and every bad process is its technical debt.

Four design decisions that determine adoption

Progressive disclosure. The interface shows the common options first and makes the advanced ones available on request. Jakob Nielsen describes it as a technique that improves three of the five components of usability: learnability, efficiency of use and error rate. He adds a second principle: whatever sits on the initial screen is what the user will treat as important. The first screen is a statement about a company’s priorities, and most systems state that everything is a priority at once.
Sensible defaults. A default is a decision the company makes once, instead of everyone making it again on every record. A good default is not an empty field, it is the most frequently correct value. Nielsen Norman Group puts two further things in this category: showing back data the user has already entered, and labels taken from the language of the business rather than from database columns.
Error prevention. The interface should be designed so that the error is impossible, or at least not easy. Nielsen Norman Group recommends four strategies: helpful constraints, suggestions, good defaults and forgiving handling of input. An error caught at data entry costs a second. The same error caught at invoicing costs hours of someone’s time and a piece of the customer relationship.
Role-based interfaces. One database, different screens. A warehouse operative does not need to see margin, and every extra field is a burden on everyone who will not fill it in. Nielsen Norman Group points out that every user eventually reaches an efficiency plateau, where further use no longer lifts performance. Accelerators are what carry them past it: keyboard shortcuts, macros, gestures.

How to measure adoption

Adoption is not measured by the mood in the meeting. Define this set of metrics before go-live, so that you have something to compare against.

Adoption. The share of intended users who performed a key operation in the system during a given period. Not logins, because logging in is not work.
Active users over time. A peak after training followed by a decline is the profile of a system people tried and gave up on.
Time on task. For the most frequent operations, measured both before go-live and after it. It feeds straight into the multiplication above.
Error rate. Corrections, cancellations, manual interventions, documents that have to be redone.
Support tickets. Not the count, but the ratio between “I do not know how” and “the system will not let me”. The first is onboarding, the second is design.
Number of shadow spreadsheets. The most honest metric of all: a spreadsheet disappears only once the system is faster than it is.

These numbers set the cost of fixing the interface against the cost of the friction the company pays for every month. I used the same arithmetic to work out when a good internal system pays for itself sooner than a new hire.

A management dashboard and a working interface should not look alike

A dashboard answers the question of how we are doing. It is read, and it can afford a few seconds of loading. A working interface answers the question of what to do with this order right now. It is opened dozens of times a day, it is written into, and it needs speed, the keyboard and error prevention. Design them the same way and you end up with two mediocre products.

There is a political mechanism behind this as well. The dashboard is what gets shown in presentations, so it receives the design attention and the budget. The working screen is never shown, even though it is where the money is made and lost. Design budget should follow frequency of use, not the seniority of whoever is looking at the screen.

Key takeaways

Write the adoption target and the way it will be measured into the brief before you sign the contract. Without a usage metric, the supplier has no reason to address it.
Measure time on task for the most frequent operations before go-live. Without a baseline you can prove neither an improvement nor a deterioration.
Take an inventory of the shadow spreadsheets. Each one is a brief to fix a process or an interface, and a more precise one than anything a workshop produces.
Before the next training session, ask whether you are training people to do the work or to work around a bad interface. The first is an investment, the second is a recurring cost.
Before you commission development, check whether removing a step, simplifying the process or configuring a tool you already pay for would solve the problem. Diagnosis is cheaper than implementation.