How to design a pilot
A pilot is not a free trial. It is a paid, bounded engagement that answers one question: does this create enough value for this customer to keep paying?
Make it small on purposeโ
Pick the narrowest slice that still produces a real outcome:
- one location, one team, one workflow;
- one language to start, if multilingual;
- one channel (say WhatsApp) rather than all of them.
A narrow pilot ships in weeks, not quarters, and the result is unambiguous.
Define done before you beginโ
Agree three things in writing with the customer:
- The outcome โ "cancelled slots are refilled within 30 minutes" โ not "an AI system".
- The measure โ what you will look at together at the end.
- The decision โ what happens if it works (a paid rollout) and if it does not (a clean stop).
Keep a human in the loop from day oneโ
Start with the human approving every automated action, then relax that only where evidence supports it. This builds trust and gives you a labelled dataset of correct decisions for free. See human approval.
Instrument itโ
You cannot prove value you did not measure. Before launch, capture the baseline: how long the task takes today, how often it fails, what leaks. During the pilot, record the same numbers. The gap is your case study โ see measuring economic value.
Time-box and set kill criteriaโ
A pilot with no end date becomes unpaid consulting. Fix a duration (e.g. four to six weeks) and pre-agree the signals that would make you both walk away. Stopping a weak pilot quickly is a success, not a failure.
Nextโ
Decide what is AI and what must be deterministic, then build.