How to choose the first process for an AI pilot

Find a concrete friction

The first project should address describable, measurable friction rather than represent all enterprise transformation. Study incomplete intake, repeated status questions or lost handoff context through real cases. Impressive demos may hide unstable processes or unknown sources of truth, making pilots hard to learn from. Interview the people receiving the output as well as those doing the current task. A handoff that appears complete to one team may create repeated clarification work for another. That downstream effort belongs in the problem definition and can change which part of the process should be addressed first.

Evaluate value and readiness

Compare pain with readiness: clear rules, accessible information, ownership and human exception routes. Valuable but disorganized processes may need simplification first. Less visible bounded processes can teach more. Volume alone is misleading when frequent requests contain widely different situations.

Write a testable hypothesis

Link a change to an observable result: prepared handoff context may reduce repeated questions. Define the measure and comparison cases, noting complexity and channel differences. Do not promise numbers before a baseline. Pilots measure hypotheses rather than confirm automatic savings in advance. Write the start and end points of the measurement before collecting results. If the manual baseline starts when a request arrives but the pilot starts only after all information is complete, the comparison will be misleading. Record how exceptional cases and human review are counted so the result describes the same work on both sides.

Bound scope and prepare an exit

Specify included categories, sources, permitted actions and retained human decisions. Define failure detection and return to normal procedure. Constant supervision may shift rather than remove work, so measure it. Assign reviewers and expansion, adjustment or stop criteria rather than judging demo appearance. Make the fallback procedure concrete enough for the operating team to use during a busy period. They should know which cases remain in progress, where the latest confirmed information is stored and who takes ownership after a pause. Test that return path before expanding volume. A pilot that demonstrates recovery and reviewability provides more useful evidence than a polished flow that only works when every dependency responds normally.

The pilot deliverable

Deliver evaluated cases, errors, review workload, required changes and a reasoned recommendation. Deferring expansion is useful when it identifies missing data, rules or ownership. Preserve learning for subsequent evaluations.

Illustrative example: comparing three candidates for the first pilot

Imagine a hypothetical company with three ideas: answering shipping FAQs, qualifying quote requests and reconciling invoices. For each, the team writes down who owns it, what data exists, which decision stays human and what a well-resolved case looks like.

Shipping FAQs have a clear start and finish, the source is a queryable system and the person who handles them today can review exceptions. Quotes depend on criteria that two departments still debate. Reconciliation is valuable but handles sensitive data and lacks a single owner. The team does not pick the most eye-catching one: it picks the one combining value and readiness, and leaves the others with an assigned prerequisite, such as clarifying quote criteria before thinking about automating them.

Common mistakes when choosing the first process

Pilots usually stumble on decisions made before they start, not on the technology. These are the most common ones and the signal that lets you catch them early.

• Choosing the most visible process to impress: if nobody can define a successful case, it cannot be evaluated.
• Starting without an owner. When an exception arises and nobody decides, the pilot stalls or improvises.
• Measuring only with the demo. Ask for real, incomplete and contradictory cases.
• Not defining when the pilot stops. Write in advance which result would lead to expanding, adjusting or stopping.
• Forgetting the review load: if someone watches all day, the work only moved elsewhere.

A checklist to decide whether a process is ready for a pilot

Before committing time, answer these questions with observable evidence rather than hunches. If two or three answers are negative, the next step is probably to prepare the ground, not launch the pilot.

A process on WhatsApp or the web also needs a decision about human support hours, the handoff format with a summary and the provider rules for starting conversations. Those conditions are checked with the current provider and written into the plan, so the team does not discover a limit halfway through the pilot.

• Can I describe in one sentence what a well-resolved case means?
• Is there one person with authority to decide exceptions?
• Is the needed data in a queryable, up-to-date place?
• Do I have a baseline of current performance to compare against?