How to Measure AI ROI: Build a Workflow Evidence Log
Record a comparable baseline, preparation and review time, exceptions, costs, and the use of returned capacity before reporting an AI workflow result.
A credible AI ROI calculation begins with a record of how the work runs before the change. Without that baseline, faster preparation can be mistaken for lower costs, and increased activity can be mistaken for increased value.
This article explains what to record before and after launch. The equations, assumptions, and calculator belong in our AI ROI guide. Use both: the guide defines the model; your measurement log supplies the evidence.
Define a comparable unit of work
Choose a unit with a clear start and finish: an invoice prepared for approval, an inquiry routed to its owner, or a document package assembled for review. Record the workload and the conditions that affect it. A routine invoice and a disputed invoice may need separate categories.
Use the same definition before and after launch. If the system expands coverage or the incoming work changes, explain the difference instead of treating all observations as equivalent.
Separate preparation, review, and correction
For each observation, record preparation time, reviewer time, correction time, elapsed waiting time, and outcome. Also record whether the workflow escalated, failed, or needed manual completion. Include unsuccessful cases in the comparison.
A draft produced quickly can still create more review work. Measure the completed workflow, including the human effort needed to make it usable. For a knowledge base, record whether the answer used an authorized, current source and whether the user could complete the task.
Record costs alongside the activity
Keep build expenditure, tool subscriptions, model usage, maintenance, and internal operating time separate. State the period covered by each amount and who supplied it. Avoid counting a subscription twice when several workflows share it.
Use the ongoing-cost guide to identify cost categories. A scenario in a calculator should remain labeled as an assumption until you replace it with an observed value.
Explain what returned capacity was used for
Reduced preparation time creates capacity. Cash savings require a further change, such as lower overtime or contractor spending. Revenue-related value requires evidence of an incremental outcome, and should be evaluated using gross profit rather than total sales.
Record the intended use of the capacity and the person accountable for it. If you cannot yet measure that outcome, report the hours separately. That makes the result more useful than converting every saved minute into a financial claim.
Keep a record someone else can inspect
A practical log includes the measurement dates, workflow version, observation count, work categories, preparation and review times, exceptions, operating costs, and the person checking the result. Include a note for missing records, unusual workload, or a changed process.
The MARCUS measurement notes show why reported operational results need clear boundaries. That deployment is founder-affiliated and its public summary omits some underlying measurement detail. It is not a forecast for another business.
Use the findings to decide the next change
Compare the result with the baseline and the acceptance criteria. If review or exception handling consumes the expected benefit, investigate before expanding. If useful capacity is returned but not being used, change the operating plan before claiming a financial return.
Bring a defined workflow and its available evidence to implementation scoping. If the starting point is unclear, request a free workflow plan.
Where this shows upWhat we actually build →
