What to automate first: a practical guide for small teams
How to pick your first business automation: the three tests a process should pass, common starting points, and how to avoid automating the wrong thing.
By Techlonix Team3 min read
Most teams carry a layer of invisible manual work: copying data between tools, chasing follow-ups, assembling the same report every Monday. It is rarely dramatic, but it adds up to a large share of the week. The hard part of automation is not the technology. It is choosing the right first process, and building it so it can be trusted.
Three tests a good first automation passes
- It is frequent. A task done daily is a better target than one done quarterly.
- It is rule-based. You can describe the steps and the exceptions in plain words.
- It is annoying. People complain about it, delay it, or make mistakes doing it.
A fourth, quieter test is that it has a clear owner. If nobody is accountable for a process today, nobody will be accountable for the automation of it either, and that is how automations quietly break and stay broken.
Common starting points
- Lead handling: new enquiries captured, logged in your CRM, and acknowledged automatically.
- Customer support triage: tickets categorised and routed, with suggested replies for a person to review.
- Reporting: recurring numbers pulled together and delivered on a schedule.
- Data entry between systems: information typed once and passed along.
- Follow-up: reminders and sequences triggered by what a customer actually did.
- Onboarding: the same checklist of accounts, emails and tasks created for every new client or hire.
Map the process before you touch a tool
Spend an hour with the person who does the task today and write down every step, including the unofficial ones: the spreadsheet they check, the person they message when something looks odd. For each step note what triggers it, what information it needs, and what “done” looks like.
This exercise does two things. It reveals steps that can simply be removed, which is always cheaper than automating them. And it exposes the exceptions, the cases that do not fit the usual pattern, which determine whether the process is ready to automate at all.
What not to automate yet
Avoid automating a process nobody fully understands, or one that changes every week. Automating a broken process only makes it fail faster. Be equally careful with high-stakes decisions: refunds, contracts, and sensitive customer conversations deserve a human until you have a long record of the automation behaving correctly.
Design for failure from day one
Every automation will fail occasionally: an API times out, a form arrives with missing data, a connected account loses permission. Good automations expect this. They retry where it is safe, alert a named person when it is not, and never let a lead or request disappear silently.
- Every run is logged, so you can see what happened and when.
- Failures send an alert to a real person, not an unmonitored inbox.
- Runs that fail partway can be safely repeated without duplicating work.
- There is a documented manual fallback for when the automation is down.
A hypothetical example: handling new enquiries
Imagine a small firm where website enquiries land in a shared inbox. Someone copies the details into a CRM, decides who should follow up, and sends a holding reply, when they get to it. An automation can do the repeatable parts the moment the form is submitted: create the CRM record, send an acknowledgement, and notify the right person with the details attached.
The judgement call, who is best placed to respond and what to say, can stay with a person, informed by a clean summary instead of a raw message. The firm gains speed and consistency without removing anyone from the loop.
Where AI fits in
Plain rule-based automation is often the right tool. AI earns its place when a step requires reading, classifying, or drafting: understanding an enquiry’s intent, summarising a long message, or writing a first reply. Keep a person in the loop for anything customer-facing until you trust the results, and review samples regularly even after you do.
Measure the return honestly
Before you build, note how long the task takes today and how often it happens. After launch, check the same numbers and include the time spent monitoring and fixing the automation. The honest figure is the hours returned, minus the hours it costs to keep running.