How to Choose Your First AI Automation Project

Choose a first AI automation project that happens often, has a clear definition of a good result, and can be tested without exposing the business to a large mistake. Give it a named owner and a narrow boundary. Then check whether AI is needed at all.

The most interesting demonstration is not always the best first project. I would rather start with a responsibility your team already understands and struggles to complete consistently.

That gives you something to compare against. It also makes learning useful even if you decide to stop the pilot.

Look for repeated work with visible friction

Ask the team what they keep copying, checking, explaining or chasing. Look for work that repeatedly returns to the owner because the next step is unclear.

Possible candidates include preparing an internal enquiry summary, checking an intake form for missing fields, or organising approved information for a staff member to review.

Describe each candidate as a task with an input and output. “Improve customer service” is too broad. “Prepare a summary of a new enquiry for the coordinator to approve” is something you can inspect.

Write down the current method as well. Otherwise, you may compare the new system with an imaginary version of the old one.

Use this screening worksheet

For each candidate, score the following from one to three: one means weak or unclear; three means strong and well understood. This is my suggested planning heuristic, not a validated performance model.

Use the total to organise a discussion, not to override judgement. A high total does not cancel a serious privacy concern or an action the business cannot safely reverse.

If ownership or information readiness scores poorly, fix that first. Those weaknesses tend to travel into whatever tool you choose.

Decide which parts need AI

A fixed rule can route an enquiry by postcode or assign a task when a form is submitted. AI may help interpret free-text language, draft a summary or identify information that needs review.

Keep that distinction visible in the design. It makes the system easier to explain and reduces the number of decisions you ask a model to make.

For a fictional maintenance company, the first pilot might collect website enquiries, check required fields, and prepare a summary. The coordinator would approve the next action. Pricing and scheduling could stay outside the pilot.

That boundary gives the team a useful experiment without pretending the entire customer journey has been solved.

Write the pilot on one page

Include the trigger, approved inputs, expected output, reviewer, stop conditions and the cases that must reach a person. State what the system is not authorised to do.

Choose test examples before building. Include an ordinary request, missing information, conflicting information, a duplicate and a request outside the service scope.

Record the starting effort and the quality standard. If a summary saves preparation time but creates more checking work, the result needs closer examination.

Make the next decision explicit

At the review point, choose among three outcomes:

• Expand: the pilot meets its quality standard and the team can operate it.
• Revise: the task is useful, but a specific weakness needs correction.
• Stop: the benefit does not justify the effort or consequences.

Stopping a weak project is useful information. It protects the team from maintaining an impressive-looking system that adds another responsibility.

That is the standard I would apply to a first project: useful enough to matter, small enough to understand, and clear enough to judge.

If you have several ideas, bring them to a conversation with me. We can compare the work behind them before deciding what deserves a build.