How do we build a competitive taxonomy that scales across multiple deal types and buyer personas?

Two ways to structure it: one weighted core versus a family of segment-specific taxonomies

Every RevOps team that tries to make competitive intelligence useful across multiple deal types eventually hits the same fork in the road, and the choice you make here determines whether your competitive data is still trustworthy in eighteen months.

Option A — the layered core with conditional extensions. You define one schema that every deal, every persona, and every region shares. Three tiers sit at the base: who you were up against (competitor identity), why the buyer chose them (a closed reason code), and the context of the decision (persona seniority, deal size band, vertical, company stage). Enterprise deals get extra fields turned on — compliance certifications, implementation timeline commitments, integration ecosystem depth, SLA tier — but those fields are conditional, not a separate table. An SMB deal sees five to eight attributes; an enterprise deal sees fifteen to twenty. Same taxonomy, different visibility rules. Queries slice across the whole dataset because everything shares a spine.

Option B — the segment-specific taxonomy family. You build one taxonomy for enterprise, one for mid-market, one for the PLG self-serve motion, and maybe one per vertical if you're in healthcare or fintech. Each is tuned tightly to how that segment actually buys. The enterprise taxonomy names procurement-committee dynamics; the SMB one names credit-card friction. Nobody has to look at fields that don't apply to them, and each team owns their own structure.

Option B feels better on day one and fails on roughly the same schedule every time. Three failure modes show up in sequence. First, cross-segment questions become unanswerable — you cannot ask "is Competitor_A winning more overall, or just moving downmarket?" because there is no shared key. Second, reason codes drift: enterprise calls it timeline_risk, mid-market calls it slow_implementation, and after two quarters nobody can merge them without a manual mapping table that itself needs an owner. Third — and this is the one that kills it — reps who work across segments (which is most reps at companies under $50M ARR) have to remember which taxonomy applies to which deal, so they pick the closest-looking option and tag inconsistently.

Option A costs more design work upfront. You have to argue about reason codes in a room with product marketing, sales enablement, and RevOps present, and that argument takes two or three sessions rather than one. What you get back is a dataset that answers questions you didn't think to ask when you built it.

There is a middle path worth naming, because larger organizations end up there whether they plan to or not: the hub-and-spoke. A global core taxonomy is owned centrally and frozen except at quarterly review. Regional or product-line teams maintain *extensions* — additional values inside existing fields, never new fields — and those extensions get reviewed at the same quarterly cadence. EMEA can add data_residency_eu as a reason code without inventing a parallel schema. This works when you have genuinely different competitive sets per region or product line and the central team has the discipline to reject new *fields* while accepting new *values*.

The adjacent decision worth flagging: this same fork appears in churn taxonomy, win/loss reason coding, and lead-source attribution. Teams that solve it once for competitive intelligence usually copy the pattern into all three, and that consistency is worth more than any individual schema's elegance. A shared vocabulary for "why did this deal go the way it went" spanning acquisition and retention is the closest thing RevOps has to a unified theory of revenue leakage.

How to decide between them

The decision is not about company size in headcount. It's about three specific structural facts, and you can answer all three in an afternoon.

Fact one: rep overlap. Pull your CRM and calculate what percentage of reps closed deals in more than one segment last quarter. If it's above roughly 30%, segment-specific taxonomies will be tagged inconsistently no matter how good your enablement is — cognitive switching cost is real and reps optimize for speed at close. Above 30% overlap, take Option A.

Fact two: competitor overlap. List the top five competitors by loss frequency in each segment. If the same names appear in three or more segments, you need a shared spine, because your executive team will ask cross-segment questions about those competitors and you need to be able to answer. If each segment faces a genuinely disjoint competitive set — which happens when you sell a self-serve tool downmarket and an enterprise platform upmarket, effectively two products — the hub-and-spoke is defensible.

Fact three: analysis headcount. Who actually runs the queries? If it's one competitive intelligence lead or a single RevOps analyst, one taxonomy is the only maintainable answer. Segment-specific taxonomies require per-segment analytical owners, and if you can't name a human for each one, they will decay.

One more filter, cheap and revealing: the thirty-second test. Put your draft taxonomy in front of three to five reps, hand them a mock deal, and time how long it takes them to name the top three likely competitors and each one's primary weakness. If it takes longer than thirty seconds of glancing at the structure, the taxonomy is too complex regardless of how correct it is. Complexity that survives design review dies in the field, silently, and you find out six months later when you notice half your loss records are tagged Other.

