Plan vs Plan Type vs Component
The confusion
Three words that sound like synonyms, describe three different levels of a hierarchy, and are used interchangeably in most comp conversations — including inside the companies that built the plans.
Ask a RevOps lead "how many plans do you have?" and you will get an answer somewhere between 4 and 40, depending entirely on which of these three things they thought you meant.
The hierarchy
What this means?
A plan type is authored once and assigned to many reps. A plan is what an individual rep signs. A component is what actually calculates money.
Get the levels confused and everything downstream breaks. "We changed the plan" could mean you re-authored a template affecting 40 reps, or adjusted one rep's quota, or altered a single accelerator rule. Those are three completely different blast radii, and they get logged in the same Slack message.
A worked hierarchy
One plan type. Three reps. Same shape, different numbers.
Tom's renewal rate was overridden for his territory. That is a change at the plan level, not the plan type — so it affects only Tom. If someone had made it at the plan-type level, all three reps would have been re-rated, and nobody would have noticed until payout.
Why the hierarchy matters for finance teams
Three questions become answerable only when the levels are distinct.
"What changed?" A component change at the plan-type level propagates to every rep on it. A component change at the plan level affects one. Without the distinction, every plan change is potentially company-wide, and audit means checking everyone.
"Who is on what?" Plan types are the unit of population. "How many reps are on the Enterprise AE plan type" is a real question with a real answer. "How many plans do we have" is not.
"Why was this rep paid differently?" Almost always because of a plan-level override on an inherited component. If overrides are invisible, this question takes a week.
Common mistakes
1. Using "plan" to mean all three levels
It is the single most common source of miscommunication in a comp implementation, and it starts in the first scoping call.
2. Editing a plan type to fix one rep
The change is correct for that rep and silently wrong for the other thirty-nine. In a spreadsheet, this is a Tuesday.
3. Not tracking overrides as overrides
An overridden component that looks identical to an inherited one is an unexploded audit finding.
How Visdum handles the hierarchy
Visdum models all three levels explicitly. A plan type is authored once with its components and assigned to a population. A rep's plan instantiates it with their own quota, OTE, dates, and any overrides — and overrides are visibly marked as overrides, not silently different values. A component calculates independently and is versioned in its own right. That means "what changed, for whom, and when" has a one-screen answer: a plan-type change shows you the affected population before you commit it, and a rep-level override shows you exactly one name.
Take a self-guided product tour →, or see how Visdum designs and explains plans.
Related terms
Plan Component · Sales Compensation Plan · Comp Plan Versioning · Rate Table · Implementation (ICM)
Calculate your OTE in 30 seconds
Frequently asked questions
What is the difference between a plan and a plan type?
A plan type is a reusable template defining the shape of compensation for a role — the components, rates, and rules. A plan is one rep's instance of that template, populated with their own quota, OTE, start date, and any overrides. One plan type typically has many plans hanging off it, which is why "how many plans do you have" is a question with no useful answer.
What is a plan component?
A single self-contained rule inside a plan that calculates one payout from one measure — new business commission, an accelerator, a renewal rate, a multi-year kicker, an MBO. A typical AE plan is four or five components running independently and summing to the rep's total variable pay.
Why does the plan hierarchy matter?
Because it determines blast radius. A component changed at the plan-type level propagates to every rep assigned to it. The same change at the plan level affects exactly one person. Without the distinction, every plan change is potentially company-wide, and auditing one adjustment means checking everybody.
What is a plan-level override?
A component whose value has been changed for one rep, diverging from the plan type they inherited it from — for example, a rep whose renewal rate is 6% while the template says 4%, because of their territory. Overrides are legitimate and common. The failure is when they are invisible, so an overridden component looks identical to an inherited one.
Can you change a plan type mid-year?
Yes, but it should be versioned with an effective date and you should be able to see the affected population before you commit. The classic spreadsheet failure is editing the template to fix one rep — a change that is correct for them and silently wrong for the other thirty-nine, discovered at payout.
How many plan types should a company have?
As many as you have genuinely distinct role motions — typically one per role and segment (SMB AE, Enterprise AE, SDR, AM, Sales Manager) rather than one per rep. If you find yourself creating a plan type for an individual, what you actually need is a plan-level override on an existing type.