It is much quieter about whether the work got better.
Usage is not value.
A busy system can still waste time. A rarely used tool can still support a critical monthly task. A report can be opened repeatedly because people trust it. It can also get opened again and again because people do not trust it.
The first question is not, "Are people using it?" but rather, "What happens when they do?"
Usage data needs a second question
Usage data is good at proving activity.
It is weaker at explaining work.
Login counts are blunt. A person got into the system. That says little about whether the task was finished cleanly. Feature clicks and dashboard views have the same problem. They mark activity. They do not explain the work.
Software reviews often begin there because the numbers are easy to collect.
Active users. Assigned licenses. Feature clicks. Login frequency. Teams with low adoption. Users who have not opened the application in 90 days.
Those are useful signals. They are not verdicts.
The missing piece is usually the workflow. What got easier? What went away? What still happens in Excel, email or Slack after the official task is done? Those answers rarely live in the usage report.
Usage points to the conversation. It does not finish it.
High usage can hide bad work
Some software is used heavily because employees have no choice.
That is common with ERP, HR, finance, customer service, collaboration and endpoint tools. The application is part of a required process. People use the tool because the work routes through it.
That is not the same as value.
A user might log in repeatedly because the workflow is confusing. A team might run several reports because no single view is trusted. Employees might spend all day in a messaging tool because the underlying process is unclear. Someone might enter the same information twice because the integration work never got finished.
That is where software usage metrics need a process owner. Someone close to the work must explain what the number means before leaders decide whether a tool is valuable, redundant or underused.
Heavy use might mean the tool is essential.
It could also mean the work is harder than it should be.
Application portfolio management can help enterprises compare software usage, ownership, cost, risk and business value across applications.
Low usage is not always failure
Low usage is easy to misread.
A feature might be ignored because no one knows it exists. It might not be enabled for the right roles, or it might need data or permissions that are not yet available. It might have been included in the contract but never tied to a real workflow.
Or it might simply not matter.
Those are different answers.
Before treating low usage as failure, teams should go back to the reason the feature was bought or enabled. What was it supposed to replace? Who was supposed to use it? Was the old process retired? Did training happen at the right point in the rollout? Did the feature depend on another system change that never arrived?
High feature use deserves the same skepticism.
A used feature is not always a valuable feature.
A feature might be popular because it saves time. It could also be popular because it helps people get around a weak process. A report export might be heavily used because users need offline analysis. It could also mean the system does not give them the answer where the work happens.
Feature use should start a conversation. It should not end one.
A used feature is not always a valuable feature.
Usage data still needs a decision
Usage data is most useful when it changes what the organization does next.
It can point to unused licenses, redundant tools, training gaps, feature confusion and unexpected dependencies. It can help with SaaS sprawl, subscription reviews, license reallocation and SaaS management. It can also give software asset management teams a starting point for portfolio discussions.
But the number should not make the decision by itself.
Low usage might point to waste, or it could also point to a rare workflow that cannot fail. High usage might point to value. It could also point to a required tool that makes users work too hard.
Application portfolio management needs that distinction. A portfolio review should connect activity to purpose, risk, cost and workflow importance.
Start with the tool people are defending, renewing or trying to cut.
Who depends on it? What work does it support? What breaks without it? What old process was supposed to go away? What would users do if the tool disappeared tomorrow?
The enterprise should count usage. Then it should ask what the usage means.
James Alan Miller is a veteran technology editor and writer who leads Informa TechTarget's Enterprise Software group. He oversees coverage of ERP & Supply Chain, HR Software, Customer Experience, Communications & Collaboration and End-User Computing topics.