Choosing your first automation project (and what to avoid)
A useful first automation is frequent, clearly defined and well understood. Here is how to assess a candidate and recognise three sources of complexity.
“We should automate more” leaves the actual task undefined. A more useful starting question is which specific piece of work to automate first, with a clear boundary, an owner and a way to assess the output.
The profile of a good first project
The ideal candidate has four properties:
- Frequent. It happens daily or weekly, so the saving compounds and the team notices.
- Rule-based. A competent new starter could do it from written instructions with no judgement calls.
- Already stable. The process has not changed in the last six months and is not about to.
- Owned by someone who wants it gone. The person doing it today will champion the change rather than resist it.
Typical examples: copying enquiries from a web form into the CRM, generating a standard quote from a price list, chasing overdue invoices at fixed intervals, compiling a weekly sales report from three sources.
Three first projects that need extra care
The one that touches every system
An automation spanning CRM, finance, scheduling and email creates several integration dependencies. Start with a smaller boundary and understand each connection before widening the scope.
The one that replaces judgement
If the current process involves someone making a call ("is this lead worth following up?"), automating it means encoding that judgement in rules. That is possible, but it is a design project first and an automation project second.
The one nobody asked for
If a team does not understand or trust an automation, people may work around it. Include the people doing the task in the design and review how the workflow handles their real exceptions.
A note on AI tools
Generative AI has widened what counts as "rule-based" — drafting, summarising and classifying are now automatable in ways they were not two years ago. The same selection criteria still apply. A frequent, stable, well-understood task is a good AI pilot; an ambiguous, high-stakes one is not, regardless of how impressive the demo looks.
Define the pilot before building it
Input
What starts the workflow, and which information must be present? Include an example of incomplete input.
Output
Describe what a correct result looks like and who checks it. Avoid treating successful execution as proof of a correct result.
Exceptions
Decide what should happen when a rule does not apply, a connection fails or a person needs to intervene.
Ownership
Name the person who will monitor the workflow and maintain it when the underlying process changes.