A Claude Skill that takes a drafted territory carve and reports what it will actually do — where coverage breaks, which territories carry more quota than their reps can reach, and which named accounts change hands at a price worth paying attention to. It runs before the carve ships to reps, while the rules are still editable, and it ends in a verdict of ready, revise, or blocked. It never writes an assignment back to the CRM.
The bundle ships at apps/web/public/artifacts/territory-carve-impact-simulator-skill/ and contains SKILL.md plus three reference templates: references/1-carve-input-template.md (the proposed carve — ordered rules, rep roster, effective date), references/2-coverage-thresholds-template.md (the org’s capacity model, ramp curve, disruption tolerances, and protected accounts), and references/3-sample-output-format.md (the exact Markdown the Skill emits, with a worked example).
When to use
Two to four weeks before a fiscal-year or mid-year realignment, on a carve that someone has drafted and nobody has stress-tested. That window matters more than it sounds: a carve becomes politically expensive to change the moment reps see the map, and the Skill records carve_status from the carve spec so a report run after socialization opens by saying the revisions it recommends now cost credibility as well as effort. Single-segment runs are also valid — one pod moving ahead of the wider realignment — as is an after-the-fact run when a segment is missing plan and nobody can say whether the coverage design or the execution is at fault.
The part that earns its keep is the weighting. Every planning tool can count how many accounts change owner, and that count is close to useless: a carve that moves 200 dormant accounts is free, one that moves twelve accounts holding late-stage pipeline with a rep of three years’ tenure is not, and the unweighted count ranks them the wrong way round. The Skill ranks churn by material open pipeline multiplied by a tenure factor, which typically collapses a 200-account change list into four or five rows carrying most of the risk.
When NOT to use
Generating a carve. This scores a carve someone else designed. It does not propose rules, rebalance accounts, or search for an optimal split. With no draft, there is nothing to simulate.
Writing back to Salesforce. The Skill is read-only on every object it touches. Territory changes execute in the system that owns them, after a human approves the plan; wiring the output into an automated assignment job removes the decision the tool exists to inform.
Comp inputs. The capacity report says whether a territory can carry a quota someone already set. Route it into comp calculations and you have created a direct incentive to argue with the inputs — productivity bands get relitigated, ramp curves get negotiated, and the model stops describing reality.
Carves that exist only as a spreadsheet of account IDs. A list of account-to-rep pairs cannot be simulated against what the routing engine will do at go-live. Convert it into rules and simulate those; if the rules cannot reproduce the spreadsheet, that discrepancy is itself the finding.
Books without ownership history. If AccountHistory does not record OwnerId changes, tenure reads as zero across the board and every carve looks cheap. The Skill returns blocked below history_coverage_floor_pct rather than emitting a churn number it cannot support.
Setup
Write the carve as ordered rules. In references/1-carve-input-template.md, replace the example rules with yours, in the order the routing engine will evaluate them, using Salesforce API field names rather than labels. Order is load-bearing: the Skill evaluates first-match-wins to mirror execution, so reordering rules changes the assignment map.
Decide on the catch-all. The template ships with a final rule that catches everything. Keep it and no_rule_matched is always zero, turning the coverage report into a question about pool size; drop it and genuine rule gaps surface by name. Pick deliberately rather than inheriting the template’s choice.
Populate the thresholds file. In references/2-coverage-thresholds-template.md, derive productivity_bands from your own trailing-12-month closed-won per fully ramped rep — 75th percentile for high, median for mid, 25th for low — rather than from a benchmark. Set max_revenue_churn_pct explicitly: the template’s 25% lets a quarter of a territory’s revenue relationships move before anything flags, which fits volume mid-market and is far too loose for high-touch enterprise.
Backtest the ramp curve. Run once with dry_run: true before trusting any capacity number. It compares your curve against last year’s new-hire cohort attainment and reports the delta — the gap between the ramp finance approved and the one the cohort produced is usually the single largest error in a capacity model.
Install and scope credentials. Drop the bundle into ~/.claude/skills/territory-carve-impact-simulator/ and set SFDC_TOKEN with read on Account, AccountHistory, Opportunity, OpportunityHistory, User, and UserTerritory2Association. Read-only is the correct scope, not a precaution.
What the skill actually does
It runs in two passes, and the split is deliberate. Pass one assigns every account by evaluating the carve rules in declared order, stopping at the first match, and records which rule index matched. Pass two does the impact arithmetic against that finished assignment map. Computing churn and capacity inline while rules are still resolving double-counts any account that more than one rule could claim — and since first-match-wins means only one rule will actually claim it, the inline numbers describe a carve that will never exist.
Unassigned accounts split into two causes rather than one bucket: no_rule_matched is a coverage gap, null_input_field is a data gap, and the Skill names the offending field. Conflating them sends a planning team to redesign rules when the fix is a backfill. In the worked example in references/3-sample-output-format.md, 387 accounts reach mid-market only because Account.AnnualRevenue is null and they skipped the two enterprise rules above it — segmentation happening by accident, and invisible in a single unassigned count.
Capacity is ramp-adjusted quota-carrying capacity, not headcount times average quota: each rep contributes their productivity band scaled by the ramp factor for the month their start date puts them in on the effective date. A territory balanced on account count that absorbs two reps starting six weeks before go-live shows a shortfall here, which is exactly the failure an account-count-balanced carve is built to hide.
That arithmetic runs in code rather than through the model’s reading of the records. A planning conversation collapses the moment two runs of the same carve produce different numbers, and a model reading several thousand account rows will not be reproducible. The model’s job is the ranking, the narrative, and the “what to change” section.
Cost reality
Because the record-level work happens in code, token cost scales with the size of the summary, not the size of the book. A 5,000-account, 30-rep carve runs roughly 2 to 4 USD per simulation on Claude Sonnet 5 at published API pricing of 3 USD per million input tokens and 15 USD per million output tokens — the reference files, the aggregated tables, and the report itself, not the 5,000 rows. That figure is an estimate derived from token pricing and typical report length; it moves with how much narrative you ask for, not with account count. A planning cycle takes five to fifteen runs as the carve gets revised, so budget around 50 USD of API spend for the cycle.
The comparison that matters is time. A RevOps analyst producing these three views by hand — pivoting the account book against the proposed rules, joining pipeline and ownership history, building a ramp-weighted capacity model — spends three to five days per iteration, which is why most teams do it once and then argue from the first version. The Skill turns each iteration into a fifteen-minute run plus an hour reading the report, which is what makes five revisions fit inside a planning window instead of one.
vs alternatives
Salesforce Sales Planning — published at 75 USD per user per month billed annually (vendor pricing page, checked 2026-08-10), covering Hierarchy Management, Segment Design, and Territory Planning; bundled into Agentforce 1 Sales Edition at 550 USD per user per month. For a 40-seat sales org the standalone add-on runs around 36,000 USD a year. Pick the platform when you want the carve to be a governed, versioned, in-CRM artifact with plan and execution in one system; pick the Skill when you need a pre-mortem on a carve someone already drafted in a spreadsheet. They are not mutually exclusive — running the Skill against a carve authored in Sales Planning is a reasonable second opinion, because the platform that generated the plan is not the natural place to look for reasons it will fail.
Fullcast — a plan-to-execution platform covering territory, quota, capacity, and routing, priced on request with nothing published. The right pick when your carve is continuous rather than annual: territories that adjust as accounts and headcount move, with plan and routing rules kept in sync. The Skill has no execution layer at all, so it loses badly on that motion.
The spreadsheet — the actual baseline at most companies, and it produces the carve that ships and then gets quietly revised in week three. It cannot weight disruption or model ramp, so it fails on the two questions that decide whether the carve holds.
Shipping and fixing in-quarter — the honest default. The cost never appears as a line item; it shows up as a segment missing plan and two enterprise reps resigning in month two, at which point nobody attributes either to the carve.
Watch-outs
A CRM snapshot that goes stale before go-live. Guard: the output header carries snapshot_date and a re-run deadline, default 14 days from snapshot_staleness_days. The deadline is in the header, not a footnote, and the report says the numbers are void past it.
Ownership history not tracked on Account.OwnerId. Tenure silently collapses to zero and every carve reads as cheap. Guard: the Skill checks AccountHistory coverage of that field and returns blocked below the floor rather than reporting an unsupported number.
A ramp curve HR wrote rather than one the data supports. Guard: dry_run backtests the curve against last year’s cohort and warns when observed months-to-full-productivity exceeds the file by more than ramp_tolerance_months, reporting the observed curve next to the configured one.
A protected-account list that only grows. Once every account someone cares about is protected, the list stops being a signal and becomes a veto on realignment. Guard: each entry carries a dated reason, and the thresholds file’s last_reviewed date drives a warning banner on every report older than 180 days.
Treating revise as a veto. The verdict names territories and accounts, not a decision. Leadership may knowingly ship a carve with a capacity shortfall because a hiring plan closes it in Q2. Guard: the “what to change” section states the fix in units — move roughly 1.2M of quota, carve out one account — so accepting the risk is an explicit choice with a size attached.
Stack
Salesforce — accounts, ownership history, open pipeline, opportunity stage history, user records
Claude — rule evaluation, impact ranking, report synthesis; arithmetic runs in code, not in context
The carve spec and thresholds files — the two inputs that make the output specific to your org rather than generic
A routing or territory-management system — Fullcast, LeanData, or Salesforce Territory Management, wherever the approved carve actually executes
---
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.
