How to document a process before you automate it

Why automation fails before it starts

Most automation projects that die in the first quarter do not die because the tools were wrong. They die because nobody agreed on what the process actually was before the build began.

We have seen this pattern repeatedly: a founder or ops lead says "let's automate our onboarding emails," a tool gets connected to a CRM, and three weeks later the team is manually overriding half the triggers because the automation does not match how things really work. The real process lived in someone's head, not in any doc.

The fix is not more sophisticated tooling. It is a 90-minute documentation session before anyone touches a workflow builder.

What good process documentation looks like

You do not need a formal BPM diagram or a SIPOC table. You need four things written down in plain language:

1. The trigger. What event starts this process? Be specific. "A new lead comes in" is not a trigger. "A form submission from the /contact page lands in HubSpot with a company size field filled in" is a trigger.

2. The steps, in order. Walk through what a person does, not what they should do. If the SDR always checks LinkedIn before sending the first email even though the playbook does not say to, write that down. Automation will not do it unless you build it in — and if you leave it out, the team will override your automation within a week.

3. The exceptions. Every real process has them. "Unless the deal is over $50k, in which case the AE calls instead of the SDR." "Unless it's a Friday, because the VP prefers to review those on Monday." Exceptions are not edge cases you can ignore — they are where your automation will break most visibly.

4. The handoffs. Where does ownership change? Between which people, systems, or queues? Handoffs are where data gets lost and where your automation needs the most explicit logic.

A simple format that works

We use a plain table with four columns: Step number, Action, Who (or what system), and Exceptions. It fits in a Google Doc or Notion page. It does not require any special software.

Sit down with the person who actually runs the process — not the manager who designed it, the person who runs it today. Record the conversation if you can. You will hear the real process, including the parts that would have broken your automation.

This session typically takes 60 to 90 minutes. It will save you more time than that in the first week of debugging alone.

How documentation changes what you build

When you hand a documented process to whoever is building your automation, the build becomes a translation exercise instead of a discovery exercise. That distinction matters more than any technical consideration.

Undocumented builds turn into requirement archaeology after the fact. The developer or consultant asks questions the operator should have answered before the project started, decisions get made inconsistently, and the resulting automation reflects assumptions rather than reality.

Documented builds produce automations that the team actually trusts, because the team was the source of truth. Trust is what determines whether an automation gets used or worked around.

When to involve an AI agent in documentation

If the process you are documenting involves a lot of unstructured communication — email threads, Slack conversations, call transcripts — an AI agent can help you surface the real steps faster than interviewing alone. Feed it a sample of actual work artifacts and ask it to identify the recurring decision points. It will not give you a finished spec, but it will surface patterns you might have missed in a 90-minute interview.

This is especially useful for processes that have evolved informally over time, where the person running them has stopped noticing some of the steps they take.

The documentation you skip becomes the bug you chase

Every shortcut you take in documentation shows up later as an edge case your automation cannot handle. We have seen teams spend 3 to 4 hours debugging an automation for every 30 minutes they skipped in upfront documentation. The math is not subtle.

If your process is too messy or exception-heavy to document cleanly, that is important information. It means the process needs redesign before automation, not instead of it. Automating a chaotic process just makes the chaos faster.

You can see how this plays out across different function types in our case studies — the pattern holds whether the process is in sales, finance, or operations.

What to do after you have the doc

Once you have a documented process, two things become easy that were hard before: scoping the build and testing the output. Your documentation becomes the test script. Run a live scenario against each step and each exception before you go live. If the automation cannot pass its own spec, you are not done.

Keep the documentation updated when the process changes. An automation that references a stale spec is almost as dangerous as no documentation at all.

Book a call with us if you want a second set of eyes on a process before you start building.