Measure AI workflow return by comparing a clearly defined baseline with the complete cost and useful outcomes of the new process. Include human review, corrections, tools, setup and ongoing maintenance. Keep capacity released separate from cash saved, and do not count proposed sales as revenue.
This guide turns that principle into a simple pilot worksheet. It extends Klarnow’s earlier essay on AI economics with fields, sample calculations and decision gates. All numbers below are illustrative assumptions for explaining the method. They are not Klarnow client results, tool prices or forecasts.
1. Define a useful completed outcome
Choose an output the business can verify. For enquiry handling, that could be a correctly recorded request with an owner and approved next action. For proposals, it could be a reviewed draft based on an accepted brief. Avoid units such as prompts generated that do not tell you whether the work helped.
Define quality before timing the task. A result should meet the agreed accuracy, completeness and handover requirements. Record incomplete and failed attempts too. Otherwise the apparent cost per outcome improves simply because inconvenient cases disappeared from the calculation.
2. Record a baseline over a comparable sample
For the current process, record attempts, useful completions, staff minutes and corrections. Note the date range and the mix of easy and difficult cases. If one period includes simple enquiries and another includes unusual requests, the difference cannot fairly be attributed to AI.
An initial small sample helps expose problems, but it cannot establish a reliable long-term improvement. Repeat the comparison across ordinary operating conditions before making a larger commitment. Keep seasonal changes, staffing changes and different customer demand visible in the notes.
3. Count the whole new workflow
Measure time spent preparing context, reviewing drafts, correcting mistakes, handling exceptions and updating approved information. Include the relevant share of subscriptions, usage, integration costs and implementation work. Record the basis of any allocation rather than pretending it is exact.
For the pilot, keep these fields: attempts; useful completions; human minutes; errors; rework minutes; tool and usage costs; setup cost; and owner decision. A cheaper model response can still produce a more expensive process when its output needs extensive correction.
4. Calculate capacity released without calling it cash
Illustrative monthly example: the existing process handles 100 comparable enquiries at 12 human minutes each. That is 1,200 minutes, or 20 hours. The supervised AI process needs six human minutes per enquiry plus two hours of monthly upkeep: 12 hours in total. The difference is eight hours.
At an assumed internal planning rate of £20 an hour, those eight hours have a capacity value of £160. If allocated tool and integration costs are £60, the net capacity value is £100 before setup. The £20 and £60 figures are assumptions used only for this example.
If setup took £400 of paid work or allocated time, a simple capacity-value payback calculation is four months at £100 per month, assuming performance and volume remain unchanged. That is not a promise of payback. Salaried hours released do not automatically reduce the payroll or put £100 into the bank.
5. Keep sales value separate and attributable
A better response process may contribute to more sales, but compare verified outcomes over an appropriate period. Count collected revenue separately from contracts and invoices. For contribution, subtract the costs of delivering the additional work; extra revenue is not all available profit.
If a lead saw an article, received a follow-up and then spoke to the founder, record that mixed journey. Do not assign the entire sale to AI because it touched one message. Where attribution is uncertain, state that the workflow influenced the opportunity rather than claiming it caused it.
Avoid counting the same benefit twice. If released staff time was used to make additional sales calls, do not add both its full capacity value and all resulting contribution without explaining the overlap. Present alternative scenarios when a clean attribution is not available.
6. Check quality and failure costs
Track serious mistakes, reopened work, duplicate messages, missed handoffs and complaints. Some failures are too consequential to offset with a large number of cheap successes. Define stop conditions before the pilot, including invented commitments or unauthorised actions.
OpenAI’s evaluation guidance explains how traces and repeated evaluations help inspect workflow failures and compare changes. For a small manual pilot, an equivalent starting point is a row-by-row review of inputs, drafts, corrections and final outcomes using consistent criteria.
7. Make a keep, revise or stop decision
Keep the workflow when it meets the agreed quality threshold, returns useful capacity or contribution, and has an owner able to maintain it. Revise when the value appears promising but the failure pattern is identifiable. Stop when review effort, errors or operating complexity outweigh the benefit.
Treat “more testing needed” as a valid result. A pilot earns expansion through evidence; it does not need to justify the decision to try AI. Record what changed, why you kept or stopped it and when the evidence should be reviewed again.
Use the free starter kit’s seven-day tracker to collect the first observations. If the business cannot yet define a successful handover, start with a diagnosis. Measurement becomes easier once the objective, record and owner are clear.
Sources & further reading
AI-assisted Klarnow editorial analysis. Sources checked on 31 October 2026. Workflows, sample sizes and financial examples are illustrative recommendations, not client results or guaranteed outcomes.