1:51Process automation: when are fixed rules enough?
Use a fictional purchase request to learn when fixed workflow rules are sufficient and how to check clear states, repeated requests and exception paths.
Source articleProcess automationUse a fictional service request to see how teams can automate handovers with clear information, meaningful states, accountable owners and exception paths.
The spoken explanation, organised by chapter.
Automation often begins with a handover between people, rather than with a new tool.
A fictional installation company receives an enquiry. Sales calls it approved, but scheduling lacks the address and expected job duration. The request was forwarded, yet nobody knows who should fill the gaps.
Start at receipt and finish at the agreed outcome. For each transition, record the information required, who supplies it and who retains responsibility when something is missing.
Received, complete and scheduled mean different things. Define when each state may change. A forwarded email alone does not confirm that another team has accepted the work or taken ownership.
Fixed fields and explicit decisions often need only rules or an integration. AI can help interpret free text, but it cannot reliably invent a missing address or resolve unclear responsibilities.
Decide what happens when a request is rejected, cancelled or incomplete. Make its current owner visible and show how staff can continue after a correction without starting everything again.
Run through an ordinary request, repeated delivery and an interrupted connection. Check state, owner and destination. Measure waiting and recovery work too; making one stage faster may create extra work elsewhere.
Begin with one recurring handover and the teams involved. Clarify the agreements first. Then automate the stages whose inputs, responsibilities and intended outcomes are sufficiently clear to test.
Read OXIAE’s business process automation guide for practical handovers and exception paths.