The tool you bought sits unused because nobody mapped the work first

Most software that sits unused was bought to fix a process nobody had written down. The team tried it, found it did not match how work really moves between people, and drifted back to spreadsheets and chat. The cause is usually the order of decisions. Map the work first, then decide what to buy, connect or build, and involve the people who will use it before anything goes live.

Most software features go unused, so adoption has to be planned from the start

Pendo’s 2019 Feature Adoption Report drew on usage data from 615 software products and found that 80% of their features were rarely or never used.¹ The figure comes from a software vendor and covers software products in general, not companies. It is still a broad measure, and it matches what owners and executives tell us: a project tool only a few people open, a CRM updated only before board meetings, an automation platform nobody remembers setting up.

The pattern has a common cause. A tool is designed for an average company. Your company differs from the average in the places that matter most: how a job passes from sales to delivery, who approves what, and which exceptions happen every week. Those differences are where the tool and the work disagree. They are also exactly what nobody wrote down before the purchase.

Adoption fails at the handoffs, where the tool and the work disagree

Look at where people abandon a tool. It is rarely inside a single task. A designer can log hours in almost any system. The break happens at the handoff, when work passes from one person to the next.

Handoff	What the tool misses	Workaround
Sale to delivery	No notice when a deal closes	Lead waits for an email
Budget to hours	No budget against hours	Budget kept in a spreadsheet
Delivery to invoice	No view of work delivered	Finance asks in chat

Source: Verticulate illustration of a typical agency project tool

Each workaround is reasonable on its own. Together they make the tool optional, and an optional tool does not survive its first busy month.

Harold Leavitt described the underlying problem in 1965. His model treats people, tasks, structure and technology as connected: change one, and the other three have to move with it.² Buying a tool changes the technology and leaves the other three as they were. Unless someone redesigns who does what, and in what order, the old way of working wins.

Adoption work changes the result more than the choice of tool

The evidence here is consistent, if imperfect. Prosci asked more than 2,600 change practitioners how their projects went. Of those with excellent change management, 88% met or exceeded their objectives, against 13% of those where it was poor.³ The data is self-reported, so treat the size of the gap with caution. The steady rise from poor to excellent is harder to dismiss.

1. Excellent88%
2. Good73%
3. Fair39%
4. Poor13%

Projects with excellent change management succeeded nearly 7 times as often as those with poor

Change management	Met objectives
Excellent	88
Good	73
Fair	39
Poor	13

Source: Prosci, Best Practices in Change Management research, more than 2,600 practitioners³

Research on AI programs points the same way. BCG’s 2024 survey of 1,000 executives found that about 70% of the challenges in AI programs come from people and process, against 20% from technology and 10% from the algorithms themselves.⁴ The point carries over to software in general: the tool has to be right, and most of the risk sits in the people and process around it.

In a company, adoption work does not need a program office. It needs the people who will use the system to shape it before launch, a reason for each of them to keep it current, and one named person watching for workarounds in the months after launch.

Four questions show whether you are ready to buy the next tool

1. Can you draw the process on one page? Include every handoff, every tool and every place where information is retyped. If you cannot, you are not ready to choose software for it.
2. What does each person get back for the data they enter? People keep a system current when it saves them work. If the only beneficiary is the owner’s report, expect the data to go stale.
3. Which tool is the record for each kind of information? If two tools both hold job status, people will trust neither. Choose one system of record and connect the other to it.
4. Who owns adoption for the first 90 days? Name a person, not a team. Their job is to notice workarounds early and fix the cause.

The tool you already own may be fine

Before you cancel a subscription, map the work it was bought for. Often the tool was set up around a guess at the process, and a few changes to its fields, statuses and connections bring it back into use. Sometimes the map shows the tool cannot hold your process, and replacing it is the right call. Either way, the decision rests on evidence instead of frustration. The playbook Run a keep, connect or replace review of your tools sets out how to make it.

Illustration. A 30-person agency buys a project management tool. Six months later, account managers still keep a budget spreadsheet, because the tool does not show budget against hours worked. The owner considers switching tools. A map of the process shows the real gap: hours are logged in a time tracker that is not connected to the project tool. Connecting the two and adding a budget field to each project ends the spreadsheet. The tool stays.

A slower first month costs less than a second unused tool

Mapping the work before you choose software adds a few weeks at the start. A second tool that nobody uses costs another round of subscription fees, and the team trusts the next one less. To map one process yourself, start with Map one process in an afternoon.