Pitch a Customer Pilot With a Decision at the End
Pitch a Customer Pilot With a Decision at the End
"Let's do a pilot" is one of the easiest sentences in a sales conversation and one of the least useful. It sounds like movement. What it usually describes is a date range, an account, and an unspoken hope that familiarity turns into a purchase. The customer is left to work out what is being tried, what will be watched, and what they are agreeing to when the window closes.
Build the proposal backwards instead. Name the decision the customer still has to make, the observation that would inform it, and the person who will make the call. Access, training, records, and criteria are all servants of those three things. It fits on a page, and it is worth agreeing before anyone promises anything.
It also helps to know which question you are answering. A demonstration shows a workflow under your control and answers whether it can work at all. A technical proof of concept asks whether something operates inside the customer's environment — installs, connects, survives the real inputs. An adoption pilot asks a third question: whether this task, done by these people, under ordinary conditions, gets done this way. Those are different trials with different evidence. A proposal that blends them usually ends with everyone disagreeing about what was proven.
Choose the next decision and a bounded workflow
Start with what the customer still needs to judge. Write the decision as a question in their vocabulary, not yours. If you cannot write it that way, you have a calendar entry rather than a pilot.
The example running through this piece is invented. Ridgeline University's materials lab is fictional, no trial has been run, and no customer has agreed to any of these terms. It is here because the arithmetic of a real proposal is easier to see when the details are settled.
The lab shares two instruments — a diffractometer and a microscope — among about a dozen authorized users: graduate researchers, a couple of postdocs, and the lab's own technician. Booking today happens through a shared calendar, a whiteboard beside the instrument, and a paper logbook. The lab manager runs the schedule. The technician releases the instrument and takes it back. A staff safety officer has a say in how instrument use is recorded.
The decision the lab actually faces is narrow:
Should handoffs for the diffractometer move from the shared calendar, the whiteboard, and the logbook to the booking workflow — before we discuss the microscope or the other two labs?
That is a question with a scope. The second instrument, the other labs, and everything downstream are deliberately outside it. That is not stinginess. It is what makes the answer usable, because a result about one instrument under one lab's conditions can be read and argued with.
It also fixes the class of question. This pilot is about practical use: is the workflow usable under ordinary handoff conditions, by the people who do handoffs? It is not a technical proof of concept — the software already runs on the lab's network — and it is not a business outcome question, such as whether the lab publishes more papers. One small activity cannot establish all three by implication. If you find yourself promising that a trial will show the software works, that people like it, and that the department benefits, you have described a deployment in miniature, and its real subject is your project management.
Define what must be available before the trial starts
Entry conditions come next: access, usable inputs, the people involved, and the supporting work. Then who performs the task, who authorizes the resources, and who is affected by the change. Supplier contributions and customer contributions both need to be on the page, in specific terms.
For the lab, the supplier would commit to configuring the booking module for one instrument, importing the twelve accounts, running a short training session at a time the technician chooses, providing a one-page handoff instruction, and naming a support contact with an agreed response expectation. The supplier would have access to booking metadata only — never to experimental data, sample identities, or results tied to users.
The lab would commit to supplying its list of authorized users and who among them may badge in after hours, the technician's availability through the trial, the current calendar and logbook for the comparison period, the lab manager's twenty minutes each week, and something less obvious: a confirmation from the safety officer that a booking record may carry the badge identity and reconcile with the badge record for anyone who runs the instrument. That last item is not paperwork. It is the requirement the stop condition below names, and settling it here rather than in week six is the difference between a result and a shrug.
Notice where the approval sits. The lab manager can authorize participation, the technician's time, and the change to the instrument's schedule. Nothing in this pilot needs the department head's sign-off, and that is deliberate. The wider decision about rolling out to other instruments stays where it belongs, with someone who is not being asked to judge a trial.
A start date does not establish readiness. Software access does not ensure that the relevant task will occur. If the technician is on leave for two of the pilot's weeks, or the instrument goes into service, the window passes without the events you need. So the proposal states the readiness rule plainly: the pilot begins on the first Monday after every item above is true, not on the date printed in the deck.
The habit of separating start conditions from evaluation conditions is not unique to sales. AWS's Prescriptive Guidance for migrating to OpenSearch has a proof-of-concept stage that distinguishes entry criteria — use case, environment access, preparation — from exit criteria for judging the outcome (the page's section on defining entry and exit criteria, docs.aws.amazon.com/prescriptive-guidance/latest/opensearch-service-migration/stage-2-poc.html, checked 18 September 2026). It is a narrowly drawn technical example for one migration path. A technical proof of concept is not a customer adoption pilot, and that page says nothing about whether this method of pitching a pilot works. What it does show is that the two lists are genuinely two lists, and it is worth keeping them on separate halves of the page.
Agree what will be observed and compared
A task needs a start and a completion point. Here, a booking begins when a borrower asks for a slot and ends when the instrument is back and the record names who released it, who received it, and when. Anything vaguer and the trial will be scored by memory.
Then look hard at what the current process can actually support, because the comparison is where pilots quietly become dishonest. In the lab today, the shared calendar shows who claimed a slot. The whiteboard beside the instrument holds the informal layer around those claims — who is running late, who has swapped with whom, who goes next. It names people, but only the ones anyone is thinking about that week, and it is wiped so often that nothing on it outlives the week it was written, so it is not a baseline anything can be compared against. The logbook shows a handwritten borrow entry, sometimes a return time, rarely the name of the person who released the instrument. Conflicts get settled in the corridor and leave no trace at all. There is therefore no way to compare request-to-confirmation times between the two processes, because the current process never recorded a confirmation.
What both sides can support is a simpler event list: request, confirmation, handoff, return, conflict. For each event, was there a record, and did it name the people involved? The new workflow will produce a fuller record than the logbook does — and it is worth saying out loud that a richer record is a difference in record-keeping, not yet a difference in outcome. Duration can be reported for the new path as a description, clearly marked as one.
Three kinds of statement need to stay apart all the way through the write-up. First, observation: six of eight handoffs have a record naming both people. Second, participant judgment: the technician says the confirmation step added about a minute to each handoff. Third, interpretation: the workflow reduced scheduling conflicts. That third claim may well be true, but this pilot's design probably cannot establish it, because conflicts are rare and the old process never captured the ones that were settled informally.
Thresholds belong to this use case, agreed by the people who will read the result. The lab manager's criterion is coverage rather than a rate: at least twelve completed bookings across eight weeks, including at least three after-hours handoffs and at least one conflict that goes through the conflict route and gets a recorded resolution. Those numbers are illustrative, chosen for this proposal, not drawn from any data set and not a statistical threshold. If someone suggests an eighty percent success rate instead, ask what evaluation design would support that number and who picked it. Borrowed thresholds produce disagreements about arithmetic rather than decisions about work.
Make all four endings possible
A pilot that can only end one way is not a pilot. The proposal should say in advance what would justify continuing, changing something, stopping, and admitting the question went unanswered.
Continue requires that the workflow actually occurred and that the agreed critical steps are held by records. In the lab: every completed booking has a request record, a confirmation, and a handoff naming both people; the after-hours handoffs happened and were recorded; a conflict went through the route and has a recorded resolution. The result is a positive answer to the diffractometer question — and it still does not settle wider rollout. The next step is likely a new pilot for the microscope, with its own entry conditions and its own decision. Rolling out is a different decision, made by a different person, informed by this result rather than caused by it.
Change means a specific, nameable problem in access or handoff, with a reason to think the evidence would come out differently next time. Suppose the after-hours handoffs went unrecorded because the deputy technician was never added to the authorized list, or suppose every conflict in the eight weeks arrived in the evening, when the lab manager — the only resolver named in the proposal — is unreachable. Fix the thing, state which observation the change is meant to produce, and run it again. A change result is a success of the pilot, not a failure of it.
Stop means an essential requirement remains unmet. The lab's safety practice requires that the booking record reconcile with the badge record for whoever runs the instrument — the requirement the safety officer confirms at the gate. If, over the trial, the two records cannot be reconciled for the people who ran the instrument, and no acceptable workaround exists, the proposal fails on a requirement that no additional weeks will repair. Put that possibility in the proposal at the start. A stop everyone knew was possible costs a few weeks. A stop that arrives as a surprise costs the relationship.
Inconclusive means too few relevant opportunities occurred, or the records do not support the comparison for reasons unrelated to the workflow. Run the lab example: the instrument goes out for service for four of the eight weeks, and the remaining weeks fall in the term break. Seven completed bookings happen, two after-hours handoffs, no conflict through the route. The question — is this workflow usable under ordinary handoff conditions, including after hours and conflicts — has not been observed. That is not a soft failure and it is not a quiet success.
An extension can be reasonable, but only with a new evidence reason. "Three more weeks of ordinary term schedule to reach twelve bookings, including a conflict" is a reason. "We're close" is not. And an extension must not become the automatic path to purchase, because that is what turns a pilot into a discount with a longer name. The customer learns the rule quickly: pilot windows here lead to invoices regardless of what happened inside them.
The last line of the proposal names the judges. In the lab, the manager decides whether the workflow is usable under handoff conditions, and the safety officer decides whether the records are acceptable. The department head decides about any wider rollout, separately, with this result in hand. A supplier does not get to judge its own pilot, and a proposal that leaves the criteria vague is usually hoping to.
Here is the whole thing on one page, in the form worth putting in front of the customer:
- Decision: whether diffractometer handoffs move to the booking workflow, before the microscope and the other labs are discussed.
- Workflow: request, confirmation, release, return, and conflict resolution for one instrument.
- Before we start: accounts and configuration, training, the technician's availability, the current calendar and logbook, the safety officer's confirmation on records, weekly review time.
- What we watch: for each of the five events, whether a record exists and whether it names the people involved.
- What would mean continue: twelve or more completed bookings with records across the critical steps, including three after-hours handoffs and one conflict resolved through the route.
- What would mean change: a named access or handoff failure with a stated reason to expect a different result next time.
- What would mean stop: the booking record cannot be reconciled with the badge record, and no acceptable workaround exists.
- What would mean inconclusive: too few relevant bookings occurred, or the records do not support the comparison for reasons unrelated to the workflow.
- Who decides: the lab manager on usability, the safety officer on records, the department head on anything wider.
- Window: eight weeks, starting the first Monday after the conditions above are met.
Those criteria are invented for this illustration and would have to be negotiated, in the customer's room, with the people named in them. That negotiation is the pilot's first real test. If the customer can read the page and say "if that happens, we stop" without it sounding like a threat, you have written a pilot. If the only ending either side will accept is a purchase, save everyone the eight weeks and say what you actually meant.
Frequently asked questions
What three things should a pilot proposal name before access, training, and records?
The decision the customer still has to make, the observation that would inform it, and the person who will make the call. If the decision cannot be written in the customer's vocabulary, the proposal is just a calendar entry.
How are a demonstration, a technical proof of concept, and an adoption pilot different?
A demonstration shows a workflow under your control and asks whether it can work at all. A technical proof of concept asks whether something operates in the customer's environment. An adoption pilot asks whether this task, done by these people under ordinary conditions, gets done this way. Blending them often leaves everyone disagreeing about what was proven.
Why is a start date not enough to begin a pilot?
A start date does not establish readiness; software access does not ensure the relevant task will occur. The invented lab pilot begins on the first Monday after all entry conditions are true, not on the date printed in the deck. AWS's OpenSearch proof-of-concept guidance separates entry criteria from exit criteria, though that is a narrow technical example, not an adoption pilot.
What can be compared when the current process lacks a clean baseline?
Compare only what both processes can support. In the lab, the shared calendar, whiteboard, and logbook never recorded a confirmation, so request-to-confirmation times cannot be compared. A simpler event list can be compared: request, confirmation, handoff, return, conflict, with whether a record exists and names the people involved. A richer record is a record-keeping difference, not yet an outcome difference.
What four endings should a pilot proposal make possible?
Continue, change, stop, and inconclusive. Continue depends on the workflow occurring and critical steps being recorded; change names a specific access or handoff failure and why evidence might differ next time; stop means an essential requirement is unmet, such as booking and badge records not reconciling; inconclusive means too few relevant opportunities occurred or records cannot support the comparison. An extension needs a new evidence reason, not just being close.