Buying Committee Coverage Math

The deals that surprise you are rarely the ugly ones. Ugly deals announce themselves: objections stack up, calls get rescheduled, the champion goes dark. You see those coming.

The deal that surprises you is the smooth one. Every meeting gets accepted. The champion is genuinely enthusiastic. Discovery went well, the technical call went well, and then the POC sits for three weeks because nobody ever asked the person who administers the system what "success" would need to look like in their environment. That person was never on a call. They were never a contact on the record. Nothing in your CRM was wrong, because nothing in your CRM was about them.

That is a coverage failure, and it is arithmetic, not intuition. An average enterprise deal now involves 6–10 stakeholders. Your CRM knows how many contacts you have. It does not know how many roles you are missing.

What is buying committee coverage?

Buying committee coverage is the measure of whether every role required to approve, validate, fund, and implement a purchase is identified, engaged, and evidenced in a specific deal — and whether the relationships between those people are mapped well enough to act on. Coverage is not contact count. A deal with 11 contacts and no economic buyer is less covered than a deal with 4 contacts where all four decision roles are accounted for.

Coverage math has three inputs:

1. Roles covered. Which seats in the decision-making unit are filled by a named person, with evidence.

2. Roles missing. Which seats the deal requires and does not have — including the ones that only bite later.

3. Relationships between them. Who reports to whom, who influences whom, and where a detractor sits relative to an advocate.

Most stakeholder mapping tools solve for the first input. The deals that slip are lost on the second and third.

Why headcount is not coverage

The reason single-threaded deals are so persistently dangerous is not that reps don't know multi-threading matters. Every rep knows. The problem is that the CRM measures the wrong thing, so a deal can look well-threaded and be structurally exposed.

A contact record tells you a person exists and, if someone remembered to set it, what their title is. Title is not role. A VP of Engineering can be the economic buyer on one deal and a technical validator on the next. A director with no budget can be the only person whose objection actually kills the purchase. Coverage is a property of the deal, not of the org chart, and it changes as the deal moves.

Research by Matthew Dixon and Ted McKenna, analysing 2.5 million sales conversations, found that 40 to 60% of qualified pipeline is lost to no decision rather than to a competitor (The JOLT Effect, 2022). No-decision losses are coverage losses. A deal does not fail to decide because a competitor was better. It fails to decide because the person who could have forced the decision was never in the room, or because the person who quietly opposed it was never identified as opposition.

The seven roles Ruby classifies

Ruby's stakeholder agents classify buying committee members into role categories, then keep reclassifying as the deal progresses. Each role has a distinct decision function and a distinct cost when it goes uncovered.

Two of these seven do the most damage precisely because they are easy to miss. The user admin is missed because they aren't a decision-maker in the usual sense, so nobody invites them until the POC needs scoping. The detractor is missed because detraction rarely presents as disagreement. It presents as a stakeholder who stops replying, or a requirement that keeps expanding.

Ruby classifies from transcripts, not from CRM notes

This is the part that separates a stakeholder map that holds up from one that flatters the rep.

CRM-derived stakeholder mapping inherits whatever the rep typed. If the rep wrote "Dana — champion" after a good call, Dana is a champion forever, including three weeks later when Dana stopped answering. The record documents an impression, and the impression doesn't get revisited.

Ruby's stakeholder agents read the meeting transcript against the existing deal record and classify from what was actually said. Ruby does not extract, it classifies. Extraction notices that a new name appeared on a call. Classification decides which seat that name occupies on this deal, at this stage — and reading the CRM record alongside the transcript is what makes that judgement possible, because the same statement means one thing on a first call and something else with a proposal outstanding.

The governing rule is the same one that governs everything Ruby writes: no evidence, no entry. A role assignment has to carry a source-cited reason. An enthusiastic tone is not evidence. A stated commitment is.

Champion status is earned, not assigned. Exactly one part of the system can tag a contact as Champion. Everything else that spots promising behaviour writes potential champion instead, and the contact stays there until advocacy actually shows up in the record. That restraint is why a Champion filter built on Ruby's data stays worth filtering on.

Same person, two outcomes

A VP of Operations spends a discovery call agreeing with everything. She calls the current process painful, says the team would love this, and asks how quickly you could start.

Ruby writes potential champion. Nothing she said commits her to anything internally. She described pain and expressed preference. Both are useful; neither is advocacy.

Three weeks later, the same VP forwards the business case to her CFO with her own framing attached, and books the internal review herself without being asked.

Now Ruby writes champion, and cites the two actions that changed the classification. Same person, same enthusiasm, different evidence — and the deal strategy that follows is different, because a champion can carry a room you're not in and a potential champion cannot.

Classification also runs in the other direction. A stakeholder who has been tagged champion and then stops appearing gets re-read against where the deal now sits. Ruby raises its sensitivity as a deal moves closer to a decision: two quiet weeks early in a deal reads as normal cadence, while the same two weeks with a proposal outstanding registers as a risk. Role and stage decide how silence scores, not the calendar alone.

Coverage gaps: the risk that hides inside a smooth deal

