In 30 seconds

A workflow looks simple on paper and is full of exceptions in practice. Those exceptions usually decide whether AI is a good fit, so find them before you design anything.

Ask about difficult cases directly. They rarely appear on their own.

Why this comes up

People describe the normal path because it is what they think you are asking about. The exceptions are treated as annoying deviations rather than part of the work.

But the normal path is often the easy part. The value, the risk and the difficulty tend to hide in the cases where the normal path does not apply.

Where hidden steps live

  • Between two systems, where someone copies or reformats information.
  • In a personal spreadsheet or note that is not part of any official system.
  • In a quick message to a colleague to confirm something.
  • In a check someone does "just to be safe."
  • In a rename, a flag or a status that only that person understands.

Ask directly: "Is there anything you do that is not in any system?" The answer is often revealing.

How to draw out exceptions

Ask about the last time each of these happened:

  • The information was missing or incomplete.
  • Two records disagreed.
  • The customer or case was unusual.
  • A system was down or slow.
  • The request was urgent.
  • Something needed approval.
  • Something went wrong and had to be fixed afterwards.

For each one, ask three questions: How often does this happen? Who notices it? What do they do next?

A small example

A team processes expense claims. The normal path is quick.

Asking about exceptions reveals several: claims in foreign currency, claims without receipts, claims that exceed a policy limit, and claims from a department with its own rules. Each has an informal owner and an unwritten resolution. Together they are a third of all claims.

Any automation that ignored those cases would fail for a third of the work, quietly.

What to do with what you find

Give each meaningful exception a visible place: a queue, an owner and an outcome. Do not force it back onto the happy path. See what an exception is and, later, the exception queue pattern.

What this does not solve

Finding exceptions does not tell you how to handle them yet. Some become rules, some need a person, some are rare enough to route to a human every time. That decision comes in the design stage.

Good enough to move on when

  • You have asked about each common failure directly.
  • You know roughly how often each exception occurs.
  • Each meaningful exception has a known owner.
  • You are not assuming the normal path is the whole workflow.