Choose the workflow with the cheapest mistakes

The wrong competition

The first automation workshop can become a contest for the most impressive demonstration. A polished report beats a dull document check. A conversational assistant beats a queue tidy-up. Meanwhile, the business learns very little about running either safely at volume.

Our suggestion is to select a first workflow by three things: how clearly success can be checked, how cheaply an error can be reversed and whether someone owns the whole process. Time savings matter, but they should survive those tests.

Different firms will land on different first projects because their processes, controls and data differ. A useful selection process makes those differences visible before anyone starts buying licences.

The Government Service Manual recommends using prototypes to test assumptions and interfaces. For an advice workflow, that suggests a pilot built around the doubtful handoff, rather than a demonstration using only the cleanest documents. The reference is a design aid from government, not an advice-firm requirement.

Start where the answer is observable

Consider checking whether a case contains a required document. The automation can propose present, missing or uncertain. A reviewer can inspect the evidence and correct it. The outcome is narrower and easier to test than whether an entire advice document is good.

Even this apparently simple task needs a definition. Does any file with the right name count? Must it refer to the right client? Must it cover the relevant period? A document can exist without being the document the workflow requires.

Write those conditions before building. They form the acceptance criteria and expose where the process already relies on unwritten judgement. If experienced staff disagree on the correct answer, resolve that disagreement before asking software to reproduce it.

Price the exception

An automation that handles routine cases quickly may still create a costly review queue. Track the effort spent investigating uncertainty, correcting output and recovering from failures. Include the work done by the person supporting the system.

Use net time saved: manual effort displaced, less review and exception effort. Treat the result as a local measurement, not a forecast to multiply across the whole firm before the workflow is stable.

The Government Data Quality Framework treats fitness for purpose as central to data quality. Applied here, that means choosing data checks for the intended action. A broad clean-data score cannot tell you whether this particular case can proceed.

A reversible pilot with a stop decision

Run the proposed automation alongside the existing process initially. Let it prepare results without changing consequential records or sending messages. Compare its decisions with reviewed outcomes and investigate disagreement.

Then allow a limited action with a clear reversal path. Record what changed, which input caused it and how an operator can restore the prior state. A workflow that cannot explain its own changes is harder to expand responsibly.

Avoid a pilot that works only because its creator watches every run. Nominate an operational owner and test what happens when that person receives a failure with no technical explanation attached.

Set the decision before seeing the results. The pilot should demonstrate acceptable error handling, a manageable exception queue and a worthwhile reduction in total effort. Define what would cause the firm to stop or redesign it.

A disappointing pilot can still be useful if it reveals that the bottleneck is unclear policy or inaccessible evidence. Do not count that as proof automation cannot work. Count it as information about what must change first.

The strongest first project earns permission for a second one by making both success and failure legible. An impressive demo earns applause. A recoverable workflow earns a place in operations.