Buyer Interview Script

A Buyer Interview Is a Decision Trace

A user can describe painful work without knowing whether the organization will pay to change it. The buyer lives inside a different problem. They must decide whether the consequence is large enough, the timing urgent enough, the proof credible enough, and the adoption burden tolerable enough to spend money and accept risk.

Use this script after user interviews have produced a specific workflow and consequence. The buyer may be an owner, department lead, practice manager, agency principal, operations head, or technical lead. What matters is not the title but the authority the person has exercised.

The interview should reveal a decision mechanism. “It sounds useful” is not one.

Bring the User’s Evidence Into the Room

Prepare a short account of the observed problem: who encounters it, one recent episode, the current workaround, and the visible consequence. Keep your proposed product out of that account. Also write down the commercial assumption this conversation could change—perhaps the budget source, acceptable pilot boundary, required proof, or first veto.

If the problem touches sensitive data, client communication, compliance, money movement, or operationally critical work, state the narrow boundary you are considering. A buyer cannot discuss risk honestly while the product boundary remains unlimited.

Open without asking the person to perform a sales meeting:

I have been learning how [team] handles [specific workflow]. One recent example
involved [brief consequence and workaround]. I would like to understand how a
change in this area would actually be evaluated: who owns the consequence,
what proof would count, and what could stop a decision. I am not asking you to
approve a purchase on this call.

Ask where the workflow enters this person’s responsibilities. If they advise but do not approve, learn whose decision they influence and request a better conversation. Do not silently promote a knowledgeable participant into “the buyer.”

Start With a Decision They Actually Made

Hypothetical buying processes are often tidy. Real ones contain exceptions, delayed budgets, informal vetoes, and work that belongs to nobody. Ask for a recent neighboring decision:

What is the last tool, service, or process change you approved—or decided not
to approve—for this team?

What first made it worth your attention?
Who brought it to you, and who else became involved?
What did you need to believe before you could say yes?
Where did the money come from?
What nearly stopped it?
Who owned rollout after the decision?

Stay with that decision until you understand the path it took. A small owner-operated company may decide in one conversation but still face a hard cash constraint. A department with delegated budget may still need security, legal, IT, or an executive sponsor. “I can approve it” and “I can get it adopted” are different claims.

Then return to the workflow you are studying:

Which parts of that path would apply here?
What would be different because this workflow involves [data, customers,
money, schedules, or another relevant boundary]?
Who could reject the change even if you wanted it?

Find the Consequence the Buyer Owns

Let the buyer translate user friction into their own ledger. Ask where a bad episode appears: delayed revenue, overtime, rework, customer loss, quality risk, management attention, missed capacity, or something else. Follow the answer into behavior.

When did this consequence last become serious enough for you to act?
What did you do then?
What does the organization spend today to contain it—in tools, services,
staff time, or accepted loss?
What is competing with this problem for attention or budget now?

Do not add every inconvenience into a grand total and call it willingness to pay. Some costs are diffuse, politically untouchable, or cheaper to tolerate than to change. Ask which cost the buyer can actually reduce, avoid, or move and who would notice the result.

A Buyer Reveals the Real Product Boundary

This fictional conversation continues the home-care scheduling example from the customer interview. Maya is speaking with Elena, the agency owner, after learning how a coordinator recovered from a same-day cancellation.

Maya: Jordan described Tuesday's cancellation and the calls and schedule
changes that followed. Where does an event like that reach you?

Elena: If a visit will be late, I want to know. Repeated misses affect the
client relationship, and overtime comes to me at the end of the week.

Maya: What is the last scheduling change you approved?

Elena: We added a texting service last year. Jordan asked for it. I approved
the subscription, but our privacy adviser first checked what information the
messages would contain.

Maya: What did you need to see before approving it?

Elena: That it reduced calls without putting client details in ordinary text
messages. We tried it at one branch before using it elsewhere.

Maya: Suppose a new tool only suggested available caregivers and Jordan still
made the assignment. What would you need to believe before a one-branch test?

Elena: I would need to know where its availability data came from and see why
each person was suggested. No automatic messages to clients or caregivers.
Jordan would have to own the test, and I would stop it if it added another
schedule we had to keep current.

Maya: If it met those boundaries, where would payment come from?

Elena: Operations software. But I would compare it with the overtime and
coordinator time at that branch, not with the cost of every missed visit.

Elena has not promised to buy. She has supplied something more useful: a budget owner, a comparison the price must survive, precedent for a branch-level test, a privacy review, an adoption owner, required explainability, and two vetoes—automatic communication and duplicate data maintenance. Those constraints define a narrower first product than user enthusiasm alone would produce.

Test Proof, Package, and Price in That Order

Once the decision path and risk boundary are visible, ask what evidence could justify the next commitment. Make the commitment concrete: a paid discovery engagement, a one-workflow pilot, a service-backed trial, or a subscription. Ask who would select participants, configure the tool, review its output, handle failure, and decide whether the test succeeded.

Offer a deliberately bounded shape, then invite correction:

A possible first test would cover [workflow slice] for [team or location] for
[period]. [Named person] would retain [review or decision], and the test would
not [important exclusion]. We would judge it by [observable result]. Would
that produce credible evidence here? What would still prevent approval?

Only now does a price question have an object. Ask how the buyer would evaluate a stated price or a narrow range against the budget source and expected result. “Would you pay?” asks for encouragement. “At $600 for this branch-level pilot, which approval or value assumption fails?” gives the buyer something they can reject precisely.

Record a Buying Path, Not a Mood

After the call, write down:

• the business consequence this buyer owns and when it becomes urgent;
• one previous approval or rejection that reveals actual decision behavior;
• the economic comparison and budget source;
• the approver, influencers, reviewers, users, adoption owner, and veto holders;
• the proof required for the next commitment;
• the smallest acceptable package and its explicit exclusions;
• risk, data, security, reliability, support, integration, and rollout boundaries;
• facts learned, founder inferences, and questions still unanswered.

Proceed to a pilot, proposal, or pricing test when the buyer can describe a plausible path through consequence, authority, proof, budget, risk, and adoption. Return to user discovery when the buyer does not recognize the consequence. Map the workflow in more detail when a veto depends on data, handoffs, or exceptions nobody can yet describe. Redesign the offer when the value is credible but the proof or rollout burden is too large. Change segment—or stop—when the first acceptable customer would require procurement, integration, assurances, or support that a solo founder cannot responsibly provide.