"Did it work?" is the wrong first question
You rolled out a new tool three months ago. Someone asks: did it work?
You probably have an answer that feels true but isn't provable — "yeah, things feel smoother." That's not measurement. That's a vibe.
The fix isn't more dashboards. It's asking a better question first: what kind of leverage was this supposed to deliver? Efficiency, Scale, Insight, and Risk Reduction each show up in different numbers. Measure an efficiency project like a risk project and you'll either overclaim or underclaim the result — and either way, you won't learn anything you can reuse.
This is the Check step. You planned, decided, implemented. Now you audit honestly, with metrics that actually match what you were trying to buy.
Before you pull any report, name the leverage you were after. Then pick metrics from that family — not a generic "usage" number.
| Leverage type | What it should move | Core metrics |
|---|---|---|
| Efficiency | Time and manual effort | Hours saved per week, tasks per person per day, error/rework rate |
| Scale | Capacity without added headcount | Volume handled per employee, response time under load, cost per transaction |
| Insight | Speed and quality of decisions | Time-to-answer for a key question, number of decisions backed by data vs. gut, forecast accuracy |
| Risk Reduction | Frequency and cost of bad outcomes | Incidents per quarter, backup restore success rate, compliance findings, time to detect an issue |
Efficiency and Scale are about doing more with the same inputs. Insight is about the quality of your decisions, not the tool's feature list. Risk is the strangest to measure, because success often looks like nothing happening — which is exactly why it gets skipped in most audits.
Efficiency: time and error metrics
Efficiency is the easiest to instrument because the baseline usually already exists in someone's memory or a time log.
- Baseline it first. Before you can claim "we saved five hours a week," you need to know what the task cost before — even a rough estimate from timesheets or a week of tracking counts.
- Track hours, not sentiment. "It feels faster" isn't data. Log actual time spent on the task pre- and post-automation for at least two full cycles.
- Watch the error rate, not just the speed. A process that's 30% faster but now has double the mistakes isn't a win — it's a new problem with better PR.
Good looks like: a measurable drop in hours per cycle, plus a flat or improved error rate. If errors went up after automating, the process wasn't ready — a signal to revisit whether it needed fixing before automating at all. That readiness question is worth running through a dedicated readiness check before you scale the fix further.
Scale: capacity and quality metrics
Scale metrics answer one question: can we handle more without hiring in lockstep or dropping quality?
- Volume per person. Orders, tickets, or leads handled per employee, tracked monthly. If this climbs while headcount stays flat, that's real leverage.
- Response time under peak load. Test it deliberately — what happens during your busiest week? Scale tech should hold response times steady even as volume spikes.
- Quality under growth. Customer satisfaction and error rates shouldn't degrade as volume rises. If they do, you scaled the pipe but not the quality control.
Good looks like: volume up, headcount flat or only modestly up, quality metrics unchanged. If you can't say what would break at double your current volume, you haven't tested scale — you've just hoped.
Insight: decision metrics
Insight is the leverage type most businesses collect data for and then never measure the payoff of. The instrument here isn't the dashboard — it's the decision log.
- Time-to-answer. How long does it take to get the number you need — profit per product, lead source performance, churn risk? Before a dashboard, this might mean two days of digging in spreadsheets. After, it should be minutes.
- Decisions backed by data. Keep a simple log of major decisions each quarter and tag each one: data-informed or gut call. Watch the ratio shift over time.
- Accuracy of predictions. If a tool flags churn risk or forecasts demand, check it against what actually happened. A tool that's directionally right most of the time is doing its job; one that's no better than a coin flip isn't insight, it's noise.
Good looks like: faster time-to-answer, more decisions with a data trail attached, and predictions that hold up against reality often enough to trust. If nobody can point to a decision the new dashboard actually changed, the insight tool is decoration, not leverage.
Risk reduction: the metric that's an absence of a number
This is the leverage type people skip measuring, because the win is that nothing bad happened. But you can still instrument it:
- Incidents per quarter. Security events, missed compliance steps, data loss — track the count, even if it's zero. Zero is the data point.
- Recovery readiness. Don't just confirm backups run — test a restore. "We have backups" and "we've successfully restored from backup" are very different claims.
- Time to detect. If something does go wrong, how long before you knew? A monitoring tool should shrink this from days to minutes.
- Consistency. Are checklists and SOPs actually followed? Spot-check a sample of completed tasks against the standard.
Good looks like: fewer incidents, verified recovery, and faster detection when something slips through. The honest audit here requires you to actually run the fire drill, not just assume the extinguisher works.
Running the honest audit
A nine-person service company automated appointment scheduling (Efficiency) and added an uptime monitor on its booking site (Risk Reduction). Here's what an honest before/after looked like at the 90-day mark:
| Metric | Before | After |
|---|---|---|
| Hours/week on scheduling calls | 6.5 | 1.0 |
| Double-booked appointments/month | 3 | 0 |
| Site downtime detected within | Next business day (customer complaint) | Under 10 minutes (alert) |
| Missed bookings from downtime | Unknown, unmeasured | 0 tracked incidents |
Two leverage types, two metric families, one honest table. The "unknown, unmeasured" cell is the most useful entry in the whole audit — it's an admission, not a spin.
Before you declare a win anywhere, run through this checklist:
- Did you name the leverage type before picking the metric, or did you pick a metric that happened to look good?
- Do you have a real baseline, or are you estimating the "before" from memory?
- Have you measured for at least one full cycle post-launch, not just week one?
- For risk reduction, have you actually tested the failure case (restore, incident response), not just assumed it works?
- Would you be comfortable sharing this number with your team, even if it's underwhelming?
If you can't answer these cleanly, you're not auditing — you're hoping. A structured backlog helps too: knowing how to prioritize your automation backlog before you build makes the after-the-fact measurement much easier, because you already agreed on what "success" meant.
Measurement isn't a one-time report card — it's how you decide what to do next quarter. A tool that clearly delivered Efficiency leverage might be ready to extend into Scale territory. A dashboard that never changed a decision might need to be simplified or dropped. Pair this with a broader four-lens tech audit each quarter, and you'll stop guessing which lever to pull next — you'll know, because the numbers told you.