60. Demos and Pilots

A demo should not be a feature tour. A pilot should not be a vague free trial.

Both should help the customer make a decision. The demo shows how your product addresses a specific pain. The pilot proves whether that value appears in the customer’s real workflow. If neither creates a next decision, you have created activity, not sales progress.

Early founders often show too much product and ask for too little commitment. The result is praise without progress.

The core demo and pilot question is: can you prove the product solves the buyer’s specific problem without turning the process into unpaid custom work?

What It Covers

This chapter covers:

• Demo design
• Pilot design
• Pilot mistakes

The goal is to move from interest to evidence.

Demo And Pilot Are Different Jobs

A demo helps the buyer understand how the product maps to their pain. A pilot proves whether that value appears in the buyer’s real environment.

Do not use one when you need the other.

Situation	Better tool
Buyer does not understand the product category	Short demo
Buyer understands category but doubts fit	Workflow-specific demo
Buyer believes value but needs proof in their data/process	Pilot
Buyer wants free implementation without a decision path	Disqualify or scope tightly
Buyer asks for many custom features before any commitment	Commercial conversation before build

A demo is not progress if it does not create a clearer next step. A pilot is not progress if there is no buyer, no success criteria, and no conversion path.

Demo Design

A strong demo begins before the screen share.

Recap Pain

Start with what you heard:

“Last time, you said your finance team spends two days reconciling marketplace payouts every month, errors show up during closing, and the founder still gets pulled in. I am going to show only the workflow related to that.”

This does three things:

• Confirms you listened.
• Focuses the demo.
• Lets the customer correct you before you show the wrong thing.

Show Relevant Workflow

Do not show every feature. Show the path that maps to the buyer’s problem.

For example:

• Current messy input.
• How the product handles it.
• What the user sees.
• What exception needs human review.
• What output the buyer cares about.
• How success would be measured.

The customer should remember the outcome, not your navigation menu.

Demo Narrative

Use a simple narrative:

1. “Here is what I heard.”
2. “Here is the workflow we will focus on.”
3. “Here is the before state.”
4. “Here is how the product changes it.”
5. “Here is the business result.”
6. “Here is what we still need to validate.”
7. “Here is the next step I recommend.”

This keeps the demo tied to customer value.

Demo Script Template

Write a lightweight script before important demos. Do not memorize it word for word. Use it to control focus.

Recap:
Last time you said [pain], caused by [workflow/current workaround], affecting [impact].

Frame:
I will show only the part of the product related to [specific workflow]. I will skip everything else unless it becomes relevant.

Before state:
Here is how this usually works today: [manual process, tool, spreadsheet, people involved].

Product workflow:
Here is how the product changes that step.

Value:
The reason this matters is [time saved, errors reduced, visibility, revenue, risk, support load].

Validation:
Is this close to how your team works? Where would it break?

Next step:
If this looks relevant, I suggest [pilot/data review/buyer meeting/proposal] by [date].

The script protects the founder from the temptation to wander. The best demo feels like a guided answer to the buyer’s problem, not a tour through the founder’s effort.

Connect To Value

Every major demo moment should connect to value:

• Saves time.
• Reduces errors.
• Improves visibility.
• Removes manual follow-up.
• Helps compliance.
• Increases revenue.
• Reduces support load.

If you cannot connect a feature to value, skip it.

Confirm Fit

Pause often:

• “Is this how your team works today?”
• “Where would this break in your process?”
• “What would need to be different for this to be useful?”
• “Who else would care about this?”

The best demos create conversation. A silent feature tour is usually a weak demo.

Questions To Ask During Demo

Pause and ask:

• “Is this close to your actual workflow?”
• “Where would this fail for your team?”
• “Which part would matter most?”
• “Which part is irrelevant?”
• “Who else would need to see this?”
• “What would stop this from being used?”
• “If this worked, what would change operationally?”

The answers often matter more than the demo itself.

Ask For Next Step

End with a specific next step:

• Technical review.
• Paid pilot.
• Buyer meeting.
• Data sample.
• Proposal.
• Security review.
• Procurement path.

