01
Begin with a baseline, not a benefit claim
Before changing the workflow, observe a representative period and record volume, completion time, waiting time, manual touches, rework, errors and exceptions. Note who performs the work and which systems are involved. A baseline turns a general complaint into a testable operating problem.
Do not treat every minute removed from a task as cash returned to the company. Time may create capacity, faster service or lower overtime without reducing payroll. State which kind of value the project is expected to create and measure that outcome directly where possible.
02
Measure the complete workflow
A local improvement can move delay downstream. Track the process from its real trigger to the business outcome so a faster data-entry step is not mistaken for a faster customer result.
Cycle time
Elapsed time from the trigger to a completed outcome.
Waiting time
Time work spends blocked between people, approvals or systems.
Manual effort
Active staff time spent copying, checking, chasing or updating.
Quality
Errors, rework, corrections and incomplete records.
Reliability
Successful runs, failed integrations, retries and unresolved exceptions.
Commercial result
Qualified responses, completed appointments, conversion or retained capacity where attribution is credible.
03
Include the real cost of ownership
Implementation cost includes discovery, design, configuration or development, integration, testing, migration, training and launch support. Ongoing cost includes software subscriptions, model usage, monitoring, maintenance, vendor changes, security work and exception handling.
A low-code workflow can be the right choice and still require ownership. A custom application can create strategic value and still be unjustified for a small, unstable process. Compare alternatives using the same time horizon and the same definition of success.
04
Use a transparent calculation
A simple ROI calculation is: measured benefit minus total cost, divided by total cost. The calculation is only as credible as its inputs. Label assumptions, show the measurement period and separate observed results from forecasts.
For a pre-implementation decision, use a range rather than a single precise figure. Test what happens if adoption is slower, volume is lower or support costs are higher. A project that works only under the most optimistic assumptions is not ready for approval.
HM Treasury's Green Book is written for public-sector appraisal, but two principles transfer well to business automation: compare credible options rather than one proposal in isolation, and test sensitivity when costs or benefits are uncertain. ZAI adapts those principles to a smaller operating decision; it does not claim that a commercial workflow assessment is a formal Green Book appraisal.
Apply the same evidence standard to every option under review.
05
Review adoption and exceptions after launch
Measure whether people use the workflow correctly and whether exceptions are resolved. If staff bypass the system, the expected benefit will not appear even when every technical step works. Interviews and process observation can explain metrics that a dashboard cannot.
Review the first release at agreed intervals. Keep, improve or retire automation based on evidence. ZAI uses this approach because an honest negative result is more useful than an attractive metric that cannot guide the next decision.