137. Pricing Test Playbook

Pricing is not a number you discover in a spreadsheet. It is a conversation about value, urgency, trust, alternatives, and risk.

Use this playbook when you have early demand but do not yet know what customers will pay, how they think about value, or what pricing structure fits the model.

Pricing hypothesis

Write:

We believe [customer segment] will pay [price/range] for [outcome] because [current cost or value created].

Include:

• Target customer
• Buyer
• User
• Current alternative
• Value created
• Price range
• Pricing unit
• Expected objection

Example:

We believe 20-100 person B2B SaaS companies will pay Rs 25,000 to Rs 75,000 per month for onboarding analytics because one retained customer can justify the cost.

Price corridor

Do not test only one price. Define a corridor.

Level	Meaning	Use
Too low	Customer accepts instantly but support, margin, or positioning suffers	Shows the floor is unsafe.
Believable	Buyer pauses, asks serious questions, and can justify value	Useful starting range.
Stretch	Buyer needs proof, urgency, or approval but does not dismiss it	Tests upside and value perception.
Too high	Buyer cannot connect price to value or budget reality	Learn whether segment, package, or proof is wrong.

The goal is not to win every conversation. The goal is to understand where value, budget, trust, and urgency meet.

Choose a value metric

A value metric is what pricing scales with.

Examples:

• Seats
• Active users
• Customers managed
• Transactions
• Revenue processed
• Workflows completed
• Locations
• API usage
• Documents processed
• Campaigns sent

Good value metrics grow with customer value. Bad value metrics punish usage or confuse buyers.

Ask:

• Does the customer understand this unit?
• Does it connect to value?
• Does it scale fairly for different customer sizes?
• Can we measure it reliably?
• Does it protect gross margin?

Buyer conversation

Do not ask, “Would you pay Rs X?” too early. First understand value.

Questions:

1. What happens if this problem is not solved?
2. What does it cost today?
3. What tools, people, or workarounds do you already pay for?
4. Who owns the budget?
5. How would you evaluate whether this is worth paying for?
6. If this delivered [specific outcome], what price range would feel reasonable?
7. What would make it too expensive?
8. What would make it suspiciously cheap?
9. What procurement or payment step would slow this down?

Listen for budget language, not just approval language.

Pilot pricing

Early pilots should not be free by default.

Use one of these:

Pilot type	Best when	Pricing approach
Paid diagnostic	Customer has problem but product is early	Fixed fee for analysis or setup
Paid pilot	Value can be delivered in a limited scope	Fixed pilot fee with success criteria
Discounted first term	Customer can become a strong reference	Lower price with clear reason and expiry
Design partner	Customer gives access, feedback, and proof	May be free or reduced, but expectations must be explicit

Free pilots are useful only if the customer gives something valuable: time, data, access, feedback, reference potential, or implementation effort.

Packaging matrix

Pricing often feels hard because the package is unclear. Define what the customer is buying before debating the number.

Package	Best for	Includes	Excludes	Proof needed
Diagnostic	Customer has pain but does not trust solution yet	Audit, workflow review, recommendation, sample output	Full implementation	Clear problem and paid discovery value
Pilot	Customer can test value in a narrow scope	Limited users/data/workflow, success metric, founder support	Unlimited customization	Time-bound outcome and next commercial step
Subscription	Repeat usage is visible	Product access, support level, standard onboarding	Custom services unless priced separately	Activation and retention evidence
Enterprise/custom	Larger buyer has complex needs	Security, integrations, advanced support, procurement documents	Unlimited scope creep	Budget owner, legal/procurement path, implementation owner

If every prospect needs a different package, you may not have a pricing problem yet. You may still have an ICP, product, or delivery-scope problem.

Discount rules

Write discount rules before negotiating.

Possible rules:

• Discount only for annual payment
• Discount only for design partners with case study rights
• Discount only for limited launch cohort
• Discount expires after a date
• Discount does not apply to services or setup
• Discount requires clear success criteria

Avoid random founder discounts. They teach customers that the price is fake.

Quote rules

Before quoting a price, know:

Question	Why it matters
Who owns the budget?	Users can like price without being able to approve it.
What is the current cost?	Price should connect to value or avoided pain.
What proof is needed?	A buyer may need pilot results, reference, security, or ROI.
What is included?	Scope prevents unlimited support expectations.
What is not included?	Services, customization, setup, migration, or training may need separate pricing.
What payment step follows?	Vendor creation, PO, invoice, GST/TDS, legal review, or card payment.

A quote without scope and payment path is only a number.

Payment proof

