The short answer
Automate a frequent task with consistent inputs, clear rules, a responsible owner, and a verifiable result. A good first project usually moves information or prepares work for a person. If the process is unclear, simplifying it comes before automating it.
The most visible annoyance is not always the best first project. A small job repeated throughout the day can matter more than an elaborate report produced once a quarter. Count the work before ranking it.
Write down the process before the tool.
Use one recent example. Write what started the task, what information arrived, which steps the person took, and how they knew it was complete. Include waiting and rework rather than just the clicks in the main software.
- Trigger: a submitted form, an accepted proposal, or a scheduled reporting date.
- Inputs: the information that has to exist before work starts.
- Owner: the person accountable for unfinished or incorrect work.
- Result: a record, report, assignment, or draft someone can verify.
- Exceptions: the situations that require a different decision.
If the answer to “who owns this?” is “everyone,” fix that before adding automation. A system can route a problem, but it cannot resolve an undefined responsibility.
Compare three candidates using the same questions.
Choose three recurring tasks and estimate monthly volume, minutes per occurrence, and the share of cases that follow the ordinary process. Ask whether the information is accessible, whether there is a clear approval point, and whether a wrong output is easy to undo.
Use the automation prioritizer for a structured comparison. Its score is a planning aid, not a prediction of return. A low-readiness answer should show what to fix rather than simply disqualify a potentially useful project.
A worked example: customer intake
Suppose an administrator copies 200 valid requests per month from a form into a customer system, taking six minutes each. That is 20 hours of monthly handling time. These numbers are illustrative, not a reported client outcome.
If 80% of requests can be handled by a consistent rule and those requests still need one minute of review, the modeled time recovered is 200 × 80% × (6 − 1) ÷ 60 = 13.3 hours. The remaining requests stay with a person. That estimate excludes monitoring and fixing errors.
The first version might create or match a customer record, assign an owner, and create a review task. It does not need to make sales decisions or send messages automatically. Keep the scope close to the time-consuming step you measured.
Watch for projects that are not ready.
A process needs preparation when its inputs are inconsistent, its rules change between team members, or the result cannot be checked. These are useful discoveries. Standardizing one intake form or deciding which system owns a field can remove work without any AI.
Be cautious about turning judgment into a brittle rule. If the outcome affects a customer commitment, a sensitive decision, or an irreversible action, define the approval step and the evidence the reviewer needs.
Run a small pilot and measure the full cost.
Record the baseline first, then test a limited version with representative cases. Include duplicates, missing data, delayed updates, and an unavailable service. Agree on who watches the pilot, when to stop it, and how manual work resumes.
Compare time recovered with the work that remains: review, maintenance, tool subscriptions, and exception handling. Recovered capacity is useful even when payroll stays the same, but label it as capacity rather than cash savings. The value calculator keeps those categories separate.
If you want help doing this with your team, the Business Automation Review turns the assessment into a written first-project plan.