The business case for an agentic programme: ROI, payback and what to measure

Nobody can tell you without looking at your process, and a supplier quoting a figure beforehand is quoting somebody else's business. Cost avoided becomes money only when a headcount, contract or licence changes. Capacity released becomes money only once someone decides where it goes. Revenue or loss changed is strongest and hardest to attribute. Against those sit a build cost, quotable from published rates, and a run cost: inference, retrieval, human review, monitoring and re-evaluation on every model change. Tenhaw publishes no return figure from an agentic system, having taken none into production; its 60% lead-time reduction at Globelynx was delivery-transformation work. A case naming all three benefit types, pricing both and adjusting for optimism bias is defensible; one 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 benefit's owner and the date it gets measured. Tenhaw publishes the method behind these steps in full, free to adopt, so a team can work through them without hiring anyone.

A proof of concept is bought to remove uncertainty rather than to pay back; treating it as an investment with a return is how organisations end up defending a two-week build as though it were a product. It buys a measured answer on whether the workflow can be done, an accuracy read on real data, and an estimated run cost, which together decide whether the larger production commitment is worth making. If the answer is no, it has paid for itself several times by preventing that commitment. Tenhaw's proof of concept for a London specialty insurance business took PDFs to business intelligence on Azure in two weeks, ground the business had circled for roughly a year, and the client owned the work product either way.

Any invented number would describe Tenhaw's workloads rather than yours, so it estimates a run cost per candidate workflow before anything is committed to. The lines are consistent and you can build the figure yourself. Per-run model cost, driven by the number of turns the agent takes and the tokens in its context each time. Retrieval and index maintenance, including re-embedding when the corpus or embedding model changes. Human review, set by your routing design rather than the technology, and usually the largest line in a regulated process. Monitoring and observability. And re-evaluation on every model version change, a recurring cost most plans treat as a one-off, and the line that decides between designs.

Not as savings, no. Count them as a measurement of the change, then do the second piece of work and establish 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 worth money only once someone decides what that something else is and attaches a value. If nothing changes, the hours are real and the money is not. Writing that distinction into the case protects you twice, since it survives scrutiny and 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, surface that 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.

In stages, with a real decision point between them, because duration is the largest unpriced risk in most AI business cases. Short fixed-price stages turn the commitment into a sequence of small ones. Tenhaw's founder co-designed a target operating model at HSBC Global Payment Solutions, 500 teams against a $450M portfolio, piloted first, with a global rollout due in 2026 and not yet begun. Analysis of 1,355 public-sector IT projects, averaging $130m over 35 months, found that every additional year of duration added about 4.2 percentage points to expected cost overrun, and that 18% overran by more than 25%. That risk applies whoever delivers, Tenhaw included. A case built on stages you can stop is worth more than a plan you have to believe.

Build the cost side first, because it is the half you can actually know. It is made of three lines you can know before approval: a fixed-price diagnosis, a fixed-price proof of concept if the diagnosis warrants one, and a build team charged by the month if the proof of concept earns it. Tenhaw fixes each stage separately, agrees the exit date at kickoff and works on 30 days' notice either way, so the commitment can be stopped between stages rather than only forecast. Estimate the run cost per workflow separately, then argue about the benefit.

Three questions, in this order: whose process the figure came from, who verified it, and what the denominator was. A return quoted before anyone has looked at your workflow is describing somebody else's business, because it is the shape of your process, its volume, its error rate and the review it needs, that decides whether any of it transfers. Then ask whether the figure was realised or only projected, and if it was realised, what baseline it was measured against and who agreed that baseline before the work started. Arithmetic you can rework beats a headline you cannot, whoever is presenting it.

Yes. A stress test asks what a sceptical reviewer will ask. Is every benefit labelled as cost avoided, capacity released, or revenue or loss changed? Does anything rest on hours saved without a headcount, a contract or a capacity constraint actually moving? Is the run cost priced beside the build, or is the payback measured against half the cost? James Rooney runs that review personally, as he does every Tenhaw engagement, and reviewing an existing case is shorter work than writing one from scratch. What usually changes is not the conclusion but the size of the number and the confidence attached to it, which is what makes a case survive its second reading.

The discipline transfers, and the Green Book is the most useful free document a finance director can read on this even though it was written for public-sector appraisal. It sets a business case out as five interconnected perspectives, strategic, economic, commercial, financial and management, and is explicit that these are not five separate documents. It also puts benefits realisation, the plan for monitoring costs and actually realising the stated benefits, inside the management case rather than treating it as something that happens afterwards. For an agentic programme that is exactly where the run cost owner and the measurement date belong, and it is the section Tenhaw most often finds empty.

Measuring one process properly, in currency and as it actually runs today, is about a fortnight of work. That fortnight is the foundation of everything else, because a benefit is the difference between two numbers and most cases only ever produce the second one. Tenhaw's own version of that job runs four weeks and covers several candidate processes with an estimated run cost each, a costed plan in three-month increments capped at twelve months and a do-not-do list. What stretches the timeline is rarely the arithmetic. It is getting the person whose numbers move to agree the measurement.

They should be able to, because a case nobody can rework is a case nobody can check. Every figure should carry the assumption it rests on and a stated confidence, and the whole thing should arrive in a form your finance function can put its own numbers into rather than as a PDF. Tenhaw hands that model over as work product the client owns outright, so your team can take it apart without asking anyone's permission. That matters because the assumptions most worth changing are yours: the fully loaded cost of an hour, the discount rate you apply, what the rework rate really is once somebody measures it. Finance revising the figures downwards is a good outcome rather than an argument.

Yes, and it is usually the most certain return in the document. A programme that avoids a seven-figure commitment to the wrong workflow has produced something real and immediate, which no projected benefit sitting two years out can match. So write the do-not-do list, the things not worth doing here and why, into the business case itself rather than into an appendix, and put the avoided commitment in currency beside the benefits you are claiming. Finance functions understand avoided spend better than anyone else in the building, so it is worth writing in their language. In audit readouts that list is often the most valuable page.

Measure the candidates before you choose, rather than choosing and then justifying. For each one: volume, elapsed time, the people involved, the error and rework rate, and what it costs to run today. That exercise frequently changes which process you would attack, which is worth knowing before you fund the wrong one, and it produces the first of the two numbers any benefit is made from. Favour a process where you can name the person whose budget or performance numbers move if it improves, because a benefit nobody is willing to own is usually a benefit nobody believes in. A process you cannot measure today is not a first candidate, it is a measurement job.