You're about to pay someone to build an automation, and you're not sure what to tell them. That's backwards. Document business processes before automating them, because the real steps, the actual bottleneck, and the exceptions nobody mentions are easier to find on paper than inside a tool. A one-page write-up costs you an afternoon. Skipping it can cost you a rebuild.
Most automation requests start the same way: "Can you just build something that does X?" The honest answer is that nobody can build it well until someone writes down what X actually is right now, step by step, including the annoying parts. That's the real case for documenting business processes before automating them — not as paperwork, but as the fastest way to find out what you're actually dealing with.
A one-page process document feels slow when you're eager to get a tool running. It isn't. It's the cheapest step in the whole project, and it's the one most people skip.
When you hand a builder a vague request, they build their guess of your process, not your actual one. The gaps show up later, after you've already paid for it. Writing the process down first forces you to answer questions you've probably never said out loud: who does this step, how often, what happens when a customer says no, and what gets typed into which spreadsheet.
This isn't about writing a manual. One page is usually enough — a numbered list of what happens from trigger to finish, including the exceptions:
Ask most owners to describe a process and you'll get the clean version, the one from training, not the one that happens on a busy Tuesday. Write it down by actually doing or watching the task once, start to finish. You'll usually find a step nobody mentioned: a phone call to confirm something, a manual check before an email goes out, a spreadsheet only one person knows how to update.
Those hidden steps are exactly what breaks an automation built from memory instead of from a real written process.
Once the steps are on paper, the slow part is usually obvious, and it's rarely the step people assumed. Owners tend to want to automate the part that feels tedious, not the part that's actually costing time. A written process lets you step back and ask: which step takes longest, which step waits on a person, and which step causes the most rework.
That's the step worth automating first. Everything else can wait.
This is the same reason it helps to write down how you follow up with leads before adding software to it — the bottleneck is often a missed step, not a missing tool.
A written process also changes the conversation with whoever builds the automation. Instead of a vague back-and-forth, you hand over a page that says exactly what happens, in order, with the exceptions called out. That gets you a real quote instead of a guess, and a tool that matches your business instead of a generic template.
It's also why automating small business busywork doesn't have to be expensive — the scope is already settled before anyone writes a line of code.
One page is usually enough. The goal is a numbered list of every step from trigger to finish, including who does each step and what happens in the exceptions. If it's longer than a page, the process itself may need simplifying before it's worth automating.
Write down each version separately — the standard path and the exception paths. If there are more than two or three branches, note that too; it tells the builder (and you) that the process may need to be simplified before automation, not just mapped.
You can write it yourself. Nobody knows the real steps better than the person who does them or manages the person who does. A builder can help turn it into something quotable, but the first draft should come from inside the business.
Yes, especially then. Small tasks are the ones people assume they understand well enough to skip writing down, and they're also the ones that quietly eat the most time once you add them up over a month.
Hand it to whoever is building the automation, or use it yourself to decide what's actually worth automating first. It's also worth keeping on file — processes drift over time, and the written version is the only honest record of what was agreed on.