“I will send details” is not a next step unless there is a date and purpose.

Demo Follow-Up

Send a short follow-up within the same day:

Thanks for the time today.

My understanding:
- Pain: [specific pain]
- Current workflow: [current workflow]
- Value if solved: [impact]
- Open questions: [risks]
- Agreed next step: [owner, date, purpose]

I will [your action]. You will [customer action].

This protects the deal from ambiguity. If the prospect does not accept the summary, you learn that alignment was weaker than it felt.

Pilot Design

A pilot is a controlled test with a business decision at the end.

It needs:

• Objective.
• Timeline.
• Stakeholders.
• Data or setup needed.
• Success criteria.
• Support plan.
• Price or commercial terms.
• Conversion path.

Example:

“Over 21 days, we will help your finance team reconcile marketplace payouts for Amazon and Flipkart. Success means reducing manual reconciliation time by 50 percent and producing a month-end report your finance lead approves. If successful, we convert to an annual plan at the agreed price.”

Pilot Agreement

Write the pilot terms before starting.

Section	What to specify
Problem	The customer pain being tested
Scope	What workflows, users, data, integrations, or geographies are included
Out of scope	What is explicitly not included
Timeline	Start date, milestones, review date
Customer owner	Who provides access, feedback, and internal coordination
Founder/company owner	Who supports the pilot
Success criteria	Metrics or outcomes
Price	Pilot fee, free conditions, or credit toward annual plan
Conversion path	What happens if success criteria are met
Risks	Known dependencies or blockers

This does not need to be a heavy legal document. A clear email or one-page agreement is often enough for early pilots. For enterprise, involve legal when required.

Pilot Risk Register

Before the pilot starts, write the risks. Pilots rarely fail only because the product fails. They fail because ownership, data, buyer involvement, scope, or urgency was weak.

Risk	Warning sign	Mitigation
No buyer involvement	User wants pilot but buyer has not agreed to success criteria.	Bring buyer into pilot kickoff or review before starting.
No customer owner	Everyone is interested; nobody owns setup.	Name one owner and backup owner.
Data delay	Customer has not shared the sample or export.	Provide template and deadline; start only after minimum data arrives.
Scope creep	New requirements appear every week.	Keep out-of-scope list and price new work.
Custom build pressure	Customer asks for features before proof.	Separate pilot validation from paid implementation.
No conversion path	”We will see after the pilot.”	Define review date, success criteria, and commercial next step.
Weak urgency	Meetings move and no one cares.	Reconfirm business problem or disqualify.

Review the risk register during the pilot. If the risk becomes real, address it openly. Silent pilot risk becomes post-pilot confusion.

Objective

The objective should be tied to customer value, not product usage.

Weak:

“Test the product.”

Strong:

“Reduce manual reconciliation effort for two marketplaces during month-end close.”

Timeline

Short pilots are better. A 14-30 day pilot often creates more urgency than a vague three-month trial. Enterprise pilots may need longer, but even then milestones should be clear.

Success Criteria

Define success before the pilot starts. Criteria can include:

• Time saved.
• Error reduction.
• User activation.
• Report generated.
• Workflow completed.
• Stakeholder approval.
• Revenue recovered.
• Support tickets reduced.

Buyer Involvement

The buyer must be involved before the pilot, not only after. If the daily user loves the pilot but the buyer never agreed to success criteria, conversion will be weak.

Paid vs Free Pilots

Paid pilots are stronger signals because they show willingness to commit. Free pilots can work when setup is light or trust is low, but they must still require something meaningful: time, data, internal owner, review date, and decision process.

If the customer will not commit anything, they are not running a pilot. They are accepting free work.

Free Pilot Guardrails

Free pilots are sometimes useful, especially when the buyer needs trust or the product is early. But free should not mean unbounded.

Use guardrails:

• Short timeline.
• Named customer owner.
• Clear data/access requirement.
• Written success criteria.
• Scheduled review meeting.
• Defined conversion discussion.
• No custom development unless paid or strategically important.

If the customer will not agree to these, they are unlikely to buy after the pilot.

Paid Pilot Signals

