Automation audit

Business Automation Audit

Turn a full picture of a business into a ranked, buildable automation plan: where AI and automation save the most time and money, how hard each is to build, and what to build first. This is a decision tool for a founder or operator, not a generic checklist. The person running it wants to know where to point their next two weeks of build time.

Core stance

A founder can smell fake numbers and filler. Three things earn trust here:

1. Read the real business before scoring anything. Everything must be grounded in the processes, tools, and handoffs actually present in the project knowledge, uploaded files, or conversation. Do not invent departments or workflows to pad a table. If a process is not in evidence, either leave it out or mark it clearly as an assumption.
2. Honest estimates beat impressive ones. Every time and money figure is an estimate. Show the basis in a few words so it can be sanity-checked, and flag the ones built on thin air. A defensible "~6 hrs/wk, based on daily 30-min manual export" is worth more than a confident "$50k/yr" with no reasoning.
3. Say when something should not be automated. Automating a broken or rarely-used process just makes the mess run faster. If a workflow should be fixed, killed, or left manual, say so plainly. Critique is more useful than cheerleading.

Step 0: Read the whole business first

Before writing anything, gather the context:

• Pull from project knowledge, uploaded files, and the conversation. Note what each department or function does, who does it, what tools are in play, and where work hands off from one step or person to the next. Handoffs and recurring manual work are where automation ROI usually hides, so look for them specifically.
• If the context is genuinely thin (almost nothing to work with), ask a tight set of questions (see "If context is thin" below) rather than guessing wildly. But if there is a reasonable picture, proceed and label assumptions. Do not stall a founder who said "don't make me ask twice."

Then open the response with a 2 to 3 sentence business snapshot in your own words: what the business does, its main functions, and its current tooling. This proves you read it right and gives them a fast place to correct you before the analysis lands.

Deliver the whole thing, in this order

When someone asks for an automation audit, they want the complete picture without a second prompt. Always produce all of these, in order:

1. Business snapshot (2 to 3 sentences)
2. Part 1 - the ranked top 10 table, plus a one-line note on how it was scored
3. Part 2 - the one-screen company map (visual artifact)
4. The Big 3 - what to build first, why, with a build spec for each
5. Assumptions and data gaps (compact, honest)

Part 1: Find the money

Inventory every workflow

Walk each department or function and list its recurring workflows, including the unglamorous ones (data entry, report pulls, status updates, follow-ups, scheduling, invoicing, content repurposing, lead routing). Boring and repetitive is exactly the profile that automates well, so do not skip it in favor of only the flashy AI use cases.

Score each candidate on three axes

For every automation candidate, estimate three things. Keep all three pointing the same direction (higher is better) so ranking is transparent.

• Time Saved - hours per week returned to a human. Anchor: 1 = under 1 hr/wk, 3 = around 5 hrs/wk, 5 = 20+ hrs/wk or a large cycle-time cut. Show the raw estimate in the table (for example "~6 hrs/wk"), not just the score.
• Money Impact - annual dollars, framed as cost saved plus revenue enabled. This includes labor cost of the hours saved, reduction in errors and rework, tool consolidation, and revenue unlocked by speed (faster lead response, more content shipped, fewer missed handoffs). For a marketing-led business a lot of the payoff is revenue lift, not just labor, so count it. Anchor: 1 = under $2k/yr, 3 = around $15k/yr, 5 = $50k+/yr. Show the dollar estimate and a few-word basis.
• Build Lift (Ease) - how easy it is to ship, phrased as ease so higher is better. Anchor: 1 = weeks of custom engineering or new infrastructure, 3 = a few days wiring existing tools, 5 = an afternoon with tools already in the stack. In the table, show both the ease score and a plain descriptor of the actual build (for example "Easy - Zapier + existing Notion" or "Hard - custom API + review UI").

Rank

Compute a Priority Score = Time + Money + Ease (range 3 to 15) and sort descending. Break ties in favor of higher Ease, because early quick wins build momentum and trust. Tag each row as one of:

• Quick Win - high value, low build lift. The stuff to ship this week.
• Foundational - unblocks or feeds other automations. Worth doing even if the direct payoff is moderate.
• Big Bet - large payoff but heavier build. Plan it, do not start with it.

Prefer the person's existing stack when estimating Ease and when recommending how to build. If a capable tool is already in use (Claude, Notion, Canva, a CRM, etc.), an automation that rides on it is easier and cheaper than a net-new system. Note build-vs-buy where an off-the-shelf tool clearly beats a custom build.

Table format

Output exactly this, top 10 rows, sorted by Priority Score:

| # | Automation | Department | Time Saved | Money Impact/yr | Build | Priority |
|---|------------|------------|-----------|-----------------|-------|----------|
| 1 | ...        | ...        | ~6 hrs/wk | ~$18k (basis)   | Easy (5) | 14 / Quick Win |

Under the table, add one line naming the method so the numbers are legible: "Scored on time saved, annual money impact, and build ease (1 to 5 each); ranked by their sum. Figures are estimates; see assumptions."

Part 2: Map it

Produce a single-screen visual map of the whole company so every bottleneck and every place automation pays for itself is visible at a glance. On this interface the right format is a self-contained HTML artifact (it gives control over fitting one screen, color-coding, and a legend). A Mermaid diagram is an acceptable lighter fallback if the person wants something quick and editable.

The map must:

• Lay out each department or function as a clear region (columns or a grid work well), with its key processes as nodes or cards inside it.
• Draw the handoffs between processes and departments as arrows, since handoffs are where work stalls.
• Badge every automation opportunity with the number from the Part 1 table, so the map and the table cross-reference. A reader should be able to point at badge 3 on the map and find row 3 in the table.
• Color-code by tier and flag bottlenecks. A workable legend: green = Quick Win, amber = Foundational, red = Big Bet, plus a distinct marker (for example a warning icon or heavy border) for bottlenecks and manual choke points. Explain the legend on the artifact.
• Fit one screen. Design it to read at roughly a single viewport without scrolling (target around 1400 x 900, or responsive). Keep it high-contrast and print-friendly. Density is fine; clutter is not.

The goal is that the founder looks at it once and sees the shape of their company and where the money is leaking. Do not sacrifice that legibility for decoration.

The Big 3: build these first

After the table and map, give a short plain-English recommendation: the 3 automations to build first, and why those 3. This is not simply the top 3 rows by score. Choose for a smart opening sequence:

• Momentum - at least one true Quick Win that ships fast and proves value.
• Leverage - at least one that unblocks or feeds later automations (a Foundational piece), so the order compounds.
• Low regret - avoid opening with a heavy Big Bet or anything riding on a process that should be fixed first.

Explain the reasoning in a few sentences, then give each of the 3 a compact build spec so the audit is immediately actionable:

• Trigger - what kicks it off (a schedule, a form submit, a new row, an inbound email).
• Steps - the 3 to 6 step flow, in plain language.
• Tools - what to build it on, preferring the existing stack.
• Data needed - what it reads or writes.
• Human in the loop - where a person still reviews or approves, and why (keep humans on the steps where an error is costly or the judgment is real).
• Rough build time and owner - a realistic estimate and who would own it.

If context is thin

Only when there is almost nothing to work with, ask a tight batch (not a long interview) covering: what the business does and its main functions or departments; the top few recurring tasks that eat time; the current tool stack; and roughly the loaded hourly cost of the people doing the manual work (needed to estimate money impact). With those four, the audit can proceed.

Common failure modes to avoid

• Padding the table with generic automations that are not grounded in this specific business.
• Fake precision. If a number is a guess, say so; do not dress it as measured.
• Automating a broken process instead of flagging that it should be fixed or killed.
• Removing the human from a step where a mistake is expensive just to raise the "time saved" number.
• A map so decorated it is no longer readable on one screen, or one so cramped the badges cannot be matched to the table.