The Pre-Contact Buying Group Map: Seats, Evidence, Veto Risk, First Touch

This guide covers one job done before first contact. You take a named target account and your product, then work out which seats will decide, approve, or veto the purchase, who probably sits in each one, and whom to reach first. It is for founders selling their own product, account executives, SDR leads, and partnerships teams. Follow it start to finish and in under two hours you can hand over a seat-first buying-group map with a coverage percentage and an ordered first-touch sequence.

What is a seat-first buying-group map?

A seat-first buying-group map lists the decision seats that one specific purchase creates, then fills each seat with a named person or an explicit placeholder. Because it starts from the purchase rather than from a persona list or an org chart, the seats that can stop a deal are on the map before anyone at the account has engaged.

The whole method rests on three terms:

• Seat: a role the purchase needs filled, such as economic buyer or security reviewer. The seat exists whether or not you know who is in it.
• Economic buyer: the seat that owns the budget the purchase is paid from and can approve the spend.
• Veto seat: a seat that cannot start a purchase but can stop or stall one. Security, privacy, legal, procurement, and AI governance are the usual veto seats.

Most published advice on this job falls into one of two camps. Vendor pages tell you to pull an org chart from a database, which finds the people who are easy to find. Deal-review templates assume a champion has already told you who is involved, which only works after contact. Neither tells you how to find the veto seats before the first message, and those are the seats that surface late and kill deals.

The finished map has six parts:

1. 6 to 12 seats derived from a written purchase spec.
2. A named person or a labelled placeholder in every seat.
3. An evidence state for each seat (confirmed, inferred, or placeholder) with the date of the evidence.
4. A formal power score and a veto risk score for each seat.
5. A coverage percentage: seats with a named person divided by total seats.
6. An ordered first-touch sequence for whoever writes the outreach.

How many seats should a buying-group map have?

Map 6 to 12 seats. Six covers the core of a simple purchase, and you move toward twelve as the product touches more data, spans more departments, or adds AI features. Published buying-group sizes disagree widely, mostly because each source counts something different.

The spread is not noise. Depending on the source, the count is the people that survey respondents named, the people seen engaging with vendors, or everyone with any role at all. Forrester surveyed more than 16,000 buyers and found an average of 13 people involved in the decision, with most purchases spanning two or more departments. It also notes that the number rises for more expensive or complex purchases. Gartner's median of six to 10 counts decision makers only.

Two consequences shape the rest of the method.

Visible engagement undercounts the veto seats. Counts of people who visibly engage sit around six, at or below Forrester's non-AI figure of seven. The gap exists because security and legal tend to engage at validation, after the shortlist is set. A map built from whoever is engaging leaves those people out.

For AI products, half the group may never appear in engagement data. The group goes from 7 to 14, and the seats that get added are review functions with no buying-intent footprint. The privacy reviewer who will assess your model never visits your pricing page.

A map built from visible engagement leaves out exactly the seats that can stop the deal.

No published rule turns the gap between surveyed and visible group size into a target number of seats, so the 6 to 12 range is my own method. Its floor matches Gartner's decision-maker median and its ceiling matches the AI-purchase survey figure. It leaves out the external participants and casual influencers who do not hold a decision. If you go above twelve you are mapping contacts, not seats.

Which seats does a purchase create?

The purchase itself creates the seats. Write down what data the product touches, which systems it integrates with, whether it has AI features, the rough contract value, and which budget pays for it. Each answer adds specific seats to the map.

The seat menu:

• Economic buyer: owns the budget that pays. Always present.
• Technical owner: owns the systems the product integrates with. Always present.
• User lead: runs the team that will use the product day to day. Add one for each department that uses it.
• Finance: approves spend and payment terms. Always present.
• Procurement: runs sourcing, quotes, and vendor onboarding. A secondary summary of Forrester's research puts procurement among the decision makers in 53% of B2B buying cycles.
• Security or third-party risk: assesses the vendor. Present whenever the product touches company data or systems.
• Privacy: present when the product touches personal data.
• Legal: reviews the contract and data-processing terms.
• AI governance: present whenever the product has AI features.

The buyer's side lists much the same seats. The Health Sector Council's AI third-party risk guide calls for "cross-functional collaboration among procurement, security, privacy, compliance, legal, clinical leadership, and business owners," and tells buyers to engage privacy, security, legal, and compliance teams early.

Who actually sits in the security seat

Who sits in the security seat depends on the product's risk tier, not on who holds the most senior security title. One published approval ladder runs like this: security analysts approve low-risk vendors, security managers approve medium-risk vendors, the CISO approves high-risk vendors, and the risk committee approves critical vendors.

The third-party risk function also rarely reports where reps expect. An industry survey, seen only through a secondary source, reports these lines:

At most organizations, mapping "procurement" as the security gate puts the wrong person in the seat. Treat procurement and third-party risk as two separate seats unless you have evidence that one person holds both.

The AI-governance seat

In Refolk's index of professional profiles, 4,534 people in the United States hold a CISO title. Only 17 US profiles carry an "AI Governance" title, at employers including Meta, Credo AI, Hewlett Packard Enterprise, Lincoln Financial, Sutter Health, and NRG Energy. That means there are 267 times as many US CISOs as US profiles with an AI-governance title. Far more companies do this work than use the title for it. At most of them, AI review sits under privacy, risk, and legal titles.

The UK sample matters for deduplication. Its non-literal titles include combined roles such as "CTO | CISO" and "Principal/CIO/CTO/CISO", so at smaller UK companies the technical owner and the security seat are often the same person. Overall there are 6.6 times as many US CISOs as UK ones. For the AI-governance seat, a placeholder that names the privacy, risk, or legal owner of record is a realistic standard.

Where does the evidence for each seat come from?

Officer seats come from regulatory filings, the company's leadership page, and press releases. Functional seats come from job postings, hiring-team boxes, conference talks, case studies, and code activity. Each source proves something specific and goes wrong in a predictable way.

US public companies list their executive officers in 10-K filings under Regulation S-K Item 401(b), with every office and position each one held in the past five years. For private companies, the leadership page and dated press releases do the same job, less reliably.

Job postings are the best pre-contact source for functional seats. A line such as "You will report to the Head of Growth" gives you the hiring manager's exact title. One practitioner guide estimates 20 to 30 minutes per posting to identify the hiring manager, which is the only public timing for any step of this job. Pick the one or two postings that touch your technical owner and security seats rather than working through all of them.

No standard published procedure exists for confirming a reporting line when the manager field is empty. Practitioners triangulate instead. They take a "report to" title, find a person who holds that title, and look for a dated talk or case study that places them in that function. When two of those three agree, you have an inference. A confirmation needs a dated primary document that names the person in the role.

Triangulation is where the hour goes. Refolk lets you ask in plain English for the people in a function at a named company, across LinkedIn, GitHub, and the open web. That turns a dozen searches into one query, and you then check the results against the posting.

The three evidence states

• Confirmed: a dated primary document names this person in this seat. That can be a filing, a company press release, the leadership page, or a talk or case study published by the company.
• Inferred: the person fits the seat by title and function on a profile or other indirect signals, but no primary document ties them to it.
• Placeholder: the seat exists and its function is named, but no person has been identified. Record the owner of record if you can see one.

Every state carries the date of the evidence, not the date you looked.

Why the date matters more than the source

People change roles slowly but steadily, and the data that records those changes runs behind. One contact-data vendor studied 148,000 records. Over twelve months, 12.6% of US sales leaders changed roles, and over twenty-four months 25.7% did. The widely repeated 30% figure is close to a two-year rate, not an annual one. The study put the monthly rate at about 1%. It also found a detection lag: over three months the measured rate was only 0.50% a month, because a change takes time to surface in any dataset that tracks employment. UK sales leaders changed roles at 1.73 times the US rate.

That is a single source, and it measured sales leaders only. Nobody has published a rate for director-and-above roles across functions. The mechanism still carries over, though: a profile can look current for around three months after it stopped being true. A dated primary document beats a profile that only looks current.

The procedure: one account name to a first-touch order

Nine steps take one rep from an account name and a product to a map that is ready to hand off. By my estimates, steps 1 to 7 take about 100 to 115 minutes, and steps 8 and 9 take a few minutes each when the evidence is fresh.

Use this skeleton for step 1. The tier at the bottom drives the security seat in step 6.

Account:
Product:
Data it touches (personal, regulated, internal only, none):
Systems it integrates with:
AI features (yes or no; what the model does with their data):
Rough contract value:
Budget that pays (department and owner title):
Departments that will use it:
Estimated risk tier (1 critical / 2 high / 3 medium / 4 low):
Reason for tier (from data sensitivity and system criticality, not value):

Use this one for steps 2 to 9. Each row is a seat, not a contact.

Account:            Product:            Risk tier:            Map date:
Seat | Person or placeholder | State | Evidence source | Evidence date | Power 1-3 | Veto 1-3 | Touch order
Economic buyer | | | | | | |
Technical owner | | | | | | |
User lead | | | | | | |
Finance | | | | | | |
Procurement | | | | | | |
Security / third-party risk | | | | | | |
Privacy | | | | | | |
Legal | | | | | | |
AI governance | | | | | | |
Coverage: named seats ___ / total seats ___ = ___% (after merging seats held by one person)
Questions for the champion (one per placeholder):

How do you score formal power and veto risk?

Formal power is whether a seat can approve spend or sign. Veto risk is whether it can stop the purchase at this product's risk tier. Score each from 1 to 3, and the two scores together set the first-touch order.

The scales are my method:

• Formal power 3: signs or owns the budget. 2: approves within a gate (finance, procurement, the tier's security approver). 1: recommends or evaluates.
• Veto risk 3: can block alone at this tier. 2: can delay the purchase or force rework. 1: advisory only.

Set the tier from the data, not from the contract value. The Open Security Architecture pattern on third-party risk names this as a known failure: "Risk tiering is based on contract value rather than data sensitivity and system criticality." Nobody has published a contract-value threshold above which security review becomes mandatory. If you cannot tell what the product will touch, one third-party risk guide says a vendor whose access is "Unknown" should start in Tier 1, critical. Once the tier is set, the approval ladder tells you who scores 3 on veto risk: the CISO at high risk, the risk committee at critical.

Veto seats matter more than headcount suggests because buyer teams disagree. Gartner, via a secondary source, reports that 74% of B2B buyer teams show unhealthy conflict during the decision. Objections from a veto seat you never spoke to are where that conflict tends to land.

The first-touch order follows from the quadrants:

1. First: the confirmed, fresh operator seat with the highest score, usually the technical owner or a user lead. In one published summary of buyer research, 78% of buyers making purchases of $10 million or more ran a trial first, and operators are the people who run trials.
2. Second: the economic buyer, with the business case.
3. Third, on Tier 1 or Tier 2 purchases or any product with AI features: the hard-veto seat, with documentation rather than a pitch.
4. Last: finance and procurement. They tend to join as a deal progresses, so an early touch adds little.
5. Never: a cold opening message to a pure veto seat.

Sources disagree about when veto seats engage. One framework puts security questionnaires in the validation stage, alongside compliance documentation, customer references, and contract negotiation. The AI third-party risk guidance tells buyers to engage those teams early. Gartner describes buying as non-linear, with buyers often looping back and forth between stages. My resolution: map the veto seats on day one for every purchase, and touch them early only when the tier is 1 or 2 or the product has AI features.

What does coverage tell you, and when is a placeholder good enough?

Coverage is the number of seats with a named person divided by the total number of seats, after merging seats that one person holds. It measures how much of the decision you can see before contact. It does not measure how likely you are to win.

The multithreading evidence is real, but none of it gives a pre-contact target. Multithreading means having relationships with more than one person in the buying group.

Gong Labs found that 77% of deals involve multiple contacts, and that large strategic deals won by reps involve an average of 17 contacts. All of these were counted after the outcome was known. Nobody has published a coverage band for the stage before contact.

My working rules:

• Count seats, not contacts.
• A seat counts as named if it is confirmed or inferred. Placeholders do not count toward coverage.
• Do not hand off unless the economic buyer and technical owner are both named. Beyond that, I aim for at least four named seats. That echoes the four-contact rules at Gong and Mintel, though those rules counted contacts in live deals, not seats before contact.
• Worked example: a 10-seat map with six named seats has 60% coverage.

How does buying-group mapping go wrong?

Most failures come from treating a signal as proof of something it does not prove. The usual results are a confident map with the wrong person in a veto seat, or a high coverage number that hides seats nobody looked for. Each failure below has a check you can run in under a minute.

1. Contact counts used as a target. The Gong figures were counted after the outcome, and deals that are already winning pick up people near the end: finance asks about payment terms, legal reads the contract, procurement wants three quotes. The false positive is five names added to a dying deal so it looks multithreaded. Check: count filled seats, not contacts.
2. The hiring-team box taken as the reporting line. The person shown is usually the recruiter working the role, and only sometimes the hiring manager. Check: compare the box against the posting's "report to" line.
3. No hiring-team box read as "no hiring manager". The box is opt-in. If the poster opts out, their profile does not appear on the job page. Check: absence proves nothing, so fall back to the "report to" line.
4. Security tier guessed from contract value. A small AI deal that touches personal data can still be Tier 1, with the CISO or a risk committee holding the veto. Check: set the tier from the data the product touches.
5. Procurement mapped as the security gate. Third-party risk reports to procurement at only 6% of organizations. Check: treat procurement and third-party risk as separate seats unless evidence merges them.
6. The AI-governance seat left empty because no title matches. Only 17 US profiles in Refolk's index carry the title. Check: fill the seat with the privacy, risk, or legal owner of record and mark it as a placeholder.
7. A "confirmed" seat that is already stale. Profile data trails real job changes by about three months. Check: confirm against a dated primary document, not a current-looking profile.
8. The UK CISO seat counted separately from the CTO seat. At smaller companies one person often holds both, as the "CTO | CISO" titles in Refolk's UK sample show. Check: deduplicate before computing coverage, or a 60% map is really 50%.

The pattern behind most of these failures is the same. Pre-contact signals are richest for the people who are easiest to see, and thinnest for the people who can say no. Seat-first mapping exists to correct that imbalance, so treat any map where every veto seat is a placeholder and every operator seat is confirmed as half finished, and not as a finished map that happens to look healthy.

Before handoff, and keeping the map current

Run the checklist below before passing the map to whoever writes the first touch. Then re-verify on a fixed cadence, because the map starts going stale the day you finish it.

The roughly 30-day re-verification interval is my own estimate, based on the role-change and detection-lag figures above. It is not a published standard. For UK accounts, where roles changed at 1.73 times the US rate in that study, I re-check sooner. The cheapest way to re-verify is to re-run the same functional query in Refolk for each seat whose evidence has aged, and compare the names against your dated sources.

Two events should trigger a re-map, not just a re-verify. The first is a change to your own product. One procurement risk guide says new AI features, model swaps, and changes to data use should trigger a new review on the buyer's side, which reopens the security, privacy, and AI-governance seats. The second is a change in the purchase spec itself, such as a new integration, a new department, or a different paying budget. Either one can add seats, so start again at step 2 rather than editing the old map.