A paid pilot is useful when:

• Setup requires founder or team effort.
• The customer needs meaningful support.
• The buyer has budget but wants proof.
• The product is replacing an existing spend.
• The pilot creates real operational value.

Even a small pilot fee changes behavior. It makes the customer assign ownership, show up, and evaluate seriously.

India Angle

In India, pilots can become endless unless scope is written clearly. Buyers may ask for customization before payment, especially in B2B and enterprise. Be helpful, but protect boundaries.

Use written pilot terms:

• Scope.
• Timeline.
• Owner.
• Deliverables.
• Support expectations.
• Price.
• GST and invoicing details where relevant.
• Conversion discussion date.

For SMBs, a practical live walkthrough may beat a polished demo deck. For enterprise, stakeholder mapping, procurement, security, and internal champion strength matter.

Indian pilot details to clarify:

• Who signs the pilot approval?
• Is GST invoicing required before access?
• Will payment happen before or after setup?
• Is there a purchase order process?
• Who will coordinate data sharing?
• Is WhatsApp acceptable for coordination, and what still needs email documentation?
• Will a successful pilot automatically move to paid, or is another approval needed?

In Indian SMB sales, the founder may be the buyer, user, and approver. In larger companies, the user may love the pilot while finance and procurement slow everything down. Map this before work begins.

Pilot Mistakes

• Free forever.
• No success criteria.
• No buyer involved.
• No timeline.
• Too much customization.
• No conversion ask.
• No written scope.
• No internal owner.
• No post-pilot review date.
• Treating usage as success when business value is absent.
• Letting the pilot expand every week without updating price or scope.
• Building custom features before commercial commitment.
• Not involving the economic buyer until the final review.
• Mistaking support responsiveness for product validation.

Demo And Pilot Checklist

Before a demo:

• What pain are we recapping?
• Which workflow will we show?
• Which features will we intentionally skip?
• What value will we connect to?
• What next step will we ask for?

Before a pilot:

• Who owns it on the customer side?
• What outcome matters?
• What data or access is needed?
• What is the timeline?
• What is the price or commercial agreement?
• What happens if it succeeds?
• What happens if it fails?

Demo Depth Ladder

Not every prospect deserves the same depth of demo. Match demo depth to qualification.

Qualification level	Demo depth	Founder behavior
Unqualified curiosity	5-10 minute category walkthrough.	Do not over-invest. Ask discovery questions first.
Pain confirmed	Workflow-specific demo.	Show only the path tied to pain.
Buyer involved	Value and implementation demo.	Discuss ROI, onboarding, security, and decision path.
Pilot candidate	Success criteria demo.	Show what the pilot will prove and what it will not prove.
Commercial buyer	Close-plan demo.	Confirm price, terms, rollout, and approval steps.

The biggest founder mistake is giving enterprise-depth demos to unqualified prospects. It feels productive, but it burns time and trains the founder to perform instead of qualify.

Demo Kill Switches

Stop or redirect the demo when:

• The prospect cannot name the pain.
• The wrong person joined and no buyer path exists.
• The prospect wants a general tour instead of a specific workflow.
• Every question is about custom features outside the roadmap.
• The prospect refuses to discuss next step, budget, or success criteria.

Redirect politely:

I can show the product, but I think we may be moving too fast. It would be more useful to first understand whether this problem is important enough for your team to act on.

This protects both sides. A demo without context creates compliments, not decisions.

Pilot Review Meeting

The review meeting should happen on the calendar before the pilot starts.

Use this agenda:

1. Recap objective and success criteria.
2. Review data or workflow results.
3. Ask the customer what worked.
4. Ask what did not work.
5. Decide: convert, extend with new terms, pause, or stop.
6. Confirm commercial next step.

Do not let the pilot fade into “we are still evaluating.” Evaluation without a review date is not a process.

If the pilot failed, learn clearly:

• Was the pain not strong?
• Was the product not good enough?
• Was implementation too heavy?
• Was the wrong stakeholder involved?
• Were success criteria unrealistic?
• Was the buyer never serious?

