Your first AI project should solve a boring problem.

Start with the work that keeps coming back.

The most useful starting point for AI is often something unremarkable: preparing a weekly report, summarising an enquiry or finding information in an internal knowledge base. These tasks have a repeatable shape. You can explain what happens today, recognise a good result and measure whether the new process helps.

Ask the people doing the work where they lose time. Look for copying between systems, reading the same information twice and turning notes into a first draft. A task that appears small in isolation can become a worthwhile project when it happens throughout the week.

Write the task down before choosing a tool.

A useful brief fits on one page. Describe what starts the task, what information is available, the output the next person needs and the exceptions that make it difficult. If your team cannot agree what a correct result looks like, resolve that first.

Start with a narrow boundary. Preparing a draft response for review is easier to assess than handing an entire customer relationship to an automated system. Keep the person who owns the business decision involved in designing the workflow.

• Input: where the information comes from and who can access it.
• Output: what the result must contain, including its format.
• Review: who checks it and what happens when it is wrong.
• Fallback: how the team completes the task when the tool is unavailable.

Count the review time as well as the time saved.

Suppose a task takes 12 minutes and happens 100 times a month. That is 20 hours of work. If an assisted process still needs four minutes of checking each time, the potential gross saving is around 13 hours, before allowing for maintenance and exceptions. This is an illustrative calculation, not a promised result.

Measure quality alongside time. A faster draft that needs frequent corrections may add pressure elsewhere. Record missing information, incorrect outputs and how often a person has to redo the task. Include software costs, setup effort and ongoing ownership when deciding whether to continue.

Run a small pilot with a clear decision at the end.

Use a representative set of examples, including awkward cases. Agree in advance what would make the pilot worth keeping: acceptable quality, a meaningful reduction in handling time and a process the team understands. Review access to business information and use approved data for testing.

At the end, make a decision. Keep and improve the workflow, change its scope or stop it. A pilot is useful when it teaches you something concrete. Once one workflow is dependable, the next opportunity is much easier to judge.