The AI Workflow Baseline Template

What should you measure before automating a workflow? Record eligible volume, human touch time, waiting time, completion and service levels, first-time-right quality, rework, exception types, full cost and customer impact over a representative period. Define every measure, its source, owner and calculation before the pilot. Then compare like-for-like cases and keep quality and risk beside speed and cost.

A baseline is a measurement contract

A baseline is not a single “hours saved” estimate. It is the agreed definition of the current process, the cases included, the observation period, the measures, the data sources and the assumptions that will be held constant when the new workflow is assessed.

This matters because automation changes the shape of work. A task may take less active time but create a review queue. More cases may be completed while difficult cases are quietly excluded. A team may report fewer errors while customers make more repeat contacts. A credible baseline makes these trade-offs visible.

The GOV.UK Service Manual recommends establishing current performance across channels and measuring continuously so trends, seasonal variation and the effect of changes can be distinguished. NIST's AI Risk Management Framework similarly calls for context-relevant benchmarks, documented measures and comparison of deployed performance with expected conditions. For an SME, the practical version is simple: write down exactly what “better” means before building.

The seven-part automation baseline

Measure the entire journey, not just the step you intend to automate. If invoice extraction takes three minutes but approval waits two days, extraction speed is not the main service constraint. If a support response is drafted quickly but reopened repeatedly, the useful outcome is resolution, not draft creation.

1. Define the unit of work and eligibility

Choose one countable unit: an enquiry qualified, invoice posted, order confirmed, case resolved or report accepted. State when it begins and ends. Then define eligibility. Are handwritten invoices included? Are multi-entity customers included? Does a reopened case count once or twice?

Segment the cases that materially change effort or risk. Useful segments can include standard versus complex, language, channel, customer tier, document quality, value band and whether an approval is required. Without case-mix data, an apparently faster pilot may simply contain easier work.

2. Separate touch time from waiting time

Touch time is active human work. Waiting time is time in queues, inboxes, handoffs or dependency gaps. Cycle time is the full elapsed journey from the defined start to the defined end. Record all three.

Use event timestamps where systems already capture them. Sample human activities directly for a defined period instead of asking people to estimate a typical day from memory. Record interruptions and batching rules. An average alone can hide long-tail delays, so report a median and a high percentile or a service-level percentage where the sample supports it.

3. Define accepted quality

Write an operational acceptance rule. For example: the record is complete, values match supporting evidence, the correct policy was applied, no material correction is required and the downstream system accepts the transaction. Count first-time-right cases, corrections, rejected outputs, repeat contacts and downstream reversals.

Do not allow faster output to purchase weaker quality. The same acceptance rule should apply before and after automation. If the new workflow adds human review, include that review time and correction rate rather than treating them as somebody else's work.

4. Treat exceptions as a first-class measure

Log why each case left the standard path, who owned it, how long it remained unresolved, how it was recovered and whether it returned safely to the main workflow. A single “manual review” bucket is too vague. Separate missing data, conflicting data, duplicate records, policy ambiguity, system outage, access failure and high-consequence approval.

This exception baseline connects directly to the exception-first automation design. It reveals which cases need deterministic validation, which can be retried, which need a fallback and which require accountable human judgment.

5. Calculate full cost per accepted outcome

Include active labour, supervision, software, outsourced processing, correction, repeat work and predictable failure cost. Divide the recurring process cost by accepted outcomes, not raw attempts. Keep one-off implementation cost separate so the operating comparison remains understandable.

The U.S. Bureau of Labor Statistics defines labour productivity as output relative to hours worked. The business translation is important: a reduction in touch time creates potential capacity, not automatic cash savings. Record how released time will become additional accepted work, shorter service time, reduced overtime, avoided contractor spend or another evidenced result.

6. Choose a representative measurement window

Use enough observations to cover normal variation and at least one realistic peak or difficult case set. Record holidays, campaigns, month-end, staffing gaps, backlogs and policy changes. If the available window is weak, label the baseline provisional and plan a longer parallel measurement during the pilot.

Freeze the original baseline; do not rewrite it after results arrive. If the business process genuinely changes, create a new comparison period and explain the break. Preserve the old view so decision-makers can distinguish improvement from changed demand.

A completed example

The figures below are an illustrative supplier-invoice baseline, not a claim about Shuhaib's clients or a promised result. Its purpose is to show the level of definition required.

The automation business case would compare accepted cases, total cycle time, first-time-right rate, exception ageing and cost per accepted case. It would not multiply 14 minutes by every invoice and call the result savings without measuring review work, adoption and actual redeployment.

Use the downloadable sheet

1. Assign an owner. One operations owner signs off definitions; finance validates cost treatment.
2. List sources. Name the report, event, queue, timesheet sample or manual log behind every measure.
3. Capture the window. Record dates, case count and known distortions.
4. Complete the baseline. Add values by segment and note uncertainty.
5. Set the pilot comparison. Use the same eligibility and acceptance rules.
6. Predefine the decision. State which combination of outcome, quality, risk and cost permits scale, change or stop.

Download the baseline template (.csv)

Common baseline mistakes

• Using a manager's estimate as measured fact. Label estimates and replace them with observed data.
• Measuring only the automated step. Include queues, approvals, corrections and downstream reversals.
• Comparing different case mixes. Keep eligibility stable and segment complexity.
• Counting attempts instead of accepted outcomes. Define useful completion and quality.
• Converting all saved time into money. Document the capacity-realisation path.
• Ignoring customer and control outcomes. Pair efficiency with service, complaints, privacy, policy and risk measures.

Connect the finished baseline to the AI outcome scorecard, the confidence-adjusted ROI model and the AI automation audit. Together they turn an automation proposal into a falsifiable operating decision.

Primary sources checked

Checked 9 September 2026. The template is Shuhaib's practitioner framework and should be adapted with the process owner, finance owner and affected users.

• GOV.UK Service Manual — how to set performance metrics
• GOV.UK Service Manual — using performance data
• NIST AI RMF Core — Map, Measure and Manage
• U.S. Bureau of Labor Statistics — productivity calculation