Failure with learning is acceptable. Endless limbo is expensive.

No-Decision Prevention

The most common pilot outcome is not yes or no. It is no decision. The customer says the pilot was useful, but nothing happens.

Prevent no-decision by defining these before the pilot:

Question	Why it matters
Who decides after the pilot?	Avoids user-only enthusiasm.
What result counts as success?	Prevents moving goalposts.
What happens if success is met?	Makes conversion path explicit.
What happens if results are mixed?	Defines whether to extend, change scope, or stop.
What budget or approval is needed?	Avoids surprise procurement after the pilot.
What date will the decision happen?	Creates urgency.

At the review, ask directly:

Based on the success criteria we agreed, do you see this moving to the paid rollout, needing a scoped extension, or stopping here?

Do not punish honesty. A clear no is useful. A vague maybe is expensive.

Pilot Conversion Path

Design conversion before the pilot starts.

Pilot result	Commercial action
Success criteria met	Convert to agreed paid plan or annual contract.
Partial success with clear fix	Extend only with updated scope, owner, and timeline.
Product gap is material	Pause or convert to paid implementation if strategically justified.
Customer did not provide access or ownership	Stop or restart only with stronger commitment.
Buyer never engaged	Do not extend until buyer joins review.
Value unclear	Return to discovery; do not keep supporting a weak pilot.

The most important phrase is “agreed.” If the post-pilot price, plan, and approval path are not discussed before the pilot, the customer can treat the pilot as research.

Pilot Close Plan

Before a pilot begins, write the close plan in plain language. Share the relevant parts with the customer.

Include:

Close-plan item	Question to answer
Business problem	What pain is the pilot proving against?
Success metric	What must improve or become visible?
Owner	Who owns the pilot on the customer side?
Users	Who will actually use or test the product?
Data/access	What must the customer provide?
Support boundary	What support will the startup provide?
Review date	When will results be reviewed?
Buyer path	Who approves conversion?
Commercial path	What plan, price, and term follows success?
Failure path	What happens if the pilot does not work?

The close plan is not aggressive. It is professional. Serious buyers appreciate clarity because it helps them manage their own organization.

When To Charge For A Pilot

Charge for a pilot when:

• Implementation takes meaningful team time.
• Customer data cleanup or integration is required.
• The customer expects support, training, or reporting.
• The pilot replaces paid work they already do.
• The customer is large enough that free work signals weakness.
• The product value can be measured in business terms.

Consider a free or very low-cost pilot only when:

• Setup is light.
• Learning value is very high.
• Reference value is explicit.
• The customer segment is strategically important.
• Scope and timeline are tightly bounded.

Free is not the problem. Unbounded is the problem.

Pilot Mutual Action Plan

A pilot without a mutual action plan is easy for the customer to start and hard for the startup to close. Everyone is friendly, the users are curious, the founder is helpful, and three weeks later nobody knows who is supposed to decide.

Create a mutual action plan before kickoff. It should be shared with the customer in writing. Keep it simple enough that the buyer can forward it internally.

Section	What to write
Business reason	Why the customer is running this pilot now, not someday.
Current pain	The workflow, cost, delay, risk, revenue leak, or quality issue being tested.
Customer owner	The person responsible for making the pilot happen internally.
Buyer or approver	The person who can approve paid rollout if the pilot works.
Users	The people who will use the product or participate in the test.
Startup owner	The founder/team member accountable from your side.
Scope included	What workflows, teams, data, reports, integrations, and support are included.
Scope excluded	What is explicitly not included in this pilot.
Customer responsibilities	Data, access, user time, review meetings, security answers, internal coordination.
Startup responsibilities	Setup, training, support, reporting, product configuration, review materials.
Success criteria	The evidence that means the pilot worked.
Decision meeting	Date, attendees, and decision options.
Commercial next step	Paid plan, contract size/range, payment terms, rollout scope, or extension terms.

Copy-paste pilot action plan

Use this as a starting template:

Pilot name:
Customer:
Startup owner:
Customer owner:
Buyer/approver:

Why we are running this pilot:
[Specific business reason]

