Six months after a system goes live, someone in a meeting asks whether it was worth it. The room offers opinions. Nobody has numbers, because nobody wrote down what things were like before.
This is entirely avoidable, and the work takes about two hours — but it has to happen before launch.
Capture the baseline first
You cannot measure improvement without a before. Two weeks before go-live, record the current state of four to six things. Rough is fine; consistent matters more than precise.
Time. How long does the process take now, end to end? Time it three times with a stopwatch rather than asking people to estimate — self-reported durations are unreliable in both directions.
Errors. How many corrections, complaints, or reworks happened in the last month? Count from whatever record exists, even if it is a WhatsApp group.
Volume. How many of the thing are processed per week? You need this because improvements often show up as capacity rather than speed.
Cost. Staff hours spent, plus anything paid out for it. Include the parts people do not count, like the two evenings a month someone spends reconciling.
Delay. Time from when something arrives to when it is dealt with — enquiry to response, invoice to payment, application to decision.
Frustration. Ask the five people who do the work to rate the process one to ten. It is subjective and it is the number leadership will care most about later.
Write these on one page with the date. That page is worth more than any dashboard you build afterwards.
What to measure after, and when
Do not measure in week one. Everything is worse in week one — that is the learning curve, not the system.
Week 4: adoption only. The only question that matters early is whether people are using it. Specifically: what percentage of the work is going through the system rather than around it? If half the team is still using the old spreadsheet at week four, nothing else you measure will mean anything. Fix adoption first; it is almost always a training or workflow-fit problem, not a software problem.
Week 8: the operational numbers. Now re-measure time, errors and delay against the baseline. Expect time saved to be smaller than promised and error reduction to be larger than expected — that is the usual shape.
Month 6: the business numbers. Capacity, cost, and whatever outcome you actually bought the system for. This is also the point to re-ask the frustration question, because the honeymoon and the backlash have both passed.
Numbers that mislead
Logins. People log in and do nothing. Measure completed actions instead.
Feature usage. That a report was run tells you nothing about whether it changed a decision.
Total records. Grows automatically. Measures time passing, not value.
Average anything, without the spread. An average response time of four hours might be a consistent four hours, or it might be mostly ten minutes with a handful of three-day disasters. Those are entirely different businesses. Use medians and look at the worst 10%.
The uncomfortable outcomes, and what they mean
Nothing improved and adoption is high. The system faithfully reproduced a bad process. This is the most common disappointing result, and it is not a software failure — it is that nobody redesigned the process while they had the chance. The fix is process work, not more features.
Time went up but errors went down. Usually a genuine win. The old process was fast because it skipped verification. Check whether the extra time is in data entry (worth reducing) or in checks (worth keeping).
Adoption is high in one team, low in another. Go and watch the low-adoption team work. There is almost always a specific step that does not fit how they actually operate, and it is usually fixable in a day.
Everyone hates it but the numbers improved. Take this seriously rather than celebrating the numbers. Sustained resistance eventually wins, and a system people resent gets worked around within the year.
Report it honestly
When you present the results, include what did not improve. Two reasons: it is true, and it is the fastest route to funding the next phase. A report that claims total success invites scepticism about all of it. A report that says "response time halved, error rate unchanged, and here is what we think that is about" gets believed — and gets budget.
Keep it running
Pick three numbers from the list and put them on a monthly review. Not thirty. Three. Systems decay quietly; a small standing measure is how you notice within a month instead of within a year.
If you want help defining a baseline before a build starts, or an honest assessment of a system already live, book a consultation.