Auditing Manual Exception Handling: Find Out What Happens When the Automation Breaks

When a prospect describes their workflow, they describe the happy path: data comes in, the pipeline processes it, the result goes out. What they rarely describe unprompted is the exception path, which is what happens when a record fails validation, a job times out, or an upstream system sends something unexpected. That path is usually manual, undocumented and owned by a few people. It is also where a new solution is most likely to be judged, because if it handles exceptions worse than the current manual fix, the people who run the process will reject it.

This article covers an atomic discovery skill from the SE Ignite catalog: investigating how the team resolves edge-case failures when automated pipelines break.

The problem this solves

• Problem: the solution is designed and demonstrated around the happy path. In the pilot or after go-live, exceptions pile up, the manual fixes no longer fit, and users conclude the new system is worse than the old one.
• Reader: Solution Engineers and solution architects scoping workflow, integration or automation solutions.
• Stage: discovery and solution design, before success criteria are agreed.
• Decision it supports: what the solution must do with failures, and which exceptions belong in the proof of concept.
• Success test: you can list the top recurring exceptions, how each is handled today, who handles it and roughly how often, and your design addresses each one.

A five-question audit

1. “What are the most common ways this process fails?” Ask for the top three, not an exhaustive list.
2. “Who notices first, and how?” An alert, a customer complaint, or someone checking a report every morning tells you a lot about maturity.
3. “Walk me through the last time it happened.” A specific recent event gives you the real steps, tools and handoffs.
4. “How often, and how long does each fix take?” Rough numbers are enough. They feed your latency quantification and the cost of inaction.
5. “What would happen if that person were away?” This exposes single points of knowledge and the real operational risk.

What to capture

• A short exception register: failure type, detection method, manual fix, owner, frequency and impact.
• Any tools used in the fix, such as spreadsheets, scripts or direct database edits. These often overlap with unofficial tool dependencies.
• Any exceptions with compliance implications, for example manual edits to records that are later audited. These link to regulatory and audit triggers.

Adapting it to the situation

• Platform engineers in a workshop: ask them to draw the exception path on the same diagram as the happy path. The contrast is usually striking.
• Frontline users worried about automation: exception handling is often the skilled part of their job. Acknowledge that expertise. It makes them more willing to describe it, and more likely to support a solution that respects it.
• A regulated, air-gapped environment: manual fixes may require approvals or separate access. Capture the control steps as well as the technical steps.
• A rapid-growth assessment after outages: exception volume grows with traffic, and manual handling stops scaling. This is often the clearest business case.
• A competitive displacement: ask how the incumbent handles exceptions. If users are attached to its workarounds, your solution must offer an equal or better path.

Common mistakes

• Demonstrating only the happy path. Include at least one realistic exception in your demo or proof of concept.
• Promising zero exceptions. No system removes all edge cases. Show how yours detects, routes and resolves them.
• Talking only to managers. The people who actually handle exceptions are often not in the meeting. Ask to speak with them.

Where this skill sits

The exception audit extends current-state workflow mapping to the paths that the map usually leaves out. Its findings belong in the success criteria for any evaluation, so the proof of concept tests the conditions that actually matter.

Practising the 80%

Asking what happens when things break is vendor-neutral and applies to any workflow. It is part of the 80% of Solution Engineering that SE Ignite teaches. Practise it by adding the five audit questions to your discovery template and running them in a role-play before your next live call. The SE Ignite curriculum is free to use.