Use the library as a decision tool
Start with a call objective and an uncertainty map. Write what must be learned, what is already known, which source supports it, what the buyer has permission to share, and which decision the answer will change. Then choose only the questions relevant to that map.
A primary study hosted by Harvard Business School found that asking more questions—especially follow-up questions—was associated with greater liking in controlled getting-acquainted conversations and an observational speed-dating setting. The question-asking research did not test B2B sales performance, qualification accuracy, or revenue. Use it as evidence about conversational perception, not as a close-rate claim.
Ask permission before exploring sensitive topics. Explain why a question matters, accept “I don’t know” or “I can’t share,” and never manufacture urgency. The sales discovery call guide owns the full meeting flow; this page owns a governed question library.
Current-state questions (1–7)
Use these prompts to establish how work happens now. Prefer a concrete recent example over a generic description.
- 1. Walk me through the last time your team completed this workflow.
- 2. What event starts the process, and what marks it complete?
- 3. Which roles, systems, and records are involved at each handoff?
- 4. Which system is authoritative when two records disagree?
- 5. Where does the process vary by team, segment, region, or case?
- 6. What manual work, workaround, or exception is considered normal today?
- 7. What changed most recently, and when did that change take effect?
Follow with “Can you show me a non-sensitive example?” or “Who can verify that?” when the answer will affect scope or a business claim. Do not confuse a remembered anecdote with the current controlled process.
Problem questions (8–14)
Problem questions should distinguish symptoms, root causes, constraints, and mere preferences.
- 8. Which step creates the most rework, delay, risk, or uncertainty?
- 9. What observable event tells you the problem occurred?
- 10. How often does that event occur in the population you track?
- 11. Which teams or customers are affected, and which are not?
- 12. What have you already tried, and what evidence showed the result?
- 13. What explanation does the team currently believe, and what contradicts it?
- 14. Which part is within your control, and which part depends on another owner?
A seller should be able to restate the problem as a falsifiable sentence: population, condition, observed defect, source, and time window. “The process is inefficient” is not yet a decision-quality problem statement.
Impact questions (15–20)
Impact questions test whether the issue is material enough to act on without forcing the buyer into invented math.
- 15. What downstream decision, customer, cost, revenue, risk, or workload does this affect?
- 16. How is that impact measured today, and who owns the definition?
- 17. What baseline and observation window would make a comparison fair?
- 18. What happens when the issue is left unresolved for one normal cycle?
- 19. What competing priority would this work displace?
- 20. Which impact is confirmed, inferred, disputed, or still unmeasured?
The FTC’s advertising-substantiation policy states that objective express or implied product claims require a reasonable basis before dissemination. When discovery will inform a proposal, preserve the buyer’s actual evidence and escalate performance, safety, financial, or regulated claims rather than converting them into polished marketing language.
Desired-state questions (21–26)
Desired-state questions define the decision and acceptance condition, not an unconstrained wish list.
- 21. What should be observably different after a successful change?
- 22. Which result is required, and which would merely be helpful?
- 23. What must remain unchanged while the process improves?
- 24. What evidence would make the operating owner accept the result?
- 25. What would cause the team to reject, restrict, or roll back the change?
- 26. How will the result be maintained after the initial rollout?
“Save time” is not an acceptance criterion until the task, population, denominator, baseline, measurement method, and quality guardrail are defined. Keep the desired-state artifact separate from vendor promises.
Stakeholder questions (27–32)
Stakeholder questions map expertise, authority, effects, and objections without stereotyping roles.
- 27. Who performs the work, who owns the result, and who bears the risk?
- 28. Who can verify the current-state facts we have discussed?
- 29. Who can approve data access, security, legal, finance, or procurement decisions?
- 30. Who could block adoption even if the commercial buyer agrees?
- 31. Which stakeholder sees the problem differently, and why?
- 32. What evidence does each decision-maker need in their own review?
Do not infer authority from title. Capture named decision rights and the scope of each approval. The buying-committee guide covers the broader committee model.
Decision-process questions (33–38)
Decision questions turn a vague buying journey into a reversible sequence of approvals and evidence.
- 33. What decision is the organization making, exactly?
- 34. What alternatives—including doing nothing—are in scope?
- 35. What evaluation criteria have been approved, and by whom?
- 36. Which proof must be observed in a pilot, reference, document, or contract?
- 37. What sequence of technical, business, security, legal, and finance approvals applies?
- 38. What event and evidence permit the next decision?
Record contradictions instead of forcing consensus. If one stakeholder expects an implementation this quarter and another has not approved the security review, the deal state is “conflicting constraints,” not “verbal commit.” Use the deal qualification criteria page for formal gates.
Economics questions (39–44)
Economics questions establish authority, cost boundaries, and scenario assumptions. They are not permission to pressure a buyer into revealing confidential information.
- 39. Which budget, capacity, or approved initiative could fund this decision?
- 40. Who owns the business case and the underlying data?
- 41. Which costs belong in the baseline, implementation, operation, and exit scenarios?
- 42. Which benefits are measurable, attributable, and not already counted elsewhere?
- 43. What assumptions would finance challenge first?
- 44. What commercial or operational boundary makes the option unacceptable?
Keep low, base, and high scenarios separate. Label calculated values, buyer-provided values, estimates, and vendor claims. A seller should not promise ROI when the buyer has not approved the baseline, attribution, confidence, time horizon, and total cost.
Risk and next-step questions (45–50)
Close discovery by testing failure, timing, and mutual action—not by manufacturing a deadline.
- 45. What could make this project fail even if the product works as described?
- 46. Which data, integration, permission, adoption, or capacity dependency is least certain?
- 47. What deadline is externally fixed, and what evidence supports it?
- 48. What unresolved question must be answered before the next commitment?
- 49. Who owns that answer, and when can they provide the artifact or decision?
- 50. If the evidence does not meet the agreed gate, what is the stop, restrict, or rollback path?
A legitimate next step has an owner, date, decision, required evidence, and stop condition. “Circle back next week” is a reminder, not a mutual action plan. The discovery follow-up guide owns the written recap.
Run, listen, and record the library safely
Use a simple loop: ask one relevant question, listen without drafting the next pitch, reflect the answer, check your interpretation, then choose a follow-up or stop. An experimental study of initial interactions found that active-listening responses were perceived differently from advice or simple acknowledgments; the active-listening study supports testing observable listening behavior, not a claim that one technique closes deals.
Record atomic assertions rather than a polished narrative. For each decision-relevant item, store the assertion, evidence type, source, source ID or artifact, speaker or owner, observed-at/as-of time, fact/inference status, confidence, conflict, permitted use, and next validation. W3C’s PROV-O recommendation provides a general entity, activity, and agent model for provenance; it does not make a CRM note complete by itself.
Managers should review behavior, not count alone: relevance, permission, neutrality, follow-up quality, reflection accuracy, evidence labeling, willingness to accept “no,” and next-step clarity. Hard fails include fabricating an answer, implying confidential knowledge, misrepresenting evidence, ignoring a stop request, or writing an inference to the CRM as confirmed fact.
For roleplay, select five questions for one scenario, give the buyer private facts and boundaries, and score what the seller does with the answers. The printable question bank owns the reusable artifact; this page explains how to choose and govern the prompts.