Skip to main content
Steady at the Top
← All articles

How to agree on a pilot that can lead to a real decision

Agree on the decision a pilot should inform before agreeing on its activity. Identify the buyer’s unresolved question, the work that could answer it, and the person authorized to evaluate the result. A successful trial supplies evidence; purchasing still requires the buyer’s separate decision.

Job feedback is information about performance effectiveness obtained directly from carrying out the work. Hackman and Oldham define this job characteristic in their 1980 chapter, Motivation Through the Design of Work. They distinguish it from judgments supplied by supervisors or other people.

For a pilot, that distinction prompts a useful design question: will doing the target work reveal whether it succeeds? This is an application of the concept, not evidence that their job-design research validates a sales-pilot charter. A sponsor’s enthusiasm and the results of the workflow are different forms of information.

Decide what uncertainty deserves a trial

Some buyers need to establish whether a product can perform a particular workflow under their operating conditions. Others already believe it can work but have unresolved budget, security, procurement, or internal ownership questions. Product usage alone may answer none of those concerns.

Ask why the organization cannot make its decision with the evidence already available. If a security review is the obstacle, another demonstration may consume effort without changing the decision. If a new workflow is the uncertainty, a carefully bounded trial could be informative.

The negotiation and pricing guide places the pilot within a larger exchange of commitments. Agreeing to trial work commits people and resources even when the parties have not agreed to a full purchase.

A pilot should also have a credible stopping point. An evaluation that extends whenever a result disappoints can become an indefinite custom service. That outcome deserves a deliberate commercial decision rather than a gradual drift.

The contract that exists only in a hopeful forecast

In a composite private scene, a founder tells family that an enterprise pilot will become a large contract. Later that evening, the founder rereads the buyer’s email. It promises access to a small test group but names no purchasing decision maker or review date.

The difference matters at home because anticipated revenue has become a reason to postpone other decisions. It matters commercially because the sales team may now treat ordinary pilot activity as evidence of a future purchase.

Replace that assumption with a specific question to the sponsor: “If this trial answers the workflow question, what decision can your organization make next?” The answer may reveal a useful evaluation route, another approval stage, or no present buying process.

Record the answer accurately in the forecast. Deal optimism can distort sales forecasting when a trial and a purchasing commitment receive the same interpretation.

Build a mutual pilot decision charter

The mutual pilot decision charter is a proposed planning method. It documents the question, work, evidence, decision route, and limits of the evaluation. The sources do not establish a conversion rate for this method.

A charter need not be elaborate. Its value comes from the buyer and supplier checking its meaning together. Use the appropriate agreements for confidentiality, data, payment, intellectual property, security, and liability. A sales worksheet cannot settle those terms.

1. Name one decision and its unresolved question

Write the next buyer decision in operational language. “Decide whether this workflow is suitable for a wider deployment” is clearer than “prove value.” Specify whose decision it is and which part the pilot can inform.

Then state what remains unknown. Perhaps users can complete a task in a demonstration, but the buyer needs to know whether they can complete it using approved data and ordinary staffing.

Keep other obstacles visible. A trial can produce useful workflow evidence while funding remains unavailable. Do not rename that funding issue as pilot failure or ask the sponsor to imply authority they do not possess.

2. Define the work and the comparison

Select a task close enough to actual use to answer the question. Identify participants, permitted data, system access, support, and operating conditions. Record any difference between the trial setup and intended deployment.

Choose a comparison the buyer can interpret. It might be an existing workflow, an agreed requirement, or a specific failure condition. Explain why that comparison matters rather than selecting a convenient measure after seeing results.

Hackman and Oldham’s distinction helps here: a participant completing the work and seeing its result differs from a manager saying the tool seems promising. Capture both when relevant, but do not treat the second as a substitute for the first.

3. Agree on evidence and its limitations

Specify what will be recorded, who can inspect it, and how missing or conflicting information will be handled. A completion measure needs an agreed definition of completion. A time measure needs a consistent start and end.

Include implementation effort and exceptions when they affect the buyer’s decision. A smooth demonstration supported by constant supplier intervention may reveal a different operating proposition from ordinary use.

