# How to design a sales enablement pilot that answers the scale question

> Design a sales enablement pilot around the question it must answer, then size it. A readiness pilot of 15–30 reps tests logistics. A proof pilot needs enough reps to compare groups, usually 100 or more, a pre-launch baseline, a team that starts 30 days later, agreed data access and a scale rule written down before launch.

Source: https://enablement.works/guides/enablement-pilot-design/ · Updated 2026-11-06 · Enablement Works

## Key takeaways

- Pilot size is a design decision: decide what the pilot must prove before you choose how many reps to include.
- A readiness pilot tests whether people finish and what breaks; a proof pilot tests whether behavior and outcomes change enough to scale.
- With 25 reps, the margin of error on a 30% rate is about plus or minus 18 points, too wide to rank teams.
- Low pilot completion is usually a sponsor-network problem, not a content problem; name the three peer leaders the sponsor will enlist.
- Report week-2 usage against week 1, and relaunch fixes personally to the reps the first version lost.

Pilots get kept small to lower the risk. Then a skeptical sales leader asks whether the program works at 100 reps or more, and the pilot has no answer either way. The risk you avoided by keeping it small comes back as doubt. This guide shows how to design a pilot that answers the question the scale decision depends on.

## What question must the pilot answer?

Decide what the pilot must prove before you decide its size. There are two kinds of pilot, and most failed pilots are one kind sold as the other.

| | Readiness pilot | Proof pilot |
|---|---|---|
| Question | Can we run it? Do people finish? What breaks? | Does it change behavior and outcomes enough to scale? |
| Typical size | 15–30 reps, one or two teams | 100 or more reps, several teams |
| Length | 2–4 weeks | 60–90 days |
| Comparison group | Not needed | A team that starts later, or a holdout |
| Main metrics | Completion, week-2 usage, support load, time per session | Behavior rate vs baseline, outcome at the target stage |
| Output | A fix list | A scale, extend or stop decision |

A small pilot is still useful. It shows logistics, support load and whether people finish. Call it a readiness pilot and do not let anyone read it as proof.

## How big does a proof pilot need to be?

Big enough that the difference you care about is larger than the noise. The quick check is the margin of error on a rate:

**95% margin of error ≈ 1.96 × √(p × (1 − p) ÷ n)**

where p is the rate you expect (for example, the share of reps who show a behavior) and n is the number of reps.

| Reps in the group (n) | Margin on a 30% rate |
|---|---|
| 5 | ± 40 points |
| 25 | ± 18 points |
| 100 | ± 9 points |
| 400 | ± 4.5 points |

A 25-rep pilot split across five teams gives five reps a team. At that size, a team's rate could sit anywhere in an 80-point range by chance. The results still get ranked, and the "top" team is really just the least weak. The report reads like a verdict, but it is noise.

