Time saved is the wrong first metric.

The calculator uses a deliberately small model. Gross capacity value equals monthly runs multiplied by minutes returned per run and the loaded hourly value. Expected failure loss equals run volume multiplied by the material failure rate and average consequence. Human-review cost equals the reviewed share of runs multiplied by review time and hourly value. Platform and maintenance cost is then subtracted. The remainder is risk-adjusted expected value.

net expected value =
  gross capacity value
  - expected failure loss
  - human-review cost
  - platform and maintenance cost

This formula is not a forecast engine. It is a disciplined way to expose assumptions that a conventional time-saved estimate hides. It does not assign a value to legal exposure, security compromise, privacy harm, or safety impact. Those may be hard constraints rather than prices. A positive number never overrides a boundary that the organization is not willing or permitted to cross.

The break-even material failure rate is especially useful. It answers a practical question: after review and platform cost, how often may the defined consequence occur before the expected value reaches zero? If the answer is 0.4 percent and the team cannot measure failures more precisely than plus or minus one percent, the business case is not robust. The next investment should be better measurement or a smaller consequence, not a more optimistic slide.

Consider a workflow that processes 2,000 requests per month and returns six minutes of staff capacity on each run. At a loaded value of $40 per hour, the familiar calculation reports $8,000 of monthly value. That number is useful, but it is only the benefit side. Assume 1.5 percent of runs create a material failure and the average recovery cost is $120. Thirty failures create $3,600 of expected loss. If five percent of runs require three minutes of review, that review costs $200. Add $300 of platform and maintenance cost, and expected value is $3,900 rather than $8,000.

The workflow may still be worthwhile. The point is not to reject it; the point is to know which variable deserves attention. In this scenario the failure rate breaks even at 3.125 percent. Reducing review time by one minute saves about $67 per month. Halving material failures saves $1,800. The loss budget tells the team that improving outcome correctness is worth far more than shaving seconds from the review screen.

Now change the consequence. If the same 1.5 percent failure rate costs $500 per incident, expected failure loss becomes $15,000 and the business case turns negative. A workflow architecture that is sensible for classifying internal notes may be reckless for issuing refunds or changing customer access. Automation percentage is not a maturity score. The appropriate autonomy depends on consequence, reversibility, observability, and the evidence available before the action.

A common ROI mistake subtracts every reviewed minute and concludes that more autonomy is always better. Review is a cost, but it can also reduce a much larger expected loss. If a three-minute check catches a $500 mistake, the review path may be the highest-return component of the design. The question is whether the workflow routes the right cases, supplies enough evidence, and allows the reviewer to decide quickly.

Review rates should not be invented from model confidence alone. Use observable rules: missing identifiers, unsupported action types, out-of-range amounts, new destinations, conflicting records, low confidence, ambiguous downstream receipts, or changes that are hard to reverse. Record why a run entered review and what the person decided. That evidence can justify narrowing or widening the boundary later. It also prevents "human in the loop" from becoming a vague box that hides an unmeasured manual process.

Keep the system assistive when the action is irreversible, the consequence is poorly bounded, the correct outcome depends on private context the workflow cannot observe, or the team cannot verify what happened downstream. Also stop when failure evidence is too sparse to estimate a useful range. Absence of observed harm in ten test runs is not a low failure rate; it is a small sample.

A recommendation can still create value. It can gather records, normalize fields, identify exceptions, draft a response, calculate a proposal, or prepare an approval packet. The person then controls the final action. This design may capture most of the handling-time value while removing the expensive failure class from the automated lane. The loss budget helps compare those architectures instead of treating full autonomy as the only successful destination.

NIST's AI Risk Management Framework is useful here because it keeps business context, measurement, and management connected. Its core material calls for the business value or context to be defined and for risk and impact to be measured throughout the lifecycle. A loss budget is one practical worksheet within that larger responsibility; it is not a substitute for governance, stakeholder impact analysis, security, privacy, or domain-specific obligations.

Disclosure: this is a self-directed business and technical analysis by One Workflow Fixed. The calculator runs locally in the browser and the included scenarios are illustrative, not client results, audited savings, financial advice, or evidence of a production deployment.