Documenting Business Processes Before You Try to Automate Them

A company decides to automate their invoice approval workflow. The process seems simple: invoice arrives, it's checked against the purchase order, approved, sent to accounting. They build automation around that happy path.

Three weeks later, invoices are getting stuck. The automation approves invoices from one supplier without checking them. It rejects invoices from another supplier even though they're fine. It doesn't know what to do with invoices that don't have a matching purchase order. A person is spending more time fixing the automation than the automation saves.

The mistake wasn't the automation tool. The mistake was skipping documentation. The actual process wasn't simple. It had exceptions, unspoken rules, and decision logic that made sense when one person was doing it but broke when codified into automation.

This pattern repeats across most failed automation projects. You can't automate what you don't understand. And you don't understand it until you write it down.

Why automation fails at exceptions

The human brain can handle exceptions. Someone says "the invoice approval process is straightforward," and they mean it—most of the time it is. But the exceptions are where complexity lives.

"Most invoices come in via email, but sometimes they're uploaded through our vendor portal. Sometimes they're faxed. And in rare cases, they're hand-delivered with a note. How does the automation know where to look?"

"Usually the invoice is checked against the purchase order. But what if there's no matching PO? Do you reject it, flag it for review, or approve it anyway? The person doing this has judgment—they know the vendor, they know if it's a legitimate one-off purchase. The automation has no judgment."

"Typically an invoice from a new vendor goes to the CFO for review. But what if it's a vendor we've worked with for five years? The rule changes based on context the automation can't see."

These aren't theoretical edge cases. They're the actual work. When you automate around them invisibly, the automation breaks against reality. Then someone manually fixes it, and now the automation is saving nothing.

What thorough process documentation looks like

It's not a narrative. It's not "Sarah handles invoice approvals." It's step-by-step clarity:

Step-by-step walkthrough:

1. Invoice arrives via email, vendor portal, or fax
2. If email: extract the PDF attachment
3. If vendor portal: download from the system
4. If fax: scan and upload manually (this step can't be automated yet)
5. Extract key fields: invoice number, date, amount, vendor
6. Look up vendor in database
7. If vendor is found: proceed to step 9
8. If vendor is not found: flag for review (wait for manual approval before continuing)
9. Search for matching purchase order
10. If PO found: compare invoice amount to PO amount
11. If amounts match: check PO status
12. If PO status is "approved for payment": auto-approve invoice and send to accounting
13. If amounts don't match: flag for review (wait for CFO decision)
14. If PO is not found: check invoice date
15. If invoice is within last 30 days: flag for review
16. If invoice is older than 30 days: check if this is a known recurring vendor (repeat vendor from previous 12 months)
17. If recurring vendor: auto-approve with a note that PO was missing
18. If not recurring vendor: reject and send back to vendor requesting PO

That's the actual process. It's more complex than "check against PO and approve." Every step you skip in documentation becomes a bug in the automation.

Decision points mapped clearly:

• Vendor found or not found? Different path
• Amounts match or don't? Different path
• Is there a PO? Different path
• How old is the invoice? Affects the rule
• Is this a recurring vendor? Affects the rule

Exceptions listed:

• What if the invoice has no date? (Set it to the date it was received)
• What if the amount is $0? (Flag it, this is suspicious)
• What if the vendor changes the format of their invoices? (You notice because someone's been handling them manually and suddenly the parser breaks)
• What if the person doing this goes on vacation? (Who takes over? Do they follow the same process or different?)

Time and resource tracking:

• How long does each invoice usually take to process?
• How long does an exception take?
• Is there ever a backlog? How long does it grow?
• Does the time vary based on vendor or invoice type?

This information tells you whether automation is even worth it. If Sarah processes 20 invoices a day and most take 2 minutes but exceptions take 30 minutes, you have a backlog problem or a training problem—maybe not an automation problem.

Success criteria:

• What does "done right" look like? 100% of regular invoices approved within 24 hours? 99%?
• What's failure? An invoice rejected that should have been approved? An unapproved invoice sent to accounting?
• How often does this happen now?

How to actually document a workflow

Talk to the person who does the work. Not their manager. Not someone who used to do it. The person currently doing it. They know the shortcuts, the workarounds, the exceptions, the unspoken rules that never made it into any formal process.

Ask specific questions:

• "Walk me through the last three invoices you handled. Tell me everything you did and why."
• "What's the hardest case you deal with?"
• "When do you have to ask someone else for help?"
• "What's changed in how you do this in the last year?"
• "What cases don't fit the normal flow? Give me examples."
• "How do you decide what's an exception versus the normal path?"
• "If you were out for a week, what would confuse your replacement?"

Observe them doing it. Watch them handle a few real cases. You'll see steps they forgot to mention because they're automatic to them. You'll see judgment calls that aren't verbalized. You'll see them check sources of truth that nobody told you about.

Map it visually. Use a flowchart, a diagram, or even a simple decision tree. This forces you to organize chaotically described information into something you can actually follow. Tools like Miro, Lucidchart, or even Draw.io work fine. The format doesn't matter. The clarity does.

Get confirmation. Show your documentation back to the person who does the work. "Is this what you actually do?" Let them correct, refine, and add exceptions you missed. This takes sessions, not minutes.

Measure baseline metrics. How long does the process take on average? How often do exceptions occur? What's the error rate? Once you automate, you want to measure if the automation improved things. You can't measure improvement if you don't have a baseline.

The exceptions are where it breaks

Most people document the happy path. The normal case. But workflows break at exceptions, and exceptions are where you discover whether you've understood the process at all.

Example: A company documents their customer onboarding process. Normal case: customer signs up, gets a welcome email, gets added to the CRM, gets their first invoice. Simple. They automate it.

But the exceptions:

• What if the customer's company name is very long and doesn't fit in the database field?
• What if they don't provide a phone number?
• What if they sign up with a personal email and later ask to change it to a company domain?
• What if they're signing up from a country you've never processed before?
• What if they request a custom payment schedule instead of the standard monthly billing?
• What if they sign up but then cancel within 24 hours?

The automation doesn't have rules for these. So it either fails silently, creates duplicate records, or approves something it shouldn't. Now someone is manually fixing onboarding cases constantly.

When you document, specifically ask: "What happens when things don't go as expected? What cases do you handle differently? How often do these happen?"

Who should be involved in documentation

The person doing the work: Essential. They know the process better than anyone.

Their manager: Useful for understanding strategic intent and how this process relates to others. Also useful for catching things the worker doesn't mention because they're "just how we do it."

Someone from the next step in the workflow: If invoices go to accounting after approval, what does accounting need? What information are they using? This tells you what needs to be captured or passed along.

Someone who used to do the work: If Sarah is new and someone else used to do this, ask the previous person what they wish they'd documented. People often remember the gotchas.

Don't try to document in a single sitting. Do it over multiple sessions. One for the overview, one for exceptions, one for observation, one for validation. Each session adds detail and catches what the previous ones missed.

When documentation reveals you're not ready to automate

Sometimes documentation reveals that the process is too inconsistent to automate yet.

Three people do the same job and their processes differ. One person approves anything under $1,000 without checking. Another always checks. The third has special rules for certain vendors. If you automate around one person's process, you've enforced a rule that nobody else follows. First, you need to standardize the process. Then automate the standardized version.

Or documentation reveals that so much judgment is involved that automation would miss the point. A customer service rep decides to refund customers based on their tone, the reason for the complaint, the customer's history, and gut feel. Automating that is possible but leads to worse outcomes than a person making the judgment call. Maybe instead of full automation, you automate data gathering—collect all the information a human needs to make the decision faster—but leave the decision to the human.

Good documentation sometimes leads to the conclusion that full automation isn't the answer. That's useful information.

After documentation: what changes?

Once you have thorough documentation, look at the process itself. Is it as efficient as it could be? Are there steps that don't add value? Are exception-handling rules clunky?

Often documentation reveals inefficiencies that a human has worked around invisibly. A person has to jump between three systems to get the data needed for one decision. A rule is outdated but nobody's noticed because the worker just ignores it. A step is ceremonial and adds no value but is done anyway.

Before automating, consider improving the documented process. A process that's messy becomes a messier automated process. Fix it first.

The documentation is also your test plan. When you automate, test against real examples from your documentation—the normal cases, the common exceptions, the weird edge cases. If the automation handles those correctly, you've got something that works.

---

FAQ

Should we document the current process or the ideal process? Document the current process first. Improve it second. Then automate the improved version. Automating an ideal process you don't actually do is a guarantee the automation will fail.

What if the person doing the work doesn't want to take time to document? Explain that this saves time later. Automation built on guesses will break and need constant manual fixes. Documentation is insurance against wasting months on broken automation.

How long should documentation take? For a single process: a few hours to a day, including interviews, observation, and validation. For a workflow involving multiple people: a week or more.

Can I document while building the automation? No. Document first. The documentation informs the automation design. If you build while figuring out the process, you'll build wrong and have to rebuild when you discover what the process actually is.

What if the process changes frequently? Document what you have now. When the process changes materially, update the documentation before you try to change the automation. Keep them in sync.

Should I document all workflows or just the ones I want to automate? Start with workflows you want to automate. Once you understand that process deeply, consider documenting others that feed into it or depend on it.

Can I skip documentation if the person doing the work will still be involved after automation? No. Explicit documentation catches exceptions and judgment logic that the person has automated in their mind. Writing it forces clarity and catches gaps.

How do I convince my boss this is worth the time investment? Show them the cost of bad automation. Failed automation costs months of fixes, frustrated team members, and broken processes. Documentation costs days. It's easy math.

What tools should I use? Flowchart tools (Miro, Lucidchart), written docs (Notion, Google Docs), video walkthrough, or even a spreadsheet. Combine them—flowchart for overview, written docs for detail, video for training.

What if documentation reveals that what we want to automate can't be automated effectively? That's valuable information. It means you invest time in documentation instead of building automation that won't work. Sometimes the answer is "automate part of this and leave the judgment calls to humans."