How to Choose Your First Business Automation
Compare repeatability, volume, data quality, and error impact before choosing a business task to automate. Includes a practical pilot checklist.

Your first automation should be a small process with clear inputs, a result you can check, and an easy way to undo mistakes. Start where the work repeats and the rules are understood. A frustrating process is a candidate for investigation, not automatically a candidate for automation.
List the tasks that actually repeat
For one ordinary working week, note tasks your team does more than once: copying enquiry details, drafting appointment reminders, summarizing feedback, or preparing a content brief. Record frequency, handling time, input source, and the person doing the work. Estimates are useful initially, but label them as estimates until you have observations.
A task performed twice a year may be annoying without justifying a connected system. A daily task may still be unsuitable if every instance requires a new judgement. Look for a recurring shape rather than identical wording.
Check four conditions
| Condition | A promising sign | A reason to pause |
|---|---|---|
| Repeatability | The same steps recur | The outcome depends on undocumented judgement |
| Input quality | Required fields are available | People routinely guess missing information |
| Reversibility | A draft or internal record can be corrected | An incorrect action creates a commitment |
| Ownership | One person checks failures and changes | Everyone assumes someone else maintains it |
These conditions are a discussion aid rather than a numerical score. An excellent time-saving estimate does not cancel out an unacceptable error impact.
Separate the normal case from exceptions
Take an enquiry tracker. The normal case contains a name, a service request, and contact information. Exceptions include duplicate messages, an existing customer, an unclear request, an attachment without text, or a complaint. Write the expected behavior for each before building the happy path.
Some exceptions should stop the process and ask a person to decide. That is a valid outcome. The goal is dependable routing, not forcing every message through the same automated action. Our troubleshooting guide shows how to trace where a process stops.
Compare three realistic candidates
Suppose your business wants to automate internal meeting summaries, invoice approvals, and content drafts. Meeting summaries and content drafts can be held for review. Invoice approvals can authorize money and require tighter controls. The sensible first experiment may be the draft even if the invoice process consumes more time.
For each candidate, ask: can we run it on fictional or approved sample data, inspect the output without changing the destination, and disable it quickly? If the answer is no, reduce the scope. “Draft a summary for review” is a better pilot than “manage all customer communications.”
Write a one-page pilot brief
- Scope: one trigger, one output, and the cases excluded.
- Inputs: required fields and approved sources.
- Review: who approves the result and what they inspect.
- Failure: what stops the run and who receives the alert.
- Baseline: current handling time and correction rate.
- Exit: how to pause the workflow and return to the manual process.
A useful brief can fit on one page. If it takes many pages to describe the first task, consider breaking it into smaller stages.
Run the pilot without hiding manual work
Track reviewer changes and the time needed to make them. If a ten-minute task becomes two minutes of generation plus nine minutes of correction, the process is slower. If it becomes three minutes of review with occasional failures, it may be useful—but the failure route still needs an owner.
Use the time-savings calculator to explore assumptions, then replace those assumptions with observed values. Expand only after the workflow handles the exceptions you documented. Your next action is to select one internal, reversible task and write its pilot brief.
Frequently asked questions
Which task should a solo business start with?
Often a draft, summary, or internal classification with a clear review step. The right choice depends on what repeats in your actual working week.
Should I automate a broken process?
First understand why it breaks. Automation can repeat missing data and unclear rules faster without resolving either problem.
How long should a pilot run?
Long enough to encounter ordinary and unusual cases at your actual volume. Define a sample and stopping criteria rather than choosing an arbitrary number of days.