Guides for your business
Test the automation before you trust it.
A successful demo only shows that one case worked. Before a process depends on it, find out what happens when information is missing, a task arrives twice or a connected tool stops responding.
By Max O’Sullivan
Define what a correct result looks like
Write down the trigger, the information the process needs and the action it should take. Name the person who handles exceptions. Decide which actions must wait for approval and how to pause the workflow.
Illustrative example — not a client result.
For a process that copies enquiries into a shared list, success might mean one record per enquiry, the right contact details and an owner assigned. It should flag incomplete entries instead of guessing and shouldn’t send a customer reply during the test.
Try the cases a demo leaves out
Use made-up records in a separate test destination. Don’t connect the test to customer messages, payments or other live actions. Avoid putting private business or customer information into a new tool just to see what it does.
- A normal, complete entry
- Does it produce exactly the expected result in the right place? Compare the stored values, not just the “success” message.
- Missing or unexpected information
- Try a missing email address or an unfamiliar format. The workflow should flag the entry for review rather than silently lose it or invent a value.
- The same entry arriving twice
- Repeat the input and try a retry after a failure. Check that the agreed duplicate-handling rule prevents an unwanted second action.
- A connected tool being unavailable
- Simulate the failure in the test setup. Check who sees the problem, what remains unfinished and how it can be retried without repeating completed actions.
- An unclear AI result
- If AI is involved, use ambiguous wording and examples with known answers. Check that a person can see the source, correct the output and stop it reaching the next step.
Keep a simple test record
For each case, note the input, expected result, actual result, pass or fail, and any correction needed. Don’t count a case as passed just because it completed without an error message.
Record time spent doing the original task, then time spent running, checking and correcting the test version. Include exceptions and any ongoing cost. Use a representative mix of easy and awkward cases; one smooth run is not enough to judge the workflow.
There’s no universal pass rate that makes an automation ready. Decide your acceptance conditions before testing, based on the consequences of a mistake. A wrong internal label and an incorrect customer commitment need different controls.
Decide whether to use it, change it or stop
If the checks pass, start with a small, supervised part of the real workload and an agreed fallback. Keep the original process available until the replacement is dependable. Make sure the owner knows how to pause it and reconcile unfinished work.
If corrections outweigh the benefit, simplify the process or change the approach. If the workflow depends on an AI judgement you can’t reliably check, reduce its role. The AI vs automation guide can help you reconsider the choice.
Repeat the relevant checks when the process, connected tool or AI setup changes. The decision to rely on it belongs to the person responsible for that work, not to a successful demo.