Ein Claude Skill, der einen entworfenen Gebietszuschnitt nimmt und berichtet, was er tatsächlich bewirkt: wo die Abdeckung bricht, welche Gebiete mehr Quote tragen, als ihre Reps erreichen können, und welche Named Accounts zu einem Preis den Besitzer wechseln, der Beachtung verdient. Er läuft, bevor der Zuschnitt an die Reps geht, solange die Regeln noch editierbar sind, und endet mit einem Urteil von ready, revise oder blocked. Er schreibt niemals eine Zuweisung ins CRM zurück.
Das Bundle liegt unter apps/web/public/artifacts/territory-carve-impact-simulator-skill/ und enthält SKILL.md sowie drei Referenz-Templates: references/1-carve-input-template.md (den vorgeschlagenen Zuschnitt — geordnete Regeln, Rep-Roster, Stichtag), references/2-coverage-thresholds-template.md (das Kapazitätsmodell der Organisation, die Ramp-Kurve, die Disruptionstoleranzen und die geschützten Accounts) und references/3-sample-output-format.md (das exakte Markdown, das der Skill ausgibt, mit einem ausgearbeiteten Beispiel).
Wann Sie ihn einsetzen
Zwei bis vier Wochen vor einem Realignment zum Geschäftsjahresbeginn oder zur Jahresmitte, auf einem Zuschnitt, den jemand entworfen und niemand belastet hat. Dieses Zeitfenster wiegt schwerer, als es klingt: Ein Zuschnitt wird in dem Moment politisch teuer, in dem die Reps die Karte sehen, und der Skill liest carve_status aus der Zuschnitt-Spec — ein Report nach der Kommunikation eröffnet deshalb mit dem Hinweis, dass die empfohlenen Änderungen jetzt Glaubwürdigkeit und nicht nur Aufwand kosten. Läufe für ein einzelnes Segment sind ebenfalls sinnvoll — ein Pod, der dem großen Realignment vorausgeht — genauso wie ein nachträglicher Lauf, wenn ein Segment den Plan verfehlt und niemand sagen kann, ob das Coverage-Design oder die Ausführung schuld ist.
Der Teil, der sich rechnet, ist die Gewichtung. Jedes Planungswerkzeug kann zählen, wie viele Accounts den Besitzer wechseln, und diese Zahl ist nahezu wertlos: Ein Zuschnitt, der 200 schlafende Accounts verschiebt, ist gratis, einer, der zwölf Accounts mit Late-Stage-Pipeline und einem Rep mit drei Jahren Beziehungsdauer verschiebt, ist es nicht — und die ungewichtete Zählung ordnet beide falsch herum. Der Skill sortiert Churn nach materieller offener Pipeline multipliziert mit einem Beziehungsdauer-Faktor, was eine Änderungsliste von 200 Accounts typischerweise auf vier oder fünf Zeilen eindampft, die den Großteil des Risikos tragen.
Wann Sie ihn NICHT einsetzen
- Einen Zuschnitt erzeugen. Er bewertet einen Zuschnitt, den jemand anderes entworfen hat. Er schlägt keine Regeln vor, balanciert keine Accounts und sucht keine optimale Aufteilung. Ohne Entwurf gibt es nichts zu simulieren.
- Zurückschreiben nach Salesforce. Der Skill ist auf jedem Objekt, das er anfasst, nur lesend. Gebietsänderungen werden in dem System ausgeführt, das sie verantwortet, nachdem ein Mensch den Plan freigegeben hat; die Ausgabe in einen automatischen Zuweisungsjob zu hängen, entfernt genau die Entscheidung, für die das Werkzeug existiert.
- Comp-Inputs. Der Kapazitätsreport sagt, ob ein Gebiet eine bereits gesetzte Quote tragen kann. Führen Sie ihn in die Comp-Berechnung, haben Sie einen direkten Anreiz geschaffen, über die Inputs zu streiten: Produktivitätsbänder werden neu verhandelt, Ramp-Kurven werden zum Verhandlungsgegenstand, und das Modell beschreibt die Realität nicht mehr.
- Zuschnitte, die nur als Tabelle mit Account-IDs existieren. Eine Liste aus Account-Rep-Paaren lässt sich nicht gegen das simulieren, was die Routing-Engine zum Go-live tut. Wandeln Sie sie in Regeln um und simulieren Sie diese; wenn die Regeln die Tabelle nicht reproduzieren, ist genau diese Abweichung der Befund.
- Books ohne Ownership-Historie. Wenn
AccountHistorykeineOwnerId-Änderungen aufzeichnet, liest sich die Beziehungsdauer überall als null und jeder Zuschnitt wirkt billig. Der Skill gibt unterhalb vonhistory_coverage_floor_pcteinblockedzurück, statt eine Churn-Zahl auszugeben, die er nicht stützen kann.
Setup
- Schreiben Sie den Zuschnitt als geordnete Regeln. Ersetzen Sie in
references/1-carve-input-template.mddie Beispielregeln durch Ihre eigenen, in der Reihenfolge, in der die Routing-Engine sie auswerten wird, und verwenden Sie Salesforce-API-Feldnamen statt Labels. Die Reihenfolge ist tragend: Der Skill wertet nach First-Match-Wins aus, um die Ausführung abzubilden, also verändert ein Umsortieren der Regeln die Zuweisungskarte. - Entscheiden Sie über die Auffangregel. Das Template liefert eine letzte Regel mit, die alles auffängt. Behalten Sie sie, ist
no_rule_matchedimmer null und der Coverage-Report wird zur Frage nach der Pool-Größe; entfernen Sie sie, tauchen echte Regellücken namentlich auf. Entscheiden Sie bewusst, statt die Vorgabe des Templates zu erben. - Füllen Sie die Threshold-Datei. Leiten Sie in
references/2-coverage-thresholds-template.mddieproductivity_bandsaus Ihrem eigenen Closed-Won der letzten zwölf Monate je voll gerampter Rep ab — 75. Perzentil fürhigh, Median fürmid, 25. Perzentil fürlow— statt aus einem Benchmark. Setzen Siemax_revenue_churn_pctexplizit: Die 25% des Templates lassen ein Viertel der Umsatzbeziehungen eines Gebiets wechseln, bevor überhaupt etwas anschlägt, was für volumengetriebenes Mid-Market passt und für High-Touch-Enterprise viel zu locker ist. - Backtesten Sie die Ramp-Kurve. Lassen Sie einmal
dry_run: truelaufen, bevor Sie einer Kapazitätszahl trauen. Der Lauf vergleicht Ihre Kurve mit der Attainment der Neueinstellungskohorte des Vorjahres und meldet die Differenz — die Lücke zwischen der Ramp, die Finance genehmigt hat, und der, die die Kohorte tatsächlich geliefert hat, ist meist der größte Einzelfehler in einem Kapazitätsmodell. - Installieren und Rechte eng ziehen. Legen Sie das Bundle nach
~/.claude/skills/territory-carve-impact-simulator/und setzen SieSFDC_TOKENmit Lesezugriff aufAccount,AccountHistory,Opportunity,OpportunityHistory,UserundUserTerritory2Association. Nur-Lesen ist der richtige Scope, keine Vorsichtsmaßnahme.
Was der Skill tatsächlich tut
Er läuft in zwei Durchgängen, und die Trennung ist Absicht. Der erste Durchgang weist jeden Account zu, indem er die Zuschnittregeln in der deklarierten Reihenfolge auswertet, beim ersten Treffer stoppt und den getroffenen Regelindex festhält. Der zweite rechnet die Auswirkungen gegen diese fertige Zuweisungskarte. Churn und Kapazität inline zu berechnen, während die Regeln noch aufgelöst werden, zählt jeden Account doppelt, den mehr als eine Regel beanspruchen könnte — und da First-Match-Wins bedeutet, dass ihn nur eine tatsächlich beansprucht, beschreiben diese Inline-Zahlen einen Zuschnitt, den es nie geben wird.
Nicht zugewiesene Accounts werden nach zwei Ursachen getrennt statt in einen Topf geworfen: no_rule_matched ist eine Coverage-Lücke, null_input_field eine Datenlücke, und der Skill benennt das verursachende Feld. Beides zu vermischen schickt ein Planungsteam in ein Regel-Redesign, obwohl die Lösung ein Backfill ist. Im ausgearbeiteten Beispiel in references/3-sample-output-format.md landen 387 Accounts nur deshalb im Mid-Market, weil Account.AnnualRevenue null ist und sie die beiden darüberliegenden Enterprise-Regeln übersprungen haben — Segmentierung, die aus Versehen passiert und in einer einzigen Zahl für nicht zugewiesene Accounts unsichtbar bleibt.
Kapazität ist ramp-adjustierte quotentragende Kapazität, nicht Headcount mal Durchschnittsquote: Jeder Rep steuert sein Produktivitätsband bei, skaliert mit dem Ramp-Faktor des Monats, in dem sein Startdatum ihn zum Stichtag verortet. Ein nach Account-Anzahl ausbalanciertes Gebiet, das zwei Reps mit Start sechs Wochen vor Go-live aufnimmt, zeigt hier eine Unterdeckung — genau das Versagen, das ein nach Account-Anzahl ausbalancierter Zuschnitt zu verbergen gebaut ist.
Diese Arithmetik läuft in Code und nicht über das Lesen der Datensätze durch das Modell. Ein Planungsgespräch bricht in dem Moment zusammen, in dem zwei Läufe desselben Zuschnitts unterschiedliche Zahlen liefern, und ein Modell, das mehrere tausend Account-Zeilen liest, ist nicht reproduzierbar. Die Aufgabe des Modells sind die Rangfolge, die Erzählung und der Abschnitt „was zu ändern ist”.
Kostenrealität
Weil die Arbeit auf Datensatzebene in Code passiert, skaliert der Token-Aufwand mit der Größe der Zusammenfassung, nicht mit der Größe des Books. Ein Zuschnitt mit 5.000 Accounts und 30 Reps kostet rund 2 bis 4 USD pro Simulation auf Claude Sonnet 5 zu den veröffentlichten API-Preisen von 3 USD je Million Input-Tokens und 15 USD je Million Output-Tokens — die Referenzdateien, die aggregierten Tabellen und der Report selbst, nicht die 5.000 Zeilen. Diese Zahl ist eine Schätzung, abgeleitet aus dem Token-Preis und der typischen Reportlänge; sie bewegt sich mit dem Umfang der gewünschten Erzählung, nicht mit der Account-Zahl. Ein Planungszyklus braucht fünf bis fünfzehn Läufe, während der Zuschnitt überarbeitet wird, also kalkulieren Sie rund 50 USD API-Ausgaben für den Zyklus.
Der Vergleich, der zählt, ist Zeit. Ein RevOps-Analyst, der diese drei Sichten von Hand erstellt — das Account-Book gegen die vorgeschlagenen Regeln pivotieren, Pipeline und Ownership-Historie joinen, ein ramp-gewichtetes Kapazitätsmodell bauen — verbringt drei bis fünf Tage je Iteration, weshalb die meisten Teams es genau einmal tun und danach aus der ersten Version heraus argumentieren. Der Skill macht aus jeder Iteration einen Lauf von fünfzehn Minuten plus eine Stunde Lesezeit, und genau das lässt fünf Überarbeitungen in ein Planungsfenster passen statt einer.
Gegen die Alternativen
- Salesforce Sales Planning — veröffentlicht mit 75 USD pro Nutzer und Monat bei jährlicher Abrechnung (Preisseite des Anbieters, geprüft am 2026-08-10), mit Hierarchy Management, Segment Design und Territory Planning; im Agentforce 1 Sales Edition zu 550 USD pro Nutzer und Monat enthalten. Für eine Vertriebsorganisation mit 40 Seats liegt das eigenständige Add-on bei rund 36.000 USD im Jahr. Nehmen Sie die Plattform, wenn der Zuschnitt ein gesteuertes, versioniertes Artefakt im CRM sein soll und Plan und Ausführung in einem System liegen; nehmen Sie den Skill, wenn Sie ein Pre-mortem zu einem Zuschnitt brauchen, den jemand bereits in einer Tabelle entworfen hat. Beides schließt sich nicht aus: Den Skill gegen einen in Sales Planning erstellten Zuschnitt laufen zu lassen, ist eine vernünftige Zweitmeinung, weil die Plattform, die den Plan erzeugt hat, nicht der naheliegende Ort ist, um nach Gründen für sein Scheitern zu suchen.
- Fullcast — eine Plan-to-Execution-Plattform für Gebiet, Quote, Kapazität und Routing, Preis auf Anfrage, nichts veröffentlicht. Die richtige Wahl, wenn Ihr Zuschnitt kontinuierlich statt jährlich ist: Gebiete, die sich anpassen, während Accounts und Headcount sich bewegen, mit synchron gehaltenem Plan und Routing-Regelwerk. Der Skill hat überhaupt keine Ausführungsebene und verliert bei dieser Arbeitsweise deutlich.
- Die Tabelle — die tatsächliche Ausgangslage in den meisten Unternehmen, und sie liefert den Zuschnitt, der ausgerollt und in Woche drei leise überarbeitet wird. Sie kann Disruption nicht gewichten und Ramp nicht modellieren, versagt also genau bei den beiden Fragen, die entscheiden, ob der Zuschnitt hält.
- Ausrollen und im Quartal nachbessern — der ehrliche Standardfall. Die Kosten tauchen nie als Budgetposition auf; sie zeigen sich als ein Segment, das den Plan verfehlt, und zwei Enterprise-Reps, die im zweiten Monat kündigen — zu einem Zeitpunkt, an dem niemand beides dem Zuschnitt zuschreibt.
Fallstricke
- Ein CRM-Snapshot, der vor dem Go-live veraltet. Guard: Der Ausgabe-Header trägt
snapshot_dateund eine Frist für den erneuten Lauf, standardmäßig 14 Tage aussnapshot_staleness_days. Die Frist steht im Header, nicht in einer Fußnote, und der Report erklärt die Zahlen danach für ungültig. - Ownership-Historie auf
Account.OwnerIdnicht aktiviert. Die Beziehungsdauer fällt stillschweigend auf null und jeder Zuschnitt liest sich billig. Guard: Der Skill prüft die Abdeckung dieses Feldes inAccountHistoryund gibt unterhalb der Schwelle einblockedzurück, statt eine Zahl zu melden, die er nicht stützen kann. - Eine Ramp-Kurve, die HR geschrieben hat und nicht die Daten. Guard:
dry_runbacktestet die Kurve gegen die Vorjahreskohorte und warnt, wenn die beobachteten Monate bis zur vollen Produktivität die Datei um mehr alsramp_tolerance_monthsüberschreiten, und meldet die beobachtete Kurve neben der konfigurierten. - Eine Liste geschützter Accounts, die nur wächst. Sobald jeder Account, an dem jemand hängt, geschützt ist, hört die Liste auf, ein Signal zu sein, und wird zum Veto gegen jedes Realignment. Guard: Jeder Eintrag trägt eine datierte Begründung, und das
last_reviewed-Datum der Threshold-Datei löst bei jedem Report, der älter als 180 Tage ist, ein Warnbanner aus. reviseals Veto lesen. Das Urteil benennt Gebiete und Accounts, keine Entscheidung. Die Führung kann einen Zuschnitt mit Kapazitätslücke bewusst ausrollen, weil ein Hiring-Plan sie im zweiten Quartal schließt. Guard: Der Abschnitt „was zu ändern ist” beziffert die Korrektur in Einheiten — rund 1,2 Mio. Quote verschieben, einen Account herausnehmen — sodass das Akzeptieren des Risikos eine ausdrückliche Entscheidung mit Größenangabe ist.
Stack
- Salesforce — Accounts, Ownership-Historie, offene Pipeline, Stage-Historie der Opportunities, Nutzerdatensätze
- Claude — Regelauswertung, Impact-Ranking, Report-Synthese; die Arithmetik läuft in Code, nicht im Kontext
- Die Zuschnitt-Spec und die Threshold-Datei — die beiden Inputs, die die Ausgabe spezifisch für Ihre Organisation statt generisch machen
- Ein Routing- oder Territory-Management-System — Fullcast, LeanData oder Salesforce Territory Management, dort wo der freigegebene Zuschnitt tatsächlich ausgeführt wird