How to write a process down so it can actually be automated

The most useful unpaid hour you can spend before talking to anyone like us. Including the exceptions hunt, which is where automation projects usually die.

The most useful thing you can do before you talk to us

Before you ring an agency, hire a developer, or ask your nephew who’s “good with computers,” there is one unpaid task that will save you more grief than any of it: write the process down. Not a tidy flowchart. A plain, honest account of what actually happens, in order, including the messy bits.

Most automation projects don’t fail because the technology was wrong. They fail because nobody agreed on what the process was in the first place. You can’t automate a thing that only exists in someone’s head, or a thing that three people would each describe differently.

Pick one process, not the whole business

Resist the urge to map everything. Pick one process that’s annoying, repetitive, or slow enough that fixing it would actually matter — enquiry handling, quoting, onboarding a new client, chasing invoices, rostering casual staff. One process, start to finish. You can do the next one later.

Start with the trigger and the finish line

Before you list a single step, write two sentences: what starts this process, and how do you know it’s finished. These sound obvious and they trip almost everyone up.

The trigger might be “a form is submitted on the website” or “the phone rings” or “an email lands in the shared inbox.” Be specific — not “someone wants a quote” but the actual event that kicks things off.

The finish line is even more useful to nail down, because it forces you to define success. Is the process done when the quote is sent? When the customer accepts it? When the job is booked in the calendar? Different answers lead to very different automations, so pick one and be honest about it.

List every step as verb, who, and what they need

Now the middle. For each step, write it as an action, name who does it, and note what they need to do it. Not “quote gets sent” but “Sarah writes the quote in the template, using the enquiry details and the current price list.” That level of detail feels tedious. It’s also the difference between a process someone can automate and a process someone has to guess at.

Keep the steps small. If a step contains the word “and” twice, it’s probably two or three steps wearing a trench coat.

Mark each step as decision, action, or waiting

Once the steps are listed, go back through and label each one:

• Action — something gets done. A form is filled in, an email is sent, a job is booked.
• Decision — a person has to choose between paths. Is this customer new or returning? Is the deposit paid?
• Waiting — nothing happens except time passing. Waiting on a reply, waiting on a payment, waiting on a supplier.

This matters because these three types get automated in completely different ways, and a process description that doesn’t distinguish them is close to useless to whoever has to build from it.

Now hunt the exceptions — this is the part that matters

Here’s the bit almost everyone skips, and it’s the reason automation projects go sideways. The main path through a process is rarely where the trouble lives. The trouble lives in the exceptions.

For every decision point and every waiting point, ask: what if it doesn’t go the normal way? What happens if they don’t reply? What if it’s a repeat customer instead of a new one? What if the deposit hasn’t cleared by the time the job is due to start? What if two people submit the same enquiry twice? What if the supplier is out of stock?

Write down every exception you can think of, and next to each one, write what actually happens now — even if what happens now is “Jenny sorts it out” or “we just wing it.” That’s a real and useful answer. It tells whoever builds the automation that this is a spot where a human still needs to be in the loop, or where a rule needs to be invented that doesn’t currently exist.

Document what happens, not what the manual says

If your business has a procedures document already, put it aside for now. Manuals describe the process as it was designed, once, by someone who then moved on to other things. They rarely describe the process as it’s actually performed today, with all its shortcuts, workarounds, and quiet local rules.

Go and watch the process happen, or better still, sit with the person who does it and get them to walk you through the last real example — an actual enquiry, an actual invoice, an actual roster clash — rather than a hypothetical one. The person doing the job every day knows things the manager writing the policy doesn’t, mostly because they’ve had to improvise around every edge case the policy never anticipated.

The tells that a process isn’t ready yet

A few warning signs will tell you a process needs more work before anyone can automate it:

• Nobody in the business agrees on what the steps actually are.
• The steps change depending on who’s doing the job that day.
• When you ask why a certain thing happens, the real answer is “Jenny just knows.”

None of these are disasters. They’re just signs that the writing-down step isn’t finished. Keep asking, keep watching, keep writing until the process is boring and predictable on paper — that’s exactly what you want.

A worked miniature example: a new enquiry

• Trigger: a message arrives through the website contact form.
• Finish line: the enquirer has received a reply and, if relevant, is booked in for a call.
• Reception (action) checks the shared inbox each morning.
• Reception (decision) checks whether this is a new contact or an existing customer.
• Reception (action) replies with the standard information pack and a link to book a call.
• Exception: no reply within two business days — currently nobody follows up, which is why some enquiries go cold.
• Exception: the enquiry arrives outside business hours — currently sits untouched until the next morning.
• Exception: it’s a repeat customer — currently gets the same generic reply as everyone else, which annoys people who’ve bought before.

Written like that, a supplier can see immediately where automation would help — the missed follow-ups, the after-hours delay, the repeat-customer handling — without anyone having to guess.

What to do with the page once it’s written

Keep it. Don’t send it to the first supplier who asks for “a quick chat about your requirements” and let the document die in an inbox. Use it as the spine of every conversation you have about fixing this process, whether that’s with us or anyone else. A good supplier will read it and ask sharper questions because of it. A supplier who barely glances at it and starts talking about their platform is telling you something useful about how the rest of the project will go.