The first automation a team ships sets the tone for the next ten. Pick well and you get a quick win, an internal sponsor, and momentum for a real programme. Pick poorly and you spend three weeks plumbing an edge case that affects four people a month — and the company quietly decides automation isn't worth investing in.
Here's the framework we use to choose. It's deliberately boring; the goal is to take judgement calls off the table and replace them with a score everyone can argue about with the same scoresheet.
The three dimensions: volume, frequency, stability
Every candidate task gets scored 1–5 on three dimensions.
Volume
How many times does this task happen per unit time? More is better for automation because the saved time compounds.
- 1 — handful per year
- 3 — a few times a week
- 5 — many times a day
Frequency consistency
Is the workload predictable, or does it spike? Predictable workloads are easier to automate; spiky ones require error handling, queues, and monitoring you didn't budget for.
- 1 — totally unpredictable, mostly “when someone asks”
- 3 — weekly rhythm with occasional bursts
- 5 — steady daily/hourly volume
Stability of the task
How often do the rules change? An automation built on rules that shift every quarter is a maintenance trap.
- 1 — rules change every cycle
- 3 — rules update a couple of times a year
- 5 — hasn't meaningfully changed in two years
Multiply the three numbers. Anything below 27 (3 × 3 × 3) is probably not your first automation. Anything above 60 is worth a serious scoping conversation.
The dimension everyone forgets: data plumbing
Most automation failures are data failures wearing automation clothes. Before you commit, answer:
- Where does the input live and can the automation reach it via API, webhook, or even a half-decent CSV export?
- Where does the output need to go and can it land there reliably without manual cleanup?
- What does the data look likein the worst real case you've seen — not the textbook example?
If the answer to any of these is “it depends” or “we'd have to ask IT,” that's your first task — not the automation itself.
The cost side of the ROI equation
Automation ROI math is easy on the time-saved side and almost always wrong on the cost side. Costs to include:
- Tooling. The platform subscription (Zapier, Make, n8n, Workato), per-run pricing, premium connectors.
- Build time.Realistic, not optimistic. Multiply your first estimate by 1.5 and you'll be closer.
- Edge-case handling. 80% of the value, 20% of the build. The other 20% of value takes 80% of the build.
- Maintenance. Expect 10–20% of build time per year to keep an automation running as its dependencies change.
- Observability.If the automation fails silently, you're worse off than if you'd kept doing it by hand. Budget time for failure alerting.
A useful rule of thumb: if the time-saved value over 18 months isn't at least 3× the all-in cost above, find a better candidate.
What to automate first (almost always)
The reliably good first automations share three traits: they're triggered by a clear event, they have one or two output systems, and their output is “move data” rather than “make a judgement.” A few examples that consistently pay back:
- Lead sync. Webform → CRM → Slack alert with the relevant context. Replaces the manual copy-paste and the where-did-that-lead-go conversation.
- Onboarding pack.CRM “deal won” → create project in Asana with the right template, send welcome email, schedule kickoff. Cuts onboarding from days to minutes.
- Status digests. Pulling weekly status from your PM tool into a Slack post or an email — saves an analyst half a day a week.
What to not automate first
- Anything that requires judgement— “approve this expense if it looks reasonable.” AI-powered tools can help, but they're a second-year project, not a first-month one.
- Tasks where the rules are still being figured out.Automate stable processes. Improve unstable ones first, then automate them.
- The CEO's pet annoyance.If it's a low- volume, high-stakes task, the ROI almost never makes sense — but the political pressure pulls you toward it. Resist gently.
A note on tools
Most teams agonise over Zapier vs Make vs n8n vs “we should just code it.” The honest truth: at the size of a first automation, the platform doesn't matter much. Pick the one your team can maintain — usually the one they've already touched. Premature platform debates eat weeks; the candidate task itself eats days.
Once you have five or six automations live, then have the platform conversation. By then you'll know what you actually need: more observability? Self-hosting for data residency? Native code steps? Those answers come from running things, not from comparison spreadsheets.
One question to ask the team before you start
“If this automation breaks at 4pm on a Friday, who finds out, and how?” If the answer is “a customer,” you don't have an automation — you have a time bomb. Sort that out before anything ships to production.