You cannot automate a process that does not exist on paper yet

The stall is predictable. An owner picks a workflow, opens a tool, and gets three steps in before hitting a fork nobody can describe. Who approves the variation? What happens when the client replies at 9pm? Does the invoice go out on completion or on Friday? Nobody knows, because the answer has always been "ask Dave". Someone put it plainly on r/Entrepreneur: "3. Document how your best people work. Your top account manager is better than your average one and its not all talent, a lot of it is just method. How they set up a brief, how they deal with a client thats being difficult. You write that down and now you have an SOP that brings everyone up to that level. And practically speaking you cant feed an ai system a process that doesnt exist on paper yet, the documentation is literally the input for the automation". That last line is the whole argument. The written process is not paperwork you complete before the real work starts. It is the input. An automation is a process description that happens to execute. If the description is vague, the automation is vague, and you spend the next six weeks patching edge cases you could have named in an afternoon. Tool choice is rarely the bottleneck in a 5-25 person services business. Ambiguity is. The complaint that surfaces again and again in automation threads is not that the software was too hard, it is that nobody sat down and mapped the real workflow before opening it.

Because they were built as a chore, and chores rot. A recurring complaint in these threads is not that nothing was ever documented, it is that the documentation was out of date almost as soon as it was written. From r/nocode: "I tried writing everything down in a shared doc once. Took me two full days and by the time I finished it was already outdated because someone changed a process. Plus people dont read long docs anyway. They just call or slack me with questions." Three separate failures are stacked in that one post. The doc was written away from the work, so it captured an idealised version rather than what people actually do. It had no owner and no trigger for updating, so drift started on day one. It was long prose, so nobody read it at the moment of need, and they messaged a human instead, which is faster for them and expensive for the business. The instinct after that experience is to conclude documentation does not work. The better read is that documentation maintained as a separate task does not work. Anything that only survives if someone remembers to update it will not survive.

It means the record is produced while the work is being done, by the person doing it, and corrected the next time it is wrong. A practical version for a small services or trades business. Record the job once, using a screen recording or voice notes taken during a site visit, with no script and no polish. Transcribe and structure it, which is the one place AI genuinely earns its keep: a transcript plus an instruction to turn it into numbered steps and list every decision point where the person paused or said it depends gets you a first draft in minutes rather than two days. Store it where the work happens, in the job card, the checklist or the ticket template, not in a documentation folder someone visits twice a year. Correct in place, so that when someone follows the steps and hits something wrong, the fix is editing that line rather than messaging the partner. Version by use: if a document has not been opened or edited in three months, either the process died or nobody is using the document, and both are worth knowing. Correctness is maintained by the people who bump into the errors, at the moment they bump into them. Compared with the alternatives: a documentation project written in a two-day block captures the ideal rather than the real and is outdated by the time it is finished; a consultant-written manual creates no internal ownership and requires re-engaging the consultant to edit; a by-product SOP stays close to reality because the people doing the work own the edits.

Fair challenge, and worth conceding. Two honest counter-arguments. First, some work genuinely should not be documented. If a task happens twice a year and takes twenty minutes, writing it up costs more than it returns. Document what is frequent, what is high-consequence when done wrong, and what a new person will need in their first month. Ignore the rest. Second, recording does not automatically produce a good process. Capturing a bad workflow just gives you a faithful description of a bad workflow. The recording step is where you find out how much of a job is waiting rather than working, and where the handoffs quietly stall. That is the real return, and it arrives before any software is involved. There is also a timing argument. From r/Entrepreneur: "We're 20 people now and still finding places where the lack of early documentation is costing us. Hindsight: we should've documented our quoting process before we hired our second salesperson. Each rep developed their own quoting style, and now the price/scope mismatch on the same service is genuinely bad. Took us 18 months to undo it." Variation compounds. Every month an undefined process runs, more people invent their own version of it, and the eventual clean-up gets larger.

Start with the process that is currently interrupting the owner most often. In a services business that is often enquiry-to-quote or job-to-invoice. A workable first pass, over about two weeks. Pick one process, not a documentation initiative. For the next five occurrences, record the person doing it, using screen capture or a phone voice memo, whatever is nearest. Draft the steps from those recordings and mark every decision point explicitly, including the ones where the answer is currently "it depends". Resolve the decision points with the owner, because that meeting is the real work and some of those decisions have never been made at all, only improvised. Have the next person who runs the process follow the written steps and fix what is wrong as they go. Only then consider what part of it a tool should do. That last step is last for a reason. By that point you know the volume, the exceptions, and where the time actually goes. You can tell whether the answer is an automation, a template, a checklist in ServiceM8 or Tradify, or simply a decision that was never made.

The person doing the work, supported by someone who can build. Not an external party on a retainer. This is where systemising efforts quietly fail. The process gets mapped by an outsider, the automation gets built by an outsider, and when reality shifts, nobody inside the business can change either one. You are back to messaging the partner, only now the partner is invoicing you. The transferable skill is diagnosis and process mapping: sitting with a job, finding where it stalls, naming the decision points, and writing the sequence down. Tool operation is the easy half, and the half that keeps changing as products come and go. That is why buildAutomation trains two or three of your own staff to do the mapping and the building, rather than doing it for you and leaving. The person who wrote this on r/Bookkeeping is the sales and ops half of a two-person bookkeeping practice, and his partner, the one who was meant to write the SOPs, resigned: "Turns out there's nothing written for any client, no SOP for onboarding new ones, and I have 6 starting last week." No software fixes that. A recording of the next client onboarding, structured into steps and corrected by the next person who uses it, does.

Do I need SOPs before I can automate anything? You need the process defined, not a formal SOP library. A numbered list of steps with the decision points named is enough to start. Formal templates and approval workflows add polish, not clarity. Define one process properly rather than half-documenting ten. How do I stop SOPs going out of date? Make correcting them part of doing the work. The person who follows the steps and finds an error edits that line immediately. Documents maintained as a separate scheduled chore drift, because updating them competes with billable work and always loses. Can AI write our SOPs for us? AI can structure a recording or transcript into clear steps very well. It cannot know your decision rules, your exceptions, or why you do something unusually. Supply the raw recording of real work and use AI for the structuring, then have a human resolve the decision points. What if our process is different for every client? It is usually less different than it feels. Document the common spine and list the variations as named branches. If genuinely every job is unique, the thing to document is the decision framework rather than the steps. Should we hire someone to document our processes? An outsider can accelerate the first pass, but ownership has to stay inside. If updating the documentation requires re-engaging an external party, it will stop being updated. Have staff record the work and use outside help for structure and challenge. Which process should we document first? The one that interrupts the owner most, or the one a new hire needs in week one. For a lot of services and trades businesses that is enquiry-to-quote or job-to-invoice. Frequency and consequence beat complexity when choosing.

Quotes are reproduced verbatim from public Reddit threads and attributed to the subreddit only. r/Entrepreneur: https://www.reddit.com/r/Entrepreneur/comments/1sqv68q/how_to_actually_automate_your_agency_not_just/ and https://www.reddit.com/r/Entrepreneur/comments/1tc22u2/services_founders_what_process_do_you_wish_youd/. r/nocode: https://www.reddit.com/r/nocode/comments/1sepzfg/i_walk_every_new_hire_through_the_same_15_tools/. r/Bookkeeping: https://www.reddit.com/r/Bookkeeping/comments/1u0kre6/my_partner_bailed_after_i_got_us_business_and_now/. These are individual accounts, not survey data. They indicate a recurring pattern, not a measured prevalence, and they are not specific to Australian businesses.