Automation projects often begin with the easiest version of a process: a request arrives, someone checks it, a system updates, and a notification goes out. That description may be accurate, but it is rarely the whole job. The work that consumes time is often hidden in the exceptions: missing information, duplicate requests, unusual approvals, corrections, and cases that do not fit the system’s assumptions.
Mapping those exceptions before building an automation makes the project more useful and safer. It helps a team decide what software should handle, where a person should review, and what should happen when the workflow cannot continue.
Start with the user’s real journey
Do not begin with a list of software features. Begin with one concrete outcome, such as approving a purchase request, onboarding a new client, or routing a service ticket. Talk with the people who submit the request, process it, approve it, and handle the unusual cases. They may describe different versions of the same process.
Write down the steps in plain language. Include the handoffs between people and systems, the information needed at each step, and the point at which someone knows the work is complete. A simple map on paper is enough for the first pass. The goal is shared understanding, not polished documentation.
Separate the normal path from the exception paths
Draw the most common path first, then ask a deliberately uncomfortable question at every step: “What makes this stop being the normal case?” Examples include:
- A required field is blank, outdated, or contradictory.
- The same request arrives twice or refers to an existing record.
- An amount, customer type, or data category requires another approval.
- A connected service is unavailable or returns an incomplete response.
- The person responsible is out of office or no longer owns the work.
- A customer changes the request after processing has started.
Record what staff do today when each exception occurs. This is where informal knowledge becomes visible. Someone may keep a spreadsheet, send a message to a colleague, or use a rule that exists nowhere in the official process description. Those workarounds are design evidence, even if they should eventually be replaced.
Classify decisions by risk
Not every decision deserves the same automation treatment. Classify each step using questions such as:
- Is the input reliable? A consistently structured value is easier to validate than free-form notes.
- Is the decision reversible? Sending a reminder is easier to undo than changing a financial or customer record.
- What is the impact of an error? Consider customer harm, privacy, money, compliance, and operational disruption.
- Can a person review it in time? A review step is only useful if the request reaches an accountable person with enough context.
Low-risk, repeatable steps are usually good candidates for early automation. High-impact decisions may still benefit from automation that gathers information, checks completeness, or prepares a recommendation while leaving the final decision to a person.
Design the human review step deliberately
“A human will check it” is not a complete control. Define who reviews the item, what evidence they see, what choices they can make, and what happens when they do not respond. The review request should include the original input, the automation’s reasoning or validation results, relevant records, and a clear deadline.
Give the reviewer explicit outcomes such as approve, reject, request information, or route to a specialist. Avoid a single vague “handle manually” queue. It hides why the automation stopped and makes it difficult to learn from repeated exceptions. If several people can approve, define whether one response is enough or all responses are required, and document what happens when an approval is canceled or abandoned.
Plan for failure, not just rejection
An exception is a business condition; a failure is when the workflow itself cannot do its job. A service may time out, a permission may expire, or a record may change between steps. Design a visible failure state with a safe retry rule, an owner, and enough logging to investigate without exposing sensitive data.
Do not retry every action automatically. Repeating a notification may be harmless; repeating a payment, record creation, or external request may create duplicates. For actions with side effects, use an idempotency key or another reliable way to determine whether the operation already succeeded. If the system cannot tell, route the case for review rather than guessing.
Choose a small, measurable first slice
A useful first automation is not necessarily the largest source of frustration. Choose a narrow slice with a clear start, finish, owner, and baseline. For example, automate intake validation and routing for one request type before attempting to automate every department’s approval process.
Measure more than time saved. Track how many requests complete without intervention, how often data is rejected, how long human review takes, how many cases are retried, and how often staff correct an automated result. These measures show whether the workflow is becoming dependable or merely moving effort into a hidden queue.
Review the map after launch
Real use will reveal exceptions that workshops missed. Set a regular review point to group new exceptions, remove obsolete rules, and decide which repeated manual steps deserve improvement. Keep a change history for the workflow and its decision rules so staff can understand why an outcome occurred.
Exception-first mapping turns automation from a shortcut into an operational design exercise. It gives a small business a practical way to start with one valuable workflow, protect the decisions that need judgment, and use evidence to decide what to improve next.
Next step: Schedule a short consultation to identify the next useful improvement.