- Working definition: Hierarchy Logic needs a published definition, population, evidence source, owner, operating consequence, effective date, and review condition.
- Business purpose: Hierarchy Logic makes one territory-design decision inspectable instead of allowing the current assignment or loudest stakeholder to become the rule.
- Mechanics: Publish the covered population, evidence standard, decision owner, approver, effective timing, exception path, and review cadence in advance.
- Operating context: Use Hierarchy Logic during planning, scenario review, activation, and material in-year changes while keeping current and proposed states separate.
- Practical test: Apply Hierarchy Logic to one disputed account and distinguish a data correction, a policy exception, and a proposed change to the standard.
- BoogieBoard doctrine: Publish the Hierarchy Logic standard before reviewing assignments so its tradeoffs remain visible and the approved sequence cannot be reverse-engineered from preferred outcomes.
What is Hierarchy Logic?
Hierarchy Logic defines how parent, child, branch, brand, portfolio, and other account relationships affect territory placement and ownership, 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 Hierarchy Logic 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 Hierarchy Logic definition names the covered population, evidence standard, decision owner, approver, effective timing, exception criteria, expiration or review condition, and the operating consequence of the decision.
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 Hierarchy Logic.
What Hierarchy Logic includes
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.
Developing too much custom Hierarchy Logic: Available hierarchy data is imperfect. It’s hard to define types of hierarchies and know how buying decisions are made. Trying to perfectly identify all Account hierarchies is a recipe for wasted time and unnecessary complexity. - Enriching too many accounts: Aiming for a perfectly enriched Total Addressable Market in CRM wastes time and money on accounts that will not be utilized.
Apply Hierarchy Logic to the complete affected population before reviewing individual preferred outcomes. Preserve the current state, classify each challenge as a correction, exception, or policy proposal, and record the approved future treatment with its effective date and decision history.
The decision record for Hierarchy Logic should retain the request, governed evidence, policy result, reviewer, approver, effective date, and any expiration or reconsideration condition. Report corrections, exceptions, and policy changes separately. Combining them in one exception count hides whether the underlying problem is data quality, inconsistent administration, or an outdated standard. Before approval, ask a reviewer outside the original design team to reproduce the Hierarchy Logic result or decision from that retained evidence.
A practical Hierarchy Logic example
The team applies Hierarchy Logic to a dated territory scenario only after publishing its definition and affected population. It keeps the current state intact, models the proposed rule across every comparable account, and identifies records excluded by an approved lock or exception.
Reviewers compare the summary result with the underlying account roster. They inspect one expected outcome and one surprising outcome, tracing the source evidence, hierarchy, Territory Logic, Balance Goals, lock status, and proposed assignment. A result that cannot be explained at account level is not ready for approval.
The approved scenario records before and after assignments, effective timing, exceptions, and rollback instructions. After activation, the operating state is reconciled to the approved model so Hierarchy Logic remains a governed part of territory design rather than a label applied after decisions were made.
How Hierarchy Logic relates to territory planning
Hierarchy Logic may vary by segment, role, customer motion, geography, product, and planning stage when the business reason is published. Each population still needs an internally consistent standard and a clear explanation of why its treatment differs.
Test the rule against ordinary cases, edge cases, vacancies, and material in-year changes. Review both the summary outcome and underlying account roster. The standard should remain usable when the original planner is no longer present to explain it.
Review Scenario, Current State Scenario, Territory Health, Territory Equity alongside Hierarchy Logic. Preserve their distinct definitions and show the dependency between them so a correction to evidence does not quietly become a policy exception or assignment preference.
Hierarchy Logic operating rules and pitfalls
The primary Hierarchy Logic 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 confusing a correction with an exception under Hierarchy Logic. A correction changes governed evidence; an exception accepts the evidence but authorizes different treatment for a documented reason, approver, and period.
Review Hierarchy Logic on the formal policy cadence and after material exceptions. Monitor unresolved requests, recurring exception reasons, expired approvals, and differences between the approved and live states; repeated exceptions may indicate that the published standard needs revision.
In practice with BoogieBoard
For Hierarchy Logic, 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.