The numbers that actually make each option work

Design decisions in taxonomy work are mostly about counts and thresholds, so here are the ones that matter and why each has the value it does.

Attribute counts by deal type. Enterprise evaluations run through a formal matrix with multiple stakeholders, so fifteen to twenty attributes is defensible — pricing model, compliance certifications, integration ecosystem, SLA tier, implementation timeline, professional services model, data residency, security review posture, and so on. Each one is something a procurement committee actually scores. Mid-market and SMB deals compress to five to eight: product category, target buyer role, primary differentiator, pricing tier, and one or two vertical-specific fields. The core set that applies universally should be four fields at most, because that's what a rep can hold in working memory while on a call.

Frequency thresholds for action. This is where most taxonomies go wrong — they collect data and never define what triggers a decision. Set explicit thresholds and publish them. A reason code appearing twice in a segment is *monitor*: note it, watch the next cycle. Three appearances is *action*: it goes on the agenda for the product/sales/RevOps review. Four or more appearances of a single competitor in a single segment is a *roadmap signal* — it goes to product with a named owner and a decision date. Without thresholds, everything looks like noise or everything looks like a crisis, depending on who's presenting.

Competitor tiering by loss share. Split your competitor list three ways. Primary competitors appear in 20% or more of losses — these get full battlecards, objection-handling scripts, and quarterly deep dives. Emerging threats appear in 5–10% and are tracked with a trend line, not a battlecard; the question is whether the number is climbing quarter over quarter. Everything below that is noted in the record but never optimized against, because building a battlecard for a competitor you saw once is how enablement libraries become unusable.

Sample size for a quarterly refresh. You need roughly 40+ tagged loss interviews per cycle to run meaningful segment queries. Below that, a single segment slice (persona = Director+, vertical = Healthcare, deal size > $100K) returns four or five records and you'll draw confident conclusions from noise. If you're not closing enough deals to hit 40 losses a quarter, run the review semi-annually instead of quarterly rather than pretending a six-record slice is a trend. Volume, not calendar, should drive the cycle.

Persona weighting. Rather than building separate persona taxonomies, weight the same fields differently. A rough starting point for enterprise: security and compliance at ~40%, integration ease at ~20%, total cost of ownership at ~20%, time-to-value at ~20%. For SMB those roughly invert — time-to-value and TCO dominate, compliance drops to a gate rather than a differentiator. These weights are starting hypotheses, not truths; the point of tagging losses is to correct them with your own data by the second quarter.

Decay window. An ungoverned taxonomy degrades in six to twelve months. That's not a hard law but it's a reliable pattern: new competitors enter, feature parity shifts, your own deal mix moves, and the fields that made sense at design time start collecting Other. Watching the percentage of records tagged Other is the single cheapest health metric you have. When Other crosses 15% on any field, that field needs new values or needs to be retired.

Query count. Six to eight standing segment queries is the right number. Fewer and you're not covering your segment matrix; more and nobody runs them all, so they get skipped and the discipline collapses. Write them once, save them, run them on the same day every month.

Building it: schema, tagging, and the sequence that gets adoption

The implementation order matters more than the schema's cleverness, because a taxonomy nobody tags is worth nothing regardless of design quality.

Start with the tag structure, not the analysis. Define the CRM fields before you define the reports. A workable base schema uses picklists — never free text — on every field:

competitive_vendor: [Competitor_A | Competitor_B | Competitor_C | Competitor_D | None] competitive_reason: [price_lower | timeline_faster | feature_built_in | support_tier | vendor_lock | proof_point_case] buyer_persona: [IC | Manager | Director | VP | C_Suite] deal_size_band: [under_10k | 10_50k | 50_250k | over_250k] vertical: [Tech | Healthcare | Financial | Retail | Other] company_stage: [Startup | Growth | Mid_market | Enterprise]

Free-text competitor names are the most common single point of failure. "Competitor A", "CompetitorA", "comp a", and "Competitor A Inc" are four rows in your pivot table and one company in reality. Picklist everything, and put the "request a new value" path behind the steward rather than letting reps add values inline.

Make the reason code mutually exclusive and force a primary. Buyers give you three reasons; your rep records all three; your analysis now double-counts. Capture a required *primary* reason and an optional multi-select of *contributing* reasons. All threshold logic runs on primary only. This single rule fixes more analytical confusion than any other schema decision.

