What automation is for
Three things, in order of value. First, removing transport work — copying data between systems, formatting, chasing, reminding. Second, enforcing a standard that humans apply inconsistently under load, such as response times and routing rules. Third, creating visibility: an automation that does nothing but flag a breach is often worth more than one that performs a task.
What it is not for: replacing a decision that requires context, hiding an understaffed function, or making an unagreed process look official.
Choosing what to automate
A candidate process needs to clear four gates. Skipping any one of them is where most automation debt comes from.
- Worth it
- Frequency times time saved has to exceed build plus maintenance. A monthly task that takes ten minutes almost never qualifies, however annoying it is.
- Ready
- The process runs the same way whoever performs it, and every decision inside it can be written as a rule. If two people disagree about a step, that step is not ready.
- Feasible
- Every system involved exposes the data through an API, webhook or reliable export — and has been stable for a quarter.
- Safe
- Failures are reversible, observable within a day, and owned by a named person after launch.
The automation readiness score turns those four gates into ten questions and a recommendation. It is deliberately harsh about the middle band, because the middle band is where the expensive mistakes live.
How I design a workflow
Write the manual version first
One page: trigger, steps, decisions, exit condition. If you cannot write it, you cannot build it. This page becomes the specification and, later, the documentation.
Separate transport from judgement
Draw a line through the process. Everything mechanical goes to the workflow. Everything requiring context becomes a task for a human, created by the workflow with the context attached.
Design the failure path before the happy path
What happens when the API is down, the record is malformed, the duplicate arrives, the rate limit trips? An automation without an error branch is a silent data-loss machine.
Make it idempotent
Re-running the workflow on the same input must not create a second record, a second invoice or a second message. Use external identifiers and existence checks, not optimism.
Instrument and alert
Log every run outcome somewhere a human already looks. Alert on failure and on suspicious success — zero results from a workflow that normally produces forty is a failure wearing a green tick.
Name the owner and the review date
Every workflow gets a person and a quarterly check. Unowned automation rots the moment a field name changes upstream.
Where the failures actually come from
| Failure mode | What it looks like | Fix |
|---|---|---|
| Silent failure | The workflow stopped three weeks ago and nobody noticed | Alert on absence of expected runs, not only on errors |
| Duplicate creation | Two records, two owners, two follow-ups, one annoyed customer | Idempotency keys and existence checks before create |
| Frozen disagreement | The workflow enforces a rule half the team never accepted | Settle the rule with the owners before building |
| Field drift | An upstream field renamed; the mapping silently writes null | Schema checks in the workflow, quarterly review |
| Automation sprawl | Sixty workflows, no inventory, nobody knows what fires when | One register with owner, trigger, systems touched, last review |
| Judgement automated | A rule decides something that needed context; the customer feels it | Route to a human task with context attached instead |
Tooling, and how little it matters
I build in n8n and Zapier, with CRM-native automation in GoHighLevel and HubSpot, and messaging through Twilio. The choice is a logistics decision, not a strategy: how complex is the branching, who has to maintain it, where does the data need to live, and what is the cost curve at volume. The n8n versus Zapier comparison covers the trade-off properly.
What actually determines success is upstream of the tool: whether the process was agreed, whether the failure path exists, and whether somebody owns it next quarter.
What good looks like
- Every workflow has an owner, a trigger description and a last-reviewed date in one register.
- Failures alert a human within one working day.
- Re-running any workflow is safe.
- The manual fallback is written down and has been tested at least once.
- No workflow makes a decision that a customer would want a human to make.
- Removing a workflow would be noticed — if nobody would notice, delete it.
Where this connects
Automation only pays after the operating model is coherent — see business operations. The highest-return workflows in most companies are in the revenue flow: lead routing and CRM automation. If the process is not settled yet, start with the when to automate guide.
Muhammad Sameed Abid
Muhammad Sameed Abid is a business operations, automation and growth systems professional with 9+ years across operations management, workflow and CRM automation, marketing operations and customer success. He is currently Head of Customer Success at GHA Marketing and writes here about the operating layer underneath growth.