Measuring adoption after go-live

The software adoption metrics that matter after go-live are four: active users by role, tasks completed in the system as a share of tasks that happened, workarounds that still live in spreadsheets and chat groups, and support tickets by category. Reviewed at 30, 60 and 90 days with the executive sponsor present, they show whether the platform is doing the work it was bought for, and they point at the fixes. Log-in counts and licence utilisation, the numbers vendors report, show whether people opened the door, not whether they did anything inside. This article sets out the dashboard we put in front of sponsors after every enterprise platform implementation and how to read it.

Adoption is the outcome an implementation is paid for. A system that is live and unused costs more than the one it replaced, because the old spreadsheets are still being maintained alongside the new licence. Measuring adoption is how you find out early enough to do something.

Why software adoption metrics need to be task-based

A user who logs in every morning, glances at a dashboard and does the real work in a spreadsheet counts as active in every vendor report. Task-based metrics ask a harder question: of the leave requests filed this month, how many went through the HRMS? Of the deals that moved stage, how many were updated in the CRM within a day? Of the tickets closed, how many carry a real resolution code? These numbers require knowing what "should" have happened, which is why the baseline is captured before go-live and why the process map from the implementation is the source of the expected counts.

The adoption dashboard

Active users: by role and by site, never in total

A total active-user number hides the department that has quietly opted out. Split by role and by site or team, and the picture changes: head office is fine, one plant has not logged a single attendance record, the field sales team uses it on Mondays only. Each of those is a different problem with a different fix. Set the definition of "active" as having completed a task, not having opened the app, and agree it before go-live so nobody argues about the definition when the number is bad.

Tasks in-system: the metric that tells the truth

This is the core user adoption KPI. For each role, the implementation identified the five tasks that matter. For each task, the baseline period established how many happen in a typical month. After go-live, count how many were completed in the system. The gap is the workaround. A sales team that closes twenty deals a month but records eight stage changes is running its pipeline somewhere else. The number does not need to be precise to be useful; it needs to be honest, consistent and compared month on month.

Workarounds: go and look

No dashboard reports the spreadsheet on a manager's desktop. The workaround inventory is built by asking and observing: what do you still keep outside the system, and why? The answers are the most valuable input to the post go-live review because each one is a specific configuration or training fix. Retire workarounds formally, with a date and a communication, once the system covers the task. A workaround that is tolerated is a workaround that is permanent.

Support tickets: read the clusters, not the count

Ticket volume falls naturally after go-live; that is not adoption, it is people giving up on asking. Categorise tickets and read the clusters. A cluster of how-to questions on one task means the training for that task did not land. A cluster of data complaints on one entity means the migration reconciliation missed something. A cluster of access requests means the role mapping is wrong. Each cluster is a fix; the ticket count alone is noise. Hypercare owns this reading in the first month, as Hypercare: what the first month after go-live should look like describes.

Running the 30, 60 and 90 day reviews

Each review is an hour, with the sponsor, the process owners and the implementation lead. The dashboard is shown by role and site. The workaround inventory is read out. The top three fixes are agreed, with owners and dates, and the previous review's fixes are checked. The 30-day review is mostly about training gaps and data; the 60-day review is about configuration changes that the first month revealed; the 90-day review decides whether the implementation is complete and what the steady-state Care Plan should cover. If the 90-day numbers are not better than the 30-day numbers, something structural is wrong, usually a process owner who is not deciding or an executive who still accepts spreadsheet reports.

AI features have their own adoption curve

Platforms increasingly ship AI features: summaries, drafting, next-best-action. These need their own line on the dashboard, because they fail differently: a feature that is tried once and abandoned because the first output was wrong. Measure suggestions accepted versus shown and track the abandonment point. Copilot adoption: why most AI features die in a month covers the pattern, and our in-app copilot work shows how the metric is built into the product.

A worked example

A field-service SaaS company rolled a new CRM out to its own sales and support teams. Log-ins looked healthy at 30 days. Tasks in-system told a different story: support closed most tickets in the system, but sales stage changes were a fraction of deals closed. The workaround inventory found a shared spreadsheet the regional managers used for forecasting because the CRM pipeline report did not show what they needed. The 30-day fix was the report; the 60-day review showed stage changes rising as managers stopped asking for the spreadsheet; the 90-day review retired it formally. The system had been fine; the report was the missing piece, and only a task-based metric found it.

Team and timeline

The adoption dashboard is built during the implementation, before go-live, so the baseline exists, and it is part of the enterprise platform implementation scope from $28,000 (from ₹18,40,000). A solutions consultant defines the tasks and the expected counts with each process owner; a data engineer builds the dashboard from the platform's audit data, often as a small data and analytics application when the platform's own reporting cannot answer the questions. The three reviews are run by the implementation lead. After 90 days, the dashboard is maintained and reviewed monthly under a Care Plan, from $1,000 per month, with the options on the pricing page.

Before you start: a checklist

• Define "active" as completing a task, not logging in, and agree it before go-live
• List the five key tasks per role and capture baseline counts before cut-over
• Decide the split for every metric: role, site, team
• Set up ticket categories so clusters can be read
• Plan the workaround inventory: who asks, who is asked, when
• Book the 30, 60 and 90 day reviews with the sponsor's name on the invitation
• Agree that each review ends with three owned fixes
• Add a line for AI feature acceptance if the platform ships copilots

Glossary

• Active user: someone who completed at least one real task in the period, by role and site
• Tasks in-system: completed tasks counted against the expected count from the baseline
• Workaround: a spreadsheet, chat group or paper process holding work the platform was meant to hold
• Ticket cluster: a group of tickets on one task, entity or role that points at a single fix
• Baseline: task counts and timings captured before go-live for comparison
• Post go-live review: the 30, 60 and 90 day meeting where the dashboard is read and fixes are agreed

Related reading

Why enterprise software implementations fail on adoption explains what these metrics are detecting, and HRMS implementation: a 90-day plan shows the reviews inside one project. On measuring whether people can actually complete tasks, the Nielsen Norman Group's usability metrics guidance is the external reference we recommend.

Count tasks, not log-ins, split by role and site, and let each review end in three fixes rather than a summary.