- Working definition: A Holdover Policy allows a prior owner to retain qualifying responsibility temporarily after a future territory model takes effect.
- Business purpose: Holdovers protect legitimate in-flight work and rep agency without allowing temporary exceptions to quietly replace the approved future model.
- Mechanics: The policy defines eligibility, required evidence, approval authority, effective date, expiration, extension rules, final ownership, and ongoing reporting responsibility.
- Operating context: Holdovers are evaluated after Balance Goals, Account Locking Criteria, approved locks, and the future Scenario have already established the durable design.
- Example: A qualified late-stage opportunity might stay with its prior seller for 90 days after go-live, then transfer unless an approved extension applies.
- BoogieBoard doctrine: Durable continuity belongs in account locking. A holdover is a narrow, time-boxed bridge, and less is usually more.
What is a Holdover Policy?
A Holdover Policy is a set of rules allowing a prior seller or team to keep temporary responsibility for a qualifying account or opportunity after a new territory model becomes effective. It protects legitimate work in progress while preserving a clear path to the approved future owner.
The same concept may be called a sales territory holdover policy or account holdover policy. The canonical term remains Holdover Policy because the rule can govern accounts, opportunities, renewals, or another defined object.
The policy is an exception mechanism, not a second territory model. Without explicit limits, a company can announce new assignments while revenue work remains concentrated in the old structure. The change is technically complete but operationally false.
A qualifying item is often called a Holdover Opportunity. Some organizations also allow account-level holdovers, but that broader exception requires more caution because it can transfer pipeline, relationships, renewals, and future opportunity together.
Holdovers belong late in the planning sequence. The team first defines Balance Goals, sets Account Locking Criteria, applies durable locks, and approves the future Scenario. Only then can it evaluate which temporary exceptions are genuinely needed.
What must a Holdover Policy include?
A usable policy names the decision fields another reviewer needs to reproduce the outcome:
| Policy field | Required decision |
|---|---|
| Eligible object | Opportunity, account, renewal, or another governed record |
| Qualification | Stage, status, value, activity, relationship, or timing threshold |
| Evidence | CRM fields, customer commitment, manager context, or other required proof |
| Requestor and approver | Who may ask and who makes the final decision |
| Effective date | When temporary responsibility begins |
| Expiration date | When the exception ends without further approval |
| Extension rule | Evidence and authority required to continue the exception |
| Final owner | Who receives responsibility after expiration |
| Reporting owner | Who monitors open, expired, transferred, and extended holdovers |
The thresholds should match the business. "Any open opportunity" is usually too broad because weak or stale pipeline can qualify as easily as a real customer commitment. A late-stage opportunity with documented next steps may justify continuity. An untouched opportunity created months ago usually does not.
Every field should have one source of truth. If the stage, value, owner, and expiration live in separate spreadsheets or messages, the organization cannot reliably enforce the policy or explain exceptions.
How does a Holdover Policy work in practice?
Assume a new territory model goes live on January 1. The company allows a seller to retain a Stage 3 or later opportunity above its materiality threshold for up to 90 days, subject to manager and RevOps approval. The numbers are illustrative; they are not universal standards.
The workflow is:
- The seller submits the opportunity before the request deadline.
- The manager confirms customer activity, next steps, stage, and commercial value.
- RevOps checks the request against the published criteria and verifies the future owner.
- The approver accepts or denies the request and records the reason.
- An approved holdover receives a January 1 effective date and March 31 expiration date.
- On expiration, responsibility transfers to the future owner unless an extension is approved through the same evidence-based process.
The reporting view should show requests, approvals, denials, current owner, future owner, duration, expiration, extensions, and final disposition. It should also separate data corrections from policy exceptions. Fixing an incorrect stage is not the same decision as waiving the stage requirement.
This workflow gives the seller a legitimate voice without turning every request into side-channel lobbying. The rule, evidence, and approver remain visible to everyone affected by the change.
How is a holdover different from an account lock?
An account lock is a durable planning constraint. A holdover is a temporary transition exception.
Account Locking Criteria identify accounts that should remain with their current territory before modeling begins. Common reasons include active opportunities, near-term renewals, strategic relationships, complex implementations, or recent ownership changes. Approved locks do not enter the Movable Book.
A holdover begins after the future model has been approved. It says the future owner is correct, but responsibility should transition later because a qualifying event is already in motion. That creates two changes: the organization activates the future model, then completes a later handoff through a Staged Account Transfer.
Use a lock when continuity should be part of the durable design. Use a holdover when the future assignment is right but temporary continuity has greater value than an immediate handoff. If the same account repeatedly receives extensions, the team should ask whether it chose the wrong mechanism or approved the wrong future owner.
What makes a Holdover Policy fail?
The first failure is broad eligibility. If every open opportunity qualifies, the policy protects old ownership rather than legitimate work. The second is missing expiration. An exception without an end date is an undocumented assignment rule.
The third failure is using holdovers as the only channel for seller input. Rep agency belongs upstream too: sellers should help identify target-account logic, data problems, Balance Attributes, and proposed locks before the design is finalized.
The fourth is ignoring the cost to the receiving territory. A holdover can delay pipeline, revenue, customer context, and capacity for the future owner. Review the complete territory rather than treating the exception as free.
Finally, govern extensions. An extension should require new evidence and a named approver, not passive rollover. Track the volume and duration of holdovers as part of Disruption and transition review. If holdovers cover a large share of the changed book, pause and ask whether the future model is actually ready.
In practice with BoogieBoard
BoogieBoard's Account Locks workflow helps teams make durable continuity decisions before optimization. Approved locks remain visible while the rest of the design pool can move, so reviewers can see both the protected relationships and the balancing tradeoffs they create. Scenario comparison and audit trails preserve who reviewed the decision and how the future book changed. Managers can inspect the protected accounts before approving the future Scenario instead of discovering continuity exceptions after activation. Use the Holdover Policy and the operating system of record to govern temporary evidence, expiration, extensions, and final transfer.
