Buying Committee Coverage Math: the nine roles and the empty seat

Buying committee coverage measures whether every role required to approve, validate, fund and implement a purchase is filled by a named person on a specific deal, with evidence, and whether the relationships between those people are mapped. Coverage counts roles, not contacts. A deal with eleven contacts and no economic buyer is less covered than a deal with four contacts where all four decision roles are accounted for.

The deal that stalls without warning

Week seven on Calder Mutual, a regional insurance carrier. 1,400 employees, a $180,000 proposal, an end-of-quarter close date.

Everything looks right. Five contacts on the deal. Discovery went well. The technical call went well. The VP of Claims Operations is genuinely enthusiastic, and every meeting invite has been accepted inside a day. The POC starts in eleven days.

Nobody has spoken to the person who administers the claims platform.

He is not a decision-maker in the usual sense, so no one invited him. He is not a contact on the record, so nothing in the CRM is wrong. He is also the only person who can define what "success" has to look like inside that environment. So the POC is about to start with no success criteria, then stall for three weeks while somebody works out who owns it.

That is a coverage failure. It is arithmetic, not intuition, and the arithmetic was available in week two.

What is buying committee coverage?

A contact record tells you a person exists and, if someone remembered to set it, what their title is. It does not tell you which seat that person occupies on this deal.

Your CRM knows how many contacts you have. It does not know how many roles you are missing. The gap between those two numbers is where no-decision losses live. Matthew Dixon and Ted McKenna analysed more than two and a half million recorded sales conversations and found that 40 to 60% of lost deals end in no decision rather than going to a competitor (The JOLT Effect, Portfolio, 2022). A deal rarely fails to decide because a competitor was better. It fails because the person who could have forced the decision was never in the room, or because the person quietly opposing it was never identified as opposition.

Buying committee coverage has three inputs, and most stakeholder mapping tools solve only the first.

1. Roles covered. Which seats 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 defers to whom, and where a blocker sits relative to an advocate.

CRM-native stakeholder fields stop at the first, because a contact object has somewhere to put a title and nowhere to put "reports to." Conversation intelligence tools go further, since they can hear a new name on a call, but hearing a name is not the same as deciding which seat it takes. The deals that slip are lost on the second and third inputs.

How many stakeholders should a B2B deal have?

Ruby computes a target stakeholder count for each deal before scoring coverage against it. The formula starts at four, the core committee present on every deal, then adds seats for the factors that reliably widen a buying group.

The number is a floor, not a cap. Ruby never removes a real stakeholder to meet it, and a deal can run wider. Nine as the floor, five people named in week seven: four seats short, and one of the four is the claims administrator.

Which seats a deal requires changes as it moves. A missing procurement contact in discovery is not a gap, because nobody should be mapping contract terms on a second call. The same gap two weeks before a forecasted close date is the reason that date is going to move.

Unfilled seats become named gaps. Ruby never invents a stakeholder to fill one.

What are the nine buying committee roles?

Ruby's stakeholder agents classify committee members into nine assignable roles, then reclassify as the deal progresses.

Three of these cause disproportionate damage because they are easy to miss. The user admin is not a decision-maker, so nobody invites them until the POC needs scoping. Compliance is not in the sales conversation at all in a regulated buyer, until they are the only conversation. And the blocker rarely presents as disagreement. It presents as a stakeholder who stops replying, or a requirement that keeps expanding.

Titles do not settle any of this. A VP of Engineering can be the economic buyer on one deal and a technical validator on the next. Coverage is a property of the deal, not of the org chart, which is why classification has to be re-run rather than set once at contact creation.

How Ruby classifies stakeholders from meeting transcripts

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 has stopped answering. The record documents an impression, and the impression does not get revisited.

Ruby runs it in two stages. A meeting analysis agent reads the transcript and extracts the structured facts: who spoke, what they said, what they committed to. A stakeholder agent then reads that extraction against the existing deal record and decides which seat each person occupies at this stage. Both halves matter, because the same sentence means one thing on a first call and something else with a proposal outstanding.

The rule that governs it: a role assignment carries a source-cited reason. An enthusiastic tone is not evidence. A stated commitment is.

Champion status is earned, not assigned. Exactly one agent in Ruby can set a contact's role to Champion. Everything else that spots promising behaviour writes potential champion instead, and the contact stays there until advocacy shows up in the record. A rep can override the classification deliberately, which is the one intended exception.

Same person, two outcomes

Dana Whitfield, VP of Claims Operations, spends a discovery call agreeing with everything. She calls the current process painful, says her team would love this, and asks how quickly you could start. Ruby writes potential champion. She described pain and expressed preference. Neither is advocacy.

Three weeks later she forwards the business case to the 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 a different deal strategy, because a champion can carry a room you are not in and a potential champion cannot.

It runs in reverse too. A stakeholder tagged champion who then stops appearing gets re-read against the current record, and Ruby raises a champion going quiet as its own risk signal at fourteen days without interaction.

Why coverage gaps never show up as deal risk

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

So Ruby scores coverage against the roles the deal requires at its current stage, then writes the missing ones into the rep's recommended actions. A gap does not get to exist without its next move. It is the same contract Ruby applies to MEDDPICC scoring, where an element with no data behind it scores 0 and the gap gets named rather than smoothed over.

On Calder Mutual, in week two, that reads:

High. No user admin identified, POC scoped for 11 days out. Technical validator confirmed feasibility. Nobody has set POC success criteria or named the implementation owner. Ask Dana who administers the claims platform day to day and get them into the scoping call.

That deal 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 seat that was never filled.

What to do with a coverage gap: multi-thread, deepen, or escalate