Current workflow/problem:
[What happens today and why it matters]

Pilot scope:
Included:
- [Workflow/team/data/use case]

Excluded:
- [Out-of-scope requests]

Customer responsibilities:
- [Data/access/users/review meetings]

Startup responsibilities:
- [Setup/training/support/reporting]

Success criteria:
1. [Metric or observable result]
2. [User/workflow adoption]
3. [Business outcome or risk reduction]

Timeline:
Kickoff:
Setup complete:
First value checkpoint:
Final review:
Commercial decision:

If successful, the next step is:
[Paid rollout, annual plan, limited production deployment, procurement, security review, or paid extension]

Known risks:
- [Risk]
- [Risk]

Decision options at review:
- Convert to paid rollout
- Extend with paid scope
- Pause because [blocker]
- Stop because success criteria were not met

Buyer confirmation script

Before kickoff, ask:

If we hit these success criteria by the review date, is this enough for you to make a paid rollout decision, or is there another stakeholder, approval, security step, or budget process we need to include now?

This question is not pushy. It is respectful of everyone’s time. If the answer reveals hidden procurement, missing budget, IT review, or a different decision-maker, the pilot has already saved itself from drifting.

India-specific pilot discipline

In India, many pilots get stuck because the champion is enthusiastic but the economic buyer, IT/security reviewer, finance team, or founder/MD is not involved early enough. The startup keeps supporting the pilot while the buyer says, “Let us discuss internally.”

Prevent this by adding one rule:

The final review must include the person who can approve the next commercial step.

If that person will not join, downgrade the pilot in your mind. It may still be useful for learning, but it is not yet a serious sales process.

Implementation Load Check

Before agreeing to a pilot, estimate the load.

Work	Estimate
Data cleanup	Hours or days required before value appears.
Integration	API, spreadsheet, manual upload, or none.
Training	Number of users and sessions.
Support	Expected founder/team time per week.
Reporting	What output must be prepared for review.
Custom requests	Must-have or nice-to-have.

If the pilot consumes heavy founder time, charge for it or narrow it. A startup can die from “promising pilots” that absorb the whole team.

Reference Customer Trade

For early customers, a pilot may be worth more if it creates a strong reference. But reference value should be explicit.

Possible trades:

• Discount in exchange for a written testimonial after success.
• Lower pilot price for permission to use anonymized metrics.
• Faster onboarding in exchange for reference calls.
• Extra founder support in exchange for a case study.

Do not assume reference rights. Ask professionally. Some customers cannot provide public references, especially in enterprise, finance, health, education, or competitive sectors. In that case, price the deal on value, not imagined marketing benefit.

Reader Action

Rewrite your next demo around one customer workflow. For every pilot, create a one-page pilot agreement with objective, scope, owner, timeline, success criteria, price, support plan, and conversion step.

If the customer resists defining success, treat that as a sales signal.

Also create a “features I will not show” list before the demo. This forces focus. The more early founders care about their product, the more likely they are to over-demo it.

Demo-To-Decision Map

A demo should move the buyer toward a decision, not simply impress them.

Before the demo, write:

Decision element	Founder note
Pain recap	What problem are we proving we understand?
Buyer outcome	What business result matters?
Workflow shown	Which workflow will we show and which will we skip?
Proof	What evidence reduces risk?
Objection to test	Which concern do we need to surface?
Decision step	What should happen after the demo?

After the demo, ask:

1. “Which part felt most relevant?”
2. “Which part would not work in your current process?”
3. “What would need to be true for this to move forward?”
4. “Who else needs to see this before a pilot or purchase?”
5. “Should we define a pilot, commercial proposal, or stop here?”

If the demo does not create a decision step, it was probably entertainment.

Pilot Exit Criteria

Define exit criteria before the pilot begins:

Exit	Criteria
Convert	Success criteria met, buyer engaged, value visible, commercial path agreed.
Extend	Specific gap remains, customer has provided access, new date and owner are clear.
Redesign	Product can solve the problem but pilot scope was wrong.
Stop	Customer did not engage, value is weak, buyer absent, or segment is wrong.

