The Process That Breaks on the First Exception

Every company has two processes: the one on paper and the one that actually happens. The first is clean, linear, easy to draw in a flowchart. The second has shortcuts, workarounds, decisions made over Slack and exceptions nobody ever documented because «it's always been like this».

When a team decides to automate something with AI, they almost always document the first version. The implementation goes live, handles simple cases well, and quietly breaks on everything that falls outside the script. The practical result: the team abandons the tool, goes back to the manual process, and concludes that «the AI wasn't ready».

The AI was ready. The mapping failed.

Why the ideal flow rarely exists in practice

Take a lead qualification process. On paper, the lead comes in through the form, passes through the SDR, gets a proposal within 24 hours, and lands in the CRM with an updated status. Clean.

In practice: half of qualified leads arrive through direct referrals to the account executive, who logs them in the CRM two days later, if at all. Some come in with the wrong company name because the actual decision-maker works at a different entity. Others ask for a proposal before any conversation has happened. And the SDR covering Friday afternoon tends to mark everything as «in progress» just to clear the queue.

None of those exceptions appear in the flowchart. But all of them show up in the real data, and any automation that ignores even one of them will produce wrong or incomplete results.

Three ways to map what actually happens

1. Interview the people doing the work, not the people who approved it

Your first source of information should be the person who does this job every day, not the manager who designed the process. The right question is not «how does this process work?» but rather «tell me about a case this week that didn't go as expected». That framing opens space for real exceptions, which is exactly what you need to capture.

In a recent customer support automation project, the team discovered that roughly 30% of tickets had an incorrect «reason» field, because the legacy system forced agents to pick a category before they understood the actual problem. The agents knew this and corrected mentally. The automation didn't.

2. Analyze logs and historical data

System logs, ticket history, CRM records, and even the spreadsheets teams maintain on the side are rich sources of real behavior. What you're looking for are deviation patterns: steps that get skipped regularly, fields that stay empty, records that loop back to earlier stages, execution times far above average.

If 15% of purchase orders get sent back for approval more than once, there's a reason. It might be a miscalibrated approval threshold, a specific supplier type that always causes confusion, or a form field that consistently induces errors. Automating that process without understanding the pattern will replicate the problem at scale.

3. Map the exceptions before the main flow

The technique I use most often is straightforward: before mapping the ideal flow, I ask the team to list everything that can go wrong or deviate from the script. We call this exception mapping. The list is usually long and uncomfortable, especially for teams accustomed to presenting processes in their best light.

Each exception on the list becomes a question: how often does this happen? Who decides what to do when it occurs? Is there a rule, or is it judgment call by judgment call? This exercise reveals where the real process depends on tacit knowledge that no system will have automatically.

The cost of skipping this step

Implementations that go straight to automation without this groundwork tend to fail in a specific pattern: they work well in the first few days, when cases are simple and the team is motivated to try something new. Over time, the exceptions surface, the system doesn't know how to handle them, the team starts working around the tool, and adoption rates drop.

The problem isn't technical. It's a scope problem. The automation was built for a process that doesn't fully exist in the real world.

I've seen this happen with support chatbots that had no fallback for complaints outside the category tree, with email automations that sent renewal messages to customers who had already churned (because the cancellation happened outside the integrated system), and with approval workflows that froze every time the primary approver was out of office.

When automation can actually begin

The signal that the mapping is complete isn't when the main flow is documented. It's when the team can answer clearly: what happens when this data arrives incorrectly? What does the system do when the responsible person isn't available? How do we handle the case that doesn't fit any category?

If those questions still generate hesitation or answers like «someone handles it manually», the process isn't ready to be automated. Not because the technology is insufficient, but because the business rules still live inside people's heads, nowhere a system can reliably reference.

The work of extracting and formalizing that tacit knowledge is slow, unglamorous, and easy to skip when there's pressure to ship. It's also what separates implementations that hold up from implementations that become cautionary tales.

The process on paper is for communication. The process as it actually runs is what you automate. Confusing the two is the most common and most expensive mistake I see in AI implementations.