Write a Sales Discovery Summary the Customer Can Correct
Write a Sales Discovery Summary the Customer Can Correct
The most useful sentence in a discovery summary is the one the customer crosses out.
Not because it is wrong. Because the customer can see that it is a guess — and can tell you which guess matters. A summary that reads like a confident verdict invites a nod. A summary that reads like a set of clearly-labeled working notes invites a correction. The correction is the product. It is the most valuable thing the discovery process can hand you before a proposal, because it arrives while the proposal is still cheap to change.
Most discovery summaries fail in one of two directions. Either they are stenography — a transcript of what was said, with no interpretation, useless for deciding what to propose. Or they are a pitch in disguise — the customer's words quietly rewritten into the seller's vocabulary, every ambiguity resolved in the direction of the thing being sold. The first leaves the seller with nothing to act on. The second leaves the customer with nothing to correct, because the summary already assumes the sale.
The middle route is more work and more honest: reconstruct what the customer reported, separate it from what you inferred, mark what you still don't know, and send it back with a request to fix the parts that would change your response. That last step is the one most teams skip, and it is the one that changes the proposal.
A note on what follows: the worked example is invented teaching material. There is no real customer behind it, no notes were collected, no summary was returned, and no correction was received. Whoever adapts this method will need to build their own before-and-after from notes they are actually permitted to use.
Reconstruct the situation before naming a solution
Start with what the customer said the work is. Then the conditions around it. Then the difficulty they described, in their frame.
This sounds obvious and is routinely skipped. The moment you write "the customer needs a faster intake process," you have already started selling. "Faster" may be your word. "Intake" may be your word. The customer may have said something narrower: "The same booking details get typed twice, once here and once there, and the second time is the one that gets missed." That is a report of re-entry work and an error location. It is not yet a diagnosis.
Use authorized notes. Quote exactly when a quotation is actually recorded and you are permitted to use it. Do not reconstruct a vivid-sounding sentence the customer "essentially said." A polished paraphrase of what the customer needs is still your interpretation, and it should be labeled as one — or moved to the interpretation column where the customer can see it and push back.
The customer's own distinctions are load-bearing. If they separate "the booking itself" from "the confirmation to the client," keep those separate. If they say two offices handle it differently, do not collapse that into "the team." Specific structure is what lets a customer read the summary and recognize their own situation. A summary that smooths everything into clean categories reads well and tells the customer you weren't listening closely.
Separate reported facts, interpretations, and open questions
This is the core move. Give the reader three visibly different kinds of sentence:
Reported — what the customer said, in their terms. Interpreted — what you think it means, and why. Open — what you don't know, and whether the answer would change anything.
The third category is where summaries earn their keep. Not a generic questionnaire dumped at the end. A question belongs here only if a different answer would change the proposed response. "Who owns the handoff between booking and confirmation?" belongs. "What is your timeline for digital transformation?" usually does not.
For every interpretation, ask a plain question: if the customer corrected this, would the proposal change? If yes, it goes in the summary as an interpretation, marked. If no, it may not need to be there at all.
And a missing answer stays missing. The temptation is to fill a gap with what similar customers usually want — "based on our experience, teams in this position typically prioritize X." That sentence is doing work the customer hasn't authorized. It should be written as what it is: a pattern you've seen elsewhere, flagged as a guess, offered for correction. Never as a report of this customer's situation.
Make success criteria provisional and correctable
When you describe the improvement you have in mind, describe it in terms the customer can recognize — and mark every measure or threshold as provisional until they confirm it.
"Our goal is to cut down the re-entry work so the booking details are entered once and confirmed accurately from that single entry." That is recognizable. "Reduce processing time by 40%" is not a goal; it is a number you invented or carried over from somewhere else. If you want to propose a measure, say so explicitly: "A measure we might use — provisional, pending your view — would be X. To assess it we would need a baseline from Y, owned by Z."
This is where discovery summaries most often smuggle in commitments. An aspiration the customer voiced in passing becomes "the agreed target." A single reported incident becomes "a recurring issue, occurring roughly weekly." Both moves feel helpful. Both convert uncertainty into something that looks settled, and the proposal built on top inherits the error.
Keep the proposed solution separate enough that the summary survives if the solution changes. If the customer's real problem is handoff responsibility and your first instinct is a new tool, a good summary should still make sense without the tool. The account of the situation should not depend on the product you're hoping to sell.
Return the summary with a consequential correction request
Send the summary back with a specific ask: check the interpretations, and answer the few open questions that materially change the next step.
Not "let us know if anything looks off." That is a request for silent approval, and it will get you a nod or nothing. Instead, name the interpretations that would change your response if they were wrong:
"We read the main problem as the second entry being error-prone. If the real issue is that it's unclear who owns the handoff, that changes what we'd propose. Which is closer?"
That question is answerable. It is also consequential: the customer can see that their answer shapes the next step.
Record what comes back. If the customer confirms a point, that confirmation has a scope — it covers what was actually addressed and no more. No reply is not agreement. A polite "looks good" is not agreement with every claim, especially the ones the customer skimmed. Attending the call is not agreement. These are easy to treat as approval in the retelling, and doing so throws away the correction you were trying to earn.
The worked example: a booking handoff
(All names, notes, and exchanges in this section are invented for teaching. Nothing here was collected, sent, or returned.)
The invented discovery notes. A hypothetical team handles client bookings. In a hypothetical call, the operations lead says, roughly: "Bookings come in, we log them, and then someone re-enters the details into the confirmation system. The second entry is where mistakes show up — a date typed wrong, a name spelled differently from the client's request. Last month a client got a confirmation for the wrong day. The team doing the confirmation sits in a different office. Honestly, when something goes wrong, nobody's sure whose job it was to catch it."
The overconfident summary. A hypothetical first draft reads:
The customer's booking process is slowed by outdated software, causing repeated data entry and errors. They need a faster, integrated booking-to-confirmation system. A confirmation error last month led to a client complaint. We propose consolidating booking and confirmation into a single automated flow, with a target of eliminating re-entry errors within 90 days.
Read that against the notes. "Slowed by outdated software" is not in the notes — the lead described re-entry and unclear responsibility, not speed or software age. "Causing repeated data entry and errors" makes re-entry the cause of the errors; the notes describe re-entry as where errors surface, and separately describe unclear ownership. "A client complaint" appears nowhere; the notes mention a wrong-day confirmation, not a complaint. "Eliminating re-entry errors within 90 days" is an invented target. The proposed solution — automation — assumes the cause is the double entry, when the lead's own last sentence points somewhere else.
Almost nothing here is a lie. Each line is a small, plausible upgrade of the material. That is how a summary becomes a pitch without anyone deciding to write one.
The revised summary. A hypothetical second draft separates the three kinds of sentence:
Reported:
- Bookings are logged, then details are re-entered into the confirmation system.
- The second entry is where mistakes appear (wrong date, name mismatch).
- One recent case: a client received a confirmation for the wrong day.
- Confirmation is handled by a different office than booking.
- When something goes wrong, responsibility for catching it is unclear.
Interpreted:
- We read the second entry as the point of failure. It may be the entry itself, or the handoff into it. The notes don't settle this.
- We read "nobody's sure whose job it was" as a possible ownership gap between the two offices. This is our reading, not the lead's stated cause.
Open (answer would change the proposal):
- Is the recurring difficulty the re-entry step itself, or unclear ownership of the handoff?
- Is the wrong-day case a one-off or part of a pattern?
- Who currently owns the handoff between booking and confirmation?
Success, provisional:
- A recognizable improvement would be booking details entered once and confirmed accurately from that entry. Whether that is achievable depends on the two questions above. Any measure and threshold are provisional pending your view; we have no baseline and no agreed owner for assessing it yet.
The invented correction. Suppose the customer replies: the re-entry step works fine when it is clear who is handling the handoff. The real issue is that when the two offices are both busy, each assumes the other is doing the second entry, and it gets missed. The wrong-day case was one instance of that, not a software failure.
What must change in the proposal. The interpretation in the first draft — cause is the double entry, fix is automation — is now wrong. Automation would not address unclear ownership; it might even hide it. The proposal now has to lead with who owns the handoff and how that ownership is made visible when both offices are busy — a responsibility and process question. The re-entry step may stay as it is, or be a secondary item. The success criterion changes from "eliminate re-entry errors" to something like "the second entry is completed and confirmed by a named owner every time." The provisional target, the baseline question, and the whole first line of the pitch shift because the customer's correction changed the diagnosed cause.
Notice that the wording of the revised summary did not need to be softer. It needed to be organized so the customer could find the wrong part and fix it. The value is in the changed understanding, not the tone.
The corrected summary, and the question that still moves the next step
After the correction, the working account reads something like this: bookings are logged in one system and confirmed from a second entry; the entries themselves are not the failure point; the failure point is the handoff between two offices, which becomes ambiguous when both are busy; one wrong-day confirmation has been reported; ownership of the handoff is not currently assigned; the proposed response is to assign and make visible that ownership, with the entry step left for a later look.
One question remains open, and it still changes the next step: is the handoff ambiguous only under peak load, or also in quieter periods? If only under load, the response is a rule for busy times. If always, it is a standing ownership change. The summary is not finished in the sense of being sealed. It is finished in the sense that the customer can now correct the one thing that matters, and everything built on top of it — proposal, scope, success measure — rests on a cause the customer confirmed rather than one the seller assumed.
That is what it means for a discovery summary to be useful: not that it is polished, and not that the customer signed it, but that it carries a correction before the interpretation hardens into a proposal.
Frequently asked questions
What makes a discovery summary useful rather than merely polished?
It is organized so the customer can find the wrong part and correct it—not written as a confident verdict that invites a nod. The most useful sentence is the one the customer crosses out, because that correction arrives while the proposal is still cheap to change. Value comes from changed understanding, not softer wording.
How should a discovery summary separate its kinds of sentences?
Use three visibly different categories. Reported means what the customer said, in their terms. Interpreted means what you think it means, and why. Open means what you do not know and whether the answer would change anything. A question belongs in Open only if a different answer would change the proposed response. Missing answers should stay missing; patterns from other customers should be flagged as guesses, not reported as this customer's situation.
How should the summary be sent back?
Send it with a specific, consequential correction request: name the interpretations that would change your response if they were wrong, and ask the customer which reading is closer. Do not ask only for “anything that looks off,” which invites silent approval. Record what returns, and treat no reply, a polite “looks good,” or mere attendance as not agreement with every claim. Confirmation has a scope that covers what was actually addressed and no more.
In the worked booking example, what was wrong with the first summary?
It said the process was slowed by outdated software, that re-entry caused repeated errors, that a client complained, and that a 90-day target would eliminate re-entry errors. The invented notes did not say outdated software, did not call re-entry the cause rather than where errors surface, mentioned a wrong-day confirmation rather than a complaint, and contained no 90-day target. Almost nothing was a lie; each line was a small plausible upgrade that turned the summary into a pitch.
What changed after the customer's correction?
The real issue became unclear ownership of the handoff between two offices, especially when both are busy and each assumes the other completed the second entry. Automation would not address unclear ownership and might hide it. The proposal should lead with who owns the handoff and how that ownership is made visible; the re-entry step may stay or become secondary. The success criterion shifts from eliminating re-entry errors to a named owner completing and confirming the second entry every time. One question still changes the next step: whether the ambiguity occurs only under peak load or also in quieter periods. That was invented teaching material; no real notes were collected, sent, or returned.