Most deal-risk tooling reports on what is in the deal. Coverage math requires reporting on what is absent, which is harder, because absence produces no signal. There is no negative call recording. Nobody sends an email to tell you they were never invited.

Ruby scores coverage against the roles the deal actually requires at its current stage, and names the missing ones as gaps in the rep's recommended actions rather than burying them in a stakeholder view. A gap is not allowed to exist without its next move — the same contract Ruby applies to MEDDPICC scoring, where an element with no data behind it scores 0 and its gap gets named.

Stage matters here as much as it does everywhere else. A missing approver on a second call is not a gap; nobody should be mapping signature authority in discovery. A missing approver two weeks before your forecasted close date is the reason that date is going to move.

The clearest case is the one that opens this post. When a deal is heading toward a technical evaluation and Ruby has no user admin identified, that lands as a high-priority action item before the POC is scoped, not after it stalls:

[HIGH] No user admin identified with 11 days to POC start. Technical validator confirmed feasibility; nobody has set POC success criteria or named the implementation owner. Ask the champion who administers the environment day to day and get them into the scoping call.

That is the whole point of measuring absence. The deal above has no risk signals. Sentiment is positive, engagement is high, every meeting is getting accepted. It is also going to stall, and the only thing that could have told you so is a role that was never filled.

The edges matter as much as the nodes

Knowing who is in the buying committee is table stakes. Knowing how they relate to each other is where strategy actually comes from — and it's the layer almost no CRM captures, because a contact record has fields for title and email and nothing for "reports to."

Ruby maps relationships between buying committee members: reporting lines, influence direction, and who briefs whom. Those edges change what the rep should do next, sometimes inverting the obvious play.

Take the most common version. A technical stakeholder has become a detractor: he's raised the same integration objection three times, each time slightly differently, and he's the reason the security review keeps expanding. The instinctive response is to go answer his objection again, more thoroughly.

Ruby's relationship map shows he reports to a director you've classified as a potential champion. That changes the recommended play. Answering the detractor directly is a debate you can lose repeatedly with no resolution mechanism. Converting his manager from potential champion to champion gives the objection an internal owner who can decide how much weight it carries. You're not going around the detractor; you're giving the organisation someone with the authority to adjudicate him.

The same logic runs the other way, and it's worth knowing before you rely on someone. A champion who reports directly to your detractor is a fragile champion, however genuine their enthusiasm. An economic buyer who only ever hears about your deal through a stakeholder you've never met is an economic buyer you don't actually have access to. Both are structural facts about the deal, invisible in a contact list, and both should change how you sequence the next three meetings.

Where coverage goes to work

A stakeholder map is only worth building if it reaches the rep at the moment they need it, so coverage travels the same routes as the rest of Ruby's deal intelligence.

Into the CRM. Ruby tags stakeholders across 8 HubSpot association labels and writes two contact properties, Influence Level and Sentiment, onto the contact record. Contact discovery resolves through four paths — match on email, match on LinkedIn URL, create a new contact, or skip — and Ruby skips by default when a stakeholder surfaces as a name with no email and no LinkedIn profile, because a name-only contact is a duplicate waiting to happen.

Into the pre-meeting brief. Up to 24 hours before a call, Ruby writes a brief to the deal record that leads with the attendees, with one row per person on the invite, and filters its meeting recommendations to the people actually in the room. New faces get flagged as new rather than blending into the list.

Into deal health. Economic Buyer and Champion carry 15 points each in Ruby's MEDDPICC weighting, and both are scored on engagement evidence rather than identification. Naming an economic buyer who has never attended a session is not coverage, and it does not score like coverage.

Key takeaways

Coverage is a count of roles, not a count of contacts. A deal with eleven contacts and no identified economic buyer is a single-threaded deal wearing a disguise.

Titles don't determine roles — deals do. The same person occupies different seats on different deals, which is why role classification has to be re-run as the deal progresses rather than set once at contact creation.

Transcript-based classification beats CRM-based classification because the CRM records the rep's impression at one moment, while the transcript records what the stakeholder actually committed to.

Champion has to be earned. Enthusiasm gets classified as potential champion until advocacy shows up in the record, which is what keeps the champion label meaningful enough to filter on.

Absence is the risk nobody reports on. A missing user admin produces no negative signal, which is exactly why a smooth-looking deal can stall at POC — coverage math has to measure the empty seats, not just the filled ones.

Relationships change the play. A detractor who reports to a potential champion is not an objection-handling problem; it's a sponsorship problem, and the move is upward rather than head-on.

Audit your coverage tonight

Twenty minutes, your five largest open deals. For each one, write down the seven roles and put a name against each — economic buyer, champion, potential champion, approver, technical validator, user admin, detractor.

Two rules while you do it. A name only counts if you can cite the specific thing that person said or did that qualifies them, and "champion" only counts if you can name an action they took internally when you weren't in the room. Everything else is a potential champion.

Then answer one question per deal: which empty seat will you notice first, and will you notice it before or after it costs you the quarter?

If a deal has more empty seats than filled ones and no risk flags on it, that isn't a healthy deal. It's an unmapped one.