Decisions & frameworks

Measure what the change returns

Time saved, usable capacity and cash savings are different results. Measure what the freed capacity actually lets the business do.

Pattern Engine · Practical field notes

Saving time does not always create usable capacity. Six minutes scattered across ten interrupted tasks differs from one uninterrupted hour. Neither automatically changes the payroll or creates another sale.

The value of an improvement depends on what becomes possible because of it. Faster response, less overtime and room for another customer are different outcomes. Naming the intended one makes the investment easier to assess honestly.

Measure the capacity you can actually use

Suppose an automation removes a recurring Friday reconciliation. The benefit may be an entire afternoon available for customer work. Another tool saves the same number of minutes in fragments throughout the week but leaves every commitment unchanged. Both can improve the working day; they support different economic claims.

A baseline should therefore capture the shape of the work as well as its duration. Include waiting, interruptions and exception handling. Measure a completed result with an acceptable level of quality, rather than the easiest activity to count.

The GOV.UK guidance on measuring service success combines performance data with evidence from users. That combination helps explain why a promising number did or did not become a practical improvement.

Distinguish capacity from cash

Suppose a hypothetical automation handles 200 requests a month and saves six minutes on each. That suggests 20 hours of gross capacity. If checking exceptions and maintaining the automation takes four hours, the net capacity is closer to 16 hours under those assumptions.

Those hours become cash savings only if spending actually changes. They may instead allow the team to respond sooner, accept more work or reduce overtime. State which result you expect and avoid counting the same benefit twice.

Include subscription, hosting and support costs separately. If additional sales are part of the case, examine the contribution they produce and whether demand and delivery capacity exist. More available time alone does not create customers.

Pair speed with a quality check

One measure rarely tells the whole story. Faster processing can be a poor result if errors increase. More form submissions may be unhelpful if the team receives less relevant information.

Choose a main outcome and a small number of checks that would reveal harm. For a scheduling workflow, you might track time to confirmation alongside corrections and missed appointments. For an internal tool, successful task completion and support requests may be more useful than login counts.

Compare under known conditions

Review the result after people have had a reasonable opportunity to use the change. Note other factors that may explain the difference: seasonality, staffing, a marketing campaign or a change in the type of work arriving.

A before-and-after comparison can guide a decision without proving that software caused every improvement. Be explicit about what the evidence supports. When the stakes justify it, a limited rollout or comparison group may provide a clearer answer.

Decide what the evidence changes

Set a review point and an owner. The result may justify expansion, a correction or retirement of the feature. A measurement nobody uses adds work without improving decisions.

Total cost of ownership covers the continuing investment. Read it alongside this guide so the expected benefit and the effort required to sustain it are considered together.

Measure AI against the finished result

For an AI-assisted build, count review, corrections and integration as well as generation. Compare similar tasks and record the tool and workflow used. A useful experiment should tell you where assistance helps and where the surrounding process needs to improve.

METR’s February 2026 productivity update explains why its later measurements were difficult to interpret because of selection effects. Its earlier study concerned a particular group of experienced developers and early-2025 tools. Neither supports a universal speed claim for today’s projects. Use the research to improve the questions you ask, then measure your own work.

Keep exploring