Ein Claude Skill, der einen nicht standardmäßigen Deal gegen Ihr Rabatt-Rubric und Ihre vergleichbare-Deal-Historie prüft und dann eine strukturierte Markdown-Empfehlung zurückgibt: den empfohlenen Gegenvorschlag, die Rubric-Abschnitte, die ihn rechtfertigen, die historischen Analogien, die ihn stützen, und ein explizites Eskalations-Flag, wenn die Anfrage außerhalb des vom Rubric Abgedeckten liegt. Der Skill ist Entscheidungsunterstützung für den Deal-Desk-Reviewer; er genehmigt nie automatisch, rabattiert nie automatisch und ersetzt nie den namentlichen Genehmiger in der DOA-Matrix. Er existiert, um die Zeit zwischen „AE hat die Anfrage eingereicht” und „Reviewer hat den Kontext, um intelligent gegenzuhalten” zu verkürzen — typischerweise von Tagen auf Minuten für Routineanfragen — ohne dem Menschen die Entscheidung abzunehmen.
Das Artefakt-Bundle liegt unter /artifacts/deal-desk-pricing-skill/: Die SKILL.md ist der Einstiegspunkt, und die drei Dateien unter references/ sind das editierbare Gerüst, das der Skill bei jedem Run lädt — das Rabatt-Rubric, das Vergleichs-Deal-Schema und die Eskalationskriterien, die der Skill vor dem Rendering prüft.
Wann einsetzen
Setzen Sie diesen Skill ein, wenn ein AE eine nicht standardmäßige Preisanfrage einreicht und ein Deal-Desk-Reviewer entscheiden muss, was er entgegnen soll:
Eine Mehrjahres-Rabattanfrage, die einen Term-Incentive auf einen Volumenrabatt stapelt.
Ein Upfront-Payment-for-Discount-Swap oder eine Net-60/Net-90-Zahlungskonzession.
Eine Ramp-Struktur (Y1 50 % / Y2 100 %, benutzerdefinierte Formen), bei der die vertragliche Laufzeit gegen das Rubric geprüft werden muss.
Eine Co-Term gegen einen bestehenden Vertrag, bei der der Käufer einen effektiven Rabatt über die verbundenen Verträge gewichtet haben möchte.
Ein Wettbewerbsdeal, bei dem der AE einen Wettbewerber und ein enges Abschlussdatum genannt hat und der Reviewer die Analogien benötigt, die unter ähnlichem Druck abgeschlossen wurden.
Der Skill gibt eine Markdown-Empfehlung mit dem empfohlenen Gegenvorschlag, den Rubric-Abschnitten und Analog-IDs, die ihn rechtfertigen, und einem Eskalationsblock oben zurück, der auslöst, wenn die Anfrage außerhalb der Rubric-Abdeckung liegt. Der Reviewer liest sie, bearbeitet sie und entscheidet.
Wann NICHT einsetzen
Verwenden Sie diesen Skill nicht — und verknüpfen Sie ihn nicht mit etwas, das diese Dinge automatisch tut:
Endgültige Genehmigung. Der Skill empfiehlt; er genehmigt nicht. Die Genehmigungsbefugnis liegt beim namentlichen Menschen in der DOA-Matrix (references/1-discount-rubric.md §8). Der Skill-Output ist ein Input zu dieser Entscheidung, kein Ersatz dafür. Eine Genehmigung auf einer LLM-Empfehlung zu verdrahten ist genau der falsche Ort, um einen Kontrollpunkt zu entfernen.
Auto-Rabattierung im Angebot. Der Skill schreibt niemals einen Rabatt in einen CPQ-Datensatz oder ein Salesforce-Angebot. Er produziert eine Empfehlung, die der Reviewer in das Angebot eingibt (oder ablehnt). Eine LLM-Empfehlung automatisch auf ein Live-Angebot anzuwenden ist der Fehlermodus, den dieser Skill zu vermeiden konzipiert ist.
Alles, was die menschliche Deal-Desk-Überprüfung überspringt. Wenn Ihr Team einen Fast-Path für In-Policy-Deals hat — einjährig, Listenpreis, keine Ausnahmen — führen Sie diesen Fast-Path über CPQ-Regeln aus. CPQ ist das richtige Tool für deterministische In-Policy-Durchsetzung; es ist schneller, billiger und audit-freundlich. Dieser Skill existiert für Anfragen, die Urteilsvermögen erfordern, und bei diesen Anfragen ist das Überspringen des Menschen genau der falsche Ort, um einen Kontrollpunkt zu entfernen.
Nicht-Tier-A-KI-Anbieter. Betreiben Sie es auf Claude (Workspace- oder Team-Plan, dessen Datenhandhabungsposition Sie überprüft haben). Preisrubrics und vergleichbare Deal-Historien sind kommerziell sensibel; leiten Sie sie nicht durch Consumer-Grade-LLMs.
Einrichtung
Bundle ablegen. Kopieren Sie /artifacts/deal-desk-pricing-skill/ in Ihr Claude Code Skills-Verzeichnis unter ~/.claude/skills/deal-desk-pricing/ (oder laden Sie es als Skill in ein Claude.ai-Projekt hoch). Die SKILL.md ist der Einstiegspunkt; Claude lädt die drei Dateien unter references/ automatisch, wenn der Skill läuft.
Rubric codifizieren. Bearbeiten Sie references/1-discount-rubric.md mit Ihren tatsächlichen Segmentdefinitionen, Term-Incentive-Tabelle, Volumenrabatt-Tiers, Zahlungsterm-Grenzen, Ramp-Formen, gestapelten Rabatt-Obergrenzen und DOA-Matrix. Seien Sie bei jedem Schwellenwert explizit. Der Skill wendet das Rubric deterministisch an — er liest, was Sie geschrieben haben, und nichts anderes, wenn er In-Policy vs. Exception-Needed vs. Out-of-Policy klassifiziert.
Vergleichbare-Deal-CSV erstellen. Legen Sie eine Geschwisterdatei unter references/comparable-deals.csv ab, die dem Schema in references/2-comparable-deal-format.md entspricht. Füllen Sie die letzten 8 Quartale nicht standardmäßiger Deals nach — einschließlich abgelehnter, verlorener und zurückgezogener Deals, nicht nur won. Anonymisieren Sie Kundennamen. Der Skill ist nur so gut wie diese CSV, und eine CSV voller won-Deals trainiert den Skill, alles abzusegnen.
Eskalations-Trigger einstellen. Bearbeiten Sie references/3-escalation-criteria.md, um Ihrer DOA-Matrix und Ihrer Strategic-Accounts-Liste zu entsprechen. Beginnen Sie konservativ (die Defaults werden zu viel eskalieren) und lockern Sie vierteljährlich, nachdem Sie beobachtet haben, was geflaggt wird.
Mit Salesforce verknüpfen. Der Skill erwartet einen deal_record-Input — entweder ein strukturiertes JSON aus Salesforce eingefügt oder eine Salesforce-Opportunity-ID, die über den bevorzugten MCP/Connector Ihres Teams aufgelöst wird. Setzen Sie SFDC_TOKEN, wenn Sie über einen Connector aufrufen. Der Skill selbst ist schreibgeschützt gegen Salesforce; er schreibt nie zurück.
Gegen drei Deals testen, die Sie bereits überprüft haben. Wählen Sie zwei In-Policy und einen Exception-Needed. Führen Sie den Skill aus, vergleichen Sie seine Empfehlung mit dem, was das Team tatsächlich entgegengesetzt hat, und stimmen Sie das Rubric oder die Eskalationskriterien ab, bis der Output des Skills wie das eigene Denken des Deal Desks liest.
Was der Skill tatsächlich macht
SKILL.md führt fünf Schritte in Reihenfolge aus. Engineering-Entscheidungen werden für jeden Schritt benannt; die Zwei-Pass-Form — zuerst Vergleichs-Deals ziehen und Rubric laden, dann evaluieren; dann gegen Eskalations-Trigger erneut prüfen — ist die tragende Design-Entscheidung.
Rubric laden und Vergleichs-Deals ziehen, in dieser Reihenfolge. Der Skill fragt die vergleichbare Deal-Historie nach den nächsten 5-10 Analogien nach Segment, ACV-Band, Laufzeit und Wettbewerbskontext vor der Bewertung der Anfrage ab. Das erste Ziehen von Vergleichs-Deals verhindert, dass die Empfehlung auf die Nominalantwort des Rubrics verankert. Ein Rubric-Tier könnte „10 % für 3 Jahre” sagen, aber wenn die letzten acht 3-Jahres-Deals in diesem Segment alle zu 14–16 % abgeschlossen wurden, liegt die Anfrage im Einklang mit dem Präzedenzfall, auch wenn sie außerhalb des Nominals liegt. Der Reviewer braucht beide Signale, um intelligent entgegenzuhalten.
Rubric deterministisch anwenden. Jede Zeile des vorgeschlagenen Angebots wird gegen das Rubric geprüft. Für jede Dimension (Rabatt %, Laufzeit, Zahlungsbedingungen, Ramp, Co-Term) berechnet der Skill In-Policy / Exception-Needed / Out-of-Policy und zitiert den spezifischen Rubric-§. Der Skill interpretiert Schwellenwerte nicht neu; er rendert das Urteil des Rubrics mit Zitaten. Wenn das Rubric schweigt, liest die Zeile „Rubric behandelt dies nicht” statt dass der Skill eine Zahl improvisiert.
Empfohlenen Gegenvorschlag berechnen. Angesichts des Rubric-Urteils und der vergleichbaren Evidenz produziert der Skill einen einzigen Gegenvorschlag, ausgedrückt als Delta von der Anfrage des AE. Zwei Regeln: Das effektive Preisziel des Käufers treffen (oder innerhalb von zwei Punkten landen), wenn das Rubric eine Struktur unterstützt, die das schafft; nie einen Gegenvorschlag empfehlen, der alle verfügbaren Zugeständnisse bis zur Rubric-Obergrenze stapelt — das ist mathematisch korrekt gegen das Rubric und kommerziell katastrophal.
Eskalationsprüfung. Die gerenderte Empfehlung wird erneut gegen die Eskalationskriterien gelesen. Hard-Trigger (über-Ceiling-Rabatt, sub-12-Monats-Enterprise-Laufzeit, benutzerdefinierte rechtliche Bedingungen, strategischer Logo-Kunde, AE-Muster-Schwellenwert) setzen escalation: required und nennen den Genehmiger. Dünne Evidenz (unter drei Analogien) bei einer Out-of-Policy-Anfrage eskaliert ebenfalls, mit Begründung „Ausreißer — unzureichende Analog-Evidenz.” Ausreißer gehen an einen Menschen, der über sie nachdenken kann; der Skill erfindet kein Präzedenzfall.
Strukturierte Empfehlung rendern. Markdown mit Header, Eskalationsblock, Anfrage-Zusammenfassungstabelle, Empfohlener-Gegenvorschlag-Abschnitt, Vergleichbare-Deal-Evidenz-Tabelle, Begründung und Reviewer-Notizen. Jede Zeile zitiert entweder einen Rubric-§ oder eine Analog-ID. Der Header enthält immer „Entscheidungsunterstützung, keine Genehmigung.”
Kostenrealität
Die Token-Kosten sind die dominante Variable und skalieren mit der Größe des Rubrics und der Anzahl der gezogenen Vergleichs-Deals, nicht mit dem Deal selbst. Ein typischer Run lädt ein 2–3k-Token-Rubric, zieht 5–10 Analog-Zeilen aus der CSV (≈ 500–1,5k Token), empfängt einen 1–2k-Token-deal_record und rendert einen 1–2k-Token-Output.
Die eingesparte Zeit pro Deal ist der Teil, der die Token-Rechnung bezahlt. Eine typische nicht standardmäßige Anfrage verbraucht 30–90 Minuten Deal-Desk-Zeit: Das Rubric ziehen, Analogien in Salesforce finden, gegen die DOA-Matrix prüfen, die Gegenvorschlag-Begründung entwerfen. Der Skill komprimiert die Vorbereitung auf unter fünf Minuten; der Reviewer verbringt die eingesparte Zeit mit Urteilsvermögen, nicht mit dem Zusammenstellen der Inputs.
Bei einem typischen Mid-Market-RevOps-Volumen von 60 nicht standardmäßigen Anfragen pro Monat (40 Exception-Needed, 15 Out-of-Policy, 5 Strategisch) belaufen sich die monatlichen Kosten auf Sonnet auf etwa 3–5 $; auf Opus auf etwa 15–25 $. Beide Bänder runden sich auf Rauschen gegenüber den Gehaltskosten einer Stunde eines Deal-Desk-Reviewers.
Erfolgsmetrik
Verfolgen Sie zwei Metriken. Sie sollten sich in entgegengesetzte Richtungen bewegen; wenn sich beide in dieselbe Richtung bewegen, haben Sie ein Kalibrierungsproblem.
Time-to-Counter. Wanduhr von „AE hat Anfrage eingereicht” bis „Reviewer hat Gegenvorschlag an AE gesendet.” Baseline vor diesem Skill ist typischerweise 4–48 Stunden (Queuing, Abruf, Entwurf). Ziel nach Adoption ist unter 30 Minuten für Routineanfragen (Skill-Run + Reviewer-Bearbeitung + Senden).
Eskalationsrate bei nicht-trivialen Anfragen. Von den Anfragen, die der Skill als Exception-Needed oder Out-of-Policy flaggt, welcher Anteil erreicht den namentlichen Genehmiger in der DOA-Matrix? Das sollte steigen, wenn der Skill korrekt kalibriert ist — die Eskalations-Trigger existieren, um Anfragen aufzuzeigen, die ein erfahrenes Auge brauchen und die früher abgesegnet wurden, weil niemand Zeit hatte, die Analogien zu ziehen. Wenn die Rate sinkt, pflastert der Skill zu sehr und die Kriterien in references/3-escalation-criteria.md müssen enger gesetzt werden.
Wenn die Time-to-Counter sinkt und die Eskalationsrate steigt, funktioniert der Skill. Wenn nur das Erste passiert, haben Sie eine Konfidenzmaschine gebaut, die Margenrisiken verbirgt.
Vergleich mit Alternativen
CPQ-Regeln (Salesforce CPQ, DealHub usw.). CPQ ist das richtige Tool für deterministische In-Policy-Durchsetzung: Listenpreis-Kataloge, Genehmigungsrouting bei Rabatt-Tiers, automatische Konfigurationsvalidierung. Verwenden Sie CPQ für den Fast-Path. Verwenden Sie diesen Skill auf CPQ drauf für die Anfragen, die CPQ als genehmigungsbedürftig flaggt — wo die Entscheidung ist „was entgegnen wir”, nicht „ist das In-Policy”. CPQ sagt Ihnen, dass die Anfrage Out-of-Policy ist; der Skill hilft Ihnen, sie zu countern.
Salesforce-Discount-Approval-Flows. Native Approval-Flows routen eine Ausnahme an den richtigen Genehmiger. Sie produzieren weder den empfohlenen Gegenvorschlag noch zeigen sie die vergleichbare Deal-Evidenz auf. Verwenden Sie Approval-Flows als Routing-Schicht; verwenden Sie diesen Skill, um den Kontext zu befüllen, den der Genehmiger liest, bevor er entscheidet.
Manuelle Deal-Desk-Überprüfung. Ein geschulter Deal-Desk-Reviewer produziert den besten Gegenvorschlag, wenn er Zeit hat, die Analogien zu ziehen und das Rubric erneut zu lesen. Die Einschränkung ist der Durchsatz: Ein typischer Reviewer bearbeitet 8–15 nicht standardmäßige Anfragen pro Tag, bevor die Abrufarbeit die Urteilsarbeit verdrängt. Verwenden Sie den Skill als Abruf-und-Erststufen-Entwurfsschicht; der Reviewer verbringt seine Zeit mit dem Gegenvorschlag, nicht mit dem Zusammenstellen der Inputs dafür.
Tabellenkalkulations-Rubric-Rechner. Manche Teams bauen ein Excel-Sheet, das ACV, Laufzeit und Rabatt nimmt und „In-Policy / Exception” zurückgibt. Günstig, schnell und spröde: Es kennt keine Analogien, keinen Wettbewerbskontext, keine AE-Muster-Trigger, und es stirbt beim ersten Mal, wenn das Rubric eine neue Dimension erhält. Verwenden Sie die Tabellenkalkulation für den AE-Self-Service; verwenden Sie den Skill, wenn die Anfrage beim Deal Desk ankommt.
Watch-outs
Over-Discounting-Empfehlung. Der Skill kann einen Gegenvorschlag produzieren, der die Lücke zum Käuferziel schließt, indem er alle verfügbaren Zugeständnisse stapelt (max. Rabatt, max. Term-Incentive, max. Zahlungsterm-Konzession). Das ist mathematisch korrekt gegen das Rubric und kommerziell katastrophal — es lässt nichts auf dem Tisch für die Verhandlung. Guard: Die Empfehlung deckt die gesamten gestapelten Zugeständnisse bei dem Niedrigsten von (Rubric-Ceiling) oder (Comparable-Median + eine Standardabweichung). Alles darüber löst das Eskalations-Flag mit Begründung „gestapelte Zugeständnisse übersteigen Präzedenzfall” aus.
Veraltetes Rubric. Die Preispolitik ändert sich vierteljährlich, manchmal schneller (eine neue Verpackung startet, ein Wettbewerber bewegt sich beim Preis, ein Segment wird neu geschnitten). Ein Skill, der gegen ein sechs Monate altes Rubric läuft, empfiehlt einen Gegenvorschlag, den das Team nicht mehr anbietet. Guard: Der Skill prüft das last_edited-Datum im Rubric-Frontmatter und stellt der Reviewer-Notiz ein „Rubric möglicherweise veraltet (zuletzt bearbeitet YYYY-MM-DD)“-Warning voran, wenn es mehr als 90 Tage alt ist. Der Reviewer ist verantwortlich für das Auffrischen des Rubrics in einem Kalender; der Skill zeigt die Veraltung auf, damit sie sich nicht versteckt.
Fehlender Wettbewerbskontext. Ein Deal, bei dem der Käufer einen Wettbewerber und ein enges Abschlussdatum genannt hat, verdient einen anderen Gegenvorschlag als ein Deal im Vakuum, auch wenn die Rubric-Urteile identisch sind. Guard: Wenn competitive_context angegeben wird, referenziert der Begründungsabschnitt ihn explizit und die Empfehlung prüft, ob eine Analogie unter vergleichbarem Wettbewerbsdruck eine andere Form angenommen hat. Wenn deal_record einen Wettbewerber flaggt, aber competitive_context leer ist, gibt der Skill eine Aufforderung zurück, in der der Reviewer gebeten wird, mit ausgefülltem Kontext erneut auszuführen, anstatt einen kontextblinden Gegenvorschlag zu produzieren.
Analogie-Auswahlbias. Eine vergleichbare Deal-CSV voller „wir haben alles genehmigt”-Deals trainiert den Skill, zukünftige Anfragen abzusegnen. Guard: Jede Analogie in der Evidenztabelle enthält ihren Genehmigungsstatus (genehmigt, abgelehnt, an Wettbewerber verloren, zurückgezogen). Der Reviewer sieht den Genehmigungsmix und kann das Kurationsproblem erkennen; der Skill flaggt auch „keine abgelehnten Analogien in den letzten 20” als Kalibrierungsnotiz in den Reviewer-Notizen.
Empfehlung als Genehmigung zitiert. Nachgelagerte Leser (AE, Kunde, manchmal der Manager des AE) behandeln die Empfehlung manchmal als den genehmigten Gegenvorschlag. Guard: Jeder Output-Header enthält „Entscheidungsunterstützung, keine Genehmigung.” und der Eskalationsblock nennt den tatsächlichen Genehmiger in der DOA-Matrix. Wenn die Empfehlung als Gegenvorschlag weitergeleitet wird, ohne den menschlichen Reviewer zu durchlaufen, macht die Namensgeber-Zeile die Prozesslücke selbst offensichtlich.
Stack
Kombinieren Sie mit Vertragsredline mit Claude für den Verhandlungsphasen-Workflow, der nach der Einigung auf den Gegenvorschlag läuft, und mit Vertragszusammenfassung mit Claude für die Post-Signature-Zielgruppenzusammenfassung. Der Deal-Desk-Skill sitzt in der Mitte: nachdem CPQ die Anfrage flaggt, vor dem Redline.
Salesforce — Opportunity- und Angebotsdaten, Genehmigungsrouting
Claude — Rubric-Evaluation, Vergleichs-Deal-Ziehung, Gegenvorschlag-Empfehlung, Eskalationsprüfung
---
name: deal-desk-pricing
description: Review a proposed deal against pricing and discount policy and return a structured recommendation — recommended discount, rubric-cited rationale, comparable-deal evidence, and an explicit escalation flag when the ask sits outside what the rubric covers. The skill is decision support for the deal-desk reviewer; it never auto-approves, never auto-discounts, and never substitutes for the human reviewer.
---
# Deal desk pricing review
## When to invoke
Whenever an AE submits a non-standard pricing ask and a deal-desk reviewer has to decide what to counter with: a multi-year discount request, an upfront-payment-for-discount swap, a ramp structure, a custom payment term, a co-term against an existing contract. The skill takes the proposed deal terms, your discount rubric, and the comparable-deal history, and returns a structured Markdown recommendation that the deal-desk reviewer reads, edits, and decides on.
The output is a reading aid for the human reviewer. It exists to shorten the time between "AE submitted the ask" and "reviewer has the context to counter" — typically from days down to minutes for routine asks — without taking the decision away from the human.
Do NOT invoke this skill for:
- **Final approval.** The skill recommends; it does not approve. Approval authority sits with the named human approver in your DOA (delegation of authority) matrix. The skill output is an input to that decision, not a substitute for it.
- **Auto-discounting.** The skill never applies a discount to a quote or a CPQ record. It produces a recommendation the reviewer types into the quote (or rejects). Wiring auto-discount on the back of an LLM recommendation is the failure mode this skill is designed to avoid.
- **Anything skipping the deal-desk human review.** If your team has a fast-path for in-policy deals, run that fast-path through CPQ rules — not this skill. This skill exists for the asks that need judgment; bypassing the human on those is exactly the wrong place to remove a checkpoint.
- **Non-Tier-A AI vendors.** Run on Claude only (workspace or team plan whose data-handling posture you have reviewed). Pricing rubrics and comparable-deal histories are commercially sensitive; do not pipe them through consumer LLMs.
## Inputs
- Required: `deal_record` — the proposed deal as structured data (Salesforce Opportunity + Quote line items, or pasted JSON). Must include: ACV, term length, payment terms, list price per line, ask (the AE's proposed discount/structure), customer name, segment, competitive context if known.
- Required: `pricing_rubric` — the path to your team's discount rubric (defaults to `references/1-discount-rubric.md`). The skill evaluates the ask against this file deterministically; without it, the skill refuses to render.
- Required: `comparable_deals` — the path to your comparable-deal history (defaults to `references/2-comparable-deal-format.md` for schema, with a sibling CSV the user maintains). The skill pulls the closest 5-10 historical analogs and includes them as evidence.
- Optional: `escalation_criteria` — overrides the default at `references/3-escalation-criteria.md`. Use when a specific deal needs tighter triggers (e.g. a strategic logo where any non-policy ask escalates to the CRO regardless of size).
- Optional: `competitive_context` — free-text notes on competing bids, displacement target, urgency. Folded into the rationale section when present.
## Reference files
Always load the following from `references/` before producing the recommendation. Without them the skill falls back to generic advice and misses the specific thresholds, analogs, and escalation paths that make the recommendation actionable.
- `references/1-discount-rubric.md` — the discount tiers, multi-year incentive math, payment-term boundaries, and approval thresholds the skill evaluates the ask against. Replace the template with your team's actual rubric on first install.
- `references/2-comparable-deal-format.md` — the schema for the comparable-deal history. The skill pulls analogs from a sibling CSV the user maintains in the same shape; this file documents the columns and how the skill ranks "comparable."
- `references/3-escalation-criteria.md` — the trigger list that forces the skill to set the escalation flag and route to a named approver rather than recommending an in-policy counter. Tune this to your DOA matrix; the defaults are conservative.
## Method
Run these five sub-tasks in order. The skill is single-pass per section but two-pass overall: pull comparables and load the rubric first, then evaluate; then re-check against escalation triggers before rendering. Engineering choices are named below.
### 1. Load rubric and pull comparables (first, not last)
Load the discount rubric verbatim. Then query the comparable-deal history for the closest 5-10 analogs by segment, ACV band, term length, and (when present) competitive context. Pull comparables *before* evaluating the ask, not after.
Why first: pulling comparables after evaluating the ask biases the recommendation toward the rubric's nominal answer. A rubric tier might say "10% for 3-year," but if the last eight 3-year deals in this segment all closed at 14-16%, the ask is in line with precedent even if it sits outside the nominal tier. The reviewer needs both signals to counter intelligently.
If fewer than three comparables exist, record that explicitly. Do not pad the list with deals from a different segment to hit a count.
### 2. Apply the rubric deterministically
Walk every line of the proposed quote against the rubric. For each dimension (discount %, term length, payment terms, ramp structure, co-term):
- Compute whether the ask sits in-policy, exception-needed, or out-of-policy according to the rubric.
- Cite the specific rubric section that drove the classification.
- For exception-needed and out-of-policy lines, name the approver in the rubric's DOA column.
Why deterministic: the rubric is the source of truth, not the skill's judgment. The skill renders the rubric's verdict with citations; it does not reinterpret. When the rubric is silent on a dimension, the skill marks the line "rubric does not address — see escalation" rather than improvising a threshold.
### 3. Compute the recommended counter
Given the rubric verdict and the comparable evidence, produce a single recommended counter. Two engineering rules:
- The counter must hit the buyer's effective price target (or be within 2% of it) when the rubric supports a structure that gets there. Trade discount for term, trade upfront discount for ramp, trade list-price hold for payment-term concession — whichever combination the rubric and analogs support.
- The counter must be expressible as a delta from the AE's ask, not a from-scratch quote. The reviewer needs to see "your ask was X, counter Y, here's why" — not a rebuild they have to map back.
If no in-policy counter hits the buyer's target, the recommendation section says so explicitly and the escalation flag in the next step fires.
### 4. Escalation check (the human-review fallback)
Re-read the rendered recommendation against the escalation criteria. For each trigger:
- If a hard trigger fires (discount > X%, term < Y months, custom legal terms, customer on the strategic-logo list, AE has run more than N exception requests this quarter), set `escalation: required` in the output and name the approver.
- If the comparable evidence is thin (< 3 analogs) and the ask is out-of-policy on any dimension, set `escalation: required` with reason "outlier — insufficient analog evidence." Outliers go to a human who can reason about them; the skill does not invent precedent.
- If the rubric is silent on a dimension the ask touches (a new packaging, an unfamiliar geo, a new payment instrument), set `escalation: required` with reason "rubric does not cover."
Why a fallback to "needs human review": the skill is decision support, not decision-making. When the rubric or analogs cannot support a confident counter, the skill explicitly hands the decision to a human rather than picking the closest tier and hoping. The named approver receives the recommendation as context; the decision is theirs.
### 5. Render the structured recommendation
Render exactly the format below. Every line cites either a rubric section or a comparable-deal ID. Anything the rubric does not address renders as `rubric does not address`, never elided.
## Output format
Render exactly this structure. The `escalation` block at the top fires only when step 4 set the flag.
```markdown
# Deal desk recommendation — {Customer} / {Opp ID} ({Date})
> Reviewer: {deal-desk reviewer name}
> Prepared by: deal-desk-pricing skill (Claude). Decision support, not approval.
> Rubric loaded: {filename}, last edited {date}.
> Comparables pulled: {N} analogs from {segment}, {term} band.
## Escalation
- **escalation: {required | not required}**
- Approver: {named approver from DOA matrix, or "n/a"}
- Reason: {trigger that fired, or "in-policy / sufficient evidence"}
## Ask summary
| Dimension | AE ask | List | Verdict | Rubric § |
|---|---|---|---|---|
| Discount % | 22% | — | exception-needed | §3.2 |
| Term | 36 months | — | in-policy | §2.1 |
| Payment terms | Net-60 | Net-30 | exception-needed | §4.1 |
| Ramp | Y1 50% / Y2 100% | flat | rubric does not address | — |
## Recommended counter
- **Discount**: 18% (vs. AE ask of 22%) — within rubric §3.2 for
3-year deals in this segment; comparable median is 17% (analog
IDs: D-2284, D-2301, D-2317).
- **Term**: 36 months — matches AE ask; in-policy.
- **Payment terms**: Net-45 (vs. AE ask of Net-60) — rubric §4.1
caps Net-X at 45 absent CFO approval; comparable median Net-30,
but Net-45 has 3 recent precedents (D-2298, D-2310, D-2322).
- **Ramp**: defer to escalation — rubric does not cover; closest
analog (D-2305) used a flat structure with a one-time first-year
credit.
Effective price to buyer at counter: {$X ACV / $Y over term} — vs.
buyer target of {$Z}. Gap: {amount, % of target}.
## Comparable-deal evidence
| Analog | Segment | ACV | Term | Discount | Payment | Approved by | Notes |
|---|---|---|---|---|---|---|---|
| D-2284 | Mid-market | $180k | 36mo | 17% | Net-30 | VP Sales | Standard close |
| D-2301 | Mid-market | $210k | 36mo | 16% | Net-30 | VP Sales | Competing with X |
| D-2317 | Mid-market | $195k | 36mo | 18% | Net-45 | CRO | Strategic logo |
## Rationale
{2-4 sentences explaining the counter. Cite rubric §s and analog
IDs, not the skill's own opinion. Surface competitive context if
present in the input.}
## Reviewer notes
- {Anything the skill noticed but cannot resolve — e.g. "AE has
submitted 4 non-policy asks this quarter, threshold is 3 — see
escalation criteria §2"}
- {Stale-rubric warning if the rubric was last edited > 90 days ago}
```
## Watch-outs
- **Over-discounting recommendation.** The skill can produce a counter that closes the gap to the buyer's target by stacking every available concession (max discount, max term incentive, max payment-term concession). That is mathematically correct against the rubric and commercially terrible — it leaves nothing on the table for the negotiation. Guard: the recommendation section caps total stacked concessions at the lesser of (rubric ceiling) or (comparable median + one standard deviation). Anything above that fires the escalation flag with reason "stacked concessions exceed precedent."
- **Stale rubric.** Pricing policy changes quarterly, sometimes faster. A skill running against a rubric that was edited six months ago will recommend a counter the team no longer offers. Guard: the skill checks the `last_edited` date in the rubric frontmatter and prepends a "Rubric may be stale (last edited {date})" warning to the reviewer notes when the date is more than 90 days old. The reviewer is responsible for refreshing the rubric on a calendar; the skill surfaces the staleness so it does not hide.
- **Ignoring competitive pressure.** A deal where the buyer named a competitor and a tight close date deserves a different counter than a deal in a vacuum, even when the rubric verdicts are identical. Guard: when `competitive_context` is provided, the rationale section must reference it explicitly and the recommendation section must check whether any analog under comparable competitive pressure took a different shape. If `competitive_context` is absent on a deal where the AE flagged a competitor in `deal_record`, the skill prompts the reviewer to re-run with the context filled in rather than producing a context-blind counter.
- **Analog selection bias.** If the comparable-deal history is full of "we approved everything" deals, the analog evidence will rubber-stamp future asks. Guard: the skill includes the approval status of every analog (approved, rejected, lost-to-competitor, withdrawn) in the comparable-deal evidence table. The reviewer sees the approval mix and can spot the curation problem; the skill also flags "no rejected analogs in last 20" as a calibration note in the reviewer notes.
- **Recommendation cited back as approval.** Downstream readers (AE, customer, sometimes the AE's manager) sometimes treat the recommendation as the approved counter. Guard: the output header always includes "Decision support, not approval." and the escalation block names the actual approver in the DOA matrix. If the recommendation is forwarded as the counter without going through the human reviewer, the named approver line makes the process gap self-evident.
# Comparable-deal history — FORMAT
> This file documents the schema. The actual data lives in a sibling
> CSV at `references/comparable-deals.csv` that the user maintains.
> The deal-desk-pricing skill pulls 5-10 closest analogs from the CSV
> on every run and includes them as evidence in the recommendation.
## Why we maintain this separately
Salesforce has the data, but Salesforce reports do not capture the *reasoning* behind a non-standard deal — why we agreed to Net-60, which competitor was on the table, what the strategic justification was. The CSV captures that reasoning so the skill can surface analogs that look like the current ask not just by numbers but by context.
## CSV schema
The skill expects the following columns. Header row required, exact column names, case-sensitive.
| Column | Type | Required | Notes |
|---|---|---|---|
| `analog_id` | string | yes | Stable ID, used to cite in recommendations (e.g. `D-2284`) |
| `closed_date` | YYYY-MM-DD | yes | Date the deal closed (or was rejected/lost) |
| `customer_anonymized` | string | yes | Anonymized name (e.g. "Mid-market SaaS Co", not real name) |
| `segment` | enum | yes | One of: `smb`, `mid-market`, `enterprise`, `strategic` |
| `acv_usd` | int | yes | Annual contract value in USD |
| `tcv_usd` | int | yes | Total contract value across the term |
| `term_months` | int | yes | Contractual term length |
| `discount_pct` | float | yes | Effective discount off list, 0-100 |
| `payment_terms` | string | yes | One of: `Net-30`, `Net-45`, `Net-60`, `Net-90`, `Custom` |
| `ramp_shape` | string | yes | One of: `flat`, `Y1-50/Y2-100`, `Y1-25/Y2-75/Y3-100`, `custom` |
| `competitor_in_deal` | string | no | Named competitor, or empty |
| `competitive_pressure` | enum | no | `high`, `medium`, `low`, or empty |
| `approved_by` | string | yes | Approver name from DOA, or `lost`, `withdrawn`, `rejected` |
| `outcome` | enum | yes | `won`, `lost`, `withdrawn`, `rejected` |
| `notes` | string | no | Free-text reasoning, max 200 chars |
## Curation rules
The skill is only as good as the CSV. Three rules to follow:
1. **Include rejected and lost deals.** A history full of `won` deals trains the skill to rubber-stamp. Aim for at least 20% non-`won` in the trailing 12 months. The skill flags "no rejected analogs in last 20" as a calibration note.
2. **Anonymize customer names.** The CSV travels with the bundle and may be loaded into a Claude session. Anonymize to "Mid-market SaaS Co" / "Enterprise Manufacturing Co" rather than real names, unless your DPA explicitly covers commercial-terms data.
3. **Refresh quarterly.** Add new closed deals at quarter close. Prune deals older than 8 quarters — pricing context decays and stale analogs distort the recommendation.
## How the skill ranks "comparable"
Analogs are ranked by similarity to the current deal across:
1. `segment` — must match. The skill never crosses segments for analogs.
2. `acv_usd` — within ±50% of the current ACV.
3. `term_months` — within ±12 months of the current term.
4. `competitive_pressure` — when the current deal has competitive context, prefer analogs with matching pressure level.
5. `closed_date` — recency tiebreaker; never prefer older over newer when the other dimensions are equal.
If fewer than 3 analogs match, the skill records that explicitly rather than relaxing the criteria. Thin evidence is itself a finding.
## Example row
```csv
analog_id,closed_date,customer_anonymized,segment,acv_usd,tcv_usd,term_months,discount_pct,payment_terms,ramp_shape,competitor_in_deal,competitive_pressure,approved_by,outcome,notes
D-2284,2026-02-15,Mid-market SaaS Co,mid-market,180000,540000,36,17,Net-30,flat,,,VP Sales,won,"Standard close, no competitive pressure"
```
## Last edited
{YYYY-MM-DD} — bump on every schema change. Adding a column requires a one-time backfill or the skill will skip rows missing the new field.
# Escalation criteria — TEMPLATE
> Replace this template with your team's actual escalation triggers.
> The deal-desk-pricing skill checks every recommendation against
> this file before rendering. When a trigger fires, the skill sets
> `escalation: required` in the output header and names the approver
> from the DOA matrix in `1-discount-rubric.md` §8.
## Why escalation is the human-review fallback
The skill is decision support, not decision-making. When the rubric or analogs cannot support a confident counter, the right move is to hand the decision to a named human — not to pick the closest tier and hope. This file enumerates the cases where that handoff is mandatory.
## §1. Hard triggers (always escalate)
If any of these is true, the skill sets `escalation: required` and names the approver. The recommendation is still rendered — as context for the human, not as the answer.
| Trigger | Approver | Reason |
|---|---|---|
| Discount > stacked ceiling in rubric §6 | CRO + CFO | Above DOA limit |
| Term < 12 months on deal > $100k ACV | VP Sales | Short-term enterprise risk |
| Payment terms beyond Net-90 | CFO | Cash flow exposure |
| Custom legal terms (MFN, uncapped indemnity, data residency) | CFO + GC | Outside deal-desk scope |
| Strategic-logo customer (per `references/strategic-accounts.md`) | CRO + CEO | Strategic deal review |
| Custom ramp shape not in rubric §5 | VP Sales + Finance | Contract structure exception |
| Custom payment instrument (PO + milestone, deferred billing) | CFO + GC | Amendment required |
## §2. AE-pattern triggers (escalate when threshold exceeded)
The skill counts non-policy asks per AE per quarter. When an AE crosses the threshold, every subsequent ask escalates regardless of size — a calibration loop forcing a manager conversation.
| Threshold | Action |
|---|---|
| AE has submitted ≥ 3 exception-needed asks in current quarter | Next ask escalates to AE manager |
| AE has submitted ≥ 5 exception-needed asks in current quarter | Next ask escalates to VP Sales + manager review |
| AE has submitted ≥ 8 exception-needed asks in current quarter | Pause: deal desk lead reviews territory before processing more |
The skill reads the AE's running count from a sibling counter file the user maintains, or from a Salesforce report ID configured in `SFDC_EXCEPTION_REPORT_ID`. If neither is configured, this section is skipped with a one-line note in the reviewer notes.
## §3. Evidence-thinness triggers (escalate when analogs are thin)
The skill cannot reason about deals it has no precedent for. When the comparable-deal pull returns thin or contradictory evidence, escalate.
| Trigger | Approver | Reason |
|---|---|---|
| Fewer than 3 comparable analogs found | VP Sales | Outlier — insufficient analog evidence |
| Analogs split (≥ 30% rejected/lost) on a similar ask | VP Sales | Mixed precedent, needs judgment |
| No analog in current quarter for this segment | Deal desk lead | Possible market shift |
| Rubric is silent on a dimension the ask touches | VP Sales + Finance | New packaging / new geo / new instrument |
## §4. Stale-data triggers (warn, do not block)
These do not force escalation but render a warning in the reviewer notes. The reviewer decides whether the staleness is material.
- Rubric `last_edited` > 90 days old
- Comparable-deal CSV `last refreshed` > 90 days old
- Strategic-accounts list `last_edited` > 180 days old
## §5. Competitive-context triggers
When `competitive_context` is provided in the input:
| Signal in competitive context | Action |
|---|---|
| Named competitor in active POC | Recommendation must reference; rationale must address displacement framing |
| Tight close date (< 14 days) and competitor named | Escalate to VP Sales for fast-track approval |
| Procurement-driven RFP with multiple finalists | Escalate to deal desk lead for final-round pricing strategy |
When `deal_record` flags a competitor but `competitive_context` is empty, the skill does not produce a context-blind counter — it returns a prompt asking the reviewer to re-run with the context filled in.
## How to tune this file
- Start conservative. The defaults above will over-escalate; that is intentional during the first month so the team sees what kinds of asks the skill flags.
- Loosen quarterly. After watching 4-8 weeks of escalations, drop triggers that consistently round-trip back to deal desk with no changes from the named approver.
- Tighten on incidents. After any deal that closed in-policy via the skill but caused a problem post-sale (margin miss, renewal surprise, legal escalation), add a trigger that would have caught it.
## Last edited
{YYYY-MM-DD} — bump on every change. The skill does not warn on this file's age (escalation is supposed to be a backstop, not a moving target), but track changes for your own audit.
