ROI Before AI Build: A Decision Gate

What does ROI before AI build mean?

ROI before AI build means defining the economic test before paying for architecture, integration, or production code. The test starts with a bounded workflow, a measured baseline, credible alternatives, full lifecycle cost, and a named owner for each benefit. Zyphh's ROI-before-build operating standard treats that evidence as an approval gate, not as a sales forecast.

The gate does not require a perfectly accurate return estimate. AI performance, adoption, usage, exceptions, and maintenance will remain uncertain before a pilot. It does require enough evidence to decide whether to approve a small test, measure an unknown first, choose a simpler option, or stop. The forecast then becomes a hypothesis that the pilot must challenge.

Why must the ROI gate come before solution design?

The ROI gate must come first because early technical choices can turn guesses into sunk costs. CSIRO's AI investment guide asks whether a project starts from a defined problem, has measurable benefits and realistic operating costs, and has been compared with a non-AI approach. Those questions decide whether a build deserves attention before they decide how it should work.

Gate outcome	What the evidence says	Next move
Approve a bounded pilot	The baseline is credible, the low case is acceptable, and the pilot can test the biggest uncertainty	Fund only the smallest scope needed to learn
Measure first	One missing input can reverse the decision	Sample the current workflow or run a manual test
Choose a simpler option	The outcome matters, but AI or custom code is not the least costly route	Compare process repair, product configuration, rules, and buying
Stop	The value is too small, the risk is unacceptable, or no owner can capture the benefit	Close the proposal and keep the evidence

A stop decision is useful. It prevents a polished demo from creating an operating obligation with no defensible benefit. A measure-first decision is also progress because it turns a vague argument into a specific research task.

What evidence should exist before a vendor prices the build?

A vendor should be able to trace its proposal from the current workflow to a measurable future state. The U.S. GAO's AI acquisition review frames a sound business case around build-versus-buy options, suitable data, technical resources, performance measures, cost, and responsibility for ongoing monitoring and maintenance.

Evidence	Credible vendor answer	Warning sign
Workflow boundary	Names the trigger, finish, owner, systems, volume, and exception path	Prices a broad department or job title
Current baseline	Separates active work, wait time, rework, errors, and financial effects	Uses a guessed percentage of payroll
Alternative options	Compares no change, process repair, configuration, buying, and building	Treats a custom AI build as the only option
Benefit logic	States what changes, who captures it, and how the change will be measured	Counts all touched time as cash savings
Lifecycle cost	Includes data work, integration, review, usage, monitoring, maintenance, change, and exit	Shows only the delivery quote
Uncertainty	Provides low, base, and high cases plus a break-even input	Presents one precise return as guaranteed
Pilot decision	Defines a threshold, test period, evidence source, and stop rule	Calls launch or usage a successful result

Which formulas belong in an AI automation business case?

Use net benefit, ROI, and simple payback together because each answers a different approval question. Every measure must use costs and benefits from the same period. For a material or multi-year investment, Finance may require discounted cash flow, net present value, or the company's normal capital method.

Measure	Formula	Decision it supports	Main limit
Net benefit	Total measurable benefits minus total costs	Does the option create more measured value than it consumes?	Hides investment size when shown alone
ROI	Net benefit divided by total costs x 100	How large is the estimated return relative to cost?	Depends on scope, period, and valuation choices
Simple payback	Initial cost divided by monthly recurring net benefit	How long until recurring net benefit repays the initial cost?	Ignores value after payback and the time value of money

The formula is not the gate. The assumptions, alternatives, evidence quality, and stop rule decide whether the number can support action.

How do you establish the current workflow baseline?

Define one trigger, one completed state, one owner, and a representative measurement period. Record run volume, active handling time by role, rework, wait time, errors, exceptions, and any traceable financial consequence. Separate active work from time sitting in a queue.

The baseline is not automatically the benefit. If a workflow uses 500 hours today, automation will not necessarily recover 500 hours. Review, exception handling, customer contact, and oversight will remain. Compare current work with the credible future process, then state whether the difference changes cash, releases capacity, improves service, reduces expected risk, or does none of those things.

Which benefits can you count without overstating ROI?

Count a benefit only when the project changes an owned outcome and the team can explain how it will measure that change. Keep cash, capacity, service quality, and risk separate. The UK Government Digital Service warns that time saved should not automatically become cashable savings because that conversion needs a separate analytical step and assumptions that may not hold.

Cash cost avoided: include a fee, contractor expense, overtime payment, credit, or planned hire only when the project can credibly prevent the spend.
Capacity released: value the reduction in active work with a Finance-approved loaded rate, but do not label it cash unless spend falls.
Quality or service: report errors, corrections, response time, backlog age, completion rate, or another observable outcome.
Risk reduced: monetize expected exposure only when event rate, impact, and expected reduction have defensible evidence. Otherwise keep it as a separate decision factor or control requirement.

NIST's AI Risk Management Framework calls for intended benefits, monetary and non-monetary costs, benchmarks, human oversight, and production monitoring to be documented. That prevents an ROI model from treating model output as free labor.

Which AI project costs are easy to miss?

Estimate the complete operating system, not the demo. The U.S. GAO Cost Estimating and Assessment Guide recommends a defined purpose and scope, technical baseline, assumptions, data collection, sensitivity analysis, documentation, and updates with actual costs. The same disciplines fit a smaller SaaS workflow.