Avoid invented precision. If the sample cannot support a broad prediction, describe the result as evidence about the tested cases. An attractive average cannot establish that untested departments, integrations, or users will perform similarly.

4. Confirm authority, resources, and review attendance

Identify the people who can supply inputs and the person who can make the next decision. Obtain confirmation that the relevant reviewers can attend or receive the evidence. A friendly champion may have influence without budget authority.

Support the champion’s internal work by giving them a fair account of the evaluation, including limitations. Do not coach them to hide the uncertainty from colleagues whose approval is needed.

Set supplier and customer responsibilities. A buyer who cannot provide approved data may need a different timetable. A supplier who cannot provide the promised support should disclose that constraint before the trial begins.

5. Establish the close, extension, and stop rules

Book the review before starting the work. Define the possible conclusions: proceed to an identified approval step, decline, or request a specific further investigation. The buyer retains the right to decide against purchase.

If either side wants an extension, require a new question, resources, and review date. “More time” without a different evidence plan rarely explains what the extension is supposed to accomplish.

Harvard’s discussion of BATNA emphasizes realistic alternatives and comparable terms. Apply that discipline to the supplier’s decision about continued trial work. A genuine alternative may be to end an uneconomic evaluation, subject to existing commitments. It is not a reason to pressure the buyer into approving an unsupported purchase.

A pilot conversation with a usable ending

Imagine a hypothetical buyer evaluating a service platform. Initial discussions propose counting logins during a month-long trial. The operational concern is different: can staff complete an approval workflow without moving sensitive information through an unapproved channel?

The supplier could say:

“Logins will show participation, but they will not answer the approval-workflow question. Could we agree on the approved task, the information users may enter, and the reviewer who can assess the completed work? At the review, we can distinguish readiness to expand from issues requiring another approval.”

The parties then select permitted cases and document assistance. They record whether each task finished, what intervention was needed, and which steps remained outside the tested environment. These are proposed design choices for this example, not research findings.

If the workflow succeeds but the security review is incomplete, the conclusion is conditional. Report the successful task result and the unresolved review separately. Calling the entire pilot successful without that qualification may mislead both organizations.

Keep fairness and investment from deciding the result

Thompson and Loewenstein’s 1992 experiments show how negotiators can interpret fairness in self-serving ways. They do not tell you what either party owes after investing in this particular pilot.

The supplier may feel that extensive support deserves a contract. The buyer may feel that participation deserves additional free customization. Neither expectation should replace the agreed scope or purchasing process.

Discuss additional work as a new decision. Specify its purpose and terms before assigning it. If the parties disagree about existing obligations, involve the authorized commercial and legal contacts rather than asking operational users to settle the dispute.

Risk-reversal design can help define a bounded evaluation offer. Keep the promise within what the supplier can deliver and the contract can support.

Read the evidence before writing the success story

At the review, present the question and comparison first. Then show the observed work, exceptions, missing data, and participant comments. This order lets reviewers assess the result before hearing the supplier’s recommendation.

A participant may like the experience while failing a required task. A task may succeed while the organization lacks capacity to deploy it. Both combinations deserve a clear account. The charter should help the parties distinguish them.

Invite the buyer to state what the evidence permits them to decide. If the answer is “nothing yet,” identify the actual obstacle. Do not erase that answer by recording an enthusiastic meeting as approval.

Check what changed in the commercial record afterward. The forecast stage, next action, and expected decision date should reflect the buyer’s confirmed process. A revised forecast may be less flattering and more useful.

Finish the pilot, including a decision against buying

Close access, handle data, and complete payments or other obligations according to the applicable agreements. Send the buyer the agreed results and a clear statement of unresolved items.

For an extension, record why the original evaluation could not answer the question. A missing customer input, an unsuitable task, and a newly discovered limitation require different remedies. The next charter should address that cause directly.

For a decline, preserve what the evaluation established without turning it into a claim of commercial readiness. A pilot can be informative even when no sale follows. Its proper endpoint is an understood result and an authorized next decision.

Sources

Steady at the Top