Choose a first AI pilot worth finishing.

Find the recurring friction.

Ask the people doing the work where they lose time, repeat steps or wait for information. Pick a process you can walk through from beginning to end.

• What starts it, and how often does it happen?
• What information goes in? What has to come out?
• Where do exceptions, rework or approvals slow it down?

Write down the starting point.

Record the current effort, turnaround time and quality requirements. Use a sample of actual work where possible. If a number is an estimate, label it that way. A useful baseline lets you judge the pilot after the excitement of the first demo.

Check value, effort and risk together.

A large potential saving does not make a good first pilot on its own. Check whether the data is accessible, the process is stable enough to test and the team has permission to use the information.

• Value: what business result would improve?
• Effort: which systems and people need to be involved?
• Risk: what happens if the output is wrong?
• Review: who can recognize a good result?

Give one person the outcome.

Name a process owner who can provide examples, evaluate the output and help people use the result. Name the decision-maker who can approve the scope and remove blockers. Those may be different people.

Decide what would make you stop.

Set the acceptance criteria before the build. Include output quality, review effort and the conditions under which the team should pause or change the approach. A pilot that identifies a poor fit has still answered a useful question.

Turn it into a one-page brief.

Keep the first brief short enough for everyone to read. Use it to agree the work before choosing the tool.

• The process and the business problem
• The current baseline and the intended result
• The inputs, systems and access required
• The process owner and the person who approves
• The first test, review points and acceptance criteria