Cost group	Include	Evidence before approval
Initial delivery	Mapping, data cleanup, implementation, integration, testing, security review, training	Scoped work, internal roles, and low, base, and high estimate
Recurring technology	Platform plans, model and API use, hosting, storage, observability, support	Representative volume and current vendor terms
Recurring people	Human review, exceptions, monitoring, maintenance, access changes	Named owner, expected hours, and coverage plan
Failure and change	Retries, incidents, model or schema changes, migration, retraining	Failure cases, repair path, and expected change frequency
End of life	Data export, retention, replacement, contract exit, decommissioning	Exit requirement and accountable owner

What does a worked ROI-before-build calculation show?

Consider a fictional SaaS operations workflow that handles 2,400 records each year. The current process uses 480 active hours plus 45 correction hours. The proposed system is estimated to reduce normal handling by 264 hours and correction work by 27 hours after residual review and exceptions. The Finance-approved loaded cost is $65 per hour.

Base-case line	Assumption	First-year value
Handling capacity released	264 hours x $65	$17,160 benefit
Correction capacity released	27 hours x $65	$1,755 benefit
Implementation	External or internal delivery	$18,000 cost
Internal setup	60 hours x $75	$4,500 cost
Software and model use	$350 per month	$4,200 cost
Maintenance and monitoring	4 hours per month x $75	$3,600 cost
Total	$18,915 benefits minus $30,300 costs	-$11,385 net benefit

First-year ROI is -37.6 percent: (-$11,385 divided by $30,300) x 100. After launch, annual recurring cost is $7,800 and recurring net benefit is $11,115. Simple payback on the $22,500 initial cost is about 24.3 months, assuming benefits arrive evenly and the base assumptions hold.

The result does not approve the build. It says the current scope fails the first-year test and needs about two years to repay the initial cost. The team can stop, find a cheaper option, narrow the scope, accept the longer payback under its normal policy, or collect evidence for a benefit it excluded. It should not add speculative revenue to make the percentage positive.

How should you test uncertainty and break-even?

Run low, base, and high cases, then vary uncertain inputs one at a time. The UK Digital and Data Benefits Framework says scenario testing helps prevent optimism bias, while HM Treasury's 2026 Green Book uses sensitivity analysis and switching values to show where a decision changes.

In the fictional example, zero first-year ROI requires $30,300 in benefits. At $65 per hour, that equals about 466 hours of credible improvement, 175 more than the base case. That gap is the break-even test. If the future workflow cannot remove that work without dropping required review, the team needs a cheaper option or a longer accepted payback period.

Vary coverage, adoption, volume, handling time, exception rate, implementation cost, monthly usage, and maintenance. Explain why each range is plausible. A generic plus or minus 20 percent range looks tidy but does not reveal which assumption can break the case.

What is the seven-part ROI-before-build gate?

The gate is ready when another operator and Finance can reproduce the case and see what would disprove it. Use seven checks. A missing check does not always kill the project, but it must produce a measure-first task or a risk decision rather than a hidden assumption.

Problem and owner: name the workflow outcome, the accountable operator, and why the current state needs to change.
Baseline: use observed volume, active work, rework, delay, errors, and financial effects from the same boundary.
Alternatives: compare no change, process repair, product configuration, ordinary automation, buying, and custom AI where each is credible.
Benefit case: state the outcome, measurement source, capture owner, timing, and whether the value changes cash or capacity.
Total cost: include initial, recurring, people, failure, change, and exit costs for the same period as benefits.
Uncertainty: show low, base, and high cases, the break-even input, and the assumption most likely to reverse the decision.
Pilot and stop rule: define what the pilot must learn, its evidence source, approval threshold, review date, and condition for stopping.

Scorecards can help compare several proposals, but do not let a total score cancel a safety, legal, or data requirement. Some conditions are gates, not weights.

How should buyers hold an AI vendor accountable?

Ask the vendor to show its assumptions in a form your team can edit. A credible partner should explain which inputs came from your records, which remain estimates, what the proposal excludes, and how the pilot will replace uncertainty with observed evidence. It should be comfortable recommending a smaller or non-AI option when that option fits.

Keep the model after approval. Compare actual volume, handling time, corrections, adoption, exceptions, review effort, usage cost, maintenance, and incidents with the baseline. If the system shifts work into an exception queue or creates more review than planned, record that cost instead of protecting the original forecast.

Use the AI automation scoping guide to turn the completed gate into a bounded statement of work. Bring the baseline, alternatives, break-even input, and stop rule to the review. A vendor that cannot work from those materials is asking you to fund a build before it can explain the decision.

Turn this into your own build plan.

Run the Workflow Opportunity Score or book a strategy call. Bring one repeated workflow, the tools involved, and the number that should move.

Run the score

Sources and further reading

FAQ

Can you prove ROI before an AI system exists?

You can test whether a project deserves a bounded pilot, but you cannot prove the final return from a forecast alone. Measure the current workflow, estimate the future state with ranges, identify the break-even assumption, and design the pilot to replace that assumption with observed evidence.

What if the main benefit is quality or risk reduction?

Keep the benefit visible even when it cannot be priced responsibly. Define the quality or risk measure, threshold, evidence source, and owner. Monetize it only when event rates, impact, and expected change have defensible support. A mandatory safety or compliance control does not need a positive ROI to be required.

Should recovered employee time count as savings?

Count it as released capacity using a Finance-approved loaded hourly cost when the future workflow credibly removes active work. Call it cash savings only if payroll, contractor, overtime, or planned hiring spend will fall. Track whether the released time moves to named higher-value work.

What should a vendor provide before an AI pilot is approved?

Require the workflow boundary, baseline evidence, alternatives, benefit logic, lifecycle cost, low, base, and high cases, break-even input, pilot metric, and stop rule. The vendor should separate facts from estimates and name who will own monitoring, maintenance, exceptions, and benefit measurement after launch.