Setting KPIs for a software rollout based entirely on the number of licences purchased — rather than the percentage of employees actively using the system — is one of the most common, most expensive, and least-examined mistakes in enterprise technology. It mistakes procurement for adoption, and spending for value. If your project board is celebrating 500 licences deployed while 340 of those users haven't logged in since the go-live party, something has gone quietly wrong.
This article is about what that mistake actually costs, why intelligent people keep making it, and what to measure instead.
What's the actual problem with licence-based KPIs?
A licence is a commercial artefact. It tells you what you've paid for. It says precisely nothing about whether anyone is getting value from the thing you've paid for.
Measuring a software rollout by licences purchased is the organisational equivalent of measuring a library's success by the number of books on the shelves. Technically accurate. Entirely beside the point.
The real measure of a software rollout is whether the people it was bought for are using it, using it well, and getting something useful out of it. Everything else is just procurement administration dressed up as project management.
Why does this matter more than it might seem?
Because KPIs shape behaviour. If your steering committee is measuring success by licences allocated, that's what your project team will optimise for. They'll push licences out. They'll tick the deployment box. They'll move on.
Meanwhile, your actual users are quietly reverting to spreadsheets, email chains, and the workarounds they had before. The system sits there, fully licensed, largely unused, gently depreciating.
According to Gartner research, organisations waste an estimated 30% of their software spend on unused or underutilised licences. That's not a rounding error. That's a budget line.
Why do organisations keep setting KPIs this way?
It's worth being honest about this, because it's not stupidity. It's a set of entirely understandable pressures producing a predictably bad outcome.
Is it just easier to count licences than measure usage?
Yes, frankly. Licences are a clean number. Your vendor gives you a dashboard. It says 500. Done. Active usage rates require you to define what "active" means, agree that definition with stakeholders, instrument your system to capture it, and then have a slightly uncomfortable conversation when the number comes back lower than expected.
Licence counts don't require uncomfortable conversations. That's most of their appeal.
Does procurement culture drive this?
Significantly, yes. In many organisations — particularly in the public sector, where I've spent a considerable portion of my career — the heaviest governance scrutiny falls on the purchase of technology, not its use. Once the contract is signed, the committee moves on. The accountability gap between "we bought it" and "people are using it" is where adoption goes to die.
I've sat in enough post-implementation reviews where the project was declared a success on slide three, and the actual usage data didn't appear until slide fourteen — by which point everyone had mentally moved on to the next initiative.
Does vendor incentive play a role?
More than vendors would like to admit. A vendor's commercial interest is in licence renewals, not in your adoption rate. If your contract renews automatically based on seat count rather than demonstrated value, the vendor has limited commercial incentive to help you drive usage. This isn't malicious. It's just the structural logic of how most enterprise software is sold.
The shift toward usage-based licensing models — where you pay for what you actually consume — is partly a market correction to this problem. It forces the conversation about adoption that licence-based models quietly avoid.
What should you actually be measuring instead?
This is where it gets practical. The goal is a KPI framework that reflects real adoption, not theoretical deployment. Here's how to think about it across three layers.
Layer 1: Deployment (the foundation, not the finish line)
Deployment metrics are legitimate — they're just not sufficient. You need to know that access has been provisioned, that the technical infrastructure is in place, and that users can get into the system. These are preconditions, not outcomes.
- Licences provisioned vs. licences purchased
- User accounts created and verified
- System availability and uptime at go-live
Layer 2: Adoption (where the real KPIs live)
Active usage rate — the percentage of licensed users who have logged in and performed a meaningful action within a defined period — is the core metric most rollouts fail to track properly. Define "active" clearly before go-live, or you'll argue about it afterwards.
- Weekly active users (WAU) as a percentage of total licences
- Monthly active users (MAU) — useful for less-frequent workflows
- Feature utilisation rate — are users accessing the capabilities the system was bought to deliver?
- Time-to-first-meaningful-action — how long after provisioning does a user actually do something useful?
- Drop-off rate — users who logged in once and didn't return
Layer 3: Value realisation (the destination the whole project was pointed at)
Adoption is a means to an end. The end is the business outcome the software was supposed to deliver. These metrics are harder to measure and take longer to materialise — which is exactly why they're so often absent from project KPI dashboards.
- Process efficiency improvement (e.g., reduction in time-to-complete a task the system was bought to support)
- Error rate reduction
- Staff time saved and redeployed
- Reduction in workarounds and shadow IT
- User-reported confidence and satisfaction scores
How do licence-based KPIs compare to usage-based KPIs?
| Dimension | Licence-Based KPIs | Usage-Based KPIs |
|---|---|---|
| What they measure | Procurement activity | Actual user behaviour |
| Ease of collection | Very easy — vendor dashboard | Moderate — requires system instrumentation and agreed definitions |
| Reflects business value? | No | Partially (adoption is a proxy, not a direct measure) |
| Encourages the right behaviours? | No — optimises for deployment, not adoption | Yes — drives change management and user enablement activity |
| Useful for vendor accountability? | Limited | Yes — creates leverage in renewal conversations |
| Risk of gaming | High — licences can be "deployed" without genuine rollout | Lower — harder to fake genuine user sessions at scale |
| Typical project board appetite | High — clean, simple, defensible | Lower — requires more explanation and honest conversation |
| Long-term value signal | None | Strong — predicts renewal value and benefit realisation |
What does a better KPI framework actually look like in practice?
I've helped design adoption frameworks for organisations ranging from NHS trusts to national charities to mid-size private sector businesses. The structure that consistently works is a simple three-horizon model tied to a realistic timeline.
The three-horizon adoption KPI model
Horizon 1 — 0 to 30 days post go-live: Deployment and first contact
- Target: 90%+ of licences provisioned to named users
- Target: 70%+ of users complete at least one login within 30 days
- Target: Zero critical support blockers unresolved at end of week two
Horizon 2 — 30 to 90 days: Sustained engagement
- Target: 60%+ of licensed users active on a weekly basis
- Target: Core workflow completion rate above a defined threshold
- Target: Reduction in help desk tickets as users become self-sufficient
Horizon 3 — 90 days to 12 months: Value realisation
- Target: Measurable improvement in the business process the system was bought to support
- Target: Active usage rate stable or growing
- Target: User satisfaction score at or above benchmark
The specific numbers will vary by organisation, system type, and workforce context. The structure, however, holds across almost every rollout I've been involved in.
How do you get a steering committee to care about usage, not just licences?
This is the real challenge, and it's a political one as much as a technical one. Steering committees are busy. They want a dashboard they can read in thirty seconds. Licence count is a very readable number.
Frame adoption as financial risk, not project management detail
The argument that cuts through fastest is the cost-per-active-user calculation. If you've purchased 500 licences at £50 per user per month, and only 200 users are active, your effective cost per active user is £125 — not £50. You're paying for 300 people who aren't showing up.
That's a number that tends to land differently than "our adoption rate is below target."
Build usage data into your project reporting from day one
Don't introduce usage metrics at the three-month review when the numbers are bad. Agree them as KPIs before go-live, get them into the project initiation document, and report on them from the first steering committee after launch. Normalise the conversation while the numbers are still forgivable.
Name the adoption risk explicitly in your risk register
"Low user adoption leading to failure to realise projected benefits" should be a line item in every software rollout risk register. It almost never is. Adding it creates accountability and gives you a legitimate forum to report on mitigation activity — which is your change management and training programme.
What role does change management play in all of this?
An enormous one, and it's the part that gets cut first when budgets are squeezed.
There's a reliable pattern in underfunded rollouts: the technical implementation gets protected because it's visible and contractual, while the change management activity — training, communications, stakeholder engagement, user support — gets trimmed because it feels softer and more discretionary. Then the system goes live, adoption is poor, and everyone wonders why.
Prosci's research consistently finds that projects with excellent change management are six times more likely to meet their objectives than those with poor or no change management. Six times. That's not a marginal improvement. That's the difference between a rollout that works and one that becomes a cautionary tale at the next digital leadership conference.
If your KPIs are focused on usage rather than licences, change management stops being a nice-to-have and becomes the primary lever for hitting your targets. That's the right relationship between measurement and activity.
Are there cases where licence-based metrics are actually appropriate?
Yes — and it's worth being honest about this rather than treating licence metrics as entirely without merit.
In the early stages of a complex, phased rollout, deployment progress is a legitimate leading indicator. If you're rolling out a system to 5,000 users across 40 locations over 18 months, tracking how many licences have been provisioned tells you whether the deployment is on schedule. That matters.
The problem isn't measuring licences. The problem is measuring only licences, or treating licence deployment as the endpoint rather than the starting line.
Similarly, for systems used infrequently by design — annual compliance training platforms, for example — weekly active user rates are a meaningless metric. The right measure there is completion rate within the required window. Context always shapes what good measurement looks like.
Frequently Asked Questions
What is the difference between a licence metric and an adoption metric?
A licence metric measures what has been purchased or provisioned — it's a commercial record. An adoption metric measures whether people are actually using the system and how. Licences tell you what you've paid for; adoption metrics tell you whether you're getting value from it.
What is a good active user rate for a new software rollout?
There's no universal benchmark, as it depends heavily on the system type, the nature of the work it supports, and the rollout approach. As a rough orientation: 70%+ active usage within 90 days is a reasonable target for systems that form part of daily workflows. For systems used less frequently, completion rates and task-specific metrics are more meaningful than raw active user counts.
How do you define "active user" for KPI purposes?
This is a critical definition to agree before go-live, not after. A common approach is to define an active user as someone who has logged in and completed at least one meaningful workflow action within a defined period (typically seven or thirty days). Logging in alone is usually not sufficient — a user who opens the system and immediately closes it is not productively engaged.
How do you track software adoption rates in practice?
Most modern enterprise systems provide usage analytics either natively or through integration with analytics tools. Key data points include login frequency, feature utilisation, session duration, and workflow completion rates. If your system doesn't provide this data natively, that's a procurement question worth asking before you sign the contract.
What happens when adoption rates are low after go-live?
Low adoption after go-live is a signal, not a verdict. The first step is to understand why — whether it's a training gap, a usability problem, a process design issue, or resistance from specific teams or managers. Targeted interventions based on that diagnosis are far more effective than generic re-training campaigns. It also helps to identify and empower internal champions — people who are using the system well and can support their colleagues.
Should software vendors be held accountable for adoption rates?
Increasingly, yes — and the most forward-thinking vendor relationships build adoption milestones into the contract itself. Success-based licensing models, where renewal terms or pricing are tied to demonstrated usage and value, are becoming more common as organisations become more sophisticated buyers. If your vendor has no commercial stake in your adoption rate, that's worth examining.
How do licence-based KPIs affect software renewal decisions?
Significantly, and usually badly. If your renewal decision is based on licence count rather than usage data, you have no evidence base for renegotiating seat numbers, challenging the price, or making the case to consolidate or replace the system. Usage data is commercial leverage. Without it, you're renewing blind.
What's the relationship between KPIs and change management in a software rollout?
Directly causal. If your KPIs measure usage, your project team will invest in the activities that drive usage — training, communications, stakeholder engagement, user support. If your KPIs measure licences, they'll invest in provisioning. What you measure shapes what you do. Getting the KPIs right is, in part, a change management decision in itself.
Nicholas Hodder is a digital transformation and technology leader with over 20 years of experience delivering technology programmes across the public, private and third sectors. He writes and speaks on the gap between technology strategy and the reality of making it work with actual human beings.