A small business should automate one frequent workflow that follows an explainable process, produces a result the team can check, and sends exceptions to a person. Start by mapping the work and measuring its current cost in time, delay, and corrections. Then choose whether to simplify it, connect existing tools, or add AI.
What makes a task a good first automation candidate?
A good first automation candidate happens often enough to matter and follows a process your team can describe. It also has a clear finish line, so you can tell whether the automation completed the work correctly.
Review each candidate against five practical questions:
- How often does the task happen?
- How much staff time does one complete run require?
- What happens when the task is late, skipped, or wrong?
- How much judgment does a person apply while doing it?
- Can someone check the result without repeating the entire task?
Frequency alone does not settle the choice. A daily task can still be a poor first project if every case requires a sensitive judgment call. A weekly transfer between two systems may be easier to automate because the source, destination, fields, and expected result are stable.
Look for a task with a clear trigger, such as a new inquiry, an approved quote, or a changed status. Define the expected output just as clearly. An automation that starts from a known event and ends with a verifiable record is easier to test than one asked to “help with operations.”
The guide to repetitive tasks explains how to compare frequency, effort, and risk before choosing a first scope.
What should you document before choosing a tool?
Write down how one recent example moved from start to finish before comparing software. The useful description includes the trigger, the information used, each action, the exceptions, the final output, and the person responsible for decisions.
A short workflow record can answer these questions:
- What starts the work?
- Where does the input come from?
- Which steps always happen?
- Which conditions disqualify or reroute a case?
- What information must be recorded, and where?
- Who approves the result?
- How will the team notice and recover from a failure?
This exercise often reveals that the task needs clarification before automation. Two employees may use different status names. A spreadsheet may contain duplicate customer records. A manual step may exist only because nobody has agreed which system owns a field. Fixing those points can reduce the work before anything is built.
The description also prevents a tool from defining your process for you. Once the workflow is clear, you can assess whether your current tools already support the required connection, whether a small custom component is missing, or whether variable inputs justify AI.
What did this look like for a wine merchant?
One wine merchant repeatedly searched for wine shops and wholesalers, checked each prospect against its criteria, and entered qualified results into its CRM. The first step was to document its existing method, including where it searched, what disqualified a contact, and what information belonged in the CRM.
I turned those steps into an agent that searches, applies the merchant’s qualification method, and records the results. The first version was not treated as final. We went through several passes before the qualification reflected the client’s way of working.
The resulting workflow accepts an instruction describing the prospects the merchant wants and returns a qualified list in its CRM. The merchant still decides whom to contact. The agent does not take over the sales relationship.
This case illustrates a useful boundary for a first automation. The repeated research and recording have a defined output, while the decision to contact someone stays with the client. It also shows why a written process is only a starting point. Testing real examples exposes criteria and exceptions that people apply naturally but may not mention in the first explanation.
This is a qualitative case from my published work. It does not establish a measured time saving, increase in lead volume, or revenue result.
Do you need a connection, an AI agent, or a simpler process?
Choose the simplest approach that can perform the defined work reliably. Stable fields and fixed rules often call for a direct connection between tools. Variable text, documents, or research may justify an AI agent when a person can verify the output.
Improve the process manually
Use this approach when the steps or ownership are still unclear. The team can agree on one status system, remove duplicate fields, and test the working method before introducing automation.
Connect existing tools
Use a direct connection when the inputs, rules, and destinations are stable. For example, approved information can move from one back-office tool to another while a person reviews failures and maintains the field rules.
Use an AI agent
Consider an AI agent when inputs vary and the task includes reading, classifying, researching, or drafting. A person should review uncertain results and retain the final decision.
At Brest Bretagne Handball, the reported need was to remove manual back-office transfers by connecting existing tools. The work did not need to be presented as an AI use case. For the wine merchant, the inputs and qualification work varied enough to support an agent, with review and contact decisions left to the client.
The practical AI guide covers how to test AI against a simpler approach. If the main problem is re-entering stable data, the duplicate data entry guide is the more relevant starting point.
Which decisions should remain with your team?
Keep a person responsible for decisions that depend on context, carry meaningful consequences, or speak for the business. Define that responsibility before the automation runs, along with the conditions that require review.
For a first project, human checkpoints may include approving a customer-facing message, choosing which prospect to contact, reviewing a financial exception, or resolving conflicting records. The automation can prepare information and route the case without making the final decision.
Failure handling belongs in the same design. Your team should know when a connection stops, an input is incomplete, or an AI result falls outside the expected pattern. A visible review queue is more useful than a workflow that appears autonomous but fails silently.
The NIST AI Risk Management Framework recommends defining human oversight and testing AI systems before deployment and while they operate. That framework is broader than a small business pilot, but the underlying practice applies: identify who reviews the system, what they measure, and how they respond when the output is wrong.
How do you know whether the first automation worked?
Measure the current workflow before building, then compare the pilot against the same measures. Include the time spent reviewing and correcting automated output, since those activities are part of the new process.
Useful measures depend on the task, but a first pilot can track:
- total time from trigger to completed result;
- staff time spent doing and reviewing the work;
- results that required correction;
- cases the automation could not complete;
- delays or errors that affected a customer or another team;
- maintenance required during the test.
Run the pilot on a limited scope with representative examples. Keep the previous method available while the team learns where the automation works and where it needs help. If the pilot reduces manual effort but creates a larger review burden, the scope or approach needs adjustment.
An automation can still be useful without handling every case. A reliable system may complete routine work and route the exceptions clearly. The decision to expand should follow the evidence from the pilot, including the costs and errors, rather than the fact that the technology can perform more steps.
What to remember
- Start with one frequent workflow that can be explained and checked.
- Map the trigger, inputs, rules, exceptions, output, and owner before choosing software.
- Use fixed automation for stable rules and consider AI when inputs vary and results can be reviewed.
- Measure review time, corrections, unresolved cases, and maintenance as part of the result.
If you have a recurring task but do not know which approach fits, describe the task, the tools you use, and where it gets stuck. We can use one real example to define a sensible first scope.
Frequently asked questions
Time is one factor, but the task also needs a stable enough process and a result that can be checked. A time-consuming task built around judgment may be a poor first candidate, while a smaller recurring transfer can provide a safer test.
Many first automations only need fixed rules or a connection between existing tools. AI becomes relevant when the input varies and the work includes reading, classifying, researching, or drafting.
A limited first scope makes the result easier to test and the failures easier to understand. Start with one useful segment, keep the decision owner clear, and expand only after the pilot shows where the approach is reliable.
Written by Antoine mazu. Antoine helps small service businesses understand and improve their workflows with solutions tailored to their needs, with or without AI. He combines product thinking with hands-on technical execution from Bayonne, France.
Sources accessed September 11, 2026: Antoine mazu’s work, NIST AI Risk Management Framework Core.
