Sales Execution
Stop resending the deck: artifacts that win buying committees
Why generic decks fail buying committees, and how to build one artifact per stakeholder concern: a risk memo, a payback model, an implementation timeline.
By Rishi Patel, Founder & CEO, RevSage.ai · · 8 min read
My champion sent me a screenshot last spring. It was my own one-pager, sitting in an internal Slack thread, with a comment above it: "this doesn't answer what Legal is asking." I'd sent that same page to five people on the deal, assuming a good story would travel on its own. It didn't. Legal wanted something about data retention terms, and I'd handed them a page about integration speed.
That's the moment I stopped treating "the deck" as a single, reusable answer. When a deal wobbles, most reps do the same thing: resend the deck, maybe with a new slide bolted onto the end. It feels like progress because you did something. It rarely moves anything, because the deck was built to answer an average buyer, and there's no such person sitting on a buying committee.
Key takeaways
- A buying committee isn't one audience in different chairs. Each member is evaluating a different risk, so a single deck can only ever answer one of them well.
- Build one artifact per real concern: map the person to their question, the evidence that would settle it, the format it needs, and the channel it has to travel through.
- A forwardable artifact is short, self-contained, written in the reader's own vocabulary, and sourced from real account or deployment data, not generic template language.
- Sequence artifacts to the stage of the deal. The security memo lands the day security shows up, not three follow-ups after the deal goes quiet.
- Opens, forwards, and who shows up to the next meeting are directional signals an artifact worked. None of them prove it on their own.
Why one deck can't survive a buying committee
A buying committee is several audiences who each showed up with a different veto. Brent Adamson's research, done at CEB and later folded into Gartner, tracked how fast this grew: the average number of stakeholders in a B2B purchase reached 6.8, up from 5.4 about eighteen months earlier (source). Gartner's own buying-journey research puts a typical complex purchase at six to ten decision makers, each arriving with research they gathered on their own (source).
I've written before about mapping and threading that committee in multithreading in B2B sales. This post assumes you've done that work already and asks a narrower question: once you know who's in the room, what do you actually hand each of them?
A generic deck answers a generic question, and nobody on a real committee has one. Infosec doesn't wonder about your roadmap. They want to know if this creates a breach or an audit finding with their name near it. Finance doesn't want a feature tour. They want to know if the math survives contact with their own numbers and when they get paid back. Ops wants to know what breaks on rollout day. Your champion wants ammunition for a room you'll never sit in. A forty-slide file, no matter how many bonus slides get tacked on, doesn't answer any of those four questions directly.
Gartner's newer sales research adds a wrinkle worth sitting with: 67% of B2B buyers now say they'd prefer a rep-free buying experience entirely (source). Buyers are already researching without you, in parallel, on their own schedule. The rep's job during that gap isn't to be present. It's to leave behind something specific and complete enough to do the work while you're not in the room.
Map the concern before you build the artifact
I run a short exercise before writing anything for a deal that's stalling. One row per stakeholder, four columns: what are they actually worried about, what evidence would settle it, what format does that evidence want, and where does it need to live so the right person actually sees it.
For a security reviewer, the concern is usually breach exposure or an audit finding attached to their name. The evidence is architecture and data-handling specifics, not marketing language. The format is a one-page risk memo they can attach to their own report. It lives in a shared doc, not buried on slide 14 of your deck.
For a CFO or economic buyer, the concern is whether the math holds up against their own numbers. The evidence is cost of the problem versus cost of the fix, in their figures wherever you have them, plus a real payback timeline. The format is one page with no adjectives, something they'd forward to their own finance team without editing it first.
For the ops or RevOps owner, the concern is what breaks during rollout and who owns fixing it. The evidence is an implementation timeline with named steps and named owners. It travels in whatever channel their team already uses, which usually isn't your CRM.
For your champion, the concern is whether they can defend this purchase to peers who weren't in your demo. The evidence is a comparable company solving a comparable problem, short enough to forward with one line of their own commentary on top. This is the artifact most reps skip, and it's often the one that closes the deal, because your champion does the actual selling once you leave the room.
The framework holds regardless of company size. What changes is how many rows the table needs. I've also written about reading which of four behavioral patterns a given buyer falls into, in the four buyer types, which pairs well with this exercise: that post tells you how someone decides, this one tells you what to put in front of them once you know.
What makes an artifact worth forwarding
Most of what gets labeled "sales enablement content" fails at the one job that matters: getting forwarded without the sender having to explain it first.
Four traits separate an artifact that travels from one that dies in an inbox.
Short. One page or one screen. If someone has to scroll to find the point, they've already decided it isn't worth the search.
Self-contained. It has to make sense to a stranger with zero context, because that's usually who ends up reading it. Your champion isn't going to write a paragraph of setup before forwarding your PDF.
In the reader's own vocabulary. A CFO reads "payback period" faster than "ROI narrative." A security reviewer reads "data retention" faster than "trust and safety." Match the words their team already uses internally, not the words on your website.
Sourced from something real. Generic AI-written collateral is easy to spot and easy to distrust, and buyers already see plenty of it. Gartner found that even as buyers lean on AI for research, 69% still turn to a human sales rep to validate what the AI told them (source). That validation only works if what you hand them is grounded in your actual customer base, your actual deployment data, or your actual account history, not a template with the company name swapped in.
This is the exact gap I built RevSage.ai to close. It runs live root-cause analysis on a deal in progress, then generates a hyperpersonalized artifact from your own knowledge base rather than a generic template, and drops it inside the CRM or inbox your team already uses. More on how that works on the product page.
Sequence the artifacts, don't dump them all at once
Timing matters as much as content. Send the security memo before anyone has raised a security question and it reads as defensive, like you're pre-empting an objection nobody made yet. Send it three follow-ups after security finally asks and the deal has already gone quiet while you scrambled to write it. I've written about what that kind of quiet usually signals in why deals stall.
The sequencing I use follows how the deal actually unfolds, not a template calendar.
Early, once a champion is engaged: nothing broad. A short recap of what you heard, written so your champion can forward it internally without editing.
Once budget enters the conversation: the CFO artifact, timed to land before the first finance meeting rather than during it.
The moment security or IT gets looped in: the risk memo, same day if you can manage it. Volunteered documentation reads as competence. Requested documentation reads as compliance.
Once procurement starts moving: the implementation timeline for ops, plus the peer case study for your champion to use in whatever internal consensus meeting you won't be in.
None of this requires a perfect signal. A reasonable guess about what's coming, delivered a week early, beats a well-built artifact delivered a week late.
Does the artifact actually move the deal?
Opens tell you the software worked. Forwards tell you a person staked a little of their own credibility on your material being worth someone else's time. I trust the second signal more. I'd rather see one forward from a stakeholder I've never met than ten opens from a champion re-reading the same page out of nerves.
Track three things per artifact, and treat all three as directional rather than conclusive: whether it was opened, whether it moved beyond the person you sent it to, and whether the next meeting that got booked included a new name. None of these prove causation by themselves. A deal can move for reasons that have nothing to do with your one-pager, and a strong artifact can land in a quarter where the buyer's budget just froze. What the pattern tells you, across enough deals, is whether your artifacts are doing real work or just adding to the pile.
Here's a gut check worth running before you build anything: would the person on the other end forward this without rewriting a single line? If the honest answer is no, it isn't ready yet, no matter how good the underlying data is.
Build one artifact this week
Pick your most at-risk deal. List every named stakeholder you can identify. Write one line for each: their likely question, and what would actually settle it. Then build exactly one artifact, for whichever concern is closest to blocking the deal right now, and send it to that person directly instead of routing it through your champion.
The deck isn't the problem so much as the assumption behind it, that one document could do six people's jobs. Eleven years of watching deals stall taught me the reps who win committees aren't the ones with the best deck. They're the ones who stopped believing one ever could be enough.
Frequently asked questions
- What should you send after a sales demo?
- Not a recap of the whole deck. Send a short note confirming what you heard, written so your champion can forward it internally without editing it, plus one artifact aimed at whichever stakeholder raised the sharpest concern on the call. A generic thank-you email with an attachment rarely moves anything.
- How do you sell to a buying committee?
- Map who is actually in the room, then build a distinct artifact for each person's real concern instead of one deck for everyone. A CFO needs a payback model in their own numbers, a security reviewer needs a one-page risk memo, an ops owner needs an implementation timeline, and your champion needs something they can forward to defend the purchase to peers you'll never meet.
- What is sales enablement content?
- In practice it means any material a rep hands a buyer to move a deal forward: one-pagers, case studies, ROI models, security memos. Most of it is written once and reused for every deal, which is exactly why it stops working once a real buying committee starts asking specific questions. The content that earns a forward is built for one stakeholder's concern, not the average buyer.
- What should a security one-pager for a B2B deal include?
- Keep it to one page: a plain summary of the architecture, how data is handled and where it lives, who has access and how that access is controlled, what happens if something fails, and a named contact for follow-up questions. Skip marketing language entirely. A reviewer forwards a document that reads like it was written by someone who understands their job.
- How many artifacts does a typical B2B deal need?
- There's no fixed number, but a useful rule of thumb is one artifact per stakeholder role that carries a distinct concern. On a mid-market deal that's often three to five: something for the economic buyer, something for the technical or security reviewer, something for the day-to-day owner, and something your champion can forward on your behalf.
About the author
Rishi Patel, Founder & CEO, RevSage.ai. Rishi has spent 11 years building and scaling B2B SaaS companies, most of it obsessing over why some reps consistently read buyers right and most don't. He founded RevSage to give every rep the buyer intuition of their best teammate.