Track payment behavior:

• Verbal yes
• Budget owner approval
• Signed order or contract
• Invoice sent
• Cash collected
• Renewal or expansion

In B2B, especially in India, verbal yes and cash received can be far apart. Your pricing test is not complete until you understand collection friction.

Commercial proof ladder

Track the strongest commercial signal reached by each prospect.

Level	Signal	Meaning
1	Says price seems reasonable	Useful but weak.
2	Discusses budget owner or approval process	Buyer path is becoming visible.
3	Accepts written pilot scope or proposal	Value and scope are serious enough to review.
4	Requests invoice, PO, vendor setup, or contract	Commercial process has started.
5	Pays	Pricing, trust, and process survived contact with reality.
6	Renews or expands	Price continues to make sense after usage.

Do not celebrate level 1 as pricing validation. A founder needs to know how far the price travels through the real buying process.

Learnings table

Customer	Price shown	Objection	Value metric reaction	Payment step	Decision
					Raise / lower / repackage / change segment

Decision criteria

Increase price if:

• Customers accept too easily
• Support or delivery load is high
• Value created is large
• Customers compare you to expensive alternatives

Reduce or repackage if:

• Right customers agree value exists but cannot justify price
• Buyer budget lives elsewhere
• Pricing unit is confusing
• The plan bundles too much

Change segment if:

• Only low-value customers object
• Higher-value customers understand the pain faster
• Payment authority is different from user enthusiasm

Pricing interview score

After each serious pricing conversation, score the account.

Score	Meaning
5	Buyer sees clear value, price feels reasonable, and payment path is known
4	Value is clear, price is possible, but procurement or proof is needed
3	User likes it, buyer or budget is unclear
2	Price objection hides weak urgency or weak fit
1	Wrong segment, no budget, or no behavior change

Average scores can mislead. Study the 4s and 5s. They show which segment, use case, or packaging deserves focus.

India pricing realities

Indian pricing tests often fail because the founder tests willingness to like, not willingness to pay. Watch for:

• Verbal approval without invoice movement.
• Discount requests before value is understood.
• Buyer saying yes while finance, procurement, or owner approval is missing.
• High support expectations at low price.
• Annual payment hesitation even when monthly price is accepted.
• GST, TDS, vendor registration, or purchase order steps delaying collection.

Track payment friction as part of pricing. A price is not real until the buying process can carry it.

Packaging review

If pricing feels stuck, change the package before assuming the market is bad.

Try:

• Paid diagnostic before subscription.
• Setup fee plus lower monthly fee.
• Tier based on usage, locations, seats, or workflows.
• Pilot fee credited into annual plan.
• Services priced separately from software.
• Higher price for high-support customers.

Pricing experiment cadence

Run pricing tests in small batches. Do not change the price after every conversation.

Batch	What to hold constant	What to test	Review after
Batch 1	Segment and problem	Price corridor	5 serious buyer conversations
Batch 2	Price corridor	Value metric or package boundary	5 serious buyer conversations
Batch 3	Package	Pilot structure and payment path	3-5 commercial next steps
Batch 4	Payment path	Discount rules and annual/monthly terms	First paid customers

In each batch, capture:

• Exact price shown.
• Who reacted: user, buyer, founder, finance, procurement, owner, or champion.
• Whether the objection was about value, budget, trust, timing, authority, or payment process.
• What the next commercial step was.
• Whether money moved.

Price learning should accumulate. If every quote is improvised, the founder cannot tell whether the market rejected the price or simply heard an inconsistent offer.

Discount decision rule

Discounts are not evil, but random discounts teach the wrong lesson. Use a written rule.

Discount reason	Default response
Customer is exact ICP and can become a reference	Consider a time-bound pilot or reference-linked discount
Customer wants annual commitment	Consider annual discount if cash collection is real
Customer needs setup help	Charge setup separately or limit scope
Customer says competitor is cheaper	Ask what value, support, and outcome they are comparing
Customer asks before understanding value	Do not discount yet
Wrong segment wants a lower price	Decline or direct to a lower-touch option

Every discount should have an exchange: reference, case study, annual prepayment, shorter pilot, faster decision, narrower scope, or valuable learning. A discount with no exchange trains the market to negotiate before value is clear.

Price conversation script

Pricing conversations should feel direct, not apologetic.

Use this flow:

1. Confirm the problem and outcome.
2. Confirm who owns the budget or approval.
3. Explain the package in plain language.
4. Say the price without over-explaining.
5. Ask how it compares with the value or current cost.
6. Listen for the real objection.

