---
name: territory-carve-impact-simulator
description: Simulate a proposed sales territory carve before it ships to reps. Evaluates the carve's assignment rules against the live account book, then reports coverage gaps, quota-capacity shortfalls, and named-account churn weighted by open pipeline and relationship tenure. Emits ready / revise / blocked — never an automatic rollout.
---
# Territory carve impact simulator
## When to invoke
Whenever someone has a drafted territory carve — a set of assignment rules, a rep roster, and an effective date — and nobody has yet checked what it does to coverage, capacity, and existing relationships. The canonical moment is two to four weeks before a fiscal-year or mid-year realignment, while the carve is still editable. Also valid: a single-segment carve (one pod, one region) that a sales leader wants to move ahead of the wider realignment, and an after-the-fact run against a carve that already shipped, to explain why a segment is missing plan.
Take a carve spec (`references/1-carve-input-template.md`), an org thresholds file (`references/2-coverage-thresholds-template.md`), and read-only Salesforce access. Produce the Markdown report in `references/3-sample-output-format.md`.
Do NOT invoke this skill for:
- **Generating a carve.** This skill scores a carve someone else designed. It does not propose rules, rebalance accounts, or search for an optimal split. If there is no draft carve, there is nothing to simulate.
- **Writing assignments back to Salesforce.** The skill is read-only on every object it touches. Territory changes are executed by the routing or territory-management system that owns them, after a human approves the plan.
- **Comp or quota-setting decisions.** The capacity report says whether a territory can carry the quota someone already assigned it. It does not set quota, and its output must not flow into comp calculations — that turns a planning tool into a negotiation instrument and the inputs start getting gamed.
- **Carves with no documented rules.** A carve that exists only as a spreadsheet of account IDs and rep names cannot be simulated against what the routing engine will actually do. Ask for the rules, or convert the spreadsheet into rules first and simulate those.
- **Books with untracked ownership history.** If `AccountHistory` does not record `OwnerId` changes, the churn report has no baseline and the skill returns `blocked` rather than a churn number that looks authoritative and is not.
## Inputs
- Required: `carve_path` — path to the carve spec (rules in declared priority order, rep roster, effective date). See `references/1-carve-input-template.md`.
- Required: `thresholds_path` — path to the org's thresholds and capacity model. See `references/2-coverage-thresholds-template.md`.
- Required: `sfdc_token` — Salesforce session token with read on `Account`, `AccountHistory`, `Opportunity`, `OpportunityHistory`, `User`, and `UserTerritory2Association`. Read-only is the correct scope; the skill must not write.
- Optional: `segment_filter` — restrict the simulation to one segment or region. Coverage gaps outside the filter are reported as informational, not as failures.
- Optional: `snapshot_date` — ISO date for the CRM snapshot. Defaults to the run date. Recorded in the output header and used to compute the re-run deadline.
- Optional: `dry_run` — boolean, default `false`. When `true`, the skill backtests the thresholds file's ramp curve against last year's new-hire cohort and reports the delta instead of running the full simulation.
## Reference files
Read all three from `references/` before computing anything. Without the thresholds file the skill has no definition of "shortfall" and will not guess one.
- `references/1-carve-input-template.md` — the proposed carve. Rules are an ordered list; the roster carries each rep's segment, start date, and assigned quota.
- `references/2-coverage-thresholds-template.md` — the org's capacity model, ramp curve, disruption tolerances, protected-account list, and material-deal floor.
- `references/3-sample-output-format.md` — the exact Markdown the skill emits. Downstream consumers (a Slack digest, a planning deck) parse this shape.
## Method
Run in order. Steps 2 and 4 carry the engineering choices; do not collapse them.
1. **Load and validate.** Parse both reference files. If any rule references a Salesforce field that does not exist in the org's schema, stop and return `blocked` naming the field — a rule against a missing field silently matches nothing and produces a coverage gap that looks like a design flaw.
2. **Assign every account, first-match-wins, in declared order.** Evaluate the carve rules in the order they appear in the carve spec, and stop at the first rule that matches each account. This mirrors how the routing engine will execute them at go-live. Do not use set-union or any-rule-matches semantics: those produce a different assignment map than the one that ships, which makes the entire simulation decorative. Record the matched rule index per account. Accounts that match nothing land in an unassigned bucket, split into two causes — `no_rule_matched` (a genuine coverage gap) and `null_input_field` (a data gap, with the offending field named). Conflating those two sends a planning team to redesign rules when the real fix is a backfill.
3. **Compute the assignment diff.** For each account, compare the simulated owner against the current `Account.OwnerId`. Join open opportunities, prior-year closed-won amount, and relationship tenure (months since the current owner's first logged activity or first closed-won on that account, whichever is earlier).
4. **Score three impact dimensions.** Do the arithmetic in code, not by reading numbers into the reasoning context — the coverage and capacity figures must be reproducible run to run, and a model reading thousands of records will not be.
- **Coverage.** Unassigned accounts by cause; accounts assigned to a rep whose roster entry has no start date on or before the effective date; territories with zero assigned accounts.
- **Quota capacity.** Per territory: ramp-adjusted quota-carrying capacity against assigned quota. Capacity is `sum over reps of (ramp factor at effective date × that rep's historical productivity band)`, not headcount times average quota. The ramp factor comes from the curve in the thresholds file, so a territory that balances on account count but absorbs three reps in month two shows a shortfall here rather than passing.
- **Named-account churn.** Rank accounts changing owner by weighted disruption, not by count. Weight is open pipeline in stages at or past the thresholds file's `material_stage`, multiplied by a tenure factor. Moving 200 dormant accounts is cheap; moving 12 accounts with late-stage pipeline held by a rep with three years of tenure is not, and an unweighted count reports the opposite.
5. **Emit one of three verdicts.** `ready` (no threshold breached), `revise` (thresholds breached, with the specific territories and accounts named), or `blocked` (a data problem makes the numbers untrustworthy — stale snapshot, missing field history, unresolvable schema reference). There is deliberately no "ship it" verdict and no automatic rollout: the skill's job is to make the cost of the carve visible before a human decides.
## Output format
The skill emits Markdown in exactly this shape. Full worked example with populated rows in `references/3-sample-output-format.md`.
```markdown
# Territory carve simulation — FY27 Enterprise realignment
snapshot_date: 2026-08-10 | effective_date: 2026-11-01 | re-run by: 2026-08-24
accounts evaluated: 4,812 | territories: 22 | reps: 31
## Verdict: revise
Two territories breach the capacity floor and one protected account moves to a
ramping rep. Coverage is clean.
## 1. Coverage
| bucket | accounts | cause |
|---|---|---|
| assigned | 4,798 | — |
| unassigned | 9 | no_rule_matched |
| unassigned | 5 | null_input_field (Account.Industry) |
| empty territories | 0 | — |
## 2. Quota capacity
| territory | assigned quota | ramp-adj. capacity | gap | flag |
|---|---|---|---|---|
| ENT-WEST-2 | 4,200,000 | 2,940,000 | -1,260,000 | shortfall |
| ENT-EAST-1 | 3,800,000 | 3,910,000 | +110,000 | ok |
## 3. Named-account churn (ranked by weighted disruption)
| account | from | to | open pipeline (material) | tenure (mo) | flag |
|---|---|---|---|---|---|
| Northwind Traders | A. Okafor | J. Reyes (ramp m2) | 890,000 | 41 | protected |
| Contoso Fabrics | A. Okafor | S. Baptiste | 410,000 | 18 | review |
## 4. What to change
- ENT-WEST-2: capacity gap of 1.26M against a 4.2M quota. Either move ~1.2M of
quota to ENT-EAST-1, or the two month-two reps need a ramp allowance.
- Northwind Traders is on the protected list and its receiving rep is in month 2.
Carve it out or delay the transfer to the following quarter.
```
## Watch-outs
- **Stale CRM ownership data makes the carve look cleaner than it is.** Guard: the output header carries `snapshot_date` and a re-run deadline (default 14 days). If the carve ships after that date the numbers are void, and the report says so in the header rather than in a footnote nobody reads.
- **Field history not tracked on `Account.OwnerId`.** Tenure and churn baselines silently collapse to zero, which reads as "nothing is moving." Guard: the skill checks whether `AccountHistory` contains `OwnerId` rows and returns `blocked` when coverage of that field is below the thresholds file's `history_coverage_floor`.
- **Rules written against fields with nulls.** Guard: the unassigned bucket is split by cause and names the specific field, so a backfill problem never gets misread as a rule-design problem.
- **A carve that balances the metric by shredding relationships.** Guard: churn is ranked by weighted disruption and protected accounts are surfaced by name, so the tradeoff appears in the report rather than in a rep's resignation two months later.
- **A ramp curve HR wrote rather than one the data supports.** Guard: `dry_run` mode backtests the curve against last year's new-hire cohort attainment. If observed months-to-full-productivity exceeds the file's curve by more than the thresholds file's `ramp_tolerance_months`, the skill warns before using the curve and reports the observed curve alongside it.
- **Simulating a carve that has already been socialized.** Once reps have seen the map, a `revise` verdict is politically expensive and gets ignored. Guard: the skill records `carve_status` from the carve spec, and when it is `socialized` the report opens with the note that revisions now carry a communication cost, so the leader weighs it explicitly rather than discovering it in the meeting.
# Carve input template
Replace the contents below with your real proposed carve. Two sections are required: `rules` (ordered) and `roster`. The example values are a mid-market/enterprise split for a US SaaS org — overwrite them, do not extend them.
## Metadata
```yaml
carve_name: FY27 Enterprise realignment
effective_date: 2026-11-01
carve_status: draft # draft | reviewed | socialized
owner: revops@example.com
routing_engine: salesforce-territory-management # or leandata, fullcast, custom-apex
```
`carve_status` changes how the report opens. Set it honestly: `socialized` means reps have already seen the map, and the simulator will say so in the header because revisions after that point cost credibility as well as effort.
## Rules — ordered, first match wins
The simulator evaluates these top to bottom and stops at the first match, because that is what the routing engine does at go-live. **Order is load-bearing.** If you reorder rules here, re-run the simulation; the assignment map changes.
Each rule needs `id`, `territory`, and `match`. `match` is a list of conditions, all of which must hold (AND). Use Salesforce API field names, not labels.
```yaml
rules:
- id: 1
territory: ENT-STRATEGIC
match:
- field: Account.Strategic_Account__c
op: equals
value: true
- id: 2
territory: ENT-WEST-1
match:
- field: Account.AnnualRevenue
op: gte
value: 500000000
- field: Account.BillingState
op: in
value: [CA, WA, OR, NV, AZ]
- id: 3
territory: ENT-WEST-2
match:
- field: Account.AnnualRevenue
op: gte
value: 100000000
- field: Account.BillingState
op: in
value: [CA, WA, OR, NV, AZ]
- id: 4
territory: MM-WEST
match:
- field: Account.BillingState
op: in
value: [CA, WA, OR, NV, AZ]
- id: 99
territory: UNASSIGNED-POOL
match:
- field: Account.Id
op: exists
```
Supported `op` values: `equals`, `not_equals`, `gte`, `lte`, `in`, `not_in`, `contains`, `exists`, `is_null`.
**On the catch-all.** Rule 99 above catches everything the earlier rules missed. Including one means your `no_rule_matched` count will always be zero and the coverage report shifts from "which accounts have no owner" to "how big is the pool." Both are valid designs; pick deliberately. Omit the catch-all if you want the simulator to surface genuine rule gaps by name.
**On nulls.** A rule condition against a null field does not match. If `Account.AnnualRevenue` is null on 400 accounts, those accounts skip rules 2 and 3 and fall through to rule 4 — silently landing in mid-market. The simulator reports these separately as `null_input_field` so you can tell a data problem from a design problem, but only if you have not masked them with a catch-all.
## Roster
One entry per quota-carrying rep in the carve. `start_date` is the rep's quota-carrying start date, not their hire date — the ramp factor is computed from it against the effective date.
```yaml
roster:
- user_id: 0053000000ABCDE
name: A. Okafor
territory: ENT-WEST-1
start_date: 2023-02-13
assigned_quota: 3800000
productivity_band: high # high | mid | low | unproven
- user_id: 0053000000FGHIJ
name: J. Reyes
territory: ENT-WEST-2
start_date: 2026-09-15
assigned_quota: 2100000
productivity_band: unproven
- user_id: 0053000000KLMNO
name: S. Baptiste
territory: ENT-WEST-2
start_date: 2026-09-01
assigned_quota: 2100000
productivity_band: unproven
```
`productivity_band` maps to a multiplier in the thresholds file. Use `unproven` for anyone without four full quarters of attainment history at this company — assigning them a band from their previous employer's numbers is how a capacity model gets optimistic.
## Territories with no roster entry
A territory that appears in `rules` but not in `roster` is reported as an empty territory, not as an error. That is a real and sometimes intentional state (an open req you plan to fill). The simulator counts its accounts as uncovered capacity and says so.
# Coverage and capacity thresholds template
This file is the org's definition of "too far." The simulator computes numbers regardless; these values decide which numbers become a `revise` verdict. Every value below ships populated with a defensible starting point — replace them with yours rather than accepting them, because a threshold nobody argued about is a threshold nobody enforces.
## Capacity model
```yaml
capacity:
productivity_bands: # annual new-business capacity per fully ramped rep, in ARR
high: 1600000
mid: 1100000
low: 700000
unproven: 900000 # deliberately mid-minus, not mid
shortfall_tolerance_pct: 10 # a territory may be under capacity by this much before flagging
```
Set `productivity_bands` from your own last-four-quarters attainment distribution, not from a benchmark report. The right way to derive them: take trailing-12-month closed-won new business per fully ramped rep in the segment, sort it, and use the 75th percentile for `high`, the median for `mid`, and the 25th percentile for `low`.
`unproven` sits below `mid` on purpose. A new hire's expected capacity is not the team median — the median is computed over people who survived their ramp.
## Ramp curve
The fraction of full productivity a rep carries in each month after their quota-carrying start date. The simulator applies the factor for the month the effective date falls in, then straight-lines the remainder of the fiscal period.
```yaml
ramp:
curve: # month after start_date : productivity factor
1: 0.00
2: 0.05
3: 0.15
4: 0.30
5: 0.45
6: 0.60
7: 0.75
8: 0.85
9: 0.95
10: 1.00
ramp_tolerance_months: 2 # dry_run warns if observed ramp exceeds the curve by more than this
```
The curve above is a 10-month enterprise ramp. A transactional mid-market motion typically reaches 1.00 in four to six months; a multi-year enterprise cycle can run past twelve. Use `dry_run` to backtest the curve against your last new-hire cohort before trusting it — the gap between the curve finance approved and the one the cohort actually produced is usually the largest single error in a capacity model.
## Disruption tolerances
```yaml
disruption:
material_stage: "Stage 3 - Validation" # opportunities at or past this stage count as material
material_deal_floor: 250000 # open amount above which a single moving deal is flagged
max_revenue_churn_pct: 25 # per territory, share of prior-year closed-won changing owner
tenure_weight_months: 24 # relationships older than this get the full tenure multiplier
```
`max_revenue_churn_pct` is the one to argue about. At 25%, a quarter of a territory's revenue relationships change hands before anyone objects. Teams with a high-touch enterprise motion often set this to 10-15%; teams doing volume mid-market can live at 40% because the relationship is with the product, not the rep.
## Protected accounts
Accounts that must not change owner without an explicit decision. These are surfaced by name in the churn report regardless of where they rank on weighted disruption.
```yaml
protected_accounts:
- account_id: 0013000000ABCDE
name: Northwind Traders
reason: renewal in Q1, single-threaded on current owner
- account_id: 0013000000FGHIJ
name: Contoso Fabrics
reason: active executive escalation
```
Keep this list short and dated. A protected list that grows every cycle and never shrinks stops being a signal and starts being a veto — review it at the start of each carve and drop entries whose reason has expired.
## Data quality floors
```yaml
data_quality:
history_coverage_floor_pct: 60 # share of accounts with at least one OwnerId row in AccountHistory
snapshot_staleness_days: 14 # re-run required if the carve ships later than this
```
`history_coverage_floor_pct` guards the churn baseline. Below this, `AccountHistory` is not reliably capturing ownership changes and tenure figures will read low across the board — which makes every carve look cheap. The simulator returns `blocked` rather than reporting a number it cannot support.
## Review date
```yaml
last_reviewed: 2026-08-10
```
The simulator prepends a warning to every report when this date is more than 180 days old. Thresholds drift as segments and headcount change, and a stale thresholds file produces confident verdicts against a model of a company that no longer exists.
# Sample output format
The exact Markdown the skill emits. Downstream consumers parse this shape — a Slack digest that reads the verdict line, a planning deck that lifts the three tables. Keep the heading text and column order stable; add columns at the right if you extend it.
Numbers below are illustrative. The values are internally consistent so you can check a renderer against them.
---
# Territory carve simulation — FY27 Enterprise realignment
snapshot_date: 2026-08-10 | effective_date: 2026-11-01 | re-run by: 2026-08-24
carve_status: draft | routing_engine: salesforce-territory-management
accounts evaluated: 4,812 | territories: 22 | reps: 31
thresholds last_reviewed: 2026-08-10
## Verdict: revise
Coverage is clean. Two territories breach the capacity floor, and one protected account moves to a rep who will be in month two on the effective date. Fixing both is a quota reallocation and a single carve-out, not a redesign.
## 1. Coverage
| bucket | accounts | cause | detail |
|---|---|---|---|
| assigned | 4,798 | — | matched rules 1-8 |
| unassigned | 9 | no_rule_matched | BillingState outside the five listed regions |
| unassigned | 5 | null_input_field | Account.Industry is null |
| empty territories | 0 | — | — |
**Rule match distribution.** Rule 4 (`MM-WEST`) absorbed 1,204 accounts, of which 387 reached it only because `Account.AnnualRevenue` was null and they skipped rules 2 and 3. That is a data gap presenting as a segmentation decision: those 387 accounts are being routed to mid-market by default, not by design. Backfill revenue on them before the effective date or accept that mid-market inherits an unknown number of enterprise-sized accounts.
## 2. Quota capacity
Ramp-adjusted capacity at the effective date, against assigned quota. Shortfall flags at more than 10% below assigned quota per the thresholds file.
| territory | reps | assigned quota | ramp-adj. capacity | gap | flag |
|---|---|---|---|---|---|
| ENT-WEST-1 | 2 | 3,800,000 | 3,910,000 | +110,000 | ok |
| ENT-WEST-2 | 2 | 4,200,000 | 2,940,000 | -1,260,000 | shortfall |
| ENT-EAST-1 | 3 | 5,100,000 | 5,340,000 | +240,000 | ok |
| ENT-EAST-2 | 2 | 3,600,000 | 3,120,000 | -480,000 | shortfall |
| MM-WEST | 6 | 6,600,000 | 6,720,000 | +120,000 | ok |
ENT-WEST-2 carries two reps with quota-carrying start dates in September 2026, putting both at month two on 2026-11-01 — a 0.05 ramp factor each. The territory is assigned 4.2M against an effective capacity of 2.94M. The account count is balanced against ENT-WEST-1; the capacity is not, which is what an account-count-balanced carve hides.
## 3. Named-account churn
Ranked by weighted disruption: material open pipeline multiplied by a tenure factor. Accounts on the protected list appear regardless of rank.
| account | from | to | material open pipeline | tenure (mo) | weighted | flag |
|---|---|---|---|---|---|---|
| Northwind Traders | A. Okafor | J. Reyes (ramp m2) | 890,000 | 41 | 890,000 | protected |
| Fabrikam Industrial | A. Okafor | S. Baptiste (ramp m3) | 620,000 | 33 | 620,000 | review |
| Contoso Fabrics | L. Zhang | S. Baptiste (ramp m3) | 410,000 | 18 | 307,500 | review |
| Tailspin Logistics | L. Zhang | M. Osei | 280,000 | 9 | 105,000 | ok |
**Aggregate.** 214 accounts change owner. 178 of them carry no open pipeline and no closed-won in the prior year — those are free to move. The four rows above account for 71% of total weighted disruption, which is the useful framing: this carve is not risky in general, it is risky for four accounts.
**Per-territory revenue churn.** ENT-WEST-2 sees 31% of its prior-year closed-won revenue change owner, against a 25% tolerance. ENT-WEST-1 sees 12%. No other territory exceeds 20%.
## 4. What to change
- **ENT-WEST-2 capacity.** A 1.26M gap against a 4.2M quota. Move roughly 1.2M of quota to ENT-EAST-1 and MM-WEST, which both have headroom, or grant a documented ramp allowance for the two September starters. Leaving it as drafted sets two new reps against a number the model says they cannot reach.
- **ENT-EAST-2 capacity.** A 480K gap, inside a single rep's band. One account-set adjustment closes it.
- **Northwind Traders.** On the protected list, 890K of material pipeline, 41 months of tenure with the current owner, receiving rep in month two. Carve it out of the realignment or delay the transfer one quarter.
- **Fabrikam Industrial.** Not protected, but the same shape. Worth an explicit decision rather than an implicit one.
- **387 null-revenue accounts routing to mid-market.** Backfill `Account.AnnualRevenue` before 2026-11-01 or re-run after the backfill; the mid-market capacity number above assumes they belong there.
## 5. Re-run conditions
Re-run this simulation if any of the following happens before the effective date:
- The carve rules change or are reordered.
- The roster changes (a start date moves, a rep leaves, a req is filled).
- 2026-08-24 passes without the carve shipping — the CRM snapshot exceeds the 14-day staleness floor.
- The null-revenue backfill completes.
