How to choose what to automate
Four conditions. Something worth automating usually meets at least three.
It recurs. Weekly or more, or reliably at a known interval. One-off work is nearly always cheaper to do by hand.
It has a clear trigger. A date, an event, a status change, a form submission. If a human has to decide when it runs, the deciding is the expensive part and automation does not remove it.
It has no judgement in it. If the right action depends on reading a situation, automation will make the wrong call at exactly the moments that matter most.
Failure is visible and cheap. You want automations that break loudly. Silent failure is worse than doing the task manually.
The order that works
Write the process down. Do it manually for two weeks following the written version. Then automate it. Skipping the middle step is how teams automate the wrong process confidently.
The ten
Follow-up reminders on anything waiting for a reply
When you send something that needs a response, a reminder fires if nothing comes back in a set number of days.
This is the highest-value automation most small teams are missing. Deals, invoices, and requests do not usually die from rejection, they die from being forgotten.
Highest value, lowest effortA recurring digest of what changed
One scheduled summary of the week: what moved, what is blocked, what is due. Posted to where the team already is.
This replaces a status meeting and several individual check-ins, which makes it the automation with the best hours-saved ratio.
Replaces a meetingTask creation from meeting outcomes
Actions agreed in a meeting land in the task system without anyone retyping them.
The manual version fails not because it is hard but because it happens after the meeting, when everyone has moved on.
Removes a retyping stepNew enquiry routing
An enquiry arrives and is assigned to an owner with a response deadline, rather than sitting in a shared inbox.
Shared inboxes create the assumption that someone else has it. An assigned owner and a clock fixes response times more than any amount of asking people to be responsive.
Fixes response timeRecurring report generation
Any report someone assembles by hand on the same day each week or month.
Even automating just the data collection, leaving the interpretation to a person, usually removes most of the work.
Automate collection, not analysisOnboarding and offboarding checklists
Someone joins or leaves, and the tasks appear for the right people automatically: accounts, access, equipment, introductions.
Offboarding especially. It is the checklist most often done from memory and the one where a missed step is a security problem.
Offboarding matters mostStale item alerts
Anything that has not moved in a set period gets flagged: deals, tickets, tasks, approvals.
This is what turns a pipeline or a board from a record into something that prompts action.
Turns records into promptsRenewal and deadline reminders
Contracts, subscriptions, certifications, tax dates. Fired far enough ahead to actually do something.
Set them at 60 or 90 days rather than 7. A reminder that arrives too late to act on is just an announcement.
60-90 days aheadRecurring data entry between tools
Anywhere a person copies the same information from one system into another.
Worth noting: this is a symptom. The automation is a patch on tools that do not share context, which is fine, but the better long-term answer is usually fewer places holding the same fact.
Treats a symptom, usefullyBackups and exports you would miss
Scheduled exports of anything that would be painful to lose and lives in one place.
Unglamorous, and the only item on this list where the value is entirely in the case where something goes badly wrong.
Test the restore, not the backup
What not to automate
Anything that contacts a customer without a human check. The failure mode is public and uncorrectable. Automated drafting plus human approval gets most of the speed with none of the risk.
Anything involving judgement about a person. Chasing someone about a deadline, escalating, flagging performance. The automated version reads as cold precisely when it needs not to.
Deletion and overwriting. Automate creating and flagging. Removing should stay manual, or at least reversible, because these fail silently and are hard to undo.
A process nobody has written down. You will encode the current mess and make it harder to change, because the logic then lives half in a tool nobody remembers configuring.
Anything that runs less than monthly. The setup and maintenance usually exceed the saving.
Keeping automations from rotting
The failure mode nobody plans for is the automation that quietly stops working. Everyone assumes it is running, and the problem surfaces weeks later.
Three habits that prevent it:
Make failure visible. Prefer automations that produce something someone sees. A digest that stops arriving gets noticed on day one. A background sync can fail silently for a quarter.
Give each one an owner and write down what it does. In six months, nobody will remember why a reminder fires on Thursdays, and an unexplained automation eventually gets switched off by someone who cannot tell whether it is still needed.
Review them twice a year. Turn off the ones that are automating a process that no longer exists. Most teams accumulate these, and each one is a small tax on understanding how the business actually works.
Frequently asked questions
- What should a small team automate first?
- Whatever someone does every week that has no judgement in it and a clear trigger. Reminders and handoffs are usually the best starting point because they fail visibly and cost nothing when they break.
- Is it worth automating something that takes five minutes?
- Yes if it happens weekly and someone has to remember to do it. The five minutes is rarely the real cost. The cost is holding it in your head, and the times it gets forgotten.
- Should I automate a process before documenting it?
- No. Automating an undocumented process encodes whatever the current mess is, and makes it harder to change later because the logic is now split between a document nobody wrote and a tool nobody remembers configuring.
- What automations most often cause problems?
- Anything that contacts a customer without a human check, and anything that deletes or overwrites data. Both fail quietly and both fail in ways that are hard to reverse, which is the worst combination.
- How do I know if an automation is still working?
- Build in a visible output. An automation that posts to a channel is obviously broken when it stops. One that silently writes to a database can fail for months without anyone noticing.