The easiest automation to build is the one that works perfectly.

That is also the least useful test.

Real work is full of odd cases.

A lead has no budget. A customer is angry. A payment does not match. A document is missing a page. Someone asks for something the process never covered.

The happy path is easy.

The exceptions are the business.

The profit signal

Signal strength: 8/10

Buyer pain: clear

Build difficulty: low

Monetization: exception audit first, implementation second

Risk: a workflow can become too complex before it has earned its place

AI tools are getting better at taking action. They can read files, use tools, follow a goal, and check their work.

But they still need boundaries.

If you only describe the normal case, the system will make up the rest.

That is where expensive mistakes begin.

Call the document an Exception Map.

The method

Take one repeated task and write down five things:

1. What normally starts the task?
2. What does a good result look like?
3. What can make the task take a different path?
4. When must a person take over?
5. What should happen when the system is unsure?

For a new enquiry, it might look like this:

Normal path: capture the enquiry, check the fit, draft a reply, queue it for approval.

Exception 1: no service area mentioned -> ask one clarifying question.
Exception 2: complaint or legal threat -> send to a person immediately.
Exception 3: budget is below the minimum -> draft a polite decline.
Exception 4: duplicate enquiry -> attach it to the existing record.
Exception 5: missing company details -> mark as incomplete, do not guess.

Now the workflow has somewhere to go when the normal path stops working.

Use this prompt

You are reviewing a business process before it is automated.

Turn the notes below into an Exception Map with these sections:

1. Normal trigger
2. Normal inputs
3. Expected output
4. Happy-path steps
5. Exceptions and alternate paths
6. Human approval points
7. What to do when information is missing
8. What the system must never guess
9. Definition of done

Rules:
- Use real examples from the notes.
- Do not invent a rule. Mark missing details as QUESTIONS.
- Keep the first version small enough to test manually today.
- Route customer promises, payments, complaints, and sensitive data to a person.
- End with three test cases: normal, exception, and unclear.

Notes:
[PASTE THE BUSINESS PROCESS HERE]

How this turns into money

Sell an Exception Audit before selling the build.

The deliverable is a short document showing:

• The normal workflow
• The five most likely exceptions
• The human approval points
• The cases the system must refuse to guess
• Three tests for the first version

This gives the buyer a useful result before they commit to a larger implementation.

It also makes the build smaller. You are not promising to automate the whole business. You are proving one process and giving it sensible edges.

Your 60-minute test

Pick the task that causes the most corrections this week.

Ask the person who does it to show you three recent examples: one normal, one difficult, and one that had to be fixed.

Run the prompt above.

Then ask an AI agent to describe the smallest workflow that passes all three tests.

Do not build until the operator agrees with the exception list.

That list is usually worth more than another tool tutorial.