How to Document a Business Process (So You're Actually Ready for Automation)

You want to automate things. You've heard about AI agents, Power Automate, ClawdBot (or MoltBot (or Open Claw))) — and you know some of the repetitive stuff your team does every day could be handled by software instead of humans.

But then someone like me asks you: "Can you walk me through exactly how that process works right now?" and things get awkward.

Not because you don't know your business. You absolutely do. It's just that most of what your team does lives in people's heads, in habits, in "that's just how Sarah handles it." Nobody's written it down because nobody's needed to. Until now.

Every AI agent, every workflow builder needs the same starting point: a clear description of what happens, in what order, with what decisions along the way.

Without that, you're asking technology to automate something you can't even describe on paper. Good luck with that.

The Bare Minimum: What a Documented Process Looks Like

This doesn't need to be a 40-page manual. You're not writing ISO documentation. You need enough detail that someone unfamiliar with the task could follow along and understand what's supposed to happen.

Here's what to capture for each process:

1. The trigger — what kicks it off?

Every process starts with something. A customer emails you. An order comes in. A staff member submits a leave request. It's month-end. Whatever it is, name it specifically.

Bad: "When we need to do invoicing."

Better: "When a project reaches the 'complete' milestone in our project management tool."

2. The steps — what happens next, in order?

Walk through it like you're explaining it to a new hire on their first day. What's the first thing you do? Then what? Don't skip the obvious bits — they're often the ones that trip up automation later.

Include who does each step. If it's always the same person, note that. If it rotates, note that too. If it's "whoever gets to it first," that's worth knowing (and probably worth fixing).

3. The decisions — where does the process branch?

This is the part most people miss. Almost every process has at least one point where someone makes a judgement call. "If the quote is over $10,000, the director needs to approve it." "If the customer is in Queensland, we use supplier A; interstate, supplier B."

These decision points are actually where automation gets interesting, because they can be turned into rules. But only if you've identified them.

4. The exceptions — what happens when it goes wrong?

What do you do when the customer doesn't respond? When the data is incomplete? When the approval gets stuck? The exception handling is often where your team spends the most time, and it's almost never documented.

You don't need to capture every possible edge case. Just the common ones — the things that happen at least once a month.

5. The systems — what tools are involved?

List every application, spreadsheet, email account, shared drive, or platform that gets touched during this process. You might be surprised how many there are. That fit-out studio I mentioned? They had about 20 different apps involved across their workflows. Consolidation wasn't feasible, and neither was the status quo. Knowing exactly which tools are involved is the first step to figuring out what can talk to what.

How to Actually Do This Without Losing the Will to Live

Right, so the above sounds like a lot of work. And if you're trying to document every process in your business at once, it absolutely is. Don't do that.

Pick one process. Just one. Ideally the one that's eating the most time or causing the most headaches. (If you're not sure which one that is, I wrote about [how to figure out your highest-priority automation candidate] previously — worth a read.)

Then do this:

Sit with the person who actually does the work. Not their manager. Not the person who designed the process five years ago. The person clicking the buttons and sending the emails today. Their version of reality is the one that matters.

Record it as they do it. Screen recording is brilliant for this. Ask them to talk through what they're doing and why as they go. You'll capture things they wouldn't think to mention in an interview because it's just muscle memory to them.

Write it up simply. A numbered list of steps, with the decisions and exceptions noted, is genuinely all you need. If you want to get fancy, a basic flowchart helps visualise the branching points. But honestly, a clear written list beats a pretty diagram that never gets updated.

Verify it with someone else. Show the documented process to another person who does the same task. They'll immediately spot the bits that are missing or different. That's useful — it tells you where the process isn't standardised, which is its own problem to solve.

What This Gets You

Once you've got even one process documented properly, a few things happen.

For a start, you're reducing your business risk in the (hopefully) theoretical "what if they get hit by a bus" moment. It only takes one hasty resignation of that person you thought would never leave before you're scrambling, stepping in and wasting time.

Secondly, you can have a real conversation with someone like me (or any automation adviser) about what's worth automating and what isn't. Instead of "we want to be more efficient," you're saying "here's a 12-step process where steps 3, 5, and 8 are manual data entry between two systems — can we automate those?"

That's a conversation that leads somewhere useful. The vague one is the expensive option where someone else does this process for you. 

You'll also spot inefficiencies you didn't know existed. It's remarkable how often the act of writing down a process reveals steps that exist for no good reason, or decision points that could be simplified

After that, the technology is the easy part. 

Just Do It!

Is documenting processes exciting? Not particularly. It's not going to make you feel like you're on the cutting edge of anything. But it's the single most valuable thing most businesses can do right now to prepare for automation and AI.

The companies that are getting the most out of these tools aren't the ones with the biggest tech budgets. They're the ones who can clearly describe what their team does, how they do it, and where the pain points are. Everything else builds on that foundation.

Start with one process. Write it down. I believe in you

---

If you've documented a process and want to know what's actually automatable, that's exactly the kind of conversation I have in our Process Automation Assessment. Or if you want to build some of this yourself, the Modern Professional workshop covers the practical side of turning documented processes into working automations with the Microsoft 365 tools you already own.