Un Claude Skill que toma un reparto de territorios ya redactado y reporta lo que realmente va a hacer: dónde se rompe la cobertura, qué territorios cargan más cuota de la que sus reps pueden alcanzar y qué cuentas nombradas cambian de manos a un precio que conviene mirar. Se ejecuta antes de que el reparto llegue a los reps, mientras las reglas todavía se pueden editar, y termina en un veredicto de ready, revise o blocked. Nunca escribe una asignación de vuelta en el CRM.
El bundle se publica en apps/web/public/artifacts/territory-carve-impact-simulator-skill/ y contiene SKILL.md más tres plantillas de referencia: references/1-carve-input-template.md (el reparto propuesto: reglas ordenadas, roster de reps, fecha de entrada en vigor), references/2-coverage-thresholds-template.md (el modelo de capacidad de la organización, la curva de ramp, las tolerancias de disrupción y las cuentas protegidas) y references/3-sample-output-format.md (el Markdown exacto que emite el Skill, con un ejemplo trabajado).
Cuándo usarlo
De dos a cuatro semanas antes de una realineación de inicio de año fiscal o de mitad de año, sobre un reparto que alguien redactó y nadie sometió a prueba. Esa ventana importa más de lo que parece: un reparto se vuelve políticamente caro de cambiar en el momento en que los reps ven el mapa, y el Skill registra carve_status desde la spec del reparto, de modo que un reporte ejecutado después de la comunicación abre diciendo que las revisiones que recomienda ya cuestan credibilidad además de esfuerzo. Las corridas de un solo segmento también son válidas —un pod que se adelanta a la realineación general— igual que una corrida posterior cuando un segmento no llega a plan y nadie puede decir si la culpa es del diseño de cobertura o de la ejecución.
La parte que justifica su costo es la ponderación. Cualquier herramienta de planificación puede contar cuántas cuentas cambian de dueño, y ese conteo es casi inútil: un reparto que mueve 200 cuentas dormidas es gratis, uno que mueve doce cuentas con pipeline en etapa avanzada y un rep con tres años de relación no lo es, y el conteo sin ponderar los ordena al revés. El Skill ordena la rotación por pipeline abierto material multiplicado por un factor de antigüedad, lo que normalmente reduce una lista de 200 cuentas a cuatro o cinco filas que concentran casi todo el riesgo.
Cuándo NO usarlo
Generar un reparto. Esto puntúa un reparto que alguien más diseñó. No propone reglas, no rebalancea cuentas ni busca una división óptima. Sin borrador, no hay nada que simular.
Escribir de vuelta en Salesforce. El Skill es de solo lectura en cada objeto que toca. Los cambios de territorio se ejecutan en el sistema que los gobierna, después de que una persona aprueba el plan; conectar la salida a un job de asignación automática elimina justamente la decisión que la herramienta existe para informar.
Insumos de comp. El reporte de capacidad dice si un territorio puede cargar una cuota que alguien ya fijó. Si lo enrutas a los cálculos de comp, creas un incentivo directo a discutir los insumos: las bandas de productividad se relitigan, las curvas de ramp se negocian y el modelo deja de describir la realidad.
Repartos que solo existen como una hoja de cálculo de IDs de cuenta. Una lista de pares cuenta-rep no se puede simular contra lo que el motor de ruteo hará en el go-live. Conviértela en reglas y simula esas; si las reglas no reproducen la hoja de cálculo, esa discrepancia ya es el hallazgo.
Books sin historial de propiedad. Si AccountHistory no registra los cambios de OwnerId, la antigüedad se lee como cero en todos lados y cualquier reparto parece barato. El Skill devuelve blocked por debajo de history_coverage_floor_pct en lugar de emitir un número de rotación que no puede sostener.
Configuración
Escribe el reparto como reglas ordenadas. En references/1-carve-input-template.md, reemplaza las reglas de ejemplo por las tuyas, en el orden en que el motor de ruteo las evaluará, usando nombres de campo de la API de Salesforce en vez de etiquetas. El orden es determinante: el Skill evalúa first-match-wins para reflejar la ejecución, así que reordenar reglas cambia el mapa de asignación.
Decide sobre la regla comodín. La plantilla incluye una regla final que captura todo. Si la dejas, no_rule_matched siempre será cero y el reporte de cobertura se convierte en una pregunta sobre el tamaño del pool; si la quitas, los huecos reales de reglas salen con nombre propio. Elige deliberadamente en vez de heredar la decisión de la plantilla.
Completa el archivo de umbrales. En references/2-coverage-thresholds-template.md, deriva productivity_bands de tu propio closed-won de los últimos 12 meses por rep completamente rampado —percentil 75 para high, mediana para mid, percentil 25 para low— en vez de tomarlo de un benchmark. Define max_revenue_churn_pct de forma explícita: el 25% de la plantilla deja que un cuarto de las relaciones de ingreso de un territorio se muevan antes de que algo se marque, lo cual encaja en mid-market de volumen y es demasiado laxo para enterprise de alto contacto.
Haz backtest de la curva de ramp. Ejecuta una vez con dry_run: true antes de confiar en cualquier número de capacidad. Compara tu curva contra la attainment de la cohorte de nuevas contrataciones del año pasado y reporta el delta: la brecha entre el ramp que aprobó finanzas y el que la cohorte realmente produjo suele ser el error más grande de un modelo de capacidad.
Instala y limita las credenciales. Coloca el bundle en ~/.claude/skills/territory-carve-impact-simulator/ y configura SFDC_TOKEN con lectura sobre Account, AccountHistory, Opportunity, OpportunityHistory, User y UserTerritory2Association. Solo lectura es el scope correcto, no una precaución.
Qué hace realmente el skill
Corre en dos pasadas, y la división es deliberada. La primera pasada asigna cada cuenta evaluando las reglas del reparto en el orden declarado, deteniéndose en la primera coincidencia, y registra qué índice de regla coincidió. La segunda hace la aritmética de impacto contra ese mapa de asignación ya cerrado. Calcular rotación y capacidad en línea mientras las reglas todavía se están resolviendo duplica el conteo de cualquier cuenta que más de una regla podría reclamar, y como first-match-wins significa que solo una la reclamará de verdad, esos números en línea describen un reparto que nunca va a existir.
Las cuentas sin asignar se dividen en dos causas en vez de un solo bucket: no_rule_matched es un hueco de cobertura, null_input_field es un hueco de datos, y el Skill nombra el campo culpable. Confundirlos manda a un equipo de planificación a rediseñar reglas cuando el arreglo es un backfill. En el ejemplo trabajado de references/3-sample-output-format.md, 387 cuentas llegan a mid-market solo porque Account.AnnualRevenue está en null y se saltaron las dos reglas de enterprise que estaban arriba: segmentación ocurriendo por accidente, e invisible en un conteo único de no asignadas.
La capacidad es capacidad de carga de cuota ajustada por ramp, no headcount por cuota promedio: cada rep aporta su banda de productividad escalada por el factor de ramp del mes en que su fecha de inicio lo ubica a la fecha de entrada en vigor. Un territorio balanceado por conteo de cuentas que absorbe dos reps que arrancan seis semanas antes del go-live muestra un déficit aquí, que es exactamente la falla que un reparto balanceado por conteo de cuentas está construido para esconder.
Esa aritmética corre en código y no a través de la lectura de registros por parte del modelo. Una conversación de planificación se derrumba en el momento en que dos corridas del mismo reparto producen números distintos, y un modelo leyendo varios miles de filas de cuentas no será reproducible. El trabajo del modelo es el ordenamiento, la narrativa y la sección de “qué cambiar”.
Realidad de costos
Como el trabajo a nivel de registro ocurre en código, el costo en tokens escala con el tamaño del resumen, no con el tamaño del book. Un reparto de 5.000 cuentas y 30 reps cuesta aproximadamente entre 2 y 4 USD por simulación con Claude Sonnet 5 al precio publicado de la API de 3 USD por millón de tokens de entrada y 15 USD por millón de tokens de salida: los archivos de referencia, las tablas agregadas y el reporte mismo, no las 5.000 filas. Esa cifra es una estimación derivada del precio por token y de la extensión típica del reporte; se mueve con cuánta narrativa pidas, no con el número de cuentas. Un ciclo de planificación toma entre cinco y quince corridas conforme el reparto se revisa, así que presupuesta alrededor de 50 USD de gasto de API para el ciclo.
La comparación que importa es el tiempo. Un analista de RevOps produciendo estas tres vistas a mano —pivotear el book de cuentas contra las reglas propuestas, unir pipeline e historial de propiedad, construir un modelo de capacidad ponderado por ramp— gasta de tres a cinco días por iteración, y por eso la mayoría de los equipos lo hace una sola vez y luego discute a partir de la primera versión. El Skill convierte cada iteración en una corrida de quince minutos más una hora de lectura del reporte, que es lo que hace que quepan cinco revisiones dentro de una ventana de planificación en vez de una.
Frente a las alternativas
Salesforce Sales Planning — publicado a 75 USD por usuario al mes con facturación anual (página de precios del proveedor, verificada el 2026-08-10), cubriendo Hierarchy Management, Segment Design y Territory Planning; incluido en Agentforce 1 Sales Edition a 550 USD por usuario al mes. Para un equipo comercial de 40 asientos, el add-on por separado sale alrededor de 36.000 USD al año. Elige la plataforma cuando quieras que el reparto sea un artefacto gobernado, versionado y dentro del CRM, con plan y ejecución en un solo sistema; elige el Skill cuando necesites un pre-mortem sobre un reparto que alguien ya redactó en una hoja de cálculo. No son excluyentes: correr el Skill contra un reparto creado en Sales Planning es una segunda opinión razonable, porque la plataforma que generó el plan no es el lugar natural para buscar razones por las que va a fallar.
Fullcast — una plataforma de plan-a-ejecución que cubre territorio, cuota, capacidad y ruteo, con precio bajo consulta y nada publicado. La elección correcta cuando tu reparto es continuo y no anual: territorios que se ajustan conforme se mueven cuentas y headcount, con el plan y las reglas de ruteo sincronizados. El Skill no tiene capa de ejecución alguna, así que pierde por mucho en esa modalidad.
La hoja de cálculo — la línea base real en la mayoría de las empresas, y produce el reparto que se lanza y luego se revisa en silencio en la semana tres. No puede ponderar disrupción ni modelar ramp, así que falla en las dos preguntas que deciden si el reparto se sostiene.
Lanzar y arreglar dentro del trimestre — el default honesto. El costo nunca aparece como una línea de presupuesto; aparece como un segmento que no llega a plan y dos reps de enterprise renunciando en el mes dos, momento en el que nadie atribuye ninguna de las dos cosas al reparto.
Puntos de atención
Un snapshot del CRM que se vuelve obsoleto antes del go-live. Guardrail: el encabezado de la salida lleva snapshot_date y una fecha límite de re-corrida, por defecto 14 días desde snapshot_staleness_days. La fecha límite va en el encabezado, no en una nota al pie, y el reporte declara que los números quedan nulos pasada esa fecha.
Historial de propiedad no rastreado en Account.OwnerId. La antigüedad colapsa en silencio a cero y cualquier reparto se lee como barato. Guardrail: el Skill verifica la cobertura de ese campo en AccountHistory y devuelve blocked por debajo del piso, en vez de reportar un número que no puede sostener.
Una curva de ramp que escribió RRHH y no una que los datos respalden. Guardrail: dry_run hace backtest de la curva contra la cohorte del año pasado y avisa cuando los meses observados hasta productividad plena exceden el archivo por más de ramp_tolerance_months, reportando la curva observada junto a la configurada.
Una lista de cuentas protegidas que solo crece. Cuando toda cuenta que a alguien le importa está protegida, la lista deja de ser una señal y se convierte en un veto a la realineación. Guardrail: cada entrada lleva un motivo con fecha, y la fecha last_reviewed del archivo de umbrales dispara un banner de advertencia en todo reporte con más de 180 días.
Tratar revise como un veto. El veredicto nombra territorios y cuentas, no una decisión. El liderazgo puede lanzar a sabiendas un reparto con déficit de capacidad porque un plan de contratación lo cierra en Q2. Guardrail: la sección de “qué cambiar” expresa el arreglo en unidades —mover unos 1,2M de cuota, sacar una cuenta del reparto— para que aceptar el riesgo sea una elección explícita con una magnitud asociada.
Stack
Salesforce — cuentas, historial de propiedad, pipeline abierto, historial de etapas de oportunidad, registros de usuario
Claude — evaluación de reglas, ordenamiento de impacto, síntesis del reporte; la aritmética corre en código, no en contexto
Los archivos de spec del reparto y de umbrales — los dos insumos que hacen que la salida sea específica de tu organización y no genérica
Un sistema de ruteo o gestión de territorios — Fullcast, LeanData o Salesforce Territory Management, allí donde el reparto aprobado se ejecuta de verdad
---
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.
