The Automation Audit: How to Decide What to Automate vs. Leave Alone

I have run this audit more than forty times across clinics, law firms, e-commerce brands, logistics companies, and agencies. The clients who skip it spend six months automating the wrong things and then blame the technology. The audit itself takes about three hours, costs nothing, and is the single highest-leverage activity before any automation project starts.

Here is the exact method I use.

The Three-Question Filter

Before I open n8n, write a line of Python, or touch an API, I ask three questions about every candidate process.

Question 1: How often does this happen?

Daily or more: full automation is worth evaluating. Weekly: partial automation or templates. Monthly or less: manual is almost certainly correct. The break-even math is ruthless. A task that takes fifteen minutes and happens once a month saves roughly three hours of labor per year if you automate it fully. A custom automation that takes two days to build and maintain needs three years to pay back. That is a poor investment.

Question 2: How bad is an error?

This is the question most teams skip. If the process sends a weekly internal report, an error is embarrassing but not catastrophic. If the process approves a patient discharge summary or triggers a wire transfer, an error costs real money or harms a real person. High-error-cost processes need human review at critical checkpoints regardless of how much automation surrounds them.

Question 3: Is the process stable?

Automation codifies a process. If the process changes every three months (new regulations, new client requirements, shifting business rules), the automation becomes a liability. You spend more time maintaining it than you saved building it. Unstable processes should be templated, not automated.

The Automation Matrix

Plotting frequency against error cost gives a clean decision framework:

HITL (human-in-the-loop) means a real person sees the output before it leaves the system. For this audit, just flag which quadrant each candidate process falls into.

The Three-Hour Walkthrough

Hour 1: Inventory

I ask the team to walk me through their actual week, not their job descriptions. I take notes in a simple table: task name, time spent per occurrence, frequency, who does it, and what goes wrong when they are rushed or make a mistake.

The goal is not a comprehensive list. It is finding the handful of tasks that consume disproportionate time and have predictable, repetitive inputs. Those are the automation candidates.

Hour 2: Filter

I apply the three-question filter to every candidate. I eliminate anything monthly or less frequent. I flag everything high-error-cost for manual checkpoint design. I sort the remainder by time-saved-per-month.

Then I do something most people skip: I ask what happens downstream when this task is delayed. A task that takes thirty minutes and holds up three other people is worth four hours of saved labor, not thirty minutes. Bottleneck value multiplies.

Hour 3: Sequencing

I sequence the roadmap by three criteria: time-to-value, dependency order, and risk. Quick wins first (high frequency, low error cost, clean inputs). Foundation automations second (those that unblock later automations). High-risk automations last, after the team has built trust in the system.

# Output from a recent clinic audit
automation_candidates:
  - task: appointment_reminder_sms
    frequency: daily
    time_per_week: 3h
    error_cost: low
    decision: automate_fully
    priority: 1

  - task: insurance_pre_auth_form
    frequency: daily
    time_per_week: 5h
    error_cost: high
    decision: automate_with_hitl
    priority: 2

  - task: monthly_revenue_report
    frequency: monthly
    time_per_week: 0.5h
    error_cost: low
    decision: template_manual_trigger
    priority: skip

  - task: patient_discharge_summary
    frequency: daily
    time_per_week: 8h
    error_cost: critical
    decision: automate_intake_only_human_reviews
    priority: 3

When NOT to Automate

After forty audits, here are the process types I consistently recommend leaving manual.

Judgment-heavy decisions with low volume. Hiring decisions, contract negotiations, strategic pivots. These require context no current automation handles well, and they happen rarely enough that the ROI is negative.

Client-facing communication that requires empathy. A law firm client asked me to automate all client follow-up emails. I said no. The firm's competitive advantage was the feeling of personal attention. Automating the emails would have saved four hours a week and eroded what clients were actually paying for.

Processes under active redesign. If leadership is rethinking the process, freezing it in automation is exactly the wrong move. Wait until it stabilizes.

Single-person processes with no successor. If only one person knows the inputs, runs the process, and interprets the outputs, automation adds fragility rather than resilience. The bottleneck is knowledge, not labor. Document and cross-train first.

The Hidden Cost of Automating Too Early

Three projects in my first year ended the same way: a client saw an automation demo, got excited, skipped the audit, and asked me to build. We built fast. The automation worked. Then one of three things happened: the source system changed its API, the process logic changed due to a regulatory update, or the team that was supposed to use the automation reorganized and the new team had different needs.

Rebuilding a working automation is more expensive than building the first version, because you have to understand what the original built before you can change it safely. An automation that was not properly documented (and most are not) is a trap.

The audit forces you to document before you build. It makes the inputs explicit, the error conditions visible, and the downstream dependencies clear. That documentation is not bureaucracy. It is the thing that keeps the automation alive in month fourteen.

A Fourth Question I Added After Getting Burned

The first clinic I worked with had a daily appointment confirmation process that looked perfect: high volume, low error cost, clean structured inputs from a known EHR system. I automated it fully in three days.

Six weeks later, the clinic changed EHR vendors. The automation broke completely. Rebuilding took longer than the original build because the new EHR had a different API, different authentication, and different field names. I had not asked whether the inputs were stable, only whether the process was stable.

Now I add a fourth question to the filter: Are the inputs stable? Not just the process, but every system that feeds it. If a vendor upgrade, a third-party API deprecation, or a data schema change would break the automation, note it explicitly and build in a monitoring layer before you go live.

A Decision Flow for Real Projects

Is the task repeatable and rule-based?
  └── No  → Keep manual
  └── Yes → Does it happen at least weekly?
              └── No  → Template it; do not automate
              └── Yes → What is the cost of an error?
                          └── Low  → Automate fully; add alerting
                          └── High → Automate with HITL checkpoint
                          └── Critical → Automate intake only; human reviews all output

Run every candidate process through this flow before you start building. It takes five minutes per candidate and saves weeks of misallocated effort.

The Output: A Ranked Roadmap

The deliverable from this audit is a single-page ranked table: process name, quadrant, priority, estimated build time, estimated monthly time saved, and recommended architecture pattern. Nothing more elaborate.

Every client who has done this audit before starting a project has had a better outcome than clients who started building immediately. Not because the audit revealed something magical, but because it prevented the first two bad ideas that sounded good on a whiteboard.

The best automation project I have run started with a list of candidates that was three pages long and ended with four automations: all in the top quadrant, all with stable inputs, all with clear error budgets. We built them in two weeks. They have been running without meaningful maintenance for fourteen months.

Start here. Every time.