Aurelle

Pillar Guide · Business Automation

Most automation advice is either a tool ad or a thought-piece. This guide is neither. It's the same five-step framework Aurelle uses with clients to find the highest-leverage automations, ship them quickly, and avoid the platform lock-in trap.

Read the framework
Workflow diagram of business automation steps

The five-step framework

The same playbook we use with every client.

01

Map the work, not the tools

Before you pick a single piece of software, you need a clear picture of where your team's time actually goes. Not the official org-chart version — the real one. Sit down with the people doing the work and list the 10 things they do every week that take more than 30 minutes. Don't filter. Don't pre-judge what's automatable. The goal is a brutally honest map of recurring effort, owner, and frequency. Almost every business that calls automation 'overwhelming' is overwhelmed because they skipped this step and tried to pick tools first.

Why this step matters

Skipping the audit is the most expensive mistake in business automation. You end up with a Zapier subscription powering three workflows nobody actually needed, while the real Monday-morning bottleneck is still being done by hand at 8am. Tools chosen without a map of the work tend to solve the wrong problem expensively, then get blamed when ROI doesn't show up. Map first, automate second — always in that order.

How to actually do it

Open a fresh tab in Sheets with five columns: Task, Owner, Frequency (per week), Time (minutes), Pain (1–5). Interview each team member for 20 minutes and capture every recurring task they personally hate or that visibly slows them down. Don't accept 'I just deal with it' — push for the actual sequence of clicks. Then sort by `Frequency × Time × Pain`. The top 10 rows are your real automation backlog. Keep this sheet living — review it once a quarter, because the work changes faster than you think.

Real example

A 20-person marketing agency assumed their bottleneck was project management. After running a one-week audit, the real top three were: weekly client status emails (6 hours of senior PM time), monthly invoice reconciliation (4 hours), and onboarding new hires across 9 tools (8 hours per hire). Project management didn't even crack the top five. They automated the actual top three first and saved roughly 60 hours in the first month — none of which a generic PM tool would have touched.

Common mistakes

The two big errors are auditing only the loudest team and trusting estimates instead of measurements. Senior people self-report low hours (they round down); junior people often own the most repetitive work but don't get asked. And nobody — including you — accurately remembers how long they spent doing something. Whenever you can, time three real instances of a task before adding it to the backlog.

02

Pick the 2 highest-leverage tasks

Once you have the audit, the temptation is to automate everything. Resist it. Most businesses don't fail at automation because they tried too little — they fail because they tried too much, ran out of attention before any single workflow was reliable, and ended up with five half-built systems that all need babysitting. Pick exactly two tasks from your audit. They should be the ones that score highest on `hours saved × frequency × pain`. The rest of the backlog stays parked until those two are shipped, documented, and proven to actually save the time you predicted.

Why this step matters

If you don't ruthlessly prioritise, every automation competes for the same scarce resource: your team's patience for change. Two well-built automations that genuinely save 10 hours a week will buy you the credibility (and the budget) to do the next five. Five mediocre automations that each save an hour and need constant fixing will burn that credibility for a year. The whole automation program lives or dies on the first two wins.

How to actually do it