This is not only a sales problem. A widely cited review in Nature Reviews Neuroscience showed that small studies have a reduced chance of detecting a true effect, and that low power also makes significant results less likely to be true and tends to inflate effect sizes ([Button et al., 2013](https://research-information.bris.ac.uk/en/publications/power-failure-why-small-sample-size-undermines-the-reliability-of/)). A small pilot that "worked" may have worked less than it looked.

Our rule of thumb: below roughly 100 people, present pooled results with a caveat and do not rank groups. The formula also flatters you, because reps on the same team are not independent. Real margins are wider.

## How do you build a comparison group without holding anyone back?

Use a staggered start. All teams begin without the program, then switch to it in waves, typically 30 days apart. Until a team switches, it serves as the comparison for the teams that already have.

Health researchers use the same design, called a stepped wedge trial. In it, all clusters start in the control condition and a random order decides when each one crosses over ([Campbell, Hemming and Taljaard, 2019](https://www.mja.com.au/journal/2019/210/6/stepped-wedge-cluster-randomised-trial-what-it-and-when-it-should-be-used)). The same paper names the main risk: confounding by time. A new pricing change or a strong month lands on everyone, so always compare waves in the same calendar period, never wave 1's first month against wave 2's first month.

Three rules make it fair:

1. Use waves of similar size, segment and tenure.
2. Decide the order by coin flip, not by which manager is keenest.
3. Take the baseline for every wave before wave 1 starts. Gartner's guidance is the same: establish a baseline for the targeted behaviors before you try to show impact ([Gartner, 2023](https://www.gartner.com/en/newsroom/press-releases/2023-02-15-gartner-expects-sales-enablement-budgets-to-increase-by-50-percent-by-2027)).

## What must be agreed before launch?

Agree three things in writing: the data, the metrics and the decision rule.

- **Data.** Who supplies call and CRM data, in what format, by what date, and where it will be analyzed. If someone names an outcome metric but never sends the data, the pilot is a demo, not a test. Call data access is often a legal and IT conversation, so start it in week one.
- **Metrics.** One behavior metric, one usage metric and one outcome metric, each with a formula. The [sales enablement metrics guide](/guides/sales-enablement-metrics/) lists formulas for each level.
- **Decision rule.** What result means scale, extend or stop. Write it before you see any data.

## Why do pilots stall, and how do you prevent it?

Low pilot completion is usually a network problem, not a content problem. When a pilot stalls, the first explanation is always the content. Peel it back and the pattern is often the same. Reps say they are too busy. Their managers never mentioned it. The peer leaders who run those teams were never told the pilot existed. And the sponsor is isolated, often new in the role and without the standing to call in favors yet.

Change research backs the sponsor's role. Prosci's Best Practices in Change Management report has found active and visible sponsorship to be the top contributor to success since 1998. In its 12th edition, projects with extremely effective sponsors met objectives 79% of the time, against 27% with extremely ineffective sponsors ([Prosci](https://www.prosci.com/resources/articles/change-management-best-practices)).

Before launch, ask one question: which three peer leaders will the sponsor personally enlist? If the answer is unclear, that is the plan. A brand-new sponsor is not a neutral fact; it is a risk factor. The fix is cheap once named: brief the peer leaders and, if needed, reopen the window. Managers matter one level down, too; see [why training fades without managers](/guides/sales-manager-reinforcement/).

## How should you report pilot usage?

Report week 2 against week 1, not a cumulative total. Week 1 measures the announcement. Week 2 measures the program. A launch total hides the most useful number in the chart, which is how much usage survives when nobody is pushing.

**Retention ratio = reps active in week 2 ÷ reps active in week 1.**

Plot it weekly for the whole pilot. A falling ratio in week 2 is a design signal; a falling ratio in week 5 is often a manager signal.

## Is a fix the same as a relaunch?

No. Reps decide once. A fix shipped quietly reaches nobody who already left, and partial coverage trains the habit of not using the tool. This is common with new tools for sellers: version one covers half the workflow, reps use it until their deal moves past that half, then stop. The rest ships later, and they do not come back.

Three habits help. Ship the whole workflow thinly before any stage deeply. When a fix lands, relaunch it personally to the reps the first version lost; release notes are not a relaunch. And if you cannot wait for full coverage, say plainly which deals it is for and give a date for the rest. This applies with special force to [AI roleplay pilots](/guides/ai-roleplay-sales-training/), where first impressions of a clunky session last.

## Example: a 120-rep proof pilot

Example: a company wants to know whether a discovery program should go to all 600 reps. It designs a proof pilot with 120 reps in two waves of 60. Wave 1 starts on 12 January, wave 2 on 9 February. Baselines for both waves are taken in the two weeks before 12 January.

The decision rule, written before launch: scale if, by 8 February, the share of reps showing the behavior on most eligible calls rose at least 10 points more in wave 1 than in wave 2, and the week-2 retention ratio was at least 60%. These thresholds are an example, not a standard.

| Metric | Wave 1 baseline | Wave 1, 8 Feb | Wave 2 baseline | Wave 2, 8 Feb |
|---|---|---|---|---|
| Reps showing the behavior on most eligible calls | 25% | 45% | 25% | 27% |
| Active reps, week 1 → week 2 | n/a | 54 → 41 | n/a | n/a |

Wave 1 rose 20 points and wave 2 rose 2, a difference of 18 points. With 60 reps per wave, the margin on each rate is roughly ± 12 points, so an 18-point gap is unlikely to be chance; a 5-point gap would not be. The retention ratio is 41 ÷ 54, or 76%. Both conditions pass, so the program scales in waves of 120, keeping the staggered design. Results go onto the [monthly CRO report](/guides/enablement-report-for-cro/).

## Common mistakes

- **Sizing for low risk instead of for the question.** The skeptic's question goes unanswered.
- **Ranking teams of five.** The "winner" is noise.
- **No baseline.** Nothing to compare against, so every result is an opinion.
- **No data agreement.** The outcome metric is named and never delivered.
- **Launching through one contact.** Completion follows the sponsor's network, not the quality of the content.

The limit: even a well-designed proof pilot shows that a program works in your conditions this quarter. It does not guarantee the effect holds at ten times the size without the operations behind it.

If you are deciding whether you have the hours to run a pilot like this properly, the free 20-minute [Capacity Check](/#capacity-check) is a useful first conversation.

## FAQ

### How long should a sales enablement pilot run?

A readiness pilot needs two to four weeks. A proof pilot needs 60 to 90 days: about two weeks for baseline, 30 days for the first wave before the comparison team starts, and enough time for behavior to show on calls. Outcome metrics may need a full cycle at the target stage.

### How many reps do you need for a sales pilot?

For a readiness pilot, 15 to 30 reps across one or two teams is enough. For a proof pilot that compares groups, plan for 100 or more, split into groups of at least 25 to 30. Below roughly 100 people, report pooled results with a caveat and do not rank teams.

### What success criteria should a sales pilot have?

Write them before launch: the behavior metric and the minimum change that counts, the usage threshold, the outcome you will watch and who supplies the data. Add the decision each result triggers, such as scale, extend or stop.

### Why do sales enablement pilots fail?

Most fail on design rather than content: too small to compare groups, no baseline, no agreed data or a sponsor without a network to drive completion. A pilot that cannot answer the skeptic's question has failed even if everyone liked it.

### Should a vendor tool pilot use your own data?

Yes, if the pilot is meant to prove impact. If the outcome metric is named but the data never arrives, the pilot is a demo, not a test. Agree access with legal and IT before kickoff, including where the data is analyzed.

### What happens after a successful pilot?

Scale in waves, not all at once. Keep the staggered-start design so each new wave has a comparison, keep the same metric definitions and relaunch to any pilot reps who dropped off. Budget the operations work, not just the licenses.

## Sources

- [Button et al., Power failure: why small sample size undermines the reliability of neuroscience, Nature Reviews Neuroscience (2013)](https://research-information.bris.ac.uk/en/publications/power-failure-why-small-sample-size-undermines-the-reliability-of/)
- [Campbell, Hemming and Taljaard, The stepped wedge cluster randomised trial: what it is and when it should be used, Medical Journal of Australia (2019)](https://www.mja.com.au/journal/2019/210/6/stepped-wedge-cluster-randomised-trial-what-it-and-when-it-should-be-used)
- [Prosci: Best practices in change management](https://www.prosci.com/resources/articles/change-management-best-practices)
- [Gartner: Gartner expects sales enablement budgets to increase by 50% by 2027 (press release, February 2023)](https://www.gartner.com/en/newsroom/press-releases/2023-02-15-gartner-expects-sales-enablement-budgets-to-increase-by-50-percent-by-2027)