Pricing Interview Script

Put an Offer in the Room

A pricing interview cannot discover the correct price. It can reveal how a buyer understands value, which budget and approval path apply, and why a specific offer would move forward or fail. The decisive evidence comes later, when someone commits money, signs a pilot, or takes the internal steps required to buy.

Use this script only after the customer recognizes the problem and you can describe a narrow outcome. Bring one proposed package with a real amount. A range such as “$500–$1,500” asks the customer to negotiate against themselves and hides which price you are testing.

Also bring the pricing hypothesis sheet, what you know about the current alternative, the likely buyer and user, the support boundary, and the result the offer promises. If you cannot state those plainly, return to problem or workflow discovery.

Begin with What Happens Today

Open without pretending the conversation is either neutral research or a closing call:

I am testing how this offer should be packaged and priced. I would like to
understand what this problem costs today, how a purchase like this gets judged,
and how you would react to one specific offer. I am not asking you to be polite;
if the offer does not make sense, I want to know where it fails.

Start from a recent purchase or a current workaround. Past decisions are more useful than a buyer’s theory about what they might do.

What are you doing today instead?
Which software, services, or people does that require?
What does it cost in money? What does it consume in time or attention?
When did you last approve or renew something comparable?
Who initiated that purchase, who approved it, and which budget paid for it?
What evidence did the approver need?

Do not force every burden into a dollar estimate. Rework, delay, customer risk, and management attention may be economically important while still being hard for the buyer to quantify. Record what the customer knows, how they know it, and what remains an inference.

Find the Outcome Worth Buying

Move from the current cost to the change the customer would recognize:

If this worked well, what would become faster, safer, cheaper, or more reliable?
Who would notice that improvement first?
How would they know it had happened?
Which part of that result would matter to the person approving payment?
What would make the improvement too small or too uncertain to buy?

Listen for a result that can survive an internal conversation: fewer hours closing the books, fewer failed handoffs, a report ready by Monday, or an approval backed by visible evidence. “Better efficiency” is not yet a value claim.

Ask how the cost and value change as the customer’s operation changes. More seats may create more support without creating more value. A client, location, completed report, protected asset, transaction, or flat operating package may track the benefit more closely. The customer can expose where a metric feels unfair or unpredictable; the founder still owns the pricing decision.

Present One Bounded Package

Describe the offer in one breath. Include the result, scope, time boundary, customer obligation, support limit, success measure, and price.

The first offer is a four-week pilot for [workflow and users]. We use [input]
to deliver [specific output], while [decision or exception] stays with your
team. You provide [customer obligation], and support covers [boundary]. We
judge the pilot by [observable measure]. The pilot costs [amount], [payment
timing and any credit toward continuation].

Then stop explaining.

How would you evaluate that offer?
What is the first part you would question?
At [amount], whose approval would you need?
Which budget would it come from?
What proof would that person require?
What would have to happen between this conversation and a signed agreement?
What would make you decline even if you believed the product could work?

If the buyer says the price is high, resist the reflex to discount. Ask, “High compared with what?” The answer separates several different failures: the problem may be minor, the promised result may be vague, the package may contain the wrong scope, the buyer may lack authority, or the amount may genuinely exceed the available budget.

If the buyer says the price is reasonable, keep going. “Reasonable” can mean affordable, familiar, harmless to say, or worth pursuing. Ask what they would do next, who else must agree, and when that step could happen.

Test Terms Without Designing a Billing Platform

Once the package has survived the first reaction, ask about the conditions around payment:

Would you expect to pay before the pilot, at a milestone, or on delivery?
Would a monthly, annual, usage-based, or fixed package match how this is funded?
What cancellation, refund, security, data, or procurement condition could stop it?
What support or setup would you assume is included?

Treat these answers as constraints to verify, not a request to implement every preference. One early buyer may need a purchase order; that does not prove the market needs enterprise billing. A low headline price may also be a bad offer for a solo founder if it silently commits you to custom onboarding, bespoke reports, complex entitlements, or unlimited support.

Ask for the Next Costly Step

End with a step that requires more intent than praise:

Based on what we have discussed, is this something you would take to [approver]
at [amount]? If yes, what is the next step and when can it happen? If no, which
assumption in the offer should I revisit first?

Depending on the stage, the next step might be an introduction to the budget owner, review of a one-page offer, access to procurement requirements, a scheduled decision meeting, a refundable deposit, or a paid pilot. Never report an encouraging interview as a sale.

After the call, record the current alternative, the economic consequence in the customer’s own terms, the buyer and budget, the proposed package and exact amount, the value metric, required proof, approval path, objections, support assumptions, and promised next action. Mark each item as observed behavior, customer statement, founder inference, or commitment.

Keep the offer when several qualified buyers can explain its value and take a credible next step at the stated price. Change the package when value is clear but scope, metric, proof, or terms obstruct the purchase. Return to discovery when buyers cannot name a consequential outcome. Delay tiers and billing automation until repeated buying behavior shows that the complexity is real.