Scope a customer pilot that can end in a buying decision
A prospect likes the demo and asks to try the product. Before you promise a pilot, ask what they still need to learn before buying. If that question has no answer, another month of access may give you more activity without a clearer decision.
This guide is for B2B SaaS founders with an established use case and a prospect considering a purchase. It starts after the discovery conversation. The task is to agree what a limited evaluation will prove, what each team will contribute, and what happens when it ends.
Choose the smallest evaluation that answers the question
Ask the prospect to finish this sentence: “We could decide whether to buy if we knew ___.” Make the missing answer specific enough to demonstrate or measure.
If they need to see how a permission works, a guided demo may answer it. If one person needs to explore an existing workflow independently, ordinary trial access may suffice. If their decision depends on performance in their own operating conditions, propose a bounded pilot with their participation.
GitLab's published Proof of Value playbook distinguishes product access from an evaluation organized around an outcome. Its current page is explicitly a working draft; it provides a useful vendor example, not evidence that this process improves conversion. The approach below is our suggested method for a smaller SaaS team.
Write the unresolved buying question at the top of a shared page. If the question is really whether you can build a missing feature, make a separate product decision before offering an evaluation of the existing product.
Agree on evidence before opening access
Use one principal outcome and a small number of essential checks. For each, record the starting point, the target, how it will be measured, and who accepts the evidence. A target without a measurement method invites a dispute at the final meeting.
AWS's guidance for contact-center migration pilots recommends defining success criteria and next steps before starting, and comparing operational data with the previous platform. That context is larger than a small SaaS sale. Borrow the discipline of an explicit comparison; choose measures relevant to your customer's job.
Check that the comparison is fair. Time spent doing the task and time waiting for another person are different measures. A quieter week can make elapsed time look better without changing the work. Keep setup and training effort visible, even if you report it separately from recurring work.
Worked example: one brokerage, one workflow
The following plan is fictional. Quillback Dispatch helps freight brokerages track missing carrier documents. A prospective customer wants to know whether its coordinator can prepare the daily missing-document list with less manual work.
The proposed pilot covers one coordinator, one agreed carrier list and the existing document-import method. It excludes a new transportation-management-system integration and automatic approval of carriers. The customer keeps its existing approval process throughout.
The coordinator would time the current list-preparation task on five working days, then repeat the measurement on five pilot days. Both teams would record the number of carrier records checked, corrections required and help provided. They would also reconcile the pilot list against the agreed source records to inspect omissions and incorrect flags.
Suppose they propose a target of no more than twenty minutes of list preparation per measured pilot day, with no unresolved omissions or incorrect flags in the agreed reconciliation. Those are invented acceptance criteria for this example, not a benchmark. Before agreeing, the coordinator and operations manager must decide whether the workload and target represent their actual needs.
If the founder prepares the list manually behind the scenes, that assistance belongs in the result. It cannot establish that the coordinator can run the workflow unaided.
Put customer work and vendor limits on the same page
Use your buyer map to confirm who can supply the data, do the work and approve the next step. A willing user cannot necessarily authorize access or spending.
Name the customer's owner for data and participation, your owner for setup and support, and the person who will judge the result. Confirm permitted data, access and any required review before transferring records. If prerequisites are missing, record the missing item and its owner before setting a start date.
Then state your effort boundary: the supported configuration, included setup, available support and excluded development. Discuss any pilot fee and the likely purchase terms before work starts. A paid pilot still needs a decision plan; a free one still consumes capacity.
For Quillback, a request for a custom integration would trigger a scope discussion. The founder could propose a separate priced project, revise the pilot with the customer, or decline. Quietly adding it would change both the effort and the question being tested.
Separate the product result from the buying result
Book the final discussion before kickoff. At that meeting, show the evidence against each agreed criterion, including failed checks and missing observations. Record whether the evaluation met the criteria, failed them, or remained inconclusive.
Then ask for the commercial decision separately. A product can meet the criteria while a purchase remains blocked by budget, procurement or priority. Record that blocker and its owner. Do not label an unsigned opportunity a sale because the pilot worked.
Extend only to answer a named unresolved question with a feasible method and a new agreed end date. “They need more time” is a prompt to investigate: did the product fail, did participation never happen, or did another priority intervene? Each calls for a different response.
Take this plan into the next conversation
Complete these six lines with the prospect before committing resources:
- Buying question: What uncertainty prevents a decision?
- Scope: Which workflow, users and data are included, and what is excluded?
- Evidence: What baseline, target, measurement and acceptance checks will you use?
- Responsibilities: Who supplies inputs, runs the work, supports it and reviews the result?
- Boundary: What effort, fee, prerequisites and change process are agreed?
- Decision: When will you review, who attends, and what happens after success, failure or an inconclusive result?
Send the page back for correction. Where an answer is missing, make resolving it the next step. The useful commitment is a pilot both teams can execute and interpret.