Pilot

Before the word existed there were two ways to get a new tool into a large company: show a demo and ask for a signature, or install it for everyone at once. Customers didn't believe the first, and vendors couldn't survive the second. Switch a 300-person company over in one move and every hard part lands in the first week — migrating old documents, sorting out who can open which folder, training people who never asked for a new tool. If the verdict two weeks later is that it doesn't fit, all of that work gets thrown away.

So the same conversation kept repeating in enterprise sales, the long multi-month process of selling to large organizations. The customer asks how they can know it will work in their environment. The vendor answers that other customers are happy with it. Neither side has offered evidence, only impressions, and the decision slides another month.

A pilot breaks that deadlock into a smaller question. Instead of deciding whether to adopt the whole thing, one department of 40 people gets access for six weeks, and the record from those six weeks decides.

A pilot is planned backwards from its ending. What goes into it is a finished product: unlike a prototype, which is thrown together just to gauge a reaction, or a proof of concept (PoC), which only checks whether something is technically possible, a pilot has customers doing their actual work inside it. Six steps.

1. Pick one question. "Is this tool useful" is too wide to answer, because no result would settle it. "Does it cut the time people spend hunting for a document" can be settled.
2. Write the success bar as a number, in advance. Something like: if 25 of the 40 invited people are still logging in three times a week in week four, expand; under 15, walk away. Set the bar afterwards and any result reads as a success.
3. Choose the accounts. Three to five customers is the usual size. One account can't tell you whether a problem belongs to the product or to that company, and ten leaves nobody with time to look closely at any of them.
4. Cut the window and the scope. Put an end date four to eight weeks out on the calendar, and open only the features the question in step 1 touches. A pilot with no end date is still running, unjudged, months later.
5. Instrument it before it starts. Usage logs, a weekly call with the customer's point person, a short survey in the final week. Bolted on later, the first two weeks come back empty.
6. On the end date, choose one of three: expand, extend, or stop. Extend is worth using once, and only when the reason the bar was missed is clear and fixable.

Getting participants set up is the same work as onboarding, the process of helping new users find their footing in a product. The difference is that in a pilot someone from the vendor usually does it by hand, creating the accounts and moving the old files across.

Pilots earn their cost when getting adoption wrong is expensive. Migrating 300 people's existing documents, deploying inside a customer's own network, handling payment data that is hard to unwind — those are the cases. On the selling side, large deals tend to bring the request unprompted. Few decision-makers sign a $45,000 annual contract off a single demo.

The other side is just as clear. A product anyone can sign up for and try alone doesn't need one. Designing a pilot and staffing it costs more than opening the door and watching retention, the share of users who keep coming back.

Three limits are worth knowing before reading a pilot result.

The sample tilts toward volunteers. The team that raises its hand is the team already curious about new tools, so satisfaction runs higher than a company-wide average would. Reading 63 percent from 40 people as the number for 3,000 gets it wrong.

Support during a pilot is not the support afterwards. While the window is open, someone from the vendor clears blockers the same day. Usage once that person steps back runs below what the pilot recorded.

Custom work done to pass a pilot stays. Rushing in a feature only that one customer uses buys a contract and leaves code someone has to maintain for years.

"We're running a four-week pilot on this one before we talk contract."

The customer can't decide from a demo, so both sides will look at a record of real use instead.

"If there's no success bar, that isn't a pilot, it's a free account."

Without something to judge against on the end date, nobody will decide anything.

"The pilot numbers were good and the company-wide rollout still stalled."

The team that used it was happy, and the person holding the budget was never convinced.

Pagedeck only runs pilots on deals at companies with more than 200 people. When a customer hesitates mid-negotiation, Sofia opens the product to one 30-person department for six weeks and writes the success bar into a document both sides sign off on. On the end date they open that same document and walk the bar against the actual numbers line by line.

Grace looks at how many pilots turn into contracts each quarter. Six out of ten means the pilot is doing its job as the last check before a signature. Under three, she reads it as a sign that pilots have become a way to postpone decisions.

The most common mistake is treating a pilot as a free trial. Both let someone use the product without paying, so the confusion is understandable. But a free trial is a sales mechanism, where people sign themselves up and convert on their own, while a pilot is a test with a written bar and an end date. Miss that difference and you end up with customers using the product indefinitely. Try to invoice six months in and the answer is that the tool was free from the start, with nothing on paper to point at.

The second is assuming a successful pilot means adoption follows. It looks as though the hard part is over and only paperwork remains. In practice the team in the pilot and the person who controls the budget are different people. A record of 30 happy users is one piece of a decision that, for the executive approving spend for 3,000, sits next to migration cost and pushback from other departments. Leave it there and successful pilot reports pile up while no contract opens. So settle at the start who decides once the window closes, and on what evidence.