Naming an empty seat is only half the job, because "multi-thread harder" is not an instruction anyone can act on. Ruby turns a gap into one of three moves.

Multi-thread. Bring in a new person to fill an empty seat. This is the move for the claims administrator: nobody in the current five can answer what the POC has to prove.

Deepen. Go back to someone already on the deal, on a different topic. Dana has talked about claims pain for six weeks and has never been asked about budget timing.

Escalate to an executive sponsor. Go up a level, either because the economic buyer has never engaged directly or because an objection needs someone with the authority to rule on it.

The three fail differently, which is why the distinction matters. A rep who multi-threads when they should deepen collects contacts without adding coverage, which is how a deal reaches eleven contacts and still cannot say yes.

Relationship mapping: the edges matter as much as the nodes

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

Marcus Feld, Director of Platform Engineering, is the blocker on Calder Mutual. He has raised the same integration objection three times, each time slightly differently, and he is the reason the security review keeps expanding. The instinctive response is to answer him again, more thoroughly. Ruby's relationship map shows Marcus reports to Elena Brandt, Senior Director of Technology, classified as a potential champion.

That changes the play from multi-threading to escalation. Answering Marcus directly is a debate you can lose repeatedly with no resolution mechanism, because nothing in the structure decides when the objection has been answered. Converting Elena from potential champion to champion gives the objection an internal owner who can rule on how much weight it carries. You are not going around Marcus. You are giving the organisation someone with the authority to adjudicate him.

The same logic runs the other way. A champion who reports directly to your blocker is a fragile champion, however genuine the enthusiasm. That is a structural fact about the deal, invisible in a contact list, and it should change how you sequence the next three meetings.

Where coverage reaches the rep

Into the CRM. Ruby tags stakeholders on the deal across eight HubSpot association labels and writes five Ruby properties onto the contact record. Two come from classification: Influence Level and Sentiment. Three are outreach tokens the analyst drafts one sentence at a time, Pain Sentence, Role Context and Recommended Action, which the rep reviews and edits on a card before anything is saved, and which land as HubSpot properties so a Sequence can personalize from them. Contact resolution runs as a four-step cascade: a known HubSpot contact id, then an email match, then a LinkedIn profile match, then create. A name with no email and no LinkedIn profile gets skipped, because a name-only contact is a duplicate waiting to happen. [INTERNAL LINK: How Ruby writes deal intelligence into HubSpot → /blog/hubspot-deal-intelligence-writeback]

Into the pre-meeting brief. Ruby writes a brief to the deal record ahead of the call, opening with the attendees, one entry per person on the invite, and filters its meeting recommendations to the people actually in the room. Reps who pick a delivery time get their briefs in one batch a day at that hour, looking 26 hours ahead so nothing near the boundary falls through. Reps who set no time get a rolling window that briefs any meeting starting within 24 hours.

Into deal health. Stakeholder coverage carries 20 of the 100 points in Ruby's default deal health score, alongside MEDDPICC qualification at 30, meeting quality at 20, velocity at 15 and open risks at 15. Within that factor, a multi-threaded deal earns full credit, a dual-threaded deal earns 0.7, and a single-threaded deal earns 0.4. Being single-threaded therefore costs about 12 points of deal health against a fully covered version of the same deal, before a single objection is raised or a date slips. Each org can tune these five weights, and Ruby scores on the product defaults until someone does. Coverage shows up again inside MEDDPICC, where Economic Buyer and Champion each carry 15 of 100 points and both score on engagement evidence rather than identification. [INTERNAL LINK: A renewal date is not a compelling event → /blog/compelling-event]

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.

The floor is computable. Company size, deal size and the personas on the account set the minimum committee a deal should aim for.

Which seats matter depends on the stage. A missing procurement contact in discovery is not a gap. The same gap two weeks before close is the reason the date moves.

Champion has to be earned. Enthusiasm classifies as potential champion until advocacy shows up in the record, which is what keeps the champion label worth acting on.

Absence is the risk nobody reports on. A missing user admin produces no negative signal, which is exactly why a smooth-looking deal stalls at POC.

A gap needs a move, not a mention. Multi-thread, deepen, or escalate. Collecting contacts without closing a role is not multi-threading.

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

Frequently asked questions

What is buying committee coverage?

Buying committee coverage measures whether every role needed to approve, validate, fund and implement a purchase is filled by a named person on a specific deal, backed by evidence, and whether the relationships between those people are mapped. It counts roles rather than contacts, so a deal with many contacts can still be uncovered.

How many stakeholders should be on a B2B deal?

It depends on company size, deal size and how many buyer personas the account has. Ruby computes a floor per deal, starting at four for the core committee and adding seats for larger companies, larger deals and each named persona, held inside a 5 to 10 range for enterprise accounts. The number is a minimum to aim for, not a cap.

What is the difference between a champion and a potential champion?

A potential champion has expressed preference: they call the current process painful, say their team would like the product, ask about timelines. A champion has taken an action on your behalf when you were not in the room, such as forwarding a business case with their own framing or booking an internal review unprompted. Enthusiasm is not advocacy.

What is a single-threaded deal?

A deal where momentum depends on one relationship. The dangerous version is not the obvious one with a single contact. It is the deal with several contacts who all sit in one function or report through one person, so the coverage looks broad and the dependency is not. In Ruby's default deal health weighting, single-threaded earns 0.4 of the stakeholder factor against a multi-threaded 1.0, costing roughly 12 of 100 points.

Audit your coverage tonight

Twenty minutes, your five largest open deals. For each one, write the nine roles down the page and put a name against each: economic buyer, champion, potential champion, technical validator, user admin, procurement, compliance, blocker, approver.

Two rules. 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 were not 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 is not a healthy deal. It is an unmapped one.