The worst pilot outcome is not a no. The worst outcome is endless ambiguity that consumes the team.

Demo Script Skeleton

A strong demo has a spine.

Use this flow:

1. Recap the customer’s situation in their words.
2. Confirm the outcome they care about.
3. Show the shortest workflow that proves that outcome.
4. Pause and ask what would break in their environment.
5. Show proof, not every feature.
6. Confirm stakeholders and decision path.
7. Ask for the next decision step.

Useful phrases:

I am going to skip anything that is not connected to the workflow you described.

If this worked, what would need to happen internally before you could try it?

What part of this would be hardest for your team to adopt?

These questions keep the demo commercial. The founder is not performing the product; the founder is testing fit.

Pilot Governance

Every serious pilot needs governance, even if it is small.

Governance item	Decision
Sponsor	Who wants the pilot to succeed?
Working owner	Who will give data, access, and feedback?
Review cadence	Weekly, twice weekly, or milestone-based?
Success metric	What number, workflow, or outcome proves value?
Risk owner	Who handles security, finance, legal, integration, or adoption concerns?
Conversion date	When will the pilot be reviewed for purchase?

Without governance, pilots become founder labor with no decision owner.

Pilot Health Dashboard

Track pilot health weekly:

Signal	Green	Yellow	Red
Customer engagement	Owner responds and attends reviews.	Slow responses.	No owner engagement.
Data/access	Required inputs received.	Partial inputs.	Blocked inputs.
Value progress	Outcome visible.	Some activity, unclear value.	No meaningful value.
Stakeholder path	Buyer involved or scheduled.	Buyer not yet involved.	Buyer unknown.
Scope control	Scope stable.	Some expansion.	Custom chaos.
Commercial path	Review date and next step clear.	Commercial discussion delayed.	No commercial path.

If a pilot turns red, do not quietly keep working. Call a review, narrow scope, or stop.

Demo And Pilot Anti-Patterns

Avoid:

• Showing every feature because the founder is proud.
• Letting a user define a pilot without the buyer.
• Accepting “we will know success when we see it.”
• Starting without data or access.
• Treating support requests as product strategy.
• Allowing free pilots to run indefinitely.
• Saying yes to custom work because the logo is attractive.
• Forgetting to ask what happens after success.

The point of a pilot is not to be liked. It is to create evidence that a customer should buy and the startup can deliver.

Pilot Review Script

Write the review script before the pilot starts. If the pilot works, the commercial next step should not be a surprise.

Review element	Question
Buyer	Who can approve conversion after the pilot?
Success proof	What metric, workflow, report, quote, or usage will show value?
Review date	When will the decision meeting happen?
Commercial terms	What price, package, or contract was discussed before kickoff?
Stakeholders	Who must see results before purchase?
Objections	Which objection must the pilot answer?
Conversion ask	What exactly will you ask for if criteria are met?
Stop rule	What result means the pilot should end instead of drift?

At the pilot review, do not ask, “So what did you think?” Ask against the agreed criteria.

At the start, we agreed success meant [criteria]. Here is what happened. Based on that, I recommend [convert / extend with one gap / stop]. Does that match how you see it?

This creates a business conversation instead of a feedback session.

Decision-Ready Demo Pack

For serious prospects, the demo should leave behind a decision pack, not just a pleasant memory. Buyers forget details. Internal champions need ammunition. Procurement and finance need clarity.

Prepare a short follow-up pack:

Pack item	Purpose
Pain recap	Shows you understood the customer’s situation.
Current workflow map	Makes the problem visible to stakeholders who missed discovery.
Proposed workflow	Shows what changes if they use the product.
Value hypothesis	Links the product to time saved, revenue protected, risk reduced, or quality improved.
Implementation needs	Data, access, team time, setup, integrations, owner.
Success criteria	Defines what a pilot or rollout must prove.
Commercial path	Price range, pilot fee, next meeting, contract path, payment terms.
Risks and open questions	Shows honesty and prevents surprise blockers.

This does not need to be a polished deck. A clear one-page email can work. The point is to help the buyer make an internal decision.

