A B2B SaaS pilot program is a bounded evaluation in which a prospective customer tries an existing product on a specific workflow to decide whether to buy. Start by agreeing what the buyer needs to learn, who will do the work, how you will measure it and when you will decide. This guide gives you a pilot brief, an attempt log and a worked scorecard you can use without signing up for anything.
Choose a pilot only when it can answer the buyer's question
Ask: What would you need to see to decide whether this product belongs in your workflow? A useful answer might be whether two account managers can prepare a complete client handoff without the founder repairing it. That can be tested. A vague request to explore the platform needs a scoping conversation first.
A pilot adds work for both sides. If a demonstration already resolves the question and the buyer is ready to buy, an extra evaluation may only delay the decision. If the blocker is an unavailable budget or an unapproved data requirement, access to the product alone will not resolve it.
Keep the pilot's job distinct from discovery and beta testing
Companies use pilot, trial and proof of concept differently. Define the work together instead of relying on the label. In this guide, a pilot evaluates a usable product in a buyer's workflow and ends in a buying decision. A technical proof of concept can be narrower: whether one integration or technical requirement works at all.
A design partnership helps shape a product that still needs learning and development. A beta test helps you observe early use and find problems. Either can lead to a commercial pilot, but feedback, attendance and enthusiasm do not establish a purchase. Keep each relationship's purpose and expected contribution explicit.
If you are still deciding whom the product is for, use the design-partner or customer-discovery guides linked below. This pilot plan starts with a plausible buyer and a workflow your current product can already attempt.
Agree on the start conditions before starting the clock
- One workflow: name the task, the people who perform it and what is outside scope. Avoid a company-wide evaluation of every feature.
- A user and a buyer: identify who will attempt the task, who can judge its usefulness and who approves the purchase. One person may hold several roles; verify that rather than assuming it.
- Usable inputs: confirm the sample work, access and permissions needed for a real attempt. Record a blocked prerequisite separately from a product failure.
- A baseline: record how the same type of task works today, including time, errors and assistance. State the measurement method before comparing results.
- Capacity on both sides: agree who handles setup, how much support is available and which custom requests are excluded.
- A calendar: choose a start date, a checkpoint and a decision date that contain enough normal work to observe the question. There is no universal 14-, 30- or 90-day requirement.
Copy the pilot brief and fill it with the buyer
Copy the blank fields into your own document. The filled column follows a fictional client-handoff product called HandoffKit and a fictional agency called Northstar Studio. Every organization, date, number and outcome in this example is invented to demonstrate the method. It is not a Soloop customer case or a recommended benchmark.
The brief is an operational plan. Record commercial and data-handling terms in the appropriate agreement separately; this table is not a contract template. On a small screen, scroll each table sideways to read all columns.
| Dimension | Your pilot | Fictional HandoffKit pilot |
|---|---|---|
| Decision | [Buyer question and decision to make] | Can account managers prepare usable client handoffs with less active work, enough to consider buying? |
| People | [Users, evaluator, buyer and founder owner] | Two account managers use it; operations lead evaluates; agency owner approves spending; founder provides setup. |
| Scope | [Workflow, sample and exclusions] | Five client handoffs in one team; no CRM integration or historic migration. Buyer checks that the five cases resemble normal work. |
| Baseline | [Current method, observations and source] | Five prior handoffs: 28, 35, 27, 32 and 28 active minutes; mean 30. Manager's timed log, with the same start/end rule used in the pilot. |
| Criteria | [Outcome, threshold, evidence and evaluator] | At least four of five handoffs completed without founder repair; mean active time for those independent completions at most 24 minutes; no missing required field in delivered handoffs. |
| Calendar | [Setup gate, start, checkpoint and final review] | Setup ready Oct 12; use Oct 13–23; checkpoint Oct 19; decision meeting Oct 26. Dates chosen for this team's available work. |
| Support | [Setup, support limit and exclusions] | One setup session plus up to two founder support hours. Log every repair. New integrations require a separate decision. |
| Commercial path | [Pilot fee, post-pilot scope/price and buyer confirmation] | Pilot fee waived for this bounded evaluation; paid rollout scope and price discussed separately. Owner's budget approval is still pending. |
| Exit | [Buy, bounded further test or stop; access/materials owner] | Review the scorecard and approval status together. End trial access if stopping; operations lead and founder confirm the agreed handling of shared material. |
Decide whether the pilot is paid, and what payment would mean
Choose terms based on the work and the buyer's process. A pilot requiring substantial setup or dedicated support needs a commercial discussion before that work starts. A narrowly bounded free evaluation may be reasonable when both sides can commit the time and you can afford the learning. Neither payment structure fixes an unclear question or an absent evaluator.
Write down what the pilot includes, what the buyer contributes, what happens at its end and how a later purchase would be considered. Make any credit toward a later purchase explicit if you offer one. Do not import an enterprise pilot fee or duration from another company's guide as the right price for your product.
Record a pilot fee, a later subscription decision and recurring product use separately. Payment for evaluation is evidence of that transaction; it does not establish renewal, retention or that the product will work independently across other accounts. Likewise, a champion saying they want to continue does not establish budget approval.
Log actual attempts, including the founder's help
Use one row per real attempt. Record the task ID, date, starting conditions, completion evidence, active effort, interruptions and any assistance. Keep elapsed waiting time separate from active work. Name the evidence you inspected; label estimates and recollections as reported.
In the fictional pilot, all five handoffs reach the recipient with the required information. One only succeeds after the founder manually repairs its export. An average that includes that faster, assisted attempt would hide the product's dependence on support.
| Dimension | Recorded effort and assistance | Completion evidence |
|---|---|---|
| P01 | 22 active minutes; no founder repair | Recipient checks required fields against the delivered handoff. |
| P02 | 12 active user minutes; founder repairs export separately | Delivered successfully after repair; founder time logged in support notes. Assisted completion. |
| P03 | 30 active minutes; no founder repair | Delivered with required fields; user has to re-enter duplicated context. |
| P04 | 24 active minutes; no founder repair | Delivered with required fields; recipient check recorded. |
| P05 | 28 active minutes; no founder repair | Delivered with required fields; user again re-enters context. |
Read the results against the criteria you agreed
Across all five fictional attempts, user time averages 23.2 minutes: (22 + 12 + 30 + 24 + 28) / 5. That looks below the 24-minute target, but the target was explicitly for independent completions. Their mean is 26 minutes: (22 + 30 + 24 + 28) / 4. The time criterion has not been met.
The independent mean is four minutes below the fictional 30-minute baseline, which is a useful observation for this sample. The small, selected set, differences between tasks and learning during the pilot prevent treating that difference as a causal estimate or a result you can promise other customers.
| Dimension | Agreed criterion or open question | Readout |
|---|---|---|
| Independent use | At least four of five handoffs without founder repair | Met for this sample: P01, P03, P04 and P05; P02 remains assisted. |
| Active effort | Independent completions average at most 24 minutes | Not met: 26 minutes. Do not substitute the assisted 23.2-minute average. |
| Completeness | No missing required field in delivered handoffs | Met in the recipient checks for these five outputs, including the repaired one. This does not establish general reliability. |
| Support burden | Could the founder sustainably support more accounts? | Unknown from these rows alone. Review the separate setup/repair time log before a rollout decision. |
| Purchase | Does the authorized buyer approve scope and price? | Unresolved: owner has not approved budget. No subscription purchase recorded. |
Finish with a buying decision, a bounded follow-up or a stop
At the final meeting, show the evidence before discussing impressions. Ask the evaluator whether the records describe their experience, then ask the buyer what decision they can make. Product fit and purchase readiness can differ; keep both visible.
In the fictional case, the founder proposes removing duplicate entry and repeating comparable handoffs. That is only a proposal. The buyer has not agreed to more work or approved spending, so the accurate outcome is: first evaluation finished; time criterion missed; further evaluation and purchase undecided. End the initial access period according to the agreed plan unless both sides explicitly change it.
- Proceed to a purchase when the buyer chooses the offered scope and terms. Record the actual next step and its owner; mark payment only when confirmed.
- Run a further test only when a specific unresolved question matters, both sides agree what will change and a new end date is set. Missing budget by itself is not a reason to keep providing unlimited free support.
- Stop when the workflow is a poor fit, the prerequisites remain unavailable, the support load exceeds what you can offer, or the buyer declines. Record what you learned without calling the account a converted customer.
Bring one unresolved research question to Soloop
Use the brief and scorecard yourself, then identify any question that public-source research can actually answer. For example: What alternatives does this kind of agency use for client handoffs, and what setup do those alternatives require? Research can inform scope and follow-up questions; the customer still has to demonstrate its own workflow.
A brief to copy: My product is [URL or demo] for [role and workflow]. A prospective buyer needs to evaluate [specific task]. Research [one question] using [public source URLs or scope]. Compare the relevant alternatives, attach source links and access dates, and separate company claims from observations and unknowns. End with the questions I should verify with the buyer before agreeing to a pilot.
Soloop's manual describes market and competitor research with reports and any collected source links in Tasks. Open the result and check the sources behind decisions that matter. Bring only material you may share. You and the buyer run the pilot, collect usage evidence and make the commercial decision; this guide does not establish an automated pilot-management service.
The Explore Soloop link opens the public entry and does not transfer this brief or your customer notes. A completed document is already a useful outcome even if you never open a Soloop workspace.
Sources and limits
Sources checked October 7, 2026. The brief, task log, thresholds, arithmetic and fictional readout are original Soloop editorial examples. They have not been tested in a customer study. Recheck the product manual when choosing a task, and adapt the pilot to the buyer's real workflow rather than adopting the example's dates or targets.
Headway's Andrew Verboncouer describes planning a B2B software pilot, collecting a baseline and maintaining a feedback cadence. His article reports practitioner experience; it does not validate the fictional results here.
Headway: How to Run a Software Pilot ProgramFirst Round's expert interview discusses choosing a pilot around the prospect's actual concern, with a defined process and prerequisites. A pilot can add friction when the prospect could already make a purchase decision.
First Round: Common Go-to-Market QuestionsSoloop documents public-source research and task results. Buyer access, usage measurements and commercial decisions in this guide remain the founder's and customer's work.
Soloop product manual