Example:

“For a pilot focused on [outcome], the price is [price] for [duration/scope]. That includes [what is included] and excludes [what is excluded]. Based on the cost of the problem you described, does that feel obviously wrong, worth discussing, or reasonable if we can prove the outcome?”

Then classify the response.

Response	Meaning	Follow-up
”That is fine”	You may be underpriced or value is clear	Ask about approval and start date
”Too expensive”	Could be price, value, trust, or budget	Ask which one
”We need to check internally”	Decision path is unclear	Ask who needs to approve
”Can you do it free first?”	Trust or urgency may be weak	Offer paid diagnostic or narrower pilot
”Competitor is cheaper”	Comparison frame is unclear	Ask what outcome/support is included

Payment path map

In many early B2B deals, pricing is not the only issue. Payment path matters.

Map it:

Question	Answer
Who approves the commercial decision?
Who creates the vendor?
Is GST invoice required?
Is PO required?
What payment terms are normal?
Who can delay payment after approval?
What document proves commitment?

A buyer saying yes is not the same as money moving. For Indian B2B especially, vendor setup, GST details, procurement habits, and finance approval can turn a simple pilot into a long collection cycle. Treat payment path as part of pricing evidence.

Pricing decision memo

After 10 serious pricing conversations, write a pricing memo.

Section	Prompt
Segment	Which buyer segment did we test?
Package	What was included/excluded?
Price shown	What prices did we actually quote?
Buyer reaction	What objections repeated?
Payment proof	What money, PO, signed pilot, or strong commitment happened?
Discount pattern	What discounts were requested and why?
Margin/support	What would delivery cost us?
Decision	Keep, raise, lower, repackage, or change buyer?

Do not change pricing forever based on one loud buyer. Use the memo to separate signal from negotiation noise.

Pricing evidence scoreboard

Pricing is not validated by a founder feeling brave enough to say a number. It is validated by buyer behavior. Build a scoreboard so pricing decisions are based on evidence, not discomfort.

Track every serious pricing conversation:

Field	Notes
Segment and buyer role	Who heard the price?
Problem cost	What cost, risk, time, revenue, or urgency did they describe?
Package shown	What exactly was included and excluded?
Price shown	What number and billing structure did you state?
Reaction	Accepted, negotiated, delayed, rejected, asked for free, asked for procurement.
Objection type	Budget, value, trust, timing, authority, comparison, payment process.
Commitment	Paid, PO, signed pilot, data shared, internal intro, next call, no action.
Discount requested	What did they ask for, and what did you ask in exchange?
Delivery burden	What support, setup, customization, or success work would be needed?

After 10 conversations, summarize:

Question	Answer
Which segment accepted the price fastest?
Which segment saw the clearest ROI?
Which objection repeated most?
Which price created respect without killing urgency?
Which package created confusion?
Which payment path slowed the deal?
Which customers would be unprofitable at this price?

Use this decision rule:

Evidence	Decision
Buyers accept quickly and support burden is high	Raise price or narrow scope.
Buyers see value but approval is hard	Improve business case and payment path.
Buyers like product but not enough to pay	Revisit urgency or buyer segment.
Buyers pay only after heavy discount	Change package, proof, or segment before scaling.
Buyers reject because outcome is unclear	Fix positioning before changing price.

Pricing tests are really value tests. The goal is not the highest possible number. The goal is a price that matches value, supports delivery, and teaches which customers are serious.

Objection diagnosis

Do not treat every “too expensive” as a price objection. It may be a value, trust, timing, authority, or packaging objection.

Buyer words	Possible real issue	Founder question
”Too expensive”	Value unclear or buyer lacks budget	”Expensive compared with what cost or alternative?"
"Can we try free?”	Trust or urgency is weak	”What proof would make a paid pilot reasonable?"
"Need to check internally”	Buyer path unclear	”Who else needs to approve and what will they evaluate?"
"We already have a tool”	Switching cost or differentiation	”What does the current tool fail to solve?"
"Maybe next quarter”	Timing, priority, or no trigger	”What would need to happen for this to become urgent?"
"Competitor is cheaper”	Package comparison is unclear	”Which outcome and support level are you comparing?"
"Send proposal”	Could be serious or polite exit	”What decision will the proposal help you make?”

The founder’s job is not to win the argument. It is to identify the real blocker. Lowering price only helps when price is truly the blocker.

Pilot commercial terms

For early B2B pricing, a simple pilot can teach more than a complex subscription.

