Run it manually three times first: finding the one process worth building against

"Automate my business" is not a brief. It is a mood. A build needs a boundary: one thing that starts, one thing that finishes, and a defined set of decisions in between. "My business" has none of those. Neither does "our admin" or "the whole quoting side of things". Someone who builds these for a living put it plainly on r/n8n: "Most founders have no idea what they actually want to automate. They come to me saying they want to "automate their business" which is the equivalent of going to a mechanic and saying "fix my car."" The mechanic analogy is exact. A mechanic can only work from a symptom: it pulls left under braking, it stalls when cold. Give a builder a symptom and they can find the fault. Give them an ambition and they will guess, and the guess is usually the process that is easiest to demo rather than the one that is costing you. The first real cost appears here. Not in software fees, but in a build that runs correctly against a process nobody had agreed on.

The failure is rarely technical. It is that the thing you built faithfully reproduces a process that was never sound. A post on r/zapier described the outcome: "They take a messy manual workflow and automate it. Result: the mess runs faster, at scale, with no easy way to stop it." Read that carefully. The build worked. That is the problem. Every inconsistency, every undocumented exception, every "oh, we do it differently for that customer" now executes reliably, hundreds of times, without a human noticing. The same post drew the conclusion that matters most: "The pattern I kept seeing across all of these: every single failure is a mapping failure. Nobody breaks automations because they picked the wrong tool. They break them because they never mapped the process first." That claim is a practitioner's observation on Reddit, not a survey, so treat it as a strong signal rather than a measured figure. When something breaks, the post-mortem almost never lands on the platform. It lands on a decision rule nobody wrote down, an input that arrives in three different formats, or an edge case that turns out to be a quarter of the volume. You cannot fix a mapping failure with a better tool. You fix it with a better map.

Sit down with one process and a blank page. Give it half an hour. You are producing four things. Trigger: what exactly starts this, and how do you find out? A good answer reads like "an enquiry form submission arrives in the shared inbox". Inputs: what information must exist before anyone can act, such as name, suburb, job type, photos and preferred date. Decisions: what judgements does a person make, and on what basis, for example "if the suburb is outside 40km, decline with the referral list". Output: what is true at the end and who can verify it, such as "quote sent, CRM record updated, follow-up scheduled". Four rules keep this honest. Write it in the past tense, describing what happened the last time, not what should happen. Every decision needs a stated rule; "it depends" means the decision is not ready, so keep asking what it depends on until you have a rule or an explicit "a human decides this". Name the systems by name, not "the CRM" but the actual account, inbox or spreadsheet. Count the exceptions, because if you cannot say roughly how often the exception path runs, you do not know the process yet. Thirty minutes is deliberate. If a process cannot be described in thirty minutes, that is information: it is really several processes, and you need to pick one of them.

The three-run rule is not ours. It comes from the same r/zapier post, which prescribed it as the fix for automating a broken process: "The fix is running the process manually three times before touching any automation tool. If it doesn't work by hand, it won't work automated." It works because one write-up is a memory, and memories are tidy. Three write-ups are a test. Run the process by hand, start to finish, three separate times over the following week or two. Write it down each time, fresh, without looking at the previous version. Then compare the three. Expect a lot of candidates to fall over at step two. That is the point of the exercise, not a failure of it. The three runs reveal steps you forgot existed, such as the nudge you send when the photo attachment is missing. They reveal decisions that are not rules: run one says "if it's urgent, jump the queue" and run two prices the same job differently. Nobody was lying, the rule simply was not there. They reveal inputs that arrive in inconsistent shapes, with addresses typed three ways and dates as text. And they reveal how often the process actually runs, which should rule out the most candidates. If you run the process four times a month and it takes ten minutes, that is roughly eight hours a year of work, and a build against it will not pay for the effort of building it, let alone maintaining it. On r/automation the underlying skill gap was described this way: "The real issue is most small business owners don't know how to describe their own process clearly enough to automate it. That skill is missing before the software is even opened." Three manual runs are how you acquire that skill.

After the three runs, score each candidate honestly against six signals. Frequency: build-worthy processes run daily or several times weekly, not a handful of times a month. Variation: the three write-ups should broadly match; if they disagree, leave it alone. Decisions: the rules can be stated in plain words rather than "it depends on the client". Inputs: they arrive in a consistent, machine-readable place rather than living in someone's head or their phone. Consequence of failure: it is visible quickly and easy to correct, rather than silent and discovered months later. Ownership: a named person will maintain it. That last signal is the one most people skip, and it is the one that determines whether the build is still running in a year. A process with no named owner will drift. The rules change, the form gets a new field, someone leaves, and the build quietly starts producing wrong output that nobody is watching. That is the argument for training your own people rather than renting a builder. The person who mapped the process is the person best placed to maintain it, because they hold the context that never made it into the documentation.

There are two, and both have weight. The first is that this is analysis paralysis. It can be. The audit is thirty minutes and the three runs happen inside your normal fortnight of work. You are not commissioning a consulting engagement. If mapping becomes a project in itself, you have picked a process that is too big. The second is that sometimes building the thing is how you learn the process. That is true, and a fair point for genuinely small builds. If the whole thing is two hours of work and easily reversible, build it and learn. The three-run rule earns its keep when the build is substantial, when it touches customers, or when it will run unsupervised. The cost of automating a mess scales with how well the build works. There is also a blunter version of the problem, from r/n8n: "99.999999999% of ppl can't articulate or find i b/c their biz is too complex, so they guess but its never right." The number is obviously rhetorical, not data. The frustration underneath it is real and shows up repeatedly in these communities. Guessing is the default state. The three runs replace the guess with a record.

How long should the whole process take before I build anything? Thirty minutes for the initial written audit, then three manual runs spread across one to two weeks of normal trading. Total hands-on effort is usually two to three hours. If a candidate needs substantially more than that to describe, it is too large and should be split into smaller processes first. What if all three of my write-ups disagree? Then you have learned something valuable at low cost. Disagreement means the process is not standardised, so any build would encode one person's version and break for everyone else. Standardise the manual process first, then re-run the three passes before touching any software. Can I do this audit if I am not technical? Yes. The audit is written in plain words: what starts it, what information is needed, what decisions get made, what is true at the end. No technical knowledge is required. Process-mapping and diagnosis are the transferable skills, and they matter far more than knowing any particular tool. Which process should I audit first? Choose the one that runs most often and annoys people most. Frequency matters more than complexity. A ten-minute task done daily is a better first candidate than a two-hour task done monthly, because it produces more evidence and pays back faster. Does this apply if I am hiring someone else to build it? It matters more. A builder can only work from the map you give them. If you hand over an ambition instead of a written trigger, inputs, decisions and output, they will make assumptions on your behalf, and you will pay to discover those assumptions later. What if the process turns out not to be worth automating? That is a successful audit. Several hours spent proving a candidate is not worth building against is far cheaper than weeks spent building and maintaining something that saves a few minutes a month. Most candidates should fail. Discard them and move to the next one.

Quotes are reproduced verbatim from public Reddit discussions and attributed to the subreddit, not to individuals. r/n8n: https://www.reddit.com/r/n8n/comments/1r9q0kd/i_have_built_n8n_automations_for_a_dozen_startups/ . r/zapier: https://www.reddit.com/r/zapier/comments/1u3256p/6_reasons_solopreneurs_break_their_automations/ . r/automation: https://www.reddit.com/r/automation/comments/1uqn3ex/unpopular_opinion_90_of_small_businesses_cant_use/ . No statistics are cited in this article. The patterns described are practitioner observations from public discussion, not survey findings.