Designing a corporate pilot with real owners

A pilot with a large company almost never fails because of the technology. It fails because nobody inside the company answers for its outcome. The practical answer is to design the pilot around specific people: a business owner who has the problem and the budget to solve it, an operational contact who commits time, success criteria written and signed before you start, a short duration, and a path to a contract agreed in advance if the criteria are met. Without these elements, a pilot risks becoming an endless experiment that eats your runway.

In short

• A pilot without an identified business owner is a long demo, not a pilot.
• You need at least three roles on the customer side: owner, operational contact, and whoever approves purchasing and security.
• Success criteria are written before you start, with numbers and a way to measure them.
• Short duration and narrow scope: one department for eight weeks beats the whole company for a year.
• The move to a contract is agreed at the start, including the post-pilot price.

Who must be there on the customer side

Before discussing features, ask who will be involved. Look for at least these roles:

• business owner: the person who has the problem, bears its consequences and has the authority or budget to decide on adoption. If the pilot succeeds, they carry it forward internally;
• operational contact: whoever will actually work with your product, give you access to data and systems, and flag problems. They need dedicated time, written into the plan;
• control functions: purchasing, IT, security, legal. They do not join every week, but they must be involved early, because they can block adoption even after a successful pilot.

A frequent warning sign: your only counterpart is an innovation team with no business owner alongside. Innovation can open the door, but someone in the operating line has to want the result.

The two-page pilot document

Put everything in writing in a short document, shared and approved by both sides. It should contain:

1. the problem, in the customer's words and, if possible, with a measured baseline;
2. the scope: which department, which processes, which users, which data;
3. the success criteria: two or three indicators, with baseline, target and who measures;
4. the duration, with start date, interim checks and end date;
5. roles and time each person commits, on both sides;
6. what the customer provides: access, data, environments, people for testing;
7. the commercial terms of the pilot;
8. what happens next: contract terms and price if the criteria are met, and what happens if they are not.

If the customer will not sign off on success criteria, ask yourself whether there really is a problem they want to solve.

Success criteria that hold up

Criteria must be measurable, tied to the owner's problem and achievable within the pilot's duration. Some practical rules:

• measure a baseline before you start, or you will not be able to show improvement;
• prefer indicators the owner already uses in their work over metrics invented for the occasion;
• separate technical criteria (the system works, integrates, handles the load) from value criteria (the process improves);
• agree who collects the data and with which tool.

Avoid vague criteria such as "assess the potential" or "explore use cases": they leave nobody able to say the pilot succeeded.

Duration, scope and price

A long pilot is not safer: it is just more expensive, for you and for the customer's patience. Choose a small but representative scope and a duration long enough to measure the criteria, often in the order of a few weeks.

On price, a paid pilot, even at a reduced rate, has two advantages: it shows the customer's commitment and it triggers purchasing processes from the start, which you would otherwise only discover at the end. If the pilot is free, ask at least for a written commitment on the time dedicated and on moving to a contract if it succeeds.

Running the pilot while it is live

• Hold a short weekly meeting with the operational contact and one every two or three weeks with the owner.
• Keep a shared log of issues, requests and decisions.
• Run a midpoint check against the criteria: if things are not heading the right way, adjust the scope straight away.
• Involve purchasing, IT and security before the end: supplier questionnaires, data processing agreements and security reviews take time.
• Close with an outcome meeting with the owner, numbers in hand, and an explicit decision.

When to say no

For a small startup, every pilot is expensive: weeks of founder time, customisation, attention taken away from other customers. That is why it is worth setting a few minimum conditions in advance, and walking away when they are missing. Typical signs that suggest not starting, or renegotiating the scope:

• you cannot meet the business owner before signing;
• the customer asks for bespoke development that no one else would need;
• there is no measurable baseline and nobody is willing to collect one;
• the move to a contract is described only as "we'll see".

Saying no, or "not yet", while explaining what would be needed to start, often strengthens your position rather than weakening it.

What to do before your next pilot

1. Ask by name who the business owner will be and meet them before signing.
2. Identify the operational contact and the time they can commit.
3. Write the two-page pilot document and get it approved.
4. Measure the baseline of the agreed indicators.
5. Agree the pilot price and the terms of the follow-on contract.
6. Start the purchasing and security checks immediately.
7. If you want a second opinion on your pilot document, get in touch.

You will find a pilot document template in Resources, and in the community other founders selling to large companies in the region.

Subscribe to Dispatch, the PATAVIUM newsletter, for practical tools to build your startup every week.