The New B2B Buying Committee: Who's Really in the Room

Five years ago, a mid-market SaaS deal might involve a champion and a budget holder. Today, the same deal passes through security review, IT architecture, legal, finance, and at least one end-user committee. The buying committee has expanded faster than most vendors' sales motions have adapted. The result is longer cycles, more unexpected blockers, and deals that die after verbal commits.

This isn't a sales process problem. It's a structural shift in how companies buy software. And whether you're the one selling or the one evaluating, understanding who is actually in the room changes everything about how you approach the decision.

The Five-to-Eight Stakeholder Reality

In 2019, Gartner research estimated that a typical enterprise software purchase involved 6–10 decision-makers. That number hasn't gone down. If anything, the mix has become more complicated.

Here's who shows up in most mid-to-enterprise B2B software deals today, and what each person is actually evaluating:

The Champion — usually the functional leader who identified the pain. In a CRM deal, this is often the VP of Sales or Head of Revenue Operations. They've done the homework, run the demos, and have a strong preference. Their job is to sell the decision internally. Their risk: if the project fails, it's their name on it. A solid CRM buyer's checklist helps champions structure their internal case before the first demo.

The Economic Buyer — the CFO or VP Finance who controls the budget. They're evaluating ROI, payback period, and what happens at renewal. They're not reading feature comparison sheets. They're asking: what does this cost over three years, and what does it cost us if we switch again in 18 months?

IT / Architecture — increasingly important, and often underestimated. They're evaluating security posture, API compatibility, data model, and whether this tool creates integration debt. In companies running a modern data stack, IT has a genuine technical veto, not just a checkbox review.

Security / CISO / DPO — especially in regulated industries or any company with EU customers. These stakeholders may not appear in your CRM opportunity until week four of a five-week deal, at which point they can introduce requirements that take another six weeks to resolve.

Legal and Procurement — focused on contract terms: data processing agreements, SLAs, termination clauses, liability caps. In larger organizations these run on their own timeline, completely independent of the business evaluation.

End Users — frequently consulted via pilot groups or advisory committees. Their concerns are different: is this tool intuitive, does it fit my workflow, am I going to be stuck learning something new for six months?

The Executive Sponsor — a senior leader who may not attend every meeting but whose opinion shapes the final call. They're usually evaluating strategic fit: does this vendor align with our direction, and can we build a durable relationship?

That's seven roles. In a 500-person company, those might be seven different people. In a 5,000-person company, some of those roles have entire teams behind them.

The Hidden Vetoes

The stakeholders above are visible in most well-run deal cycles. What's harder to surface are the hidden vetoes: roles that don't appear in CRM opportunities but can sink a deal late in the process.

The Executive Assistant — controls access to the executive sponsor. If you haven't built that relationship, your meeting request sits in a queue.

The Internal Tech Champion in IT — not the IT director, but the senior engineer who actually evaluates API docs and integration quality. They may have no formal approval authority but can deliver a damning technical review that kills momentum.

The Budget Holder for Adjacent Systems — if your tool touches a data warehouse or a billing system, whoever owns those systems has an informal veto. Integration projects land on their roadmap.

The Person Who Used Your Competitor at a Previous Company — this is informal but real. If the CFO spent three years at a company that ran Salesforce and trusts it implicitly, that's a voice in the room without a formal role.

Mapping these hidden vetoes requires active discovery. You can't find them on LinkedIn. You find them by asking your champion: "Who else has a stake in how this decision lands?"

How Committee Composition Varies by Company Size

The committee structure changes significantly at different revenue and headcount levels.

SMB (under 100 employees, under $10M revenue) — buying decisions often involve three people: the champion, the CEO or COO, and occasionally an IT-adjacent person. Cycles are short. The champion and the economic buyer are sometimes the same person. Legal review is minimal. The risk is speed: decisions made without enough evaluation often regret it at renewal.

Mid-market (100–1,000 employees, $10M–$250M revenue) — this is where committee complexity spikes. You typically have 5–8 stakeholders across finance, IT, legal, and the business unit. IT is asserting more governance. Finance is scrutinizing multi-year terms. Security is now a real function. The champion has to manage internal politics they didn't have to navigate at a smaller company.

Enterprise (1,000+ employees) — 8–15 stakeholders is common, and formal procurement processes add overhead regardless of deal urgency. Vendor management teams, preferred vendor lists, and compliance reviews can add months. Deals that get to legal review without all prior stages complete often stall here permanently.

The Stakeholder Influence Map

Understanding who's in the room isn't enough. You need to understand the structure of their influence. Here's a framework for mapping it.

Place every identified stakeholder into one of four cells, based on two dimensions:

Decision Power (high or low): Can this person's approval move the deal forward? Can they sign the PO, approve the budget, or formally commit?

Blocking Power (high or low): Can this person stop the deal regardless of who else has approved it? Security, legal, and data protection roles often have high blocking power with no corresponding decision power.