Demo Follow-Up Email

Use a structure like this:

Thanks for the time today. Here is what I heard:

Problem: [specific pain]
Current workflow: [how it works today]
Impact: [cost/risk/delay/revenue issue]
What we showed: [relevant workflow, not full feature list]
Open questions: [data/security/buyer/stakeholder/pricing]
Recommended next step: [pilot/proposal/stakeholder call] by [date]
Success would mean: [criteria]

If the prospect does not correct your recap, you have created a shared record. If they do correct it, that is useful too. Better to discover misalignment immediately than after weeks of pilot work.

Pilot Conversion Design

A pilot should be designed backward from conversion. Before kickoff, know what must happen for the customer to buy.

Conversion question	Good answer
Who approves conversion?	Named buyer or owner.
What result proves value?	Metric, workflow improvement, user adoption, time saved, money saved, revenue protected.
Who must believe the result?	Buyer, user, manager, IT, finance, founder.
What commercial terms are expected?	Package, price, duration, payment terms, scope.
What implementation burden is acceptable?	Customer knows the time/data/access needed.
What risk could block purchase despite success?	Security, integration, budget, procurement, legal, internal politics.
What is the decision meeting date?	Scheduled before or at kickoff.

If these answers are missing, do not call it a pilot. Call it a trial, research project, or product feedback exercise. Those can be useful, but they are not the same as a commercial pilot.

The Pilot Drift Warning

Pilot drift usually starts politely:

• “Can we also try this other use case?”
• “Can you add one custom report?”
• “Let’s extend it another month.”
• “We will discuss internally.”
• “The main buyer could not join the review.”

Respond with scope discipline:

Happy to discuss that. To keep this pilot useful, let's first close the original success criteria. If this new use case matters, we can either add it as paid scope or make it the next phase after conversion.

The founder must protect the pilot from becoming unpaid consulting.

Demo Types By Stage

Not every prospect deserves the same demo. Match the demo to the maturity of the conversation.

Situation	Demo type	Goal
Early discovery	Concept walkthrough	Learn whether the workflow and pain are real.
Problem confirmed	Workflow demo	Show the exact before/after state.
Buyer involved	Business-case demo	Connect product to outcome, cost, risk, and decision criteria.
Technical reviewer involved	Technical proof demo	Address access, data, integration, security, reliability, and implementation.
Multiple stakeholders	Decision demo	Align everyone on problem, scope, success, pricing, and next step.
Renewal/expansion	Impact demo	Show usage, outcomes, missed value, and expansion path.

The wrong demo creates the wrong conversation. A technical demo too early overwhelms. A vision demo too late frustrates buyers who need implementation answers.

Pilot Pricing And Scope

Free pilots are sometimes useful, but they are dangerous when they attract low-intent prospects. A paid pilot, even a small one, teaches more about urgency and buyer behavior.

Pilot pricing options:

Model	When useful	Watch out
Free proof of concept	Very strategic customer, high trust gap, founder needs access to learn.	Must still have owner, success criteria, and deadline.
Paid pilot fee	B2B workflow with real business value.	Fee should be enough to prove seriousness, not so high it becomes procurement-heavy.
Refundable deposit	Buyer wants risk protection but has urgency.	Define refund condition clearly.
Services-led pilot	Product is early but manual delivery creates value.	Track manual effort and path to productization.
Limited production rollout	Customer has clear need and can start with one team or workflow.	Keep scope narrow.

Write pilot scope in plain language:

Pilot duration:
Customer team:
Workflow included:
Workflow excluded:
Data/access needed:
Startup responsibilities:
Customer responsibilities:
Success criteria:
Review date:
Commercial decision after pilot:
Pilot price:
Post-pilot price range:

If the customer refuses to discuss what happens after the pilot, the pilot may be research, not sales.

Pilot Conversion Review

Schedule the review meeting before the pilot starts. Otherwise the pilot ends with silence.

Review agenda:

1. Original problem and success criteria.
2. What was implemented.
3. Usage and adoption evidence.
4. Outcome evidence: time, money, quality, risk, revenue, or speed.
5. User feedback.
6. Open issues and whether they are blockers.
7. Commercial proposal.
8. Decision: convert, extend with paid scope, expand, pause, or stop.

