- Working definition: Territory Viability needs a published definition, population, evidence source, owner, operating consequence, effective date, and review condition.
- Business purpose: Territory Viability makes one territory-design decision inspectable instead of allowing the current assignment or loudest stakeholder to become the rule.
- Mechanics: Define the signal, calculation, denominator, comparison population, source date, and acceptable range in advance before interpreting the result.
- Operating context: Use Territory Viability during planning, scenario review, activation, and material in-year changes while keeping current and proposed states separate.
- Practical test: Recalculate Territory Viability for one territory, then trace the result to its account-level inputs, missing values, locks, and comparison group.
- BoogieBoard doctrine: Publish the Territory Viability standard before reviewing assignments so its tradeoffs remain visible and the approved sequence cannot be reverse-engineered from preferred outcomes.
What is Territory Viability?
Whether a territory can support the role, quota, workload, and coverage motion assigned to it, with the definition, owner, evidence, and review timing published before assignments are approved. It becomes operational when the population, source evidence, owner, and consequence are explicit enough for another reviewer to reproduce.
The scope of Territory Viability begins with the decision it supports. In the design & equity context, that decision should define a territory decision that planners, leaders, managers, and sellers can inspect against a published standard. Its definition should exclude adjacent decisions that use different evidence, owners, or consequences.
A complete Territory Viability definition names the signal, unit, calculation, denominator, comparison population, source date, missing-value treatment, and acceptable range. Without those choices, a precise result can still be impossible to reproduce or interpret.
The nearest concepts are Balance Goal, Balance Attribute, Account Locking Criteria, Territory Logic. Keep their boundaries explicit so changing evidence for one concept does not quietly rewrite the policy or calculation represented by Territory Viability.
Inputs and measurement for Territory Viability
Start with governed account data, role definitions, Territory Logic, Balance Goals, Account Locking Criteria, and a dated Current State Scenario. Record the field or policy owner, source date, transformation, comparison population, and correction path. If any required input is unavailable, mark the limitation rather than filling it with an undocumented proxy. That preserves the difference between observed evidence and planning judgment.
Capacity Plan: How will you define Territory Viability? ➡️ Territory Plan: How many ICP accounts does the Territory need to have?
Preserve the current calculation of Territory Viability before testing a future scenario. Compare like populations, then open the records behind the highest, lowest, and most surprising values. A territory-level difference identifies where to investigate; it does not explain the cause on its own.
The review package for Territory Viability should retain the input fields, calculation version, excluded records, distribution by territory, and account-level values behind each summary. Record whether the measure is a design objective, a constraint, or a diagnostic signal. That distinction determines whether it can drive account movement or should only prompt further investigation. Before approval, ask a reviewer outside the original design team to reproduce the Territory Viability result or decision from that retained evidence.
A worked Territory Viability example
Suppose four comparable territories contain 520 in-scope accounts. The team defines the Territory Viability input, freezes the source date, and calculates the result for each territory. The lowest result is 79 and the highest is 121. That spread is a review signal, not automatic proof that one territory is unfair.
Reviewers open the account roster behind both values. They check whether the difference reflects real variation in territory viability, a stale or missing source field, an approved lock, or a population that should not have been compared. They then model a future scenario and record which accounts moved, which remained locked, and how the other Balance Goals changed.
The team accepts the scenario only when it can state the calculation, denominator, comparison group, source date, and acceptable variance in plain language. If improving Territory Viability creates an unacceptable loss in workload, customer continuity, or another priority, the tradeoff remains visible rather than being hidden inside a composite score.
How to interpret Territory Viability
Interpret Territory Viability only within a defined comparison population. Publish the numerator, denominator, units, source date, missing-value treatment, and acceptable variance. A precise result without those choices is not reproducible and should not be used to justify account movement.
Use the measure to reveal a tradeoff, then inspect the records behind it. Do not optimize Territory Viability in isolation or combine unlike roles and motions merely to simplify reporting. Test whether improvement persists after locks, data corrections, and customer obligations are applied.
Review Scenario, Current State Scenario, Territory Health, Territory Equity alongside Territory Viability. Together they show whether the metric represents a useful Balance Goal, a supporting attribute, or only a diagnostic signal that should remain visible without controlling the model.
Territory Viability data rules and pitfalls
The primary Territory Viability failure is letting a preferred assignment determine the rule after stakeholders have already seen the result. Prevent it by publishing the definition and decision sequence before individual assignments are reviewed, then evaluate proposed changes across the full affected population.
Another failure is treating Territory Viability as an objective to maximize without checking what moved underneath it. Recompute the result, inspect missing values and outliers, and compare other Balance Goals before accepting the scenario.
Review Territory Viability on the planning cadence and whenever its source, calculation, denominator, comparison population, or business hypothesis changes. Retain historical values so the team can test whether the measure predicted the outcome it was intended to represent.
In practice with BoogieBoard
For Territory Viability, the relevant BoogieBoard workflow is scenario-level Balance review backed by the account roster. BoogieBoard's Balance workflow displays multiple territory measures in the same Scenario Result, so reviewers can compare the complete tradeoff instead of relying on one combined score. A planner can preserve the Current State Scenario, change a goal or constraint, inspect the territory-level result, and then open the account roster behind an unexpected value. Approved locks remain visible while the movable population changes. This makes the concept reviewable before activation and gives managers evidence for why one scenario was selected over another.
