Question-based selling (QBS) is Thomas A. Freese’s method of replacing the pitch with a sequence of questions, and in a small team it only works if the answers get written down. Our rule is simple: each of the four question types gets one deal field (five fields in practice, because the last type produces a name and a date), and an empty field is not a mark against the rep. It is the next question to ask.
Freese laid it out in Secrets of Question Based Selling. The guides that rank for it do a fair job on which questions to ask and in which order. Weflow’s is the most complete, and it even closes with a step about putting QBS into the CRM. It is one step out of five, with no field names and nothing about what a manager looks at afterwards. That part is this post.
The answer nobody wrote down
A rep comes back from a good discovery call. “They loved it.” You ask what the buyer said the problem costs them. The rep remembers it was “a lot”, something about evenings. Two weeks later, on the second call, the rep asks a version of the same question again, and the buyer notices.
Weflow’s summary of Freese puts the premise in one line: the person asking the questions controls the conversation, and most sellers ask too many of them too early, before they have earned the right (Weflow). That is true during the call. After the call, control passes to whoever holds the answers. If that is the rep’s memory, nobody holds them. The CRM shows a stage called Qualified and a notes box that says “good call, sending deck”.
The repeat question is the expensive part. QBS spends it’s first minutes building enough credibility to probe at all. A buyer who answered a question once and hears it again in different words concludes the rep was not listening, and the credibility is gone in one sentence. The manager pays too: a deal review built on “they seemed keen” is a review of the rep’s mood, not of the deal.
So our position. A question whose answer is not recorded was asked for the rep’s own comfort. We would rather a rep asked three questions and wrote down three answers than asked nine and wrote down none.
The four QBS question types, two lines each
Weflow sorts QBS questions into four types, with a long table of examples we are not going to repeat (Weflow). Here is our two-line version of each, because the field names in the next section come from them.
Probing. Open questions about how things work today, asked once you have some credibility. “Walk me through how the week’s schedule gets to your staff.”
Value-based. What the problem costs, in the buyer’s unit. They turn “that’s annoying” into a number the buyer said out loud.
Solution-focused. What would be different if the problem were gone, in the buyer’s words. Weflow’s point here is the one we care about: the prospect articulates the value themselves, and that persuades them more than anything a rep can script.
Closed-ended confirmation. “So the main issue is the schedule, is that right?” and “Does it make sense to bring your co-owner into the next conversation?” Small questions. They catch a wrong assumption before it reaches the proposal, and they are the only type whose answer is a yes or a no.
If you want actual question lists, we have one for a small team’s discovery call and one by deal stage, built as HubSpot playbooks. This post is about what each type leaves behind.
One question type, one deal field
The table is the whole method as far as the CRM is concerned. Field names are generic on purpose; long text, number and date fields exist in every CRM we work with, and the setup lives in that CRM’s own documentation, not here. The example deal is made up: a three-rep team selling scheduling and payroll software to a regional restaurant group.
| Question type | Deal field | Filled in on the example deal |
|---|---|---|
| Probing | Current situation (long text) | Nine restaurants. Each GM builds the week’s schedule in a spreadsheet and texts a photo of it to staff. Payroll is the owner, two evenings every other week. |
| Value-based | Cost of the problem (number, unit in the field name, or one short line) | About 8 hours a month of the owner’s time, her estimate. One overtime dispute a month on top. |
| Solution-focused | Wanted outcome, in their words (text) | “I want to stop being the payroll department.” Schedule out by Thursday, payroll approved in one sitting. |
| Closed-ended confirmation | Decides (short text: name and role) and Decision by (date) | Priya Natarajan, owner; her brother co-signs anything above the monthly software budget. Mid-January, before the two new openings. |
Read across the rows and the mapping fits in one sentence: probing questions fill Current situation, value-based questions fill Cost of the problem, solution-focused questions fill Wanted outcome, and closed-ended confirmation questions fill Decides and Decision by.
Three notes on the table.
The cost field overlaps with the expected effect in our value selling fields post. If you already keep a value case on the deal reuse that field. One number, one home. The moment the same number lives in two fields, one of them is wrong.
The confirmation type is the only one that produces two fields, and that is deliberate. A confirmation question gets a yes on the call, but what you record is what the yes was about: who decides, and by when. A name without a date is a hope. A date without a name is a deadline nobody owns.
The wanted-outcome field should read like a quote. If it reads like our product description, it was our sentence and the buyer nodded, which is not the same thing. “Stop being the payroll department” could only have been said by one person about one business, and that is the test.
Look at the example once more. The detail that changes the next call is “her brother co-signs”. It came from a closed question (“Is this your decision alone?”), the type most reps skip because it feels blunt. Without that one field the rep books a demo for Priya and finds out about the brother at the contract.
Question-based selling vs SPIN: where they differ
SPIN is a fixed four-stage sequence (Situation, Problem, Implication, Need-payoff) that can feel mechanical if followed too strictly, while QBS puts the weight on earning the right to ask and leaves the order to the rep’s judgment. That is how Weflow’s comparison puts it. On paper the two still look like cousins: four question types, asked in sequence, answers worth recording. We have written about SPIN selling for Pipedrive teams separately.
For the record on the deal, two differences matter more than that.
SPIN’s four types describe the arc of one conversation, so the fields in our SPIN post fill up over one call and then mostly sit. QBS confirmation questions recur: after discovery, after a recommendation, at stage changes. So “Decides” and “Decision by” are living fields. They get rewritten, and a manager who watches one thing should watch how often that date moves.
And in SPIN as we run it, there is no confirmation type. The closed question is the piece QBS adds, and it is exactly where the name and date come from. If your team already runs SPIN and it works, do not switch frames for the sake of fields. Add the two confirmation fields and keep the rest. Weflow’s guide makes the same point about layering QBS on top of an existing framework. We would put it more narrowly. Borrow the closed question. If you also use conceptual selling, the fields are different, and we list them separately.
Gap selling and consultative selling are different frames again, and the records they leave overlap with the first and third fields here. Pick one frame per team. The fields survive a change of frame. The reps’ patience for re-learning them does not.
The Friday check: an empty field is the next question
Read the five fields top to bottom and stop at the first blank: that blank is next week’s question.
Here is how we run it. On Friday, pull the deals that changed stage this week or are due to, and open each one. For a pipeline a small team can hold in their heads, it takes under half an hour.
That blank tells you which question type has not been asked, so the the task for next week writes itself. “Current situation” empty: probing has not happened, and the next activity is a probing call, not the demo that is already booked. “Cost of the problem” empty: one value-based question, “what does that cost you in a month”, and the rep is not allowed to guess the answer. “Wanted outcome” empty: ask it, and write down the sentence, not a summary of it. “Decides” empty: the closed question, “is this your call alone?”. “Decision by” empty: “when do you need this running?”. For other methods, see the best sales books and the CRM field each adds.
The stopping rule matters more than the order. We do not read past the first blank, because a deal with the later fields full and an earlier one empty is usually a deal where the rep guessed. A wanted outcome with no recorded situation is our outcome with the buyer’s name on it.
Now the part about reproach, because it decides whether the fields survive a quarter. A blank field is information. It says where the conversation is. A rep who gets told off for blanks fills them with something, and a field that says “TBD” or “they’ll get back to us” is worse than an empty one, because it hides the gap the empty one showed. So the rule on our reviews is blank is allowed, invented is not. The manager’s job on Friday is to turn each blank into one scheduled activity with a one-line purpose and then to leave the rep alone until it happens.
One exception we do send back. If the first three fields are full and “Decides” says “the team”, the deal goes back a stage. The team does not sign.
We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. Deal Health checks every deal against more than 20 rules and shows which deals need attention and why: no next activity scheduled, a close date that has passed, and the other routine signals. It does not read your five QBS fields. That check stays with you and the Friday half hour, and the routine signals are what Deal Health takes off that half hour so the time goes to the fields. Check your CRM with SalesBond if you want to see which deals already look thin before you open the records. For the rest of what we ask once the fields are read, our post on deal review questions that end in a buyer action picks up where this one stops.
Try it before you add a single field. Take the five most advanced deals in the pipeline today and, for each, try to write the four answers from what is already in the CRM. Count the blanks. If more than half are blank, your team does not have a questioning problem. It has a recording problem, and five fields fix that faster than a workshop.
