Why SOPs come before automation

You want to automate something. Your customer follow-up process is eating hours. Your quote preparation is inconsistent. Your team keeps doing the same thing differently.

So you hire someone to build an automation. They spend a week building it. You deploy it. It works 70% of the time. The other 30%, something goes wrong—an edge case you didn’t mention, a step that sometimes happens out of order, a rule that only applies on Tuesdays.

The problem: you automated something you didn’t fully understand.

This guide explains why documenting the process (writing an SOP) before automation is not overhead—it’s the difference between automation that works and automation that becomes technical debt.

What is an SOP?

An SOP is a written, step-by-step description of how you do something, including:

• The trigger. When/why does this process start?
• The steps. In order, what exactly happens?
• The rules. Are there if/then conditions? When does something not apply?
• The output. What’s the end result?
• Exceptions. What happens if something goes wrong?

Example:

Customer Inquiry Response SOP

Trigger: Customer sends support email.

Steps:
1. Log ticket in Intercom, tag with topic (issue type).
2. If urgent (contains words: ASAP, broken, emergency) → reply in 2 hours.
   Else → reply in 24 hours.
3. Check customer history (past tickets, purchase history, account age).
4. Draft response addressing their specific issue (see FAQ docs for common responses).
5. If issue requires product fix, escalate to engineering (flag ticket with "escalate" tag).
6. Send response.
7. Set reminder to follow up in 3 days if issue remains open.

Output: Customer email replied, ticket logged, escalation flagged if needed.

Exception: If the customer is high-value ($5k+ annual) or has been with us 2+ years, 
priority goes up one level.

This is not complicated. It’s clear and concrete. And it reveals things you didn’t know you were doing.

Why an SOP reveals problems

When you write the SOP, you often discover:

Variation. You thought you always did X the same way. But writing it forces you to realize: actually, sometimes you do X, sometimes you skip it, sometimes you do a shorter version.

Missing steps. You have a vague memory of “checking something” or “asking the team first” for certain cases, but you never named the rule.

Unclear rules. You say “high-priority tickets first,” but what makes something high-priority? You think you know, but when you write it, it turns out you have three different definitions depending on who you ask.

Process debt. You realize half the steps are workarounds for a tool that doesn’t work well, or old client requirements nobody mentioned.

These problems exist whether or not you automate. But they only surface when you try to automate, because you can’t tell a computer “you’ll figure it out”—you have to be explicit.

By writing the SOP first, you find these problems early, fix them, and then automate the clean process, not the messy one.

The SOP → Automation → Measurement loop

Once you have an SOP, automation becomes straightforward:

1. SOP (2 hours to write) — You define the process exactly.
2. Automation (varies) — You give this document to a developer or automation tool. They build it to match.
3. Measurement (weekly) — You track: did the automation follow the SOP? If yes, it worked. If no, either fix the automation or refine the SOP.

Without the SOP, you get: vague requirements → guessing automation → confusion about whether it’s working.

Common SOPs for small businesses

If you’re considering automating, these are good first candidates:

• Customer response workflow — inbound email → categorize → draft → review → send.
• Quote/proposal generation — gather inputs → draft → review → format → send.
• Lead qualification — form submission → research → score → assign.
• Onboarding — customer signs → send templates → set up account → schedule kickoff.
• Invoice follow-up — invoice due → auto-remind if overdue → escalate if very late.
• Team assignment — task arrives → evaluate → assign to right person → notify.

How to write an SOP (30 minutes to 1 hour)

1. Pick the process. Choose one that takes time, repeats often, and is relatively self-contained.

2. Do it once, documenting as you go. Next time this process happens, write down every step as you do it. Don’t clean it up yet.

3. Identify the trigger and output. When does it start? What’s the end result?

4. List the steps. Be as concrete as possible. “Review customer info” is vague. “Open their account in Salesforce, check last order date, read last three support tickets” is concrete.

5. Find the if/thens. Where do you make a decision? Write those rules. “If customer is 1+ year old, do X. Otherwise, do Y.”

6. Describe exceptions. When does this process not apply, or apply differently?

7. Ask the team. If others do this process, ask them: did I miss anything? Do you do it differently? Lock in the answers.

8. Write it down. One page, clear language, numbered steps.

9. Try it. The next time this process happens, follow the SOP as written. Does it work? If not, refine it.

Common mistakes

Mistake 1: Making it too general. “Handle customer feedback.” That’s not a process, that’s a bucket. “When customer leaves a 1-star review on Google, log it, respond within 24 hours, and assign to product for investigation.” That’s a process.

Mistake 2: Forgetting the why. “Send reminder email” is a step. “Send reminder email because most late invoices get paid if reminded once” tells people why they’re doing it, and they’ll use judgment if the rule changes.

Mistake 3: Making it once and never updating. SOPs drift. You automate based on the SOP, but then the process changes and the automation becomes outdated. Update the SOP whenever the process changes.

Mistake 4: Automating first, SOP-ing later. Don’t do this. You’ll build automation around current practice, not improved practice.

Next steps

Pick one process you want to automate. Write the SOP (1 hour). Then, show it to your team or give it to a developer and say, “Build this.”

For guidance on the automation step, read [[ChatGPT is not an agent]] — it explains the difference between a tool and an agent, so you know what kind of automation makes sense for your SOP.

Also see [[measuring if AI training actually saves time]] — once you automate, measure whether it actually works.