Take your sorted backlog and apply two filters before picking. First: does the task have a clear, stable input and output? (If the inputs change weekly, automation is brittle.) Second: does the team trust the current process? (If they don't, automating it just speeds up the wrong thing.) From the rows that survive, pick the top two by `Frequency × Time × Pain`. Write a one-paragraph success criterion for each — 'this is done when X happens automatically and saves Y hours per week, measured for 30 days'. Get sign-off from the task owner before any code is written.

Real example

A 35-person services company had 14 candidates on its automation backlog. Filtered for stability and team trust, only 6 survived. The top two by score were the weekly utilisation report (3 hours of partner time) and new-client onboarding email sequence (2.5 hours of ops time). They shipped both in three weeks. Combined, those two saved 22 hours per month. With that proof in hand, they got immediate sign-off for the next four — instead of the usual six-month internal debate.

Common mistakes

People pick the most exciting automation, not the highest-leverage one. AI-generated reports look fun in a demo; cleaning up a CSV every Monday does not. But the boring one is usually 5x the hours saved. Score on impact, not on novelty. The other common mistake is picking two automations owned by the same person — if that person is sick or quits, both stall. Spread ownership.

03

Choose the lightest tool that fits

Tool selection is where most automation projects quietly go wrong. The decision usually defaults to whatever the loudest team member already knows, which is rarely the right answer for the next three years of the business. The right framing is: what's the lightest possible tool that can do this reliably? Lightest means cheapest, simplest, and least dependent on a third-party platform with surprise pricing changes. We use a four-tier ladder — built-in features → no-code (Zapier/Make) → Apps Script → custom code — and we always start at the top of the ladder and only step down when the tier above genuinely cannot do the job.

Why this step matters

Over-engineering an automation costs you twice: once at build time and forever afterwards in maintenance, surprise bills, and migration risk. Under-engineering hurts even more — when a critical Zap silently fails because you exceeded your task quota, the manual work comes back instantly. The right tier is almost always the one most teams skip past. We see businesses jumping straight to Zapier when a simple Sheets formula would have done it, and businesses building bespoke microservices when Apps Script would have done it in a tenth of the time.

How to actually do it

Walk through the ladder in order. Tier 1: can a built-in Sheets feature, Gmail filter, or Calendar setting handle it? (Often yes for simple stuff.) Tier 2: if it crosses tools, can Zapier handle it in 1–3 steps without branching? Tier 3: if it lives inside Google Workspace, has branching logic, or talks to Sheets data, Apps Script almost always wins on cost and control. Tier 4: only when none of the above scale or fit (real-time, high-volume, regulated data) do you need custom code. For each automation, write the chosen tier and one-sentence reason in your backlog sheet — it makes future audits enormously easier.

Real example

A SaaS team was paying $179/month for Zapier to handle 11 workflows. Re-running the ladder, 7 of those 11 were perfect Apps Script candidates (they all touched Sheets or Gmail), 2 were better as built-in Gmail filters, and only 2 genuinely needed Zapier. They kept Zapier on a $30 plan, moved 7 to Apps Script (free), retired 2 entirely. Net saving: about $1,800 per year, plus zero monthly task limits and no third-party platform risk on the workflows that mattered most.

Common mistakes

The biggest tool-selection mistake is letting one team member's preference drive the whole stack. The second is choosing a tool by its homepage rather than its limits page — Zapier looks unlimited until you read the multi-step task math; Make looks unlimited until you trace what 'operations' actually count as. Always check the pricing edge cases against your real volume before committing.

04

Build, document, hand over

An automation that only one person understands is not an asset — it's a liability with a countdown timer. The moment that person leaves, gets sick, or simply forgets the details, the system either breaks or becomes untouchable. Building well is only half the job. Every automation needs a named internal owner (not the person who built it), a Loom walkthrough that explains it in plain language, a one-page handover doc, and explicit failure alerts. We treat documentation and handover as part of 'done' — an automation isn't shipped until those four things exist.

Why this step matters

Skipping handover is the single most common reason automations get quietly retired. Three months in, a status changes upstream, the script breaks silently, the only person who understood it is on leave, and someone redoes the work by hand 'just for now' — for the next six months. The cost of fifteen extra minutes spent recording a Loom is roughly zero. The cost of an undocumented system rotting and being replaced by manual work is enormous.

How to actually do it

Before marking any automation complete, do four things. First, assign one internal owner who isn't the builder — this person doesn't need to write code, just to know what the system does and who to call if it breaks. Second, record a 5-minute Loom showing the system in action and where the triggers / settings live. Third, write a one-page doc with: what it does, where it lives (folder, sheet, project ID), how to pause it, and who built it. Fourth, wire failure alerts to a Slack channel or email — never let a script fail silently. Store the doc next to the system, not in a separate wiki nobody opens.

Real example

A 50-person operations team had three automations built by a contractor a year earlier. None had docs. When the year-end report broke, nobody knew which script ran it, where the triggers lived, or even which Google account owned the project. It took two weeks of forensics to fix what should have been a 30-minute change. After that incident they made handover non-negotiable — and the next contractor's work has been edited, extended, and trusted by the internal team for two years.

Common mistakes

People treat documentation as a 'phase 2' that never happens, and they over-rely on memory. The other classic error: building failure alerts but routing them to a personal email or a long-dead Slack channel. Test the alert by intentionally breaking the script once — if nobody hears about it within an hour, the alert isn't real.

05

Measure, then expand

The reason most automation programs stall after the first wave isn't lack of ideas — it's lack of evidence. Without measured before/after numbers, every conversation about expanding becomes a vibe check, and vibe checks lose to whatever feels urgent that week. The fix is simple but uncomfortably disciplined: measure hours saved per automation for the first 90 days, in real numbers, with the task owner co-signing the figure. Real numbers earn you the right (and the budget) to automate the next five things. Made-up numbers don't.

Why this step matters

Measurement does three things at once: it proves ROI to skeptical leadership, it surfaces automations that didn't actually save what they promised (so you can fix or retire them), and it builds an internal habit of treating automation as an investment portfolio instead of a series of one-off projects. Skip it and your automation roadmap will live or die on whoever happens to be the loudest stakeholder this quarter.

How to actually do it

For each shipped automation, run a 90-day measurement: hours per week the task used to take (timed average of three real instances pre-launch), hours per week now (timed three real instances at day 30 and day 60), and any failures or manual interventions in the period. Track these in a single 'Automation ROI' sheet — one row per automation. At day 90, hold a 30-minute review: what worked, what didn't, what's next. The sheet becomes both your scoreboard and your roadmap input — automations that under-deliver get fixed or killed, and the wins fund the next round.

Real example

An ecommerce ops team measured their first three automations for 90 days. Two delivered exactly what was promised (8 and 11 hours saved per week respectively). The third — a clever-looking AI summariser — saved only 30 minutes once the team factored in time spent verifying outputs. They retired the third, doubled down on the patterns that worked, and used the recovered hours to fund three more high-leverage builds. Without measurement, the AI summariser would have stayed live indefinitely while the team quietly distrusted it.

Common mistakes

The classic mistake is celebrating the launch and never measuring the result. The second is letting the builder report the savings — owners are biased upward. Always ask the task owner, not the builder, to time the post-launch task. The third is measuring in dollars too early; hours are easier to measure honestly, and dollars follow.

Tools comparison

The three tools we recommend most — and where each one fits.

Zapier

Simple triggers between popular apps

$20–$70 / month

Best for

Quickly wiring 2–3 popular SaaS tools together for a known recipe. Marketplace of pre-built integrations means you're often a few clicks away from a working flow.

Limitation

Hits its limits fast on complex branching, monthly task caps, and pricing that scales aggressively as workflows multiply. Strong dependency on Zapier itself.

Use when

You need to connect 2–3 popular tools quickly and the logic is mostly linear.

Make (Integromat)

Branching logic, multi-step workflows

$9–$30 / month

Best for

More complex automations with conditional branches, error handling, and many steps. Visual scenario builder gives you fine-grained control that Zapier doesn't.

Limitation

Steeper learning curve, still a third-party platform with operation quotas, and the visual editor can become unwieldy for very large flows.

Use when

Your automation has if/then branches, loops, or multiple conditional steps.

Our pick

Apps Script

Aurelle's pick for Workspace teams

Free — runs in your Google account

Best for

Anything that lives inside Google Workspace: Sheets, Gmail, Drive, Calendar, Docs. Native triggers, full programmatic access, no monthly bill, no vendor lock-in.

Limitation

Requires actual code (we handle this for you). Not the right choice when the workflow lives entirely outside Google's tools.

Use when

The automation lives in Sheets, Gmail, Drive, or Calendar — which is most ops automation.

When to use what: start with the lightest tier that genuinely solves the problem. If it lives in Google Workspace, default to Apps Script. If it crosses tools and the logic is simple, Zapier earns its keep. If you've got branching, loops, or multi-step orchestration, Make is the better fit. Custom code only when none of the three can scale to your volume or compliance needs.

Common questions

What founders actually ask before they automate.

No — and that's the most expensive misconception in this space. Automation has a real cost: build time, maintenance, monitoring, and the cognitive overhead of remembering what's running where. The right portfolio is usually 8–15 well-chosen automations covering the top recurring tasks, not 50 brittle ones. Automate the work that's high-frequency, stable, and painful. Leave the work that's variable, judgement-based, or rare to humans. A small portfolio of reliable automations almost always outperforms a sprawling one nobody fully trusts.

Get the right starting point

Book a free 30-minute call. We'll run the framework on your business in real time and tell you exactly where to start.

Or email hello@aurellestudio.co