The ordinary path through a business process is often easy to describe. The awkward cases reveal what the process really means. Before automating work, collect examples of amendments, incomplete information and unusual approvals. You do not need to build a separate feature for every exception, but you do need a deliberate way to handle important ones.
Ask for the last difficult case
A hypothetical Sunshine Coast equipment installer might describe a straightforward path from accepted quote to installation booking. Ask about the last job that did not fit. Perhaps the customer split the installation across two dates or changed the site contact after materials were ordered. These examples can expose hidden assumptions about what counts as one job. Record the trigger, decision and outcome for each exception rather than collecting colourful stories without identifying the rule they challenge.
Group exceptions by their effect
Some cases need additional information, some need a different decision maker and some change the sequence of work. Others can be handled through a note without changing the workflow at all. Grouping by effect helps avoid building dozens of special screens. For the installer, split appointments might need a different job structure, while a changed contact may require only an amendment. Ask whether an exception affects the system's meaning or simply adds detail to an otherwise valid record.
Choose a handling strategy
For each meaningful exception, decide whether the first release supports it directly, routes it to a named person or excludes that work from the initial audience. The tradeoff is between broad automation and manageable complexity. A manual route can be sensible when it is visible and someone owns it. It is less sensible when staff must invent a workaround under pressure or alter unrelated fields to force a case through the system.
Test the boundary with staff
Walk the proposed strategies through representative examples. Confirm that staff can recognise an exception and know what to do next. Avoid relying on a developer to guess the business consequence of a rare case. Your next scoping step is an exception register containing the scenario, why the normal rule fails, the chosen handling route and the person who can confirm it. Prioritise cases that would block completion or make the recorded outcome misleading, even if they occur infrequently.
Planning checklist
- Collect recent difficult examples.
- Group by how they change the rule.
- Give every important exception a handling route.