Is your automation actually helping? A practical SME scorecard.

Define the finish line before counting the minutes

Suppose a small agency wants to automate enquiry handling. A generated summary is not the whole job if a coordinator must still find the customer, check the brief and assign an owner. Define the outcome in operational terms: the enquiry is attached to the correct record, its important facts have been checked, and a named person knows what happens next.

Write the same definition for the current and proposed process. If the new workflow stops earlier, its apparent speed advantage can be misleading. Record requests that remain unfinished as well as those that complete. This article offers a practical pilot scorecard, not a promised return or an accounting method.

Build a baseline your team recognises

Review a sample that reflects ordinary work: straightforward requests, incomplete briefs, duplicates and the occasional awkward exception. Include different staff members and busy periods where they matter. A quiet morning with your most experienced coordinator is useful evidence, but it is not necessarily typical.

The GOV.UK Service Manual recommends establishing a baseline before assessing improvement. Applied to an SME pilot, that means recording current handling time, completed requests and corrections before changing the workflow. Ask staff to check the findings against their experience. If the sample leaves out a common branch of the process, add it before treating the numbers as a comparison point.

Measure the work that reaches a useful finish, including the effort needed to get it there.

Track active effort and waiting time separately

A customer might wait two days for an answer that takes twelve minutes to prepare. Those are different problems. Active effort measures the time people spend doing the work. Elapsed time measures the journey from the agreed start to the reviewed finish. Queue time helps explain the gap between them.

For a Dubai team handing work to a London colleague, a delay may come from working hours or unclear ownership rather than slow drafting. Capture when a request arrived, when someone began reviewing it and when the outcome was ready. An automation that prepares drafts overnight can still leave the same morning bottleneck if nobody owns the review queue.

Use a worked example that includes supervision

Here is an illustrative calculation, not a Codoki client result. Imagine 200 requests taking eight minutes each: 1,600 minutes of staff effort. During a pilot, normal handling and review take four minutes per request, or 800 minutes. Additional exception work takes 120 minutes and routine maintenance takes 60. The new total is 980 minutes, leaving a difference of 620 minutes: ten hours and twenty minutes.

That difference describes measured capacity in this example. It does not automatically reduce payroll or create revenue. Avoid counting exception time twice if it is already included in the per-request figure. Record what the team actually does with any available capacity, such as clearing a backlog or giving customers a more considered response.

Put quality beside speed

A shorter handling time is not useful if more requests reach the wrong person. Keep a small set of quality measures beside the time figures: completed requests, corrections after review, unresolved exceptions and repeat customer contact caused by an incomplete answer. Show the underlying counts so a percentage from a tiny sample is not mistaken for a stable trend.

The Service Manual defines completion rate by comparing completed transactions with those started. For your pilot, keep the start and finish definitions consistent and show requests still in progress separately. Do not make the numbers look better by silently removing difficult cases or failed attempts from the denominator.

Keep operating costs visible without overcomplicating the pilot

Maintain a separate list of the resources the new workflow needs: software subscriptions, model usage, hosting, support and time spent managing changes. Keep one-off setup work visible too, but do not mix it into a weekly effort comparison without explaining the treatment. Your business can then decide which measures it needs for its own budgeting process.

The Service Manual's cost-per-transaction guidance includes the broader cost of delivering a service and supporting its users. The practical lesson here is narrow: the price of an API call is not the cost of operating a workflow. A cheap draft can still require expensive supervision, and a useful improvement may be qualitative rather than financial.

Agree what would justify keeping the workflow

Before the trial begins, ask the process owner to write a short acceptance statement. For example: handling effort should fall, routing errors should not increase, every unresolved case should have an owner, and staff should be able to pause and recover the workflow. These are suggested criteria; your actual thresholds should reflect the task and the consequences of mistakes.

At the review, choose between continuing, changing the design, collecting more evidence or stopping. Compare similar types of work and note other changes, such as new staff or a seasonal surge, that might explain the result. Keep the scorecard after launch so a helpful pilot does not quietly become an unmaintained process.

Put the idea to work.