Term	Founder decision
Duration	2 to 8 weeks is often enough to test value
Scope	One workflow, team, location, dataset, or use case
Success metric	Define before launch, not after the customer likes it
Fee	Fixed pilot fee, setup fee, or paid diagnostic
Included support	Name calls, onboarding, support channel, and response expectations
Exclusions	Custom integrations, unlimited reports, one-off services, extra users
Next step	Subscription, annual plan, expansion, or stop decision

Write pilot terms in plain language. A vague pilot becomes unpaid consulting. A clear pilot creates commercial evidence and protects both sides.

Example:

The pilot runs for 30 days with one operations team and up to 200 records. The goal is to reduce manual reconciliation time by 30 percent or identify the blockers. It includes one setup call, weekly review, and founder support on email/WhatsApp. It excludes custom integrations. At the end, we decide whether to convert to a monthly plan, extend with new scope, or stop.

Price-packaging fit

Sometimes the number is fine but the package is wrong.

Symptom	Likely packaging issue	Test
Buyer wants proof before subscription	Trust gap	Paid diagnostic or limited pilot
Buyer wants heavy setup	Services hidden inside SaaS	Setup fee or implementation package
Small customer loves it but cannot pay	Segment mismatch	Lower-touch package or different segment
Large customer needs security/procurement	Enterprise readiness gap	Enterprise package with longer sales path
Usage varies widely	Wrong value metric	Usage, workflow, location, or volume-based pricing
Support load is high	Price too low for delivery	Raise price, narrow scope, or charge service separately

Do not force every customer into one plan too early. But also do not create a custom price for every conversation. The goal is to learn which package repeats.

Founder pricing posture

Pricing tests are emotionally hard because the founder is asking for proof that the work matters. Use a posture that is calm and direct.

Weak posture	Better posture
Apologizing before saying price	State price clearly, then ask how it compares to value
Discounting at first pause	Let the buyer think and ask what feels off
Over-explaining features	Tie the package to outcome and scope
Treating rejection as failure	Classify the objection and improve the test
Hiding payment terms	Discuss invoice, GST, PO, approval, and payment date early

The founder should not sound desperate to close. The founder should sound serious about value, scope, and learning.

Pricing confidence ladder

Do not move from one price conversation to a public pricing page too quickly. Build pricing confidence in layers.

Confidence level	Evidence	Founder action
Guess	Price is based on competitor pages, instinct, or desired positioning.	Use only for internal hypothesis.
Conversation	Buyers react to the price in discovery or sales calls.	Record objections and value language.
Commitment	Buyer accepts pilot, paid diagnostic, deposit, or serious procurement step.	Tighten scope, payment path, and success criteria.
Collection	Cash is collected on the agreed terms.	Review invoice, approval, GST/TDS/payment process where relevant.
Repeatability	Similar customers accept similar packaging.	Standardize pricing for that segment.
Unit economics	Price supports delivery, support, margin, and CAC/payback.	Scale carefully and monitor discounting.

Use this rule:

Do not call a price validated until at least one target buyer has accepted it and the company understands delivery cost.

For Indian B2B, collection proof matters. A signed order, verbal approval, or procurement email is useful, but cash timing can still decide whether the price works for the company. Track price, invoice date, expected payment date, actual payment date, deductions, and follow-up owner.

Price change review

Before changing price, diagnose what failed.

Problem	Change price?	Better first move
Buyer does not understand value.	Not yet.	Improve positioning, demo, proof, and ROI story.
User loves it but buyer absent.	Not yet.	Map buyer and approval path.
Delivery cost is too high.	Maybe raise price.	Narrow scope, charge setup, or reduce manual work.
Segment has low willingness to pay.	Maybe change segment.	Test with a segment that has stronger pain or budget.
Competitor is cheaper.	Not automatically.	Compare outcome, service level, trust, integration, and risk.
Deals close only with discounts.	Maybe package differently.	Reduce scope or create a paid pilot with clear limits.

Most pricing problems are really value, segment, trust, scope, or payment-path problems. Price is the visible number; the hidden system around it matters just as much.

Common mistakes

• Asking friends what they would pay
• Setting price only from competitor pages
• Discounting before understanding the objection
• Testing price with users who do not control budget
• Ignoring gross margin, support cost, and collection timing

Done when

The pricing test is useful when:

• You know which buyer owns the budget
• You have tested at least one real price conversation
• You understand the strongest objection
• You know whether the value metric makes sense
• You can separate price resistance from weak urgency
• You have at least one payment or serious commercial next step

Related chapters

• 58. Pricing and Negotiation
• 94. SaaS Metrics
• 155. Startup Calculators