Bring evidence, not vibes:

Evidence	Example
Usage	Number of active users, workflows completed, records processed.
Outcome	Hours saved, errors reduced, leads handled, collections improved, response time reduced.
Qualitative	User quote tied to a specific workflow.
Business	Buyer agrees the result matters.
Implementation	Clear list of what remains before rollout.

The founder should leave the review with a decision or a specific missing item. “We will get back to you” is not a review outcome.

India Pilot Traps

Common traps:

• The buyer asks for a “POC” but there is no buyer, budget, or decision date.
• The startup does unpaid implementation work for weeks because saying no feels rude.
• The customer asks for custom reports that are really consulting deliverables.
• A friendly founder agrees verbally but accounts/procurement delays payment.
• The user loves the product but the owner does not see business value.
• The pilot requires sensitive data before trust, paperwork, or security expectations are clear.

Practical safeguards:

• Use a written pilot note even if there is no heavy contract.
• Ask for GST and invoicing requirements early.
• Name the customer owner and startup owner.
• Agree on a review date before implementation begins.
• Keep one clear success metric.
• Do not add new use cases unless scope and price change.

Founder-led selling in India often rewards relationship, but relationship is not a substitute for scope control.

Demo Personalization Map

A demo should feel like the customer’s workflow, not your product tour. Before the demo, map what each stakeholder needs to see.

Stakeholder	What they care about	Demo focus
User	Ease, speed, fewer errors, less manual work.	Daily workflow and before/after experience.
Buyer	Business outcome, ROI, risk, adoption.	Cost of pain, result, implementation plan.
Founder or CXO	Strategic priority, trust, speed, accountability.	Why now, impact, proof, and next decision.
Finance	Cost, payment terms, measurable value.	Budget category, savings, leakage, or revenue impact.
IT or security	Data, access, reliability, integration.	Controls, permissions, deployment, support.
Operations	Rollout effort, ownership, escalation.	Implementation steps, responsibilities, support model.

Open the demo with a recap:

Last time, you said the biggest issue was:
Today I will show only the workflow related to that.
At the end, we should decide whether this is worth a pilot, who needs to be involved, and what proof you need.

This tells the buyer the demo is a decision meeting, not entertainment.

Pilot Kill Criteria

Every pilot should have success criteria and kill criteria. Kill criteria protect the startup from endless free work.

Define before the pilot starts:

Question	Example
What would make the pilot successful?	Reduce reconciliation time by 50 percent for one workflow.
What would make the pilot fail?	Customer does not provide data, users do not use it, or buyer will not attend review.
What is outside scope?	Custom dashboards, unrelated workflows, integrations not needed for proof.
Who owns customer actions?	Named customer owner with response expectations.
Who owns startup actions?	Named founder or implementation lead.
When is the review?	Calendar date before work begins.
What happens after success?	Paid rollout, annual plan, expanded pilot, or decision meeting.

If a prospect refuses to define success or attend the review, they may not be evaluating seriously. The founder can still help, but should not treat the pilot as pipeline.

Pilot Commercial Gate

Before starting a pilot, pass a commercial gate. This protects the startup from pilots that create product feedback but no buying path.

Gate	Required answer
Buyer	Who can approve payment after the pilot?
Pain	What business pain is the pilot proving?
Success	What measurable or observable result matters?
Scope	What is included and explicitly excluded?
Customer effort	What data, access, time, or people must the customer provide?
Price path	What is the pilot price and expected post-pilot price range?
Review	When is the decision review, and who must attend?
Failure	What happens if customer actions are not completed?

Write the gate decision:

We will start this pilot because:
The commercial buyer is:
The conversion path is:
We will stop or re-scope if:

If the gate fails, the pilot may still be useful as research. Label it that way. Do not forecast it as sales pipeline.

Related Links

• 59. Discovery Calls
• 61. Pricing and Negotiation
• 137. Pricing Test Playbook
• 138. Founder Sales Call Playbook