SOP vs Automation: When to Document and When to Automate

Ask an agency owner whether a process should be documented or automated first, and the honest answer they give is usually “we’ll do both eventually.” That answer sounds responsible and it is the reason so many agencies end up with SOP folders nobody opens and automations nobody trusts. The order matters, and skipping a step in that order does specific, predictable damage. I have spent twelve years running delivery operations for marketing agencies, across 92 completed engagements, and the document-or-automate call is the one I watch agencies get backwards more than any other.

What actually happens when you automate an undocumented process?

You take whatever the team happens to be doing that week and turn it into a rule. Say your account managers currently skip the access checklist during a busy onboarding week, not because that step is wrong, but because nobody has time to fight for it under pressure. Automate the sequence as observed, without writing it down and questioning it first, and the skip becomes permanent. Worse, it stops looking like an oversight and starts looking like a decision, because a system performs it consistently now instead of a stressed person doing it inconsistently. Nobody chose to remove the access checklist. The workflow chose it, by accident, because that’s what the data showed the week someone happened to be watching.

This is the quiet failure mode of automating first. It is not that the automation breaks. It runs perfectly, every time, and reproduces whatever was broken about the process before anyone thought to fix it.

What actually happens when you document a process that should not exist?

The opposite mistake looks more careful and still costs you. Say a step in your reporting process exists to reformat a client’s numbers for a dashboard tool the agency stopped using two years ago, and nobody has removed it because removing steps feels riskier than keeping them. Write a clean, well-structured SOP for that step and you have not fixed anything. You have made the waste official. A procedure with a named owner and a review date reads as intentional, and intentional-looking waste is harder to question than obvious waste, because now someone has to argue against a document instead of just against a habit.

Documentation does not distinguish between a process that deserves to exist and one that survived by accident. It writes down whatever it is pointed at with equal confidence.

What is the actual test, before you do either?

Run every candidate process through five questions before deciding what to do with it.

• Stability. Does the process look the same this month as it did three months ago? If the steps change week to week, neither documenting nor automating is the right move yet. You would be recording or hard-coding a moving target, and both actions produce something wrong on the day they ship.
• Frequency. How often does the step actually happen, counted rather than remembered? A process that runs several times a week earns real investment. A process that runs twice a year rarely earns either a formal SOP or an automation; a short note or a competent person handling it manually is usually enough.
• Judgment required. Does the step involve a decision, or does it just involve doing the same thing the same way? A decision belongs to a person and belongs in a document that helps them make it well. A repeated action with no decision in it is the only kind of step a rule should ever touch.
• Cost of a silent failure. If this step is wrong, does someone notice in ten seconds, or does a client notice three weeks later? The steps where a mistake stays invisible the longest are the ones that need either the tightest documentation or a verification check built into the automation, not less oversight because a machine is doing it.
• Who maintains it. Is there a specific person whose job gets harder if this drifts out of date, or is it “the team’s” responsibility, which means nobody’s? An SOP or an automation with no named owner decays at the same rate regardless of which one you built.

A process that fails stability fails everything downstream of it. There is no test after that one worth running.

What is the correct sequence?

Define, document, simplify, then automate only the part that survives. Each step exists to catch a specific mistake the step before it cannot see.

Define

Before anything gets written down, decide what the process is actually for: the trigger that starts it, the outcome that ends it, and who it serves. This is not the same as documenting the current steps. It is deciding whether the current steps are even trying to do the right thing, which is a question no amount of careful formatting answers.

Document

Write down what the process actually does today, not the improved version in your head. This step is where the accidental parts of a process become visible, because writing “skip the checklist when busy” down, in plain words, reads as obviously wrong in a way that doing it quietly under pressure never did. The mechanics of building a document your team will actually use are their own subject, and I have covered them separately in the agency SOP guide.

Simplify

Once the process is on the page, cut everything that exists for a reason that no longer applies: the step built around a client who left, the workaround for a tool the agency replaced, the approval added after one incident that never happened again. This is the step most agencies skip, because it means arguing with your own documentation right after finishing it. Skip it and you go on to automate the waste you just took the trouble to write down.

Automate

Only what is left after simplifying is a candidate for automation, and even then only the parts that are stable, frequent, low in judgment, and cheap to verify. Ranking what has already earned automation, once it clears this bar, is a separate question with its own order, and I have written that ranking out in full in what to automate first. On cost: automation platforms typically price per seat, per workflow, or per task, and some are self-hosted with no per-task fee at all. Confirm current terms with whichever vendor you pick rather than assuming last year’s pricing still holds; the model matters more to your decision than the number.

When is it honest to skip documentation entirely?

There is a narrow, real exception, and pretending it does not exist is its own kind of dishonesty. If a step is already stable, already high frequency, involves no judgment at all, and a human will never need to run it manually as a fallback, writing a prose SOP before building the automation adds a second copy of the same logic that will start drifting from the first one the moment someone edits the workflow without updating the document. In that specific case, define the outcome, simplify the inputs, and build the automation directly, with clear step names and comments inside the workflow itself standing in as the record. The workflow becomes the documentation.

The condition that makes this honest, rather than a shortcut, is the “never run manually” clause. The moment a new hire might need to do the task by hand before the automation exists, or the system might go down and someone has to cover it, you need the document regardless of what gets automated. That single condition is why this exception applies to a small slice of agency processes and not to most of them.

One more case is worth naming honestly: sometimes the disagreement is not about the process at all, it is about who owns it or whether it should exist in the agency’s structure in the first place. No document and no automation resolves that. That is a structural question, and it sits under business process improvement consulting rather than under either of the two choices in this piece.

So which one goes first?

Document first, in nearly every case that lands on my desk. Not because documentation is inherently superior to automation, but because most agency processes fail the stability test on the day someone proposes automating them, and an automation built on top of an undocumented process hard-codes today’s version of the mess into a system that is harder to question than a person doing the job imperfectly. A person doing it badly can be corrected in a conversation. A workflow doing it badly keeps doing it badly with total confidence until someone goes looking.

Automation is not owed to a process because it is annoying or because a tool exists that could run it. It is earned by a process that has already survived being written down, argued with, and cut. The narrow exception above is real, but it is the exception, and treating it as the default is how agencies end up automating the waste instead of the work.

Where should you start?

You can run this yourself: pick five processes, run each through the five tests above, and be honest about which ones fail stability before you touch a keyboard. If you would rather have someone else do the sorting, the Agency Ops Audit is $1,500 fixed, two weeks, and it ends with a written 90-day roadmap that says which processes to define, which to document, which to simplify, and which have actually earned automation, plus a 60-minute readout call to walk through it. My basis for the order in this piece is the same as everywhere else on this site: twelve years running agency delivery operations and 92 completed engagements, working inside ClickUp, Asana, Monday.com, Airtable, and Notion with n8n doing the automating.