Make a Sales Deck Travel Beyond Its Internal Champion
Make a Sales Deck Travel Beyond Its Internal Champion
The call goes well. The person across the table understands the proposal, asks good questions, and says she'll share the deck with a couple of colleagues. You send it. She forwards it. Two people open a file that was never built for them, in a tab between a budget spreadsheet and a calendar reminder, with no one in the room to explain what any of it means.
Most of what made the proposal make sense was spoken, not written. That's the whole problem. A deck travels beyond its champion only when the context of the conversation travels with it: the current situation, the proposed change, the basis of the value claim, the work adoption will require, and the decision that is still open.
One more thing before anything else. A contact's enthusiasm is not evidence of agreement, and it is not authority to buy. The person forwarding your deck may be able to describe the idea beautifully and still be unable to approve the integration work, spend the budget, or speak for anyone else in the building. Treat the handoff as a writing problem with a described route, not as a signal that the deal is nearly done.
Find out who will read it next
Ask the champion directly, before you send: who else will see this, what does each of them have to judge, and what do they already know? The answers change the document. They don't change it in the way a logo swap changes it. They change which pages exist.
Three roles are worth separating even when one person seems to hold two of them. There is the person who forwards — your contact, who understands the idea and controls who sees it next. There is the person who must judge a piece of the proposal on its technical or operational merits, often without any interest in the sales story. And there is the person who can authorize the next step and the spending that goes with it. Forwarding, evaluating, and authorizing are different jobs with different questions, and a single deck has to work for all of them at once.
Use whatever the customer actually tells you about their own process rather than importing a template from a previous account. Some organizations route every new tool through a review you've never heard of; some let a regional manager approve a small trial on her own. If you don't know the route, put the question in the packet as an open item and ask your contact. Writing "the procurement team will need to review this" because procurement usually appears in your deals is not preparation. It's fiction with a company logo on it.
Here is a small invented case, used through the rest of this piece. Nothing in it is drawn from a real account, and no forwarding case was studied to produce it. A scheduling vendor has a call with Dana Ruiz, a facilities operations lead at a property company called Fairgate, which manages twelve buildings. Dana likes what she hears and asks for the deck to pass along. The vendor asks who else will read it, and Dana names two people.
Marcus administers the property-management system that holds work orders, and anything that touches it goes past him. Nadia is a regional operations director who can approve a limited trial but not a company-wide rollout. Dana also mentions that her own director has "asked about" scheduling tools, which is not the same as being involved, and that she isn't sure whether a security review gets triggered by connecting anything to the work-order system. That last item goes in the packet as an open question, addressed to Marcus, rather than being quietly resolved in the vendor's favor.
Recover the facts that lived only in the call
Now do the unglamorous work: read your own notes of what was confirmed and compare them against the slides. What you're looking for are the things that were obvious in the room and invisible on paper.
The GOV.UK Service Manual's guidance on sharing user research findings describes research decks written to make sense without the presentation, keeping each finding's facts and its consequences together (page reviewed 20 September 2026). That is UK government-service research communication, and it is a limited analogy here — it is not evidence about US sales practice, not a rule about how many slides anything should have, and not a finding about how buying decisions get made in companies. Transferred to a sales deck, it points at something simple: the document has to carry its own reasoning.
For the Fairgate case, that means at least five things that a live call supplies for free.
The current situation, with attribution. Twelve buildings. Requests arrive by email and phone into a shared inbox, and one dispatcher re-types each one into a spreadsheet. Preventive work lives on a calendar and a whiteboard. The vendor's notes record roughly forty to sixty requests a week and, for non-urgent work, "sometimes a day" between a request arriving and a technician being assigned. Those last two figures are Dana's estimates, not measurements, and the packet has to say whose estimates they are. An attributed estimate invites correction. An unattributed one reads as a measurement and gets challenged later, in a worse room.
The proposed change, in the customer's own terms. Three changes: a shared intake form, assignment by trade and site, and a text to the technician. That's it. The rest of the product can wait for a second conversation.
The basis of the value claim, and what the call does not contain. Nobody measured anything. The value case rests on the two estimates Dana gave — forty to sixty requests a week, and a delay of "sometimes a day" for non-urgent work — plus the dispatcher time that goes into re-typing each request, which nobody has counted at all. The packet can say where the value would come from and whose numbers support it. What it cannot do is present a saving as though someone had calculated it. This is one reason the day-90 review exists: it is the point at which estimates get replaced by counts. Until then the honest version of the value case is directional, attributed, and marked as unmeasured.
What exists today versus what is proposed. This distinction does real work, because the original deck blurs it. Intake forms, assignment rules, and text notifications run in the product today. Writing work-order status back into Fairgate's property-management system does not exist yet; it is proposed, and whether it is even possible depends on what that system exposes, which is Marcus's territory. A slide that says "seamless integration with your existing systems" is doing something dishonest by accident: it takes an unresolved requirement and dresses it as a capability.
The obligation that sits next to the claim. Texts would land on technicians' personal phones. Fairgate's device policy may prohibit work notifications on personal devices. That belongs beside the notification claim, not in an appendix, because it can change whether the proposed change is adopted at all.
Two more things from the call are worth keeping, in their proper categories. Dana said that if the re-typing came off the dispatcher's desk, "the team will be happy." That is Dana predicting other people's reactions, not other people agreeing. And Dana said she thought Marcus would be fine with it "as long as it doesn't create a second system of record." The reassurance is a guess. The condition is the useful part, and it is the best information available about the question Marcus will actually ask.
What Dana did not do is approve anything she can't approve — integration work, budget, or the other ten buildings. The deck has to make that clear without making Dana look like she's backpedaling.
Route questions without hiding the hard parts
Keep the main argument self-contained. A reader who opens the first six or seven pages should be able to understand the situation, the proposal, its limits, and the decision being requested, and then decide whether to read further. Everything else — integration detail, security questionnaires, rollout planning for the remaining buildings — gets a route, not a spot in the main line.
The route has one rule: an appendix is a place for depth, never a place for consequences. If a limit changes whether someone would say yes, it goes on the page where the affected claim lives, next to it. The write-back question sits with the capability comparison. The personal-phone policy question sits with the notification claim. An appendix link at the back titled "technical details" is not a disclosure; it's a place for inconvenient facts to be found later by someone who is now annoyed.
Equally important: routing different readers to different material is not permission to tell different stories. If Marcus's version of the numbers is softer or prettier than Nadia's, then neither version is evidence of anything, and the first person to compare notes ends the process.
The revision for Fairgate looks roughly like this, compared with what the vendor originally had.
The original deck ran: modern maintenance scheduling; why we built it; logos of other customers; scheduling in one place; smart assignment; seamless integration with your existing systems; "what this could look like at Fairgate" with three unattributed bullets; next steps. Nothing in it is false, exactly, and none of it survives being read cold by Marcus or Nadia, because both of them have to answer a question the deck never raises.
The forwardable version keeps a similar spine and adds the missing context:
- A short handoff note from Dana — three sentences she can edit or rewrite, stating why the document is being shared and which decision is open.
- The situation at Fairgate, dated and attributed to the 14 March call and Dana's confirmation email two days later, with her estimates labeled as estimates.
- What would change, limited to the three changes.
- The text-to-technician change, with the personal-device policy question on the same page as an unresolved condition rather than routed to the back.
- Where the value case rests: fewer re-typed requests and faster assignment, both Dana's estimates rather than measurements, and the day-90 review as the point where estimates get replaced by counts.
- Supported today, proposed, and unanswered, in three columns, with the write-back status in the "proposed" column.
- What a 90-day trial involves: the two sites Dana proposed, two days of setup on the vendor's side, a spending ceiling Dana says sits inside Nadia's discretionary budget, a day-90 review against two measures Dana named, and the conditions that end it early. Each of those carries its source on the page, and anything Dana did not settle is marked as proposed rather than agreed.
- The decision on the table: approve the trial, decline it, or ask for something before deciding.
- An appendix linking to the integration questions for Marcus, data and security notes, a rollout sketch for the other ten buildings, and the call notes.
Now trace each reader's actual question. Marcus's question — "am I about to run two systems of record?" — is answered on the capability page and expanded in the integration appendix, and it stays on the main path because his answer can reshape the trial itself. Nadia's question — "what am I approving, what does it cost, what happens if it fails, and does it commit me to twelve buildings?" — is answered on the trial and decision pages. Dana's question — "does this still say what I said, and does it make me look like I've already committed to something I haven't?" — is answered by the attribution on the situation page and by the handoff note, which states the decision as open rather than as a favor Dana is doing the vendor. And a stranger's question — "why am I reading this at all?" — is answered on page one and in the title.
This is a paper comparison, not a measured result. No one has tested this packet on a Fairgate reader, because Fairgate is invented.
Check the handoff without the original presenter
The introduction is part of the deliverable, and it should be short enough that Dana will actually send it. The version to give her states three facts: why the document exists, what it covers including what is still unknown, and which decision remains open. It does not claim her endorsement, and it does not ask anyone to trust her rather than the document. If she wants to write her own, the same three facts need to be in it — otherwise the reader is left reconstructing the meeting from a friendly sentence.
Then check the mechanics, from the recipient's side rather than yours. Confirm that the file you send is the version you finished editing, that its date is current, and that sharing permissions let the intended readers open it. Open every link while signed out, or ask a colleague to open them from an account that has none of your access; an appendix link that only resolves inside your company is an appendix that doesn't exist. And keep facts out of speaker notes and animations. A forwarded file is usually read one page at a time on a phone, often without ever entering presentation mode.
For the hardest check, find someone uninvolved — a colleague who has never spoken to Fairgate — and ask them to read the packet and answer four questions from the material alone: what is being proposed, what is unresolved, what is the reader being asked to decide, and who would do the integration work and at whose cost. If they can't answer, the packet isn't finished, and you've just found the gap for the price of a coffee.
That check is a proposal, not a tested method. It measures whether the document communicates; it says nothing about whether Nadia will approve anything. And if the honest answer to one of those questions is "we don't know yet," write that down. Making the champion explain missing evidence on your behalf is how a friendly contact ends up defending a document in a room where she has no authority.
The finished object is modest: a self-contained argument, a route to depth that doesn't hide the awkward parts, and an introduction that says why the document exists and what is still being decided. The champion's part stays truthful. She passed along something she understood, and nobody has to reconstruct a telephone call to judge it. That doesn't guarantee a yes. It lets a no, or a not yet, arrive on the merits — which is the only kind of answer worth building a next step on.
Frequently asked questions
Why isn't a champion's enthusiasm enough to make a sales deck travel?
A contact's enthusiasm is not evidence of agreement, and it is not authority to buy. The person forwarding the deck may be able to describe the idea beautifully and still be unable to approve integration work, spend budget, or speak for others in the building. Treat the handoff as a writing problem with a described route, not as a signal that the deal is nearly done.
What context must travel with the deck, and how do you learn who will read it?
The deck travels when it carries the current situation, the proposed change, the basis of the value claim, the work adoption will require, and the decision still open. Most of what made the proposal make sense was spoken. Ask the champion before sending who else will see it, what each person has to judge, and what they already know; those answers change which pages exist. Separate the forwarder, the evaluator who judges technical or operational merits, and the authorizer who can approve the next step and spending.
In the Fairgate example, what facts from the call had to be recovered or qualified?
Fairgate manages twelve buildings. Requests arrive by email and phone into a shared inbox, and one dispatcher re-types each into a spreadsheet; preventive work lives on a calendar and a whiteboard. The 40 to 60 requests a week and the 'sometimes a day' delay for non-urgent work are Dana's estimates, not measurements. The proposed change is limited to a shared intake form, assignment by trade and site, and a text to the technician. The value case is unmeasured. Writing work-order status back into the property-management system is proposed, not existing. Texts would land on technicians' personal phones, and the device policy may prohibit that. Dana's 'the team will be happy' is her prediction, not others agreeing, while 'as long as it doesn't create a second system of record' is the useful condition. Dana did not approve integration work, budget, or the other ten buildings.
Where should limits, unresolved questions, and different readers' material go?
Keep the main argument self-contained: a reader should understand the situation, proposal, limits, and requested decision from the first six or seven pages. An appendix is a place for depth, never for consequences. If a limit changes whether someone would say yes, put it on the page where the affected claim lives, next to it: the write-back question with the capability comparison, the personal-phone policy with the notification claim. Routing different readers to different material is not permission to tell different stories; if one reader's version of the numbers is softer, neither version is evidence.
What checks help confirm the handoff will work without the original presenter?
Give the champion a short introduction stating three facts: why the document exists, what it covers including what is still unknown, and which decision remains open. It should not claim her endorsement or ask anyone to trust her rather than the document. Confirm the sent file is the finished version, its date is current, and sharing permissions let intended readers open it. Open every link while signed out or through a colleague with none of your access; keep facts out of speaker notes and animations. For the hardest check, ask an uninvolved colleague to read the packet and answer four questions from the material alone: what is being proposed, what is unresolved, what decision is requested, and who would do the integration work and at whose cost. If they cannot, the packet is not finished. This check is a proposal, not a tested method, and it says nothing about whether Nadia will approve.