Every institutional sale I have been part of has had a moment where a pilot was proposed. It sounds like a kindness to both sides. The buyer gets to try the product with no commitment, and the seller gets a foot in the door. For a small team it is also the most dangerous document you will not write.
The pattern is familiar. A principal or a head of department is enthusiastic. A pilot is agreed in a hallway. Fourteen months later the product is still "in pilot", the champion has been moved to another campus, nobody can say what success was supposed to look like, and your two best engineers have spent a good part of the year doing the institution's integration work for free.
The pilot did not fail. It never had a way to succeed or to end. This article is about what to write into a pilot before the first login, so that it either converts or ends cleanly and quickly. Both outcomes are fine. The expensive outcome is the third one.
Why pilots stall
A pilot is a decision postponed. Everyone involved is making a small, reversible commitment because the large commitment is not yet possible. That is a legitimate use of a pilot, but it carries a hidden assumption: that someone will eventually make the large decision.
In an institution, that decision usually belongs to someone who was never in the pilot. The enthusiastic user is rarely the person who owns the budget, and the budget owner is rarely the person who signs. A purchase above a head's own limit needs a second signature, sometimes a committee, and often a fiscal year boundary. Your pilot may be running perfectly while the actual decision sits in a calendar you have never seen.
A small team has a particular weakness here. A larger vendor can afford a customer-success person to chase the decision. You cannot, so the pilot has to carry that weight itself, in writing, from the first day.
The pilot charter: five things to write down
I ask for one page, signed by both sides, before any account is created. It does not need to be a legal document. It needs to be specific.
1. Named success criteria
"Teachers find it useful" is not a criterion. A criterion is something that can be observed and that would change a purchasing decision if it came out the other way. For an assessment product it might be that a defined group of teachers set and graded a defined number of assessments through the system over a defined term, and that grading time per assessment fell against a baseline the institution agrees to measure. For an ERP-style product it might be that attendance and fee records for one grade were run entirely through the system for a full month-end.
Write the number, the group, and the period. Then write who measures it. If the institution will not name a measure, the pilot is a courtesy visit.
Two things to be careful about. First, keep it to three criteria at most. A pilot with twelve goals will hit nine and be judged on the three it missed. Second, include one criterion that is about the institution's behaviour, not the product's: for example, that the named teachers are given time in their timetable to use it. Products fail pilots when the people were never freed up to use them, and that is a finding the buyer needs to see written down.
2. A decision date
A pilot needs an end date and a decision date, and they are not the same. The pilot ends on the day the evidence is in. The decision date is when someone says yes, no or "not this year" at a meeting that is already in a diary.
The sentence I want in the charter is: "On this date the institution will decide whether to proceed, and the next step is X." Put it in the calendar before you sign. If a buyer cannot commit to a decision date, they are telling you something about their own process, and you should believe them.
A "no" on a known date is a good result for a small team. It frees your people and costs you a few weeks, not a year.
3. A budget owner in the room
Before the pilot starts, one meeting must include the person who controls the money for this category of spend, even if only to say they have heard about it. Not the user, not the sponsor: the person whose budget line would carry the purchase.
If you cannot get that meeting before the pilot, it is a warning, not an inconvenience. Ask directly: "If this meets the criteria, who decides and from which budget?" The answers I trust are specific ("the principal, from the technology line, at the budget review in March"). The answers I have learned to worry about are warm and vague ("we will find the money if it works").
For public institutions, ask early whether small-value or innovation routes exist for paid trials. Many do, and a pilot that is paid through the proper route is also a pilot that has already passed procurement once.
4. A scoped integration
Integration is where small teams lose the year. The sentence that does the damage is "we will integrate with whatever you use". The institution's student information system, identity provider, timetabling tool and fee software are each a project. A pilot is not the time to build all of them.
Write down exactly one integration, with a named technical contact on the institution's side, a sample data extract delivered by a stated date, and the specific fields that will flow. Everything else is manual or out of scope, and the charter says so. If a second integration turns out to be essential to the decision, that is a finding, and it is priced as a separate piece of work.
This is also where the security review lands. A pilot involving student data will be asked how data is handled and where it lives, often by someone who was not at the kickoff. Having the answers ready, in the form I describe in the data-residency article, keeps that from becoming a six-week pause.
5. Exit terms
What happens on the decision date, in each direction. If the answer is yes: the commercial terms (or the commitment to agree them within a stated number of days), the rollout scope, and who owns the first-year plan. If the answer is no: data is exported and deleted, accounts are closed, and both sides record why. Writing the "no" path down early is oddly reassuring to a buyer. It tells them you are not trying to trap them.
Free pilot or paid pilot
I now ask for a paid pilot where I can, and the reason is not the revenue. A fee, even a modest one, forces a budget conversation and a purchase order, which means a budget owner is already involved. Free pilots are approved by whoever has the authority to say yes to free things, which is often the person least able to buy.
The trade-off is real. A paid pilot can slow the start, particularly in a small school where any spend needs a board nod. It can also filter out a perfectly good buyer who would have converted. When the fee is a barrier, I would rather reduce the scope than waive the fee entirely: a smaller group, a shorter period, but still a signed charter and a named decision date. Some institutions will only do an unpaid pilot, and that is acceptable if every other clause in the charter holds. An unpaid pilot with no decision date is the one to decline.
Signals during the pilot
You will not control the calendar, but you can watch for early signs.
Usage that stops when your team stops chasing is a bad sign. A pilot that is only active during your visits is a demonstration, not an adoption. Check whether the named users log in on days nobody has reminded them.
A new person appearing in the conversation, particularly from finance or IT, is usually good news. It means the idea has travelled upward.
The champion going quiet is the one to act on early. Ask them, kindly, what is changing. Departures and reorganisations kill more pilots than product problems do, and no charter protects you from them entirely. What a charter gives you is a document a successor can read, and a decision date that survives a change in personnel.
What I got wrong
I have started a pilot before any budget owner had attended a single meeting, on the strength of a good relationship with the sponsor. The pilot went well on every measure we had. It ended in silence, because the person who could buy it had never been asked.
I have also said "we will integrate with whatever you use" in the excitement of an early meeting, and then spent months as an unpaid integration team for a system we were not selling into.
Both mistakes had the same root: I was treating the pilot as a courtesy, not as a negotiation whose terms were being set in the first week.
The short version
A pilot is a decision postponed, so write down who will make the decision, when, and on what evidence. Keep success to three measurable criteria and one commitment from the institution about people's time. Put a decision date in a diary before the first login. Meet the budget owner before the pilot, not after it. Scope one integration and name the contact. Write the exit terms in both directions. Where possible, charge something.
None of this guarantees a sale. A champion can leave and a budget can vanish. But a pilot written this way ends with an answer in weeks, and for a small team that is the difference between a company and a consultancy that works for free.
Illustrations generated with AI.