Business Process Automation: Map It, Then Plan for Failure

Automate a business process by mapping what really happens first, then deciding what the automation does when things go wrong. Most disappointment comes from a workflow that handles the normal case and has no plan for the missing field, the duplicate, or the tool that is down.

Map the process as it is

Write out the steps in the order they occur, who does each, what information moves between them and where it is stored. Include the awkward parts that people handle from memory. A process drawn from how it is supposed to work will not match what you automate.

Mark the exceptions

For each step ask what usually goes wrong. Typical answers:

• Information is missing or in the wrong format.
• The same item arrives twice.
• A rule has an exception that only one person knows.
• A tool is unavailable or a login expires.
• A result looks plausible but is wrong.

Design the failure path

For every exception choose a response: stop and tell a named person, park the item in a visible queue, or retry once. Silent failure is the worst outcome. Anything unsure should wait for a human rather than guess, and you should be able to pause the whole workflow quickly.

Hypothetical worked example

Imagine a small wholesaler whose orders arrive by email and need entering into a spreadsheet before an invoice is prepared. The map shows five steps, and the owner realises one customer always sends orders as photographs of handwritten lists. Automation is agreed for the typed orders only. Missing quantities go to a queue labelled for review, duplicate order references are flagged, and any failure sends a note to the office manager. Invoices are prepared as drafts, not sent. After testing on a month of old orders, the handwritten ones are left manual. The business is invented.

Test with real cases

Use anonymised past examples, including ones that previously caused trouble. Keep a list of what the workflow handled, what it queued and what it got wrong, and compare after a trial period before relying on it.

Scope and monitoring

The achievable result depends on the tools you use, the access they allow, the scope agreed and how it is monitored afterwards. Costs are agreed once those are clear.

Questions people ask

Keep reading

See reviewing documents and spreadsheets and pilot validation and handover. The AI business guides list everything else, and the AI installation service describes the approach.

More from Dean

• All AI business guides
• AI coaching, consultancy and installation
• UK coverage
• See AI in action
• About Dean