What you will learn Not a chapter to read but one to do. Take one of your projects, write the measurement plan on a single page, and test whether it actually works.
As measuring and reporting results showed, past cycle time has no retroactive measurement. Postpone this exercise a week and that much of the baseline is gone for good.
The last line is not optional. Filled in by managers alone, every number becomes an estimate.
The most common mistake. Too wide a scope and you cannot tell later what improved.
| Item | Yours |
|---|---|
| Where does it start? | |
| Where does it end? | |
| What is one unit? | (one enquiry / one invoice / one report) |
| How many per month? |
Do not invent new ones. Use figures already produced by a system or a ledger. Starting to measure something new changes behaviour, which contaminates the very baseline you are taking.
| Metric | Value today | Where you checked | Verified |
|---|---|---|---|
| Cycle time per item | □ | ||
| Error / rework rate | □ | ||
| Items per month | □ |
Three rows is enough. Three tracked for six months beats ten attempted and none completed.
| Item | Yours |
|---|---|
| Measurement window | (long enough to average out weekday and seasonal variance — usually 2–4 weeks) |
| Start date | |
| Who pulls the same numbers after deployment | (a name) |
| Reporting cadence | (monthly / quarterly) |
The third row is the whole table. If a consultant measures before and nobody measures after, there is nothing to compare against. Check now whether that person will still be around after launch.
Run the plan through four questions.
From what you wrote under "where you checked", someone else must be able to produce the same number. If not, that is a memory, not a measurement.
It is common to pick a metric that does not move even when cycle time drops. Write down now which direction, and by how much, this number should move if the AI works. If you cannot, the metric is wrong.
Without these, "40 min → 12 min" becomes a lie later.
Ticking the last box is honest. But left as is, the financial effect records as zero. Note now that this is a change management problem, not a measurement one.
1. Why pick metrics you already count rather than new ones?
Starting to measure something new changes behaviour and contaminates the baseline. A figure already produced by a system is also the only kind you can pull the same way after deployment.
2. Why test "could someone else pull this in three weeks?"
If they cannot, it is a memory rather than a measurement. A baseline is only worth anything compared by the same method to the post-deployment value; if the method is not reproducible, there is no comparison.
3. Why measure rework rate and review time from the start?
Without them the improvement is overstated. Cycle time falling from 40 to 12 minutes means little at a 40% rework rate — the real figure is 12 minutes plus the fixing. Added later, there is no baseline to compare against.
You are ready to keep the numbers; next, keep the evidence → Audit trail and observability
HyperTeams□ 40 minutes□ One project (the one settled in Phase 1)□ One person who actually does the work✗ "customer service" → too wide✗ "generating replies with AI" → that is the tool, not the work✓ "intake → triage → draft reply → send to owner" ← like thisIf "where you checked" reads like this, do it again: ✗ "about half a day" → no basis ✗ "the team lead's sense" → an estimate ✓ "ticket system duration field, mean over July"□ Rework rate — share of AI output a human had to fix□ Review time — the time spent checkingWhere do the saved hours go? □ More throughput □ Redeployment □ Less overtime □ Not decided yet[Project] First-line customer enquiries[Scope] intake → triage → draft reply → send to owner (unit: one enquiry, 1,800/month)[Metrics] cycle time per item 18 min ← ticket system duration field, July mean repeat-contact rate 12% ← same customer within 48h, July items per month 1,800 ← ticket system monthly total[Window] 2026-09-01 → 09-28 (4 weeks)[Owner] Support team, Kim — same metrics monthly after deployment[Hidden costs] rework rate, review time — measured from launch day[Saved time goes to] more throughput (clearing overnight backlog) — not yet confirmed