The business case, answered in full.

Nobody can tell you without looking at your process, and a supplier who quotes a figure before doing so is quoting somebody else's business. What can be said generally is the shape of the answer. The return is made of three components: cost avoided, which becomes money only when a headcount, contract or licence actually changes; capacity released, which becomes money only if someone decides where the released capacity goes; and revenue or loss changed, which is the strongest and the hardest to attribute. Against that sits a build cost, which is quotable from published rates, and a run cost, which is per-run inference and retrieval, human review, monitoring, and re-evaluation on every model change. A case that names all three benefit types, prices both cost types, and adjusts for optimism bias is defensible. A case built on hours saved is not.

Six steps and none of them starts with technology. Measure the current process in currency: volume, elapsed time, people, error and rework, total cost to run today. Estimate the future state and split the difference into cost avoided, capacity released, and revenue or loss changed, labelling each. Attach a confidence and the underlying assumption to every line. Price the build from a published rate card and the run per workflow, before approval rather than after. Adjust explicitly for optimism bias by increasing costs and duration and reducing benefits, and show the adjustment. Then name the person who owns the benefit and the date it gets measured. Our Agent-Readiness Audit produces exactly this, over six to eight weeks at a fixed £30,000 to £90,000, alongside the sequenced costed plan and the do-not-do list.

A proof of concept is bought to remove uncertainty rather than to pay back, and treating it as an investment with a return is how organisations end up defending a two-week build as though it were a product. The arithmetic that is checkable is the cost side: ours is a fixed £20,000 to £55,000 over two to four weeks, and you keep the working code and the requirement corpus whichever way the decision goes. What it buys is a measured answer on whether the workflow can be done at all, an accuracy and confidence read on your real data, and an estimated run cost, which together determine whether the far larger production commitment is worth making. If the answer is no, the proof of concept has paid for itself several times over by preventing that commitment, and that is the return worth counting.

Any invented number would describe our workloads rather than yours. The lines to estimate are consistent though, and you can build the figure yourself. Per-run model cost, driven by how many turns the agent takes and how many tokens go into its context on each one. Retrieval and index maintenance, including re-embedding whenever the corpus or the embedding model changes. Human review, which is set by your routing design rather than by the technology, and is usually the largest line in a regulated process. Monitoring and observability. And re-evaluation on every model version change, which is a recurring cost most plans treat as a one-off. Our audits produce an estimated run cost per candidate workflow before anything is committed to, precisely because this is the number that decides between designs.

Not as savings, no. Count them as a measurement of the change and then do the second piece of work, which is establishing what happens to those hours. If a fixed-term contract ends or a vacancy goes unfilled, that is cash and it belongs in the case with the date it lands. If the time returns to people who then do something else, it is capacity released, and it is only worth money once someone decides what that something else is and attaches a value to it. If nothing changes, the hours are real and the money is not. Writing that distinction into the case protects you twice: it survives scrutiny, and it stops the programme being judged in a year against a saving that was never going to appear in a ledger.

By adjusting for it deliberately and visibly, which is what public-sector appraisal guidance has required for years. The Green Book defines optimism bias as the proven tendency for appraisals to be over-optimistic about key assumptions and instructs appraisers to increase their estimates of cost and duration and decrease their estimates of benefit. Three practical habits follow. Show the adjustment as its own line, so reviewers can see it rather than hunt for it. Have someone outside the programme write the pessimistic case, not the sponsor. And treat duration as a priced risk rather than a scheduling detail, because the published evidence on IT programmes is that cost risk rises with every additional year of runtime.

Four things, monthly, and only the first is about the technology. Run cost per unit of work, against the estimate made before approval, because that is where an unpleasant surprise shows up first. Volume actually processed by the system rather than volume it is capable of processing, since adoption is usually the constraint. The exception rate and therefore the human review hours the system is really consuming, which is the line that quietly eats the benefit. And the benefit itself, measured on the agreed date by the named owner, against the figure in the approved case rather than against a revised one. If the fourth measurement has no owner and no date, the first three will be reported and the programme's result will never actually be established.

The person whose budget or performance numbers move, which is almost never the person who sponsored the technology. Get them to agree the measurement and the date before the build starts, because agreeing it afterwards is a negotiation and agreeing it beforehand is a specification. The same person should also own the run budget, since a benefit owner with no cost exposure has an incentive to be generous. Where no such person exists, that is worth surfacing immediately: a process nobody owns end to end is a programme risk long before it is a measurement problem, and it usually means the first piece of work is establishing the ownership rather than building anything.