How to Document Business Processes Before Automation

Before you automate a business process, you need to document the real process as it actually runs, not the idealized version. This guide shows you how to capture a process quickly and accurately so your automation is built on reality.

Who Should Do the Documentation

The worst way to document a process is to have a manager watch from the outside and guess what happens. The best way is to watch the person who actually does the work.

Do not document from your own observation. You will miss steps, shortcuts, and exception handling that the person doing the work has learned through experience.

Do document with the person who does the work.
- Schedule 60-90 minutes with the person who regularly performs this process
- Tell them you want to understand how it actually works, not how it should work
- Ask them to walk you through their last 2-3 instances of this task, step by step
- Ask them to narrate their decisions, not just their actions
- Ask them what breaks, what gets skipped, and what they wish they did not have to do

Validate with a second run.
Have the same person (or someone else who does the same task) walk you through it again. Compare the two walkthroughs. Where they differ is where the variability and exception handling lives.

What to Capture

A good process document answers these questions about each step:

What happens: The action taken, written in plain language.

Who does it: The role or person responsible (not just "we" or "they").

What tool or system is used: The specific tool, screen, or file involved.

What information is needed to do this step: What does the person need to know or have access to before they can complete this step?

What is the output: What does this step produce that feeds into the next step?

What can go wrong: Common errors, exceptions, or edge cases that require different handling.

Example:
Step 3: Send the quote to the customer
- Who: Sales coordinator
- Tool: CRM (HubSpot) + email
- Input needed: Customer email address, quote document, subject line, send method
- Output: Sent email logged in CRM timeline, timestamp recorded
- What can go wrong: Wrong customer email, quote attached with wrong pricing, email bounces

The Exception List

Most process documentation captures the happy path. The real complexity is in the exceptions, and the exceptions are what break automations.

Document every exception you encounter in the walkthrough:
- What is the exception?
- What triggers it?
- How is it handled differently from the standard process?
- Who decides how to handle it?
- How often does it happen? (daily, weekly, monthly, or less)

Example exceptions for a quote follow-up process:
- Exception: Customer says they never received the quote
- Handling: Resend from CRM, check if email bounced, confirm correct email address
- Frequency: Weekly
- Who handles: Sales coordinator

• Exception: Customer asks for a different format or layout
• Handling: Escalate to sales manager for approval, note in CRM
• Frequency: Monthly
• Who handles: Sales manager

Automations that handle the happy path but fail on exceptions will create more work than they save. Decide for each exception whether to build handling into the automation or route it to a human.

Validation and Version Control

A process document that is not validated is just a guess. Before you hand this off to automation design, validate it.

Validation checklist:
- [ ] The person who does the work has reviewed and approved the document
- [ ] A second person who does the same work has confirmed it is accurate
- [ ] You have run through the documented steps on 2-3 real instances and they matched
- [ ] Exceptions are documented and you have a plan for handling each one

Version control:
- Process documents go out of date as soon as the process changes
- Assign a review date to each document (at minimum, when you start automation work)
- When the process changes, update the document and notify anyone who uses it
- Track version history: v1.0, v1.1, v2.0 with dates and what changed

Tools for Process Documentation

You do not need fancy software. A shared doc or spreadsheet is often enough to get started.

Minimum viable documentation:
- A shared Google Doc or Notion page
- Numbered steps with who, what, tool, and output for each
- An exception list at the bottom
- Version and date at the top
- Name and date of the person who validated it

If you want more structure:
- Miro or FigJam for flowchart-style process mapping
- Camunda or similar BPMN tools for formal process modeling (overkill for most small businesses)
- A simple table in Notion or Airtable that everyone on the team can access

Do not let tools slow you down. Better a simple doc that is actually used than a sophisticated flowchart that is never finished.

Good process documentation is the foundation of good automation. Invest the time upfront to get it right. An automation built on inaccurate process documentation will fail in ways that are expensive to fix and embarrassing to explain to your team.