Choose a frequent, understandable workflow with a clear owner, accessible inputs, a measurable baseline, and a manageable failure path. Start where you can evaluate the result, not where the demo looks most impressive.
Compare candidates using the same questions
A team may suggest invoicing, dispatch, document review, lead follow-up, and reporting at once. Before comparing technology, compare the work: how often it happens, how many handoffs it needs, and what a mistake would affect.
Our recommendation is to shortlist two or three processes and walk through a recent example of each. A process that cannot be explained consistently may need an operational decision before it needs automation.
Name the person who owns the result
The pilot needs an owner who can describe exceptions, review the proposed behavior, and decide whether the result is useful. A sponsor can approve spending, but the person responsible for the workflow supplies different information.
For an illustrative service request pilot, the owner might be the coordinator who assigns work every morning. They can identify why a request gets delayed and which details the team repeatedly has to chase.
Check the inputs before promising automation
Determine where the required information comes from, whether the team can access it, and how reliably it arrives. A well-defined process can still be a poor first pilot if the necessary system cannot provide an export or suitable integration.
If documents or messages need interpretation, separate the part that retrieves information from the decision that changes a business record. AI might assist with one step without owning the entire workflow.
Measure the work before changing it
Choose a baseline that the business can actually collect. Examples include time until assignment, number of manual handoffs, or requests still unresolved after an agreed period. Use a representative period and note unusual conditions.
Do not treat a demonstration with synthetic records as evidence of a measured business improvement. A demo can validate behavior; an operational pilot needs real use and a consistent definition of the outcome.
Define the exception route
Write down what happens when information is missing, a tool is unavailable, or the proposed action needs a person’s judgment. Someone should be able to see the unfinished work and take over.
A pilot can deliberately keep a human approval step. The question is whether that step has a clear purpose and enough context for the reviewer. Moving all uncertainty into an unexplained approve button does not resolve it.
Agree on the decision after the pilot
Set a review point and decide what would justify expanding, adjusting, or stopping the workflow. Include operating effort: if staff spend substantial time correcting outputs or maintaining the integration, that work belongs in the assessment.
The first pilot should teach the business how to evaluate an automated process. A modest workflow with visible results provides a stronger basis for the next investment than an ambitious demonstration that nobody owns after launch.