Make exceptions and corrections visible

A normal path describes only part of the replacement. Support effort tends to collect around incomplete requests, duplicate events, changed decisions, unavailable services and records that disagree. Put those cases into the operating process with named recovery paths instead of leaving them in a miscellaneous edge-case list.

Ask for categories of exception rather than stories that could expose private details. What can be missing when a request arrives? Which values can conflict? Which actions can occur twice? What may change after approval? Which external responses can be late or absent? The categories can then be checked against anonymised records or policy material.

For each exception, write down detection and recovery separately. Detection may come from validation, a reconciliation job, a person noticing an inconsistency or a requester's follow-up. Recovery names who can correct the problem, which state the work returns to, and whether later steps must be reversed or repeated. A generic "failed" status usually hides all of this.

Correction rules deserve close attention. If an approved value changes, does the product preserve the original, create a revision or overwrite it? Who can make the change? Does it need approval again? Which downstream systems have already received the earlier value? These decisions affect the data model, audit history, permissions and integration design together.

Duplicates are another useful test. A request may be submitted twice, a payment notification may be delivered again, or a user may retry after a slow response. The team needs a way to recognise the same business event without blocking legitimate repeated activity. That usually requires an identifier, a time boundary or a comparison rule stated more precisely than "ignore duplicates".

Include abandonment and cancellation. Work sometimes stops because the requester withdraws, information never arrives or the task no longer applies. The future system should distinguish an intentional stop from an item that disappeared from a queue. Record who can close it, what reason is required and whether it can be reopened.

Review the exception set with the people who resolve problems, not only the owners of the main process. They see where evidence runs out and which changes are difficult to undo. Their input often changes the proposed states and permissions before development begins.