Playbook · November 14, 2025 · 8 min read

The Automation Audit: Finding 20 Hours of Weekly Manual Work

Almost every operations team is sitting on 15 to 25 hours of weekly manual work that could be automated in weeks. Here is the audit process we use to find it, rank it, and decide what to build first.

Most operations teams know they are doing manual work. What they rarely know is how much, where it concentrates, and which of it is worth automating first. When we start an engagement at BTAC, we do not begin with tools. We begin with an audit: a structured, two-to-three-week process for finding the hours hiding inside routine work. This article is the playbook we use. You can run it yourself.

The goal of an automation audit is not to produce a vision deck. It is to produce a ranked list of candidate automations, each with an estimated hours-per-week cost, an error profile, and a build difficulty — so the first thing you build is the thing that pays back fastest.

Why audit before you build

The most common failure mode we see is a business automating the task that annoyed someone loudest last week. Annoyance is a bad proxy for cost. A task that irritates a founder might consume forty minutes a week, while an invisible re-keying process in the back office consumes twelve hours across three people. The audit exists to replace anecdote with arithmetic.

A second reason: roughly a third of the manual work we find should not be automated at all. Sometimes the process itself is broken and automation would just make it break faster. The audit catches that before you spend money.

Step 1: Interview the people doing the work

Sit down with each person who touches operations — not the managers describing the work, the people doing it. Thirty to forty-five minutes each. Three questions do most of the work:

  1. Walk me through yesterday, from the first task to the last.
  2. What do you do every day or every week that follows the same steps each time?
  3. What do you copy from one screen into another?

The third question is the highest-yield question in the entire audit. People do not experience copy-paste as "a process" — they experience it as background noise, so it never appears in process documentation. In one engagement with a twelve-person wholesale distributor, the office manager's answer to question three surfaced forty-five minutes a day of re-keying Shopify orders into the accounting file that nobody, including her manager, knew was happening.

Two interviewing rules. First, never ask "what should we automate?" — you will get either blank stares or a wish list detached from hours. Ask about what they did, not what they want. Second, interview at least two people per function. Discrepancies between their answers usually reveal undocumented handoffs, and undocumented handoffs are where errors breed.

Step 2: Shadow the processes that matter

Interviews give you a map; shadowing gives you the terrain. Pick the five to eight processes that came up most often and watch them happen, screen-shared or in person, for one full cycle each.

While shadowing, time the task with a stopwatch. Do not ask "how long does this take?" — self-reported times are typically off by a factor of two in either direction. Also count the systems touched. A process that touches four systems has four failure points and, usually, four logins worth of friction nobody has priced.

Step 3: Learn the signatures of manual work

After a few dozen audits, automatable work announces itself. Watch for these signatures:

Copy-paste between systems. Data moving from an email into a spreadsheet, from a spreadsheet into the accounting package, from the accounting package into a report. Every paste is a candidate for an integration, and every paste is an error opportunity.

Re-keying the same record twice. If a customer's details are typed into the CRM and then typed again into Xero, that is not two tasks — it is one task done twice, plus a reconciliation task nobody admits to.

Chasing status updates. Messages that begin "just checking on", "any update on", or "has this been approved yet" are the signature of a workflow with no system of record. The fix is usually a shared database with status fields — Airtable or Baserow — plus automatic notifications, not more messages.

Assembling reports by hand. Anyone opening three exports and stitching them into a weekly spreadsheet is doing a database query with their hands. These are often the fastest wins we deliver, because the data already exists — it just lives in separate tools.

Checking and correcting. If someone spends time "just verifying" numbers between two systems, the two systems disagree regularly, which means errors are already reaching customers or the ledger.

Rules stated in plain language. Listen for sentences like "if it's a trade customer, we apply the discount and copy the invoice to the shared drive." Any rule a person can state that clearly, a workflow tool can execute in Make.com, Zapier, or n8n.

Step 4: Score and rank the candidates

For every candidate process, record four numbers:

  • Hours per week. Measured, not estimated. Multiply per-run time by runs per week, across everyone who does it.
  • Error rate. In the shadowing sample, what fraction of runs needed rework or contained a mistake caught later? Use a rough percentage.
  • Frequency. Daily tasks outrank monthly ones at equal total hours, because errors and fatigue compound with repetition and because daily automation starts paying back immediately.
  • Rule-basedness. Score 1 to 5. Could you write the procedure as a checklist a new hire could follow without judgment calls? A 5 means fully rule-based; a 2 means it needs human judgment in the middle.

Then compute a simple priority score:

Priority = (Hours per week × 2) + (Error rate % ÷ 5) + (Rule-basedness × 2) + (Frequency bonus 0–5)

The weights are not sacred. What matters is that hours dominate, errors break ties, and rule-basedness filters out work that needs judgment. Frequency bonus: 5 for daily, 3 for weekly, 1 for monthly.

Add one more column — build difficulty, low/medium/high — based on whether the systems involved have APIs and whether the data is structured. This does not change the priority score; it decides sequencing among the top candidates.

Step 5: A worked example

Here is a condensed version of a real audit at an eight-person e-commerce operation, three systems: Shopify, Xero, and a shared spreadsheet.

| Process | Hours/wk | Error rate | Rule-based (1–5) | Priority | | ------------------------------------ | -------- | ---------- | ---------------- | --------------------------- | | Re-keying Shopify orders into Xero | 6.5 | 8% | 5 | 6.5×2 + 1.6 + 10 + 5 = 29.6 | | Chasing supplier order confirmations | 4.0 | 10% | 4 | 8 + 2 + 8 + 5 = 23.0 | | Weekly sales report assembly | 3.0 | 5% | 5 | 6 + 1 + 10 + 3 = 20.0 | | Refund status updates to customers | 2.5 | 12% | 3 | 5 + 2.4 + 6 + 5 = 18.4 | | New product listing setup | 3.5 | 4% | 2 | 7 + 0.8 + 4 + 3 = 14.8 |

Total identified: about 20 hours a week across one and a half roles. The ranking said to build the Shopify-to-Xero sync first — highest hours, highest rule-basedness, and both systems have mature APIs (low build difficulty). We built it in Make.com in the first two weeks of the engagement. It recovered roughly 6 hours a week and eliminated a monthly reconciliation scramble the team had treated as normal.

The product listing task scored lowest despite real hours, because judgment (image selection, tone of descriptions) sat in the middle of it. It was correctly deprioritized — an important outcome. An audit that says "not yet" to something is doing its job.

Deciding what to build first

From the ranked list, pick the top candidate that meets three conditions: the systems involved have workable APIs or exports, the process owner agrees the rules are stable, and the team feels the pain weekly. Build that one, measure hours returned for four weeks, then move down the list. Sequencing matters more than ambition: two small automations running in production teach a team more than one large one stuck in testing.

Expect the first build to surface edge cases the interviews missed — returns, partial payments, the one customer whose record is always wrong. That is normal, and it is why we scope builds in weeks rather than promising perfection in a specification document.

Where to start

Block out two weeks. Run the three-question interviews, shadow the top processes with a stopwatch, score everything with the formula above, and put the numbers in front of whoever signs off on spend. You will likely find between fifteen and thirty hours of weekly manual work in a team of five to fifteen people — that is the consistent range across our audits.

If you want a second pair of eyes on the list you produce, book a 30-minute audit and bring your scoring sheet. We will tell you which candidate we would build first, what it would take, and what it costs you to keep doing all of it by hand.

Next step

Have a process this could apply to?