Automation projects are usually designed around the happy path: the invoice that matches its purchase order, the order with a valid customer number, the support request that fits neatly into a category. The happy path is easy to demo and easy to estimate. It is also the part that would have caused the least trouble anyway.

What decides whether automation works in production is how it handles everything else. The mismatched invoice. The duplicate order. The email in a language nobody expected. If exceptions are an afterthought, they land in someone’s inbox without context, and the time saved on the happy path is spent untangling them.

Start by listing the exceptions

Before designing any automated flow, collect real cases from the current process over a few weeks. For each case that did not go smoothly, note what went wrong, how it was spotted, who resolved it and what information they needed. Then group them. Often a few exception types cover most of the volume, with a long tail of one-offs behind them.

This list is the design input. The common exception types deserve their own handling. The long tail needs one reliable route to a person.

Decide what the system may do alone

For every decision point in the flow, assign one of three modes:

  • Automatic. The system acts and logs what it did. Use this where the rules are clear and a wrong action is cheap to reverse.
  • Suggest and confirm. The system prepares the action and a person approves it. Use this where judgment matters or a mistake is expensive.
  • Hand off. The system recognizes it cannot decide and routes the case to a person, along with everything it has collected so far.

Make the boundaries between these modes explicit and easy to adjust. A common pattern is to start conservatively, with more cases in suggest-and-confirm, and move categories to automatic as the team sees how the system behaves.

Design the review queue as a product

The person handling an exception is a user of the automation, and their screen deserves the same design attention as the happy path. A good review queue:

  1. Explains why the case is there. “Amount differs from the purchase order by more than the agreed tolerance” is actionable. “Validation failed” is not.
  2. Shows the relevant context. The source document, the records it was matched against, the history of the customer or supplier.
  3. Offers the likely actions. Approve, correct a value, reject, escalate, ideally one click each.
  4. Records the decision and the reason. This is the raw material for improving the rules later.
  5. Sorts by urgency, not arrival time. A payment due tomorrow matters more than one due next month.

Set ownership and time limits

Every queue needs an owner and a service level. Decide in advance who handles each exception type, how quickly, and what happens when a case sits too long. Without this, exceptions pile up quietly until a customer or supplier complains. Plan for absences as well. A queue that depends on one person stops when that person goes on holiday.

Use exceptions to improve the system

The decisions people make in the review queue are the most useful feedback the automation will ever get. Review them regularly:

  • If reviewers approve the same kind of case every time without changes, that category may be ready for automatic handling.
  • If they keep correcting the same field, the problem is probably upstream, in a form or an integration.
  • If a new exception type appears, the process around the automation has probably changed.

Track a few simple measures: the share of cases handled automatically, the volume in each queue, how long cases wait, and how often reviewers override the system’s suggestion. The trends tell you where to work next.

Common mistakes

  • Sending every exception to a shared mailbox with no structure.
  • Handing off a case without the data the system already gathered, so the person starts from scratch.
  • Setting confidence thresholds once and never revisiting them.
  • Measuring success by automation rate alone, which rewards pushing doubtful cases through.
  • Forgetting that people who used to do the whole task now see only the hard cases, and may need different training and more time per case.

If you are planning an automation project, a good first step is to sit with the people who run the process today and collect a few weeks of real exceptions. That list gives a more honest estimate of the work than any happy-path demo, and it shows where human judgment needs to stay.