Thirty-six automations. Across five companies. Industries ranging from fintech to government to consumer products. Each one started as a conversation about friction — something that was taking too long, costing too much, or failing too often. Each one ended with a system that ran without anyone watching it.
What I didn't expect, building this many over this short a time, was how quickly the patterns would become obvious. Not just what works technically — but which automations actually change how an organisation operates, and which ones are clever solutions to problems that should have been eliminated entirely.
"Most teams automate the wrong things first. They make the slow things faster when they should be asking whether those things need to happen at all."
The order that actually works
Every team I've worked with comes in with a list. The list is always a mix of the genuinely high-leverage and the deceptively obvious. The obvious ones get done first — usually because they're the most visible pain points, the ones that have generated the most complaints. But visible pain isn't the same as high leverage.
Here's the sequencing I've arrived at after doing this enough times to see the patterns clearly:
- 01 Eliminate before you automate. Before building anything, audit the process. Is this step necessary? Often the answer is no — it exists because of a legacy constraint that no longer applies. Automating a redundant step just makes redundancy faster.
- 02 Data first, logic second. Start with the pipes, not the brains. If your data isn't clean, structured, and flowing reliably, every automation built on top of it will be fragile. Fix the substrate before adding complexity.
- 03 Automate the handoffs, not just the tasks. The highest ROI automations I've built are the ones that eliminate transitions between tools, teams, or stages — not the ones that make a single task faster. Handoffs are where time, context, and accuracy are lost.
- 04 Build for failure from day one. Every automation will eventually encounter an input it wasn't designed for. The ones that survive long-term have explicit error handling, fallbacks, and monitoring. The ones that don't are quietly causing problems nobody notices until they're significant.
What breaks — and why
The automations that fail tend to fail for one of three reasons. The first is brittle data dependencies — the automation was built assuming a specific format or structure, and when that format changed (as it always does), the whole thing collapsed.
The second is scope creep during build. You start with a clear brief, and somewhere in the middle it expands. One extra condition. One additional output format. One more edge case to handle. Each addition feels small, but collectively they produce a system that's too complex to debug and too tangled to modify.
If I can't explain what an automation does in two sentences, it's doing too much. Split it. Smaller, composable automations are dramatically easier to maintain, debug, and extend than large monolithic ones.
The third reason — and this one is more subtle — is that the automation solves for the current state of a process, not the desired state. The team wanted to move faster in a broken workflow. They got that. But the workflow is still broken, just running at higher speed.
What you actually need
Looking back across all thirty-six, the automations that delivered the most lasting value share a common characteristic: they didn't just speed things up, they fundamentally changed how information moved through the organisation.
The reporting automation that used to take a senior analyst four hours every Friday and now runs itself at 7am. The client intake flow that used to require three people across two departments and now routes, assigns, and notifies without any human in the loop. The performance dashboard that used to be a weekly manual export and is now live, always current, always accurate.
None of these felt glamorous to build. They weren't AI-powered agents or complex multi-step orchestrations. They were clean, disciplined connections between the right data sources and the right outputs — built carefully enough to run reliably without maintenance, forever.
That's what most teams actually need. Not the most sophisticated automation. The most reliable one.
If you're about to build your first automation — or your thirty-seventh — the question worth sitting with before you start is this: am I making a broken process faster, or am I fixing the process? The answer determines everything about what you should build.
without anyone watching.
We design automations that are built to last — clean, composable, monitored, and maintained. No Zap graveyards, no brittle pipelines, no 2am alerts.
Start the conversation →