Measure what changed. Then call it a return.

Define one completed job

Pick a unit the business recognizes: one quote prepared to an agreed standard, one customer request resolved, or one reconciled report delivered. Define completion, quality, and the start and finish points before collecting data. Otherwise the old process gets measured through delivery while the AI process gets measured only until it produces a draft.

Track all eligible requests, not just successful automated runs. Record how many were attempted, completed correctly, sent for manual handling, or left unresolved. Keep elapsed turnaround time separate from active staff time. Waiting overnight and spending an hour correcting an output are different problems.

Build a baseline you can compare

Sample ordinary work alongside difficult and incomplete cases. Record case mix, volume, staffing, active handling time, rework, and the definition of a correct result. Compare the assisted process on similar work. If the pilot handles only easy cases, report that boundary rather than applying its average to the whole business.

A before-and-after comparison can be distorted by seasonal demand, better input data, staffing changes, or a redesigned process. Where practical, compare similar work during the same period or phase the rollout. Document remaining differences. Report observations and uncertainty; do not attribute every improvement to AI.

Keep capacity and cash in separate columns

If salaried staff complete the same work in fewer hours while payroll stays the same, you have released capacity. That can be valuable: the team may clear a backlog, answer customers sooner, or handle additional demand. It is not automatically a reduction in spending.

The UK Government Efficiency Framework distinguishes cash-releasing benefits, which reduce spending, from non-cash-releasing benefits such as staff time made available for other work. That distinction is useful for a business pilot too; it is not a claim that public-sector reporting rules apply to your company.

Count reduced overtime only when spending actually falls. Count additional sales only when you can support the attribution, and use the resulting contribution after incremental fulfillment costs rather than gross revenue. Do not count the same released hours as both labor savings and capacity used to create those extra sales.

Include the cost of getting there

Separate one-time discovery, integration, data preparation, testing, training, and rollout costs from recurring operation. Include internal staff effort when reporting an economic cost view. If you also report a cash-only view, label it clearly and explain which existing staff costs do not create additional cash outlay.

Use the same period and scope for benefits and costs. In a simple undiscounted ROI calculation, subtract total incremental costs from attributable benefits, then divide by those costs. Both numerator and denominator must cover the same horizon. Keep a cash ROI calculation separate from a capacity valuation that uses loaded staff rates.

Simple payback divides initial cash outlay by a positive, steady monthly net cash benefit after recurring incremental cash costs. If adoption ramps slowly or benefits vary, track cumulative cash flows instead. If monthly net cash benefit is zero or negative, there is no positive payback period under that scenario. Longer or material investments need a fuller finance review, not just this screening calculation.

A small example without a fictional success story

Illustrative arithmetic only: suppose 100 comparable items require 12 minutes of staff effort each under the existing process. That is 20 hours. If the assisted process takes eight minutes per item including review, corrections, and exceptions, it uses 13 hours and 20 minutes. The observed difference would be six hours and 40 minutes for that workload.

Those hours are not a dollar saving by themselves. If payroll, overtime, and other spending do not change, cash savings from labor are zero for that period. The capacity may still be useful, but record where it goes. If the assisted process produces worse outcomes or has unresolved work, that must remain visible alongside the time comparison. These numbers are hypothetical, not DBAI client results or a forecast.

Use operational evidence before making a financial claim

DBAI’s SimpliLeads case study describes a dashboard that brings dialer, CRM, calendar, and billing data into one operational view. That kind of connected record helps a team inspect delivery and reconcile what happened across tools. The published scope is evidence of integration work, not a measured ROI result for the framework in this article.

Copy this pilot measurement worksheet

# One workflow — measurement plan
Completed job and quality standard:
Eligible work and exclusions:
Baseline period / pilot period:
Case mix and comparability limits:
Business owner / measurement owner:

## Record in both periods
Eligible and attempted items:
Accepted completions / manual fallbacks / unresolved items:
Active staff minutes, including review and rework:
Elapsed turnaround and backlog:
Errors, severity, and customer consequences:

## Benefits — do not double count
Released hours on comparable work:
Where that capacity was actually used:
Verified spending reductions and evidence:
Attributable additional contribution and evidence:
Nonfinancial outcomes:

## Costs and calculation basis
One-time cash outlay:
Internal implementation effort:
Recurring incremental cash costs:
Recurring internal support effort:
Horizon and basis: cash / economic (label separately):
Benefits and costs over that same horizon:
ROI = (benefits - costs) / costs, where costs > 0:
Uncertainty: lower / central / upper scenario:

## Decision
Quality and permission requirements passed:
Adoption and exception workload:
Continue / revise / stop, with reasons:
Next review date and owner:

Decide using a range, not a promise

Build lower, central, and upper scenarios from uncertainty in adoption, eligible volume, review time, operating cost, and realized benefit. Show which assumptions change the decision. A pilot can justify continued learning without proving a business-wide return; a useful result can also be that a simpler automation is enough.

Agree the review date and the person who can stop or narrow the rollout. Keep quality and permission failures as independent decision criteria. A positive spreadsheet does not excuse an unreliable workflow.