The four resulting quadrants:

High Decision Power Low Decision Power
High Blocking Power Executive Sponsors, CFO CISO, Legal, DPO
Low Blocking Power Budget Holders End Users, IT Engineers

Quadrant 1 (High Decision + High Blocking): These are your deal-makers. Get them aligned early. If they're not bought in, nothing else matters.

Quadrant 2 (Low Decision + High Blocking): These are your hidden veto holders. You need their sign-off, but they can't champion you. Ignore them at your peril. The CISO who shows up in week six and asks questions nobody prepared for is a Quadrant 2 failure.

Quadrant 3 (High Decision + Low Blocking): Budget holders who've delegated the technical evaluation. They're important at the close, but earlier in the process they rely on others' input.

Quadrant 4 (Low Decision + Low Blocking): End users and technical evaluators. They shape preference and generate internal narrative, but their formal authority is limited. Champion them anyway. The person who trains their team on a new tool after purchase creates success or failure on the ground.

What This Means for Vendors

According to Forrester's B2B buying research, the number of interactions required to complete a B2B purchase has roughly doubled since 2019, driven largely by the expanded committee structure. Multi-threading used to be an advanced enterprise sales technique for large deals. Today it's table stakes for anything mid-market and above.

Most CRM tools create one-to-one contact records in opportunities. An SDR finds a champion, creates a contact, logs activity against that contact. That single-threaded approach fails when the decision is made by a committee whose members each need different information at different times.

The CRMs handling this better are building buying committee features into their deal objects. Salesforce's Account Engagement, HubSpot's multi-contact deal stages, and newer tools like Pocus and Demandbase are trying to track stakeholder coverage explicitly. If your current CRM doesn't support multi-threading natively, it may be worth comparing Rework vs. Salesforce on deal object structure before your next renewal. But the tools are ahead of most teams' actual processes. Having the feature doesn't mean the team is using it.

Practically, here's what multi-threading looks like: before a deal advances past the first two calls, your champion should have helped you identify at least one other person in each of the critical quadrants above. If you're 30 days into a deal and the champion is the only contact you have, the deal is likely to stall.

The 10-Minute Discovery Exercise

Here's a repeatable approach that surfaces committee structure in the first two discovery calls.

After understanding the problem and current state, ask your champion. This lines up directly with the qualification frameworks that well-run sales teams use to surface buying committee structure in early calls:

  1. "When a decision like this gets made at your company, who else typically weighs in?" (Opens the full committee question without pressure.)
  2. "Is there someone in IT or security who'd want visibility early?" (Surfaces the hidden veto holders before they appear in week five.)
  3. "Who controls the budget, and do they have any direct questions I should be prepared to answer?" (Identifies the economic buyer and any early finance concerns.)
  4. "Is there an existing vendor relationship I should know about?" (Flags competitors and relationship dynamics.)
  5. "What does success look like for you personally, not just for the project?" (Separates the champion's institutional motives from personal stakes.)

These questions don't require a special technique. They require the discipline to ask them before you're deep into a demo cycle. Most vendors wait too long. By the time the hidden veto holder appears, the sales engineer has already built a custom demo environment, and reversing course is expensive.

What Buyers Should Take From This

If you're on the buying side, the committee structure above isn't just a vendor problem. It's your governance problem. Deals that fail don't always fail because the vendor was wrong. They fail because the evaluation process didn't involve the right people early enough, and someone with blocking power surfaced concerns that could have been resolved in week one, not week eight.

The most efficient buyers designate a single evaluation owner who is responsible for mapping the committee, gathering input, and synthesizing a recommendation. That person isn't always the champion. It's whoever has the organizational credibility to run a fair internal process.

If you're evaluating a new platform, start by building your own version of the Stakeholder Influence Map above before the first vendor demo. Know who your Quadrant 2 people are. Bring them in early, even if informally. A 30-minute preview call with your CISO in week two costs less than a six-week delay caused by security questions in week seven.

The Direction This Is Heading

The buying committee is going to keep expanding, not contracting. McKinsey research on B2B decision-making shows that even post-pandemic, buyer preferences have permanently shifted toward digital, self-directed evaluation — which paradoxically requires more internal alignment before a vendor ever gets in the room. AI governance requirements are adding a new stakeholder category in many companies — the governance gap that AI creates at work is landing directly in software procurement processes. Data privacy regulation is creating formal DPO involvement in software evaluations that didn't require it before. And the sheer density of existing vendor relationships means more IT teams are actively managing vendor portfolios with scrutiny that didn't exist when companies ran five SaaS tools instead of 130.

Understanding the structure of modern buying committees isn't a sales tactic. It's a prerequisite for running an efficient evaluation — on either side of the table. The companies that navigate this well spend less time in deal stalls and make better software decisions. The ones that don't keep wondering why their verbal commits don't convert.

Learn More