Back to Blog
    AutomationAutomationProcess FirstSMB

    Automate the Process Before You Automate the Tool

    Every failed automation project I've seen shares the same root cause: they tried to automate chaos. Here's the diagnostic framework that changes everything.

    NH
    Nigel Holder
    6 min readFebruary 4, 2025

    "Every failed automation project I've seen shares the same root cause: they tried to automate chaos. Here's the diagnostic framework that changes everything."

    The Automation Trap

    There's a pattern I see constantly in SMB automation projects. A business owner discovers that a tool like Zapier, Make, or an AI assistant can automate a tedious task. They're excited. They build it quickly. It works — for about two weeks.

    Then an edge case appears. The automation breaks. Nobody knows why. The business owner either spends hours debugging or abandons the automation entirely and goes back to doing it manually.

    The root cause isn't the tool. It's that the process was never stable to begin with.

    Chaos Doesn't Automate Well

    Automation is, at its core, a codified assumption about how a process works. When the automation fires, it executes a fixed set of logic based on inputs it expects.

    If your process is inconsistent — if data arrives in different formats, if decisions get made differently depending on the day or the person — the automation will fail unpredictably. You've just moved the inconsistency upstream, into a technical system that's harder to observe and diagnose.

    The Diagnostic Framework

    Before building any automation, I run through five questions:

    1. 1.Can you describe this process as a decision tree? If you can't articulate the logic in a flowchart, an automation can't follow it either.
    1. 1.Does this process produce consistent inputs? Automations are brittle when input formats vary. Standardize before automating.
    1. 1.Who currently owns this process? If the answer is "everyone" or "it depends," the process isn't owned. Fix ownership first.
    1. 1.What's the failure mode if this automation breaks at 2am? Build your automation with its most likely failure mode in mind, not its ideal execution.
    1. 1.Is this process stable enough to document? If you couldn't write a clear SOP for it today, you're not ready to automate it.

    Process Stability as a Prerequisite

    Think of automation readiness as a spectrum:

    • Level 0 — Ad hoc. Process exists differently every time. Not automatable.
    • Level 1 — Consistent. Same steps, same decisions, every time. Documentable.
    • Level 2 — Documented. Written SOP exists and is followed reliably. Automation-ready.
    • Level 3 — Automated. Tool executes the documented logic. Optimizable.

    Most businesses try to jump from Level 0 directly to Level 3. The jump never sticks.

    The most valuable work I do isn't building automations — it's helping businesses reach Level 2. Once you're there, the automations are almost trivial to build, and they actually hold.

    Newsletter

    Enjoyed this?

    Get practical frameworks on process design, automation, and systems thinking — delivered to your inbox when they're ready. No filler.

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.