Skip to main content

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:

  1. The outcome โ€” "cancelled slots are refilled within 30 minutes" โ€” not "an AI system".
  2. The measure โ€” what you will look at together at the end.
  3. 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.