Why Software Fails After the Contract Is Signed

By Victor Hoang · Updated Oct 11, 2026

Think about the last software purchase that disappointed you. Was the product missing a feature you'd been promised? Or did it simply never become part of how anyone worked?

If you're honest, it's usually the second. The tool passed the evaluation, the contract got signed, a kickoff happened, and then the login count crept along for months while people kept doing the job the old way. Eventually someone asked in a budget meeting why you were paying for it.

Here's the position this piece argues, and you can push back on it: in most disappointing software purchases, the decision that went wrong wasn't which product to pick. It was what happened in the first 90 days after you picked it. Buyers pour weeks into feature grids and demos, then hand the rollout to whoever has a spare afternoon. That's backwards, and it's fixable.

A caveat before we go on. Nobody has a clean, universal measurement of "software purchases that failed because of adoption." What we do have is partial evidence, from vendors and researchers, that points the same direction. We'll use it carefully and say where it stops.

The Question Buyers Skip

Selection feels like the hard part because it's visible. There's a shortlist, a scorecard, a committee, and a decision. It produces a document and a signature.

Adoption is invisible by comparison. It's a hundred small choices: whether a manager opens the tool in the Monday meeting, whether the old spreadsheet gets switched off, whether the new field is required or optional, whether anyone is told what "using it" means. None of that shows up on a scorecard, so none of it gets owned.

The result is a pattern most operators have lived through. The buying committee disbands the day the contract is signed. The champion goes back to their real job. IT confirms the tool is provisioned. And the people who have to change how they work get an email. If you want to understand why a well-chosen tool still fails, start by asking who, by name, was accountable for usage on day 30.

Good evaluation still matters, and we've written about how to run proofs of concept that predict success. But a great POC only tells you the tool can work. It doesn't make anyone use it.

What the Evidence Does and Doesn't Say

Let's separate what's measured from what's repeated.

Unused software is common, according to vendors who sell to fix it. Productiv, a SaaS management company, analyzed nearly 100 million licenses over three years and reported that only 47% of SaaS licenses were used over a 90-day period on average, as covered by Help Net Security in July 2023. That's vendor data, and the coverage doesn't state how many organizations were in the sample. Zylo, another SaaS management vendor, reports in its 2026 SaaS Management Index that license utilization rose from 47% in 2024 to 54% in 2025. Again vendor-published, and the page doesn't state a sample size.

Read those two together and the honest summary is: by these vendors' measures, roughly half of paid licenses show little or no use, and the number is improving slowly. It doesn't tell you why, and it covers all licenses, including ones nobody ever needed.

Change management correlates with outcomes. Prosci's Best Practices in Change Management research, based on more than 2,600 change practitioners, found that 88% of projects with excellent change management met or exceeded their objectives, against 73% with good, 39% with fair and 13% with poor change management. Two cautions. This is a survey of people who do change management for a living, so it measures correlation, not proof that the work caused the result. And it covers projects generally, not software purchases specifically. Still, the gap between 88% and 13% is large enough to take seriously.

Be wary of the famous "70% of change efforts fail" number. McKinsey partners have cited it in interviews, but they attribute it to unnamed academic research, so there's no primary study behind it to point to. If a vendor deck quotes it, ask for the source.

Key Facts

• In Productiv's data (nearly 100 million licenses), 47% of SaaS licenses were used over a 90-day period, on average. Vendor-published, 2023 coverage.
• Zylo reports license utilization of 54% in 2025, up from 47% in 2024. Vendor-published, 2026 index.
• In Prosci's study of more than 2,600 practitioners, 88% of projects with excellent change management met or exceeded objectives, versus 13% with poor change management.

Five Ways Software Fails After Signature

When you look at where adoption actually breaks, it's rarely mysterious. Five patterns cover most of it.

1. Nobody owns the outcome. The buyer owns the contract, IT owns the setup, the department head owns the team. Nobody owns "60% of the team uses this weekly." Without a named person, the default owner is no one.

2. The old workflow is still allowed. If the spreadsheet, the inbox, or the legacy tool still works, people will keep using it. Switching costs are paid in effort, and the old way is already learned. A tool that adds a step without removing one loses.

3. The tool fits the demo, not the Tuesday. Real work has exceptions, messy data and deadlines. If the first week of use runs into a missing integration or a confusing screen, people give up quietly and don't tell you.

4. Training is an event, not a habit. A one-hour session at launch is forgotten by the third week. Usage sticks when it's tied to a recurring moment, such as a weekly review that's run inside the tool.

5. Leaders don't use it either. If the weekly report still arrives as a slide deck built by hand, the message is clear. People follow what managers inspect, not what they announce. Our guide to CRM rollout and adoption walks through this in a concrete setting, and the same logic applies to any tool.

Shift the Effort: From Feature Grid to Rollout Plan

You don't need to stop comparing features. You need to rebalance. A reasonable split for a meaningful purchase (this is a recommendation, not a measured benchmark) is to treat the rollout plan as a deliverable that must exist before signature, with the same weight as the pricing proposal.

Concretely, before you sign, ask the vendor and your own team for three things in writing:

• A named internal owner with time carved out, not "in addition to their day job."
• A description of what stops being done once the tool is live. Which spreadsheet, which meeting, which approval email goes away?
• A usage target for day 90, agreed by the buyer, the owner and the budget holder.

If a team can't answer those three, you haven't finished buying. You've finished shopping.

This also changes who should be in the room. The buying committee usually includes people who evaluate and people who pay. It rarely includes the front-line manager whose team has to change. Add that person before signature, not after.

A 90-Day Adoption Plan

The table below is a template. The usage targets are illustrative starting points to adjust for your team and tool, not industry benchmarks.

Two notes on using it. First, measure meaningful use, such as completing the core workflow, not logging in. A login proves a password works. Second, set the day-90 target before you sign, because a target invented after the fact gets shaped to match whatever happened.

The Day-90 Decision

At day 90, you have a rare moment of clarity, and most companies waste it. You have three honest options.

Expand. The target was met. Roll out to the next team, with the owner and the playbook already proven.

Fix. Usage is low but the reason is specific and solvable, such as a missing integration or a workflow mismatch. Fix it, and set a 30-day recheck.

Stop. Usage is low and the reason is that the tool doesn't fit the work. This is the cheap moment to leave, ideally before an annual renewal, and it's much better than discovering the same thing in month eleven.

For this to work, your contract should allow it. When you negotiate, look for a pilot phase, a seat ramp tied to rollout, or a termination window in the first quarter. The same discipline applies to the number of tools you carry in the first place; our look at the true cost of software sprawl shows what unmanaged accumulation costs, and how much to spend per employee is a useful companion when you're sizing seats.

What to Do Next

1. Audit your last three purchases. For each, write down who owned adoption at day 30, what the usage looked like at day 90, and whether you renewed on facts or on inertia. Patterns will show up fast.
2. Add a rollout plan to your buying checklist. No signature without a named owner, a "what stops" list and a day-90 target.
3. Add a front-line manager to the committee. One person from the team that has to change, with a real vote on feasibility.
4. Pull usage data before every renewal. Ask the vendor for activity by user, then compare against seats paid. If the vendor can't provide it, treat that as a finding.
5. Pick one tool this quarter and run the 90-day plan on it. Starting with a single tool beats a company-wide program that nobody owns. If you want more on change in general, see our library pages on change management and employee technology adoption.

Selection decides what you could get from a tool. Rollout decides what you actually get. Put the same care into the first 90 days that you put into the shortlist, and the next budget meeting becomes a lot shorter. If you're also deciding whether to let teams choose their own tools, standardize or let teams choose covers the tradeoff.