A large buyer asks for a pilot. Everybody is delighted. Engineering builds an integration, a team is assigned, and the pilot begins with no written criteria and no end date.
Four months later it is still running. The champion has moved roles. Nobody can say whether it succeeded because nobody defined success, and the vendor has spent a quarter of a year proving nothing.
Step 1: qualify before agreeing to anything
Budget, authority, timeline and what happens if it works. A pilot with no funded project behind it is unpaid consultancy, and the question has to be asked before the effort starts.
Step 2: establish why they want a pilot at all
Genuine technical uncertainty, a procurement requirement, a way of deferring a decision, or a method of extracting free work. The four are distinguishable if asked about directly.
Step 3: agree the success criteria in writing
Specific, measurable and few. Three criteria that can be demonstrably met or not met. Anything vaguer produces a pilot that ends in an opinion rather than a decision.
Step 4: agree the end date before the start date
With the review meeting scheduled. A pilot without an end drifts, and drift is the mechanism by which enterprise deals quietly die.
Step 5: agree what happens if it succeeds
The contract, the timescale, the approximate value and who signs. Agreeing it at the outset is worth more than anything said during the pilot itself.
Step 6: scope it narrowly
One use case, one team, one integration. Broad pilots take longer, prove less and involve more people who can say no.
Step 7: name the owners on both sides
Somebody accountable at the buyer and somebody at the vendor. Pilots fail most often because nobody on the buyer's side had time, not because the software failed.
Step 8: decide on charging deliberately
Where setup effort is significant, charge and credit it against the contract. It filters seriousness and it changes how the buyer's organisation treats the work.
Step 9: use the buyer's own data
A pilot on sample data proves very little and everybody knows it. The data conversation is also where the security review begins, and it takes longer than anybody plans for.
Step 10: run the security and legal work in parallel
Not afterwards. Starting procurement at the end of a successful pilot adds months to a deal that everybody already agreed to.
Step 11: check in weekly
Short, scheduled and with the owner. Pilots die quietly and a weekly conversation surfaces the problem while it is still fixable.
Step 12: be willing to decline
A request that is unscoped, unfunded and unowned should be met with a smaller offer rather than a yes. Declining well is a commercial skill.
Step 13: close on the agreed date
Review against the criteria, state the outcome, and move to the contract or stop. Extending a pilot to avoid a decision is how a quarter disappears.
Step 14: qualify the enquiry before it reaches a person
An assistant that establishes the use case, the timescale, the team size, whether there is a funded project and who owns it turns a vague pilot request into something a salesperson can act on in an hour. That screening is what receptionist screening questions describes, the larger buyer version sits in pilot and proof of concept requests from large buyers, the pricing side in enterprise pricing enquiries that need qualifying, and the same structured scoping appears in group programmes and workshop questions answered. See pricing, run the numbers on the chatbot ROI calculator, and the sector view sits under saas.