What to Automate — and What Never To

Ask people why their automation project died and you will hear about the platform, the integrations, the edge cases. Ask what they automated first and the real answer usually appears: they picked their most complicated, most annoying process — because annoyance felt like urgency.

Complexity is exactly what makes automations brittle. Choosing well is most of the work.

The four-part test

A process is a good candidate when all four of these hold. Three out of four is a maybe. Two is a no.

• Frequent — it runs at least three times a week, so small savings compound into something you notice
• Rule-based — you can write it as 'when X happens, do Y' without the word 'depends'
• Stable — the rules have not changed in the last few months and are not about to
• Safe to fail — if it breaks at 2am, the consequence is inconvenience, not damage

Calculating whether it is worth it

Weekly time saved is frequency multiplied by duration. Compare that against your honest build time — then double the build estimate, because everyone underestimates.

If it does not pay back within about three months, it is not your first automation. It might be your fifth, once you are faster at building them.

What never to automate end to end

• Anything irreversible — sending money, deleting records, cancelling a service. Automate the preparation, keep the trigger human
• Anything that reaches a customer unreviewed. In a relationship-driven market, an obviously automated message costs more trust than the minutes it saves
• Judgement calls — who to hire, what to charge, whether to make an exception. You can automate the gathering, not the decision
• Processes nobody has written down. If it only exists in one person's head, document it first; automating an undocumented process just hides it deeper

Good first automations

These are unglamorous, which is the point. They run constantly, follow clear rules, and fail harmlessly.

• Form submissions into a spreadsheet, a notification and a record
• New content posted to your channels on a schedule
• A daily digest of orders, signups or enquiries
• Files from email filed into the right cloud folder
• Reminders for follow-ups you keep forgetting

Start with one

Build one. Run it for two weeks. Fix what breaks. Only then build the second.

People who build four at once abandon four at once — they are debugging four unfamiliar systems while still doing the manual work as backup. One at a time is slower on paper and faster in practice.