Add the persona lens as a view, not as data. The same underlying record should render differently depending on who's looking. Build a "Persona Lens" toggle in whatever surface reps use — CRM view, competitive intel tool, enablement portal — that reorders competitor strengths and weaknesses by the persona selected. The data doesn't change; the sort order does. This is what lets you serve a technical buyer and an economic buyer from one dataset without maintaining two.

Sequence the rollout so early value is visible. Month one: collect and tag 40+ loss interviews. Don't build reports yet; you have nothing to report on. Week three of month one: run your six to eight standing segment queries for the first time. Week four: hold a product/sales/RevOps review on segment-specific threats — this is the meeting that determines whether the taxonomy survives, because it's where sales sees their tagging turn into a roadmap decision. Month two: update roadmap, pricing, and messaging on what the queries found, and tell the reps explicitly which change came from which tag. Attribution back to the field is the entire adoption mechanism.

Version everything. Tag each taxonomy iteration with a date and a change log. Without version control, historical competitive analysis stops being comparable — you cannot tell whether timeline_faster losses tripled or whether you just split one old code into two. The change log should record what changed, why, and who approved it. Three lines per change is enough.

Close the loop from the field. Give reps a one-click way to flag an attribute as outdated or to request a missing one, right from the record they're tagging. Route those flags to the steward's queue. Most will be noise; the 10% that aren't are your earliest signal of a new competitor or a shifted buying criterion, and they arrive months before the aggregate data shows it.

Where taxonomy work touches the rest of the revenue stack

The competitive taxonomy isn't a standalone artifact, and treating it as one is why it often gets built, admired, and abandoned. It's a join key into three adjacent systems.

Upstream: discovery and qualification. If your taxonomy names six reason codes, your discovery framework should be asking questions that surface those six things early. When timeline_faster is your top loss reason in enterprise healthcare, the implementation-timeline conversation belongs in the second call, not the eleventh. The taxonomy tells you what to ask; the qualification framework carries it. Teams that update one without the other end up with beautifully tagged losses and no change in outcomes.

Downstream: pricing and packaging. Reason codes map almost one-to-one onto packaging decisions. feature_built_in — meaning the competitor includes something you charge for — is a packaging problem, not a sales problem, and no amount of objection handling fixes it. price_lower at a consistent 20%+ gap in one segment is a pricing-tier question. Routing these to the right owner is half the value of having the taxonomy at all; the other half is preventing sales from being blamed for a product gap and product from being blamed for a discounting habit.

Sideways: churn and renewal taxonomy. The categories that explain why you lose new deals overlap heavily with why you lose renewals — competitor displacement, feature gap, price pressure, support quality. Using the same vocabulary in both lets you ask whether a competitor is beating you at acquisition, at renewal, or both, which is a materially different strategic picture. A competitor that only wins new logos is a positioning problem. One that also takes renewals is a product problem.

Adjacent motions worth the same treatment. Partner-influenced deals, procurement-led RFPs, and marketplace transactions each have competitive dynamics your core schema may not capture. Resist creating separate taxonomies for them. Add a motion_type field to the context tier and let the same reason codes carry through. If a reason genuinely doesn't exist elsewhere — marketplace_billing_preference, say — add it as a value, gated behind the steward, and see if it survives two quarters.

Governance is the difference between a taxonomy and a spreadsheet. Name a steward — usually product marketing or a competitive intelligence lead, occasionally RevOps. Give them a quarterly review against three signals: new competitor entrants or major feature releases, shifts in your own deal-type mix, and enablement feedback on fields that are never used or consistently misread. That third signal is the most valuable and the most ignored. A field with 90% Other isn't collecting data; it's collecting shrugs, and every quarter it survives teaches reps that tagging doesn't matter.

Tooling scales with you, and starting simple is fine. A spreadsheet works for an early-stage team with one analyst and forty deals a quarter. As volume grows, move to CRM custom fields with proper picklists, or a dedicated competitive intelligence platform if you're maintaining battlecards at the same time. The requirement isn't sophistication — it's that the taxonomy be searchable, filterable, and reachable inside the tool reps already have open during a live deal. Static documents in a shared drive are where taxonomies go to become historical artifacts.

Measure whether it's working. Two proxies are practical. Track win rate on deals where competitive intel was pulled versus where it wasn't — imperfect, since reps pull intel on harder deals, but directionally useful over enough volume. And survey reps on time-to-find: how long does it take to get the competitive positioning they need? If that number is climbing, the taxonomy is growing faster than its usability. A third signal, cheaper than both: watch the Other percentage on every field, every month. It's the most honest metric you have, because it measures what reps do rather than what they say.

Related questions

How is a competitive taxonomy different from a battlecard?

The taxonomy is the data structure — the fields and values you tag every deal with. The battlecard is content generated from it for a specific competitor. Taxonomy tells you which battlecards to build and when they're stale. Build the taxonomy first.

What if we have fewer than 40 losses a quarter?

Run the review semi-annually instead of quarterly, and widen your segment slices. Don't draw conclusions from five-record queries. Supplement with won-deal interviews, which surface competitive dynamics too and roughly double your sample.

Who should own the taxonomy — product marketing or RevOps?

Product marketing usually owns the *content* (what the reason codes mean, competitor positioning). RevOps owns the *plumbing* (CRM fields, picklist hygiene, query maintenance). One named steward on the content side, one on the systems side, and a standing quarterly meeting between them.

Can we use AI to auto-tag loss reasons from call recordings?

Increasingly yes, and it helps with volume — but auto-tagging into free-text kills your picklist discipline. Constrain any automated tagger to your existing closed value set, and audit a sample every cycle against human-tagged records before trusting the output.

How many reason codes is too many?

Past roughly ten primary reason codes, reps stop reading the list and pick from the top three. Keep primary reasons under ten. Use the contributing-reasons multi-select for nuance rather than expanding the primary picklist.

FAQ

What is a competitive taxonomy in the context of deal types and buyer personas?

A structured framework that categorizes competitors, the reasons buyers choose them, and the context in which those decisions happen — persona seniority, deal size, vertical, and company stage. It exists so that "we lose to Competitor_A" becomes "we lose enterprise healthcare deals over $150K to Competitor_A on implementation timeline," which is a sentence someone can act on.

How do you keep one taxonomy usable across very different deal sizes?

Conditional fields. Define a small universal core — four or so attributes every deal carries — then turn on extended attributes only for deal types that need them. An SMB record shows five to eight fields; an enterprise record shows fifteen to twenty. Same schema, same reporting spine, different visibility rules by deal type.

What role do buyer personas play without creating persona-specific taxonomies?

Personas change which attributes *matter*, not which attributes *exist*. Tag the same fields on every deal, then apply persona weighting when you surface the data — a technical buyer sees integration and security ranked first, an economic buyer sees TCO and time-to-value. One dataset, multiple lenses. Separate per-persona taxonomies become maintenance nightmares within two quarters.

How often should the taxonomy be updated?

Review quarterly, but trigger an off-cycle update whenever a major competitor changes pricing, launches a significant product, or visibly shifts target segments. Involve sales in every review — they see new entrants first. Keep a change log with date, what changed, and why, so historical analysis stays comparable across versions.

What tools work best for managing this?

Start with a spreadsheet if you're early. Graduate to CRM custom fields with strict picklists as volume grows, and to a dedicated competitive intelligence platform once you're maintaining battlecards alongside the data. The non-negotiable requirement is that it's searchable and filterable from inside whatever tool reps have open during a live call.

How do we know it's actually helping?

Watch three things: the percentage of records tagged Other on each field (rising means decay), rep-reported time-to-find competitive intel, and win rate on deals where intel was pulled versus not. The Other metric is the most honest, because it measures behavior rather than opinion and costs nothing to compute.

Sources

• Gartner Sales Research — https://www.gartner.com/en/sales/research
• Forrester Research — https://www.forrester.com/research/
• Harvard Business Review — https://hbr.org/topic/subject/competitive-strategy
• Pragmatic Institute — https://www.pragmaticinstitute.com/resources/
• Salesforce Developer Documentation, picklist and record type design — https://developer.salesforce.com/docs
• HubSpot Knowledge Base, custom properties — https://knowledge.hubspot.com/properties/create-and-edit-properties
• SBI (Sales Benchmark Index) — https://sbigrowth.com/insights
• U.S. Small Business Administration, market research and competitive analysis — https://www.sba.gov/business-guide/plan-your-business/market-research-competitive-analysis

Related on PULSE

• [How do you categorize and score churn types (product, price, competitor, organizational)?](/knowledge/q523)
• [What content should marketing create to help sales close specific deal types, and how do we avoid shipping content sales never reads?](/knowledge/q687)
• [How do I build a deal-coaching practice that scales?](/knowledge/q716)
• [How do you build a renewal motion that scales in 2027?](/knowledge/q12278)
• [How do I measure sales efficiency at different ARR scales?](/knowledge/q101)
• [What coaching question helps a salesperson identify their most effective closing technique for different buyer types?](/knowledge/q14429)