claude-skill

Révision tarifaire du deal desk avec Claude

Difficulty

intermédiaire

Setup time

60min

For

revops · deal-desk

RevOps

Stack

Un Claude Skill qui examine une transaction non standard contre votre référentiel de remises et votre historique de transactions comparables, puis retourne une recommandation Markdown structurée : la contre-proposition recommandée, les sections du référentiel qui la justifient, les analogues historiques qui l’étayent, et un flag d’escalade explicite quand la demande sort du périmètre couvert par le référentiel. Le skill est une aide à la décision pour le réviseur du deal desk ; il n’approuve jamais automatiquement, ne remise jamais automatiquement, et ne se substitue jamais à l’approbateur nommé dans la matrice DOA. Il existe pour réduire le temps entre « le commercial a soumis la demande » et « le réviseur dispose du contexte pour contrer intelligemment » — typiquement de jours à minutes pour les demandes courantes — sans retirer la décision à l’humain.

Le bundle se trouve dans /artifacts/deal-desk-pricing-skill/ : le SKILL.md est le point d’entrée et les trois fichiers sous references/ sont les paramètres modifiables que le skill charge à chaque exécution — le référentiel de remises, le schéma des transactions comparables, et les critères d’escalade que le skill vérifie avant de rendre.

Quand utiliser

Déployez ce skill quand un commercial soumet une demande de tarification non standard et qu’un réviseur du deal desk doit décider quoi contre-proposer :

Une demande de remise multi-annuelle qui cumule l’incitation de durée sur une remise de volume.
Un échange paiement-anticipé-contre-remise ou une concession de délai de paiement Net-60/Net-90.
Une structure de montée en puissance (A1 50 % / A2 100 %, formes personnalisées) qui nécessite de vérifier la durée contractuelle contre le référentiel.
Une co-durée contre un contrat existant où l’acheteur veut la remise effective pondérée sur les contrats joints.
Une transaction concurrentielle où le commercial a nommé un concurrent et une date de clôture serrée, et où le réviseur a besoin des analogues qui ont conclu sous une pression similaire.

Le skill retourne une recommandation Markdown avec la contre-proposition recommandée, les § du référentiel et les IDs d’analogues qui la justifient, et un bloc d’escalade en haut qui se déclenche quand la demande sort du périmètre du référentiel. Le réviseur la lit, la modifie, et décide.

Quand NE PAS utiliser

N’utilisez pas ce skill — et ne le câblez pas dans quoi que ce soit qui fait ces choses automatiquement :

Approbation finale. Le skill recommande ; il n’approuve pas. L’autorité d’approbation appartient à l’humain nommé dans la matrice DOA (references/1-discount-rubric.md §8). La sortie du skill est une entrée pour cette décision, pas un substitut. Câbler une approbation au-dessus d’une recommandation LLM est exactement le mauvais endroit pour supprimer un point de contrôle.
Auto-remise sur le devis. Le skill n’écrit jamais une remise dans un enregistrement CPQ ni dans un devis Salesforce. Il produit une recommandation que le réviseur saisit dans le devis (ou rejette). L’application automatique d’une recommandation LLM à un devis en cours est le mode d’échec que ce skill est conçu pour éviter.
Tout ce qui court-circuite la révision humaine du deal desk. Si votre équipe dispose d’un chemin rapide pour les transactions conformes à la politique — durée unique, prix catalogue, aucune exception — faites passer ce chemin rapide par les règles CPQ. Le CPQ est le bon outil pour l’application déterministe des politiques ; il est plus rapide, moins coûteux, et favorable à l’audit. Ce skill existe pour les demandes qui nécessitent un jugement, et sur ces demandes contourner l’humain est exactement le mauvais endroit pour supprimer un point de contrôle.
Fournisseurs IA non-Tier-A. Exécutez sur Claude (plan workspace ou team dont vous avez revu la posture de traitement des données). Les référentiels de remises et les historiques de transactions comparables sont commercialement sensibles ; ne les faites pas passer par des LLMs grand public.

Configuration

Déposer le bundle. Copiez /artifacts/deal-desk-pricing-skill/ dans votre répertoire de skills Claude Code à ~/.claude/skills/deal-desk-pricing/ (ou téléversez comme Skill dans un projet Claude.ai). Le SKILL.md est le point d’entrée ; Claude charge automatiquement les trois fichiers sous references/ quand le skill s’exécute.
Codifier votre référentiel. Modifiez references/1-discount-rubric.md avec vos définitions de segment réelles, votre tableau d’incitation de durée, vos paliers de remise de volume, vos limites de conditions de paiement, vos formes de montée en puissance, vos plafonds de remises cumulées, et votre matrice DOA. Soyez explicite sur chaque seuil. Le skill applique le référentiel de manière déterministe — il lit ce que vous avez écrit, et rien d’autre, lors de la classification conforme / exception-nécessaire / hors-politique.
Construire le CSV de transactions comparables. Déposez un fichier sibling dans references/comparable-deals.csv correspondant au schéma de references/2-comparable-deal-format.md. Rétro-alimentez les 8 derniers trimestres de transactions non standard — incluant les transactions rejetées, perdues, et retirées, pas seulement les won. Anonymisez les noms de clients. Le skill ne vaut que ce que vaut ce CSV, et un CSV plein de transactions won entraîne le skill à entériner.
Affiner les déclencheurs d’escalade. Modifiez references/3-escalation-criteria.md pour correspondre à votre matrice DOA et à votre liste de comptes stratégiques. Commencez conservative (les valeurs par défaut vont sur-escalader) et assouplissez trimestriellement après avoir observé ce qui est signalé.
Connecter à Salesforce. Le skill attend un input deal_record — soit un JSON structuré collé depuis Salesforce, soit un ID d’Opportunité Salesforce résolu via le MCP/connecteur préféré de votre équipe. Définissez SFDC_TOKEN si vous invoquez via un connecteur. Le skill lui-même est en lecture seule contre Salesforce ; il n’écrit jamais en retour.
Tester sur trois transactions déjà révisées. Choisissez deux conformes à la politique et une exception-nécessaire. Exécutez le skill, comparez sa recommandation avec ce que l’équipe a réellement contre-proposé, et affinez le référentiel ou les critères d’escalade jusqu’à ce que la sortie du skill ressemble à la propre réflexion du deal desk.

Ce que le skill fait réellement

SKILL.md exécute cinq étapes dans l’ordre. Les choix d’ingénierie sont nommés pour chaque étape ; la forme en deux passes — extraire les comparables et charger le référentiel d’abord, puis évaluer ; puis revérifier contre les déclencheurs d’escalade — est le choix de conception structurant.

Charger le référentiel et extraire les comparables, dans cet ordre. Le skill interroge l’historique des transactions comparables pour les 5 à 10 analogues les plus proches par segment, tranche ACV, durée, et contexte concurrentiel avant d’évaluer la demande. Extraire les comparables d’abord empêche la recommandation de s’ancrer sur la réponse nominale du référentiel. Un palier du référentiel peut indiquer « 10 % pour 3 ans », mais si les huit dernières transactions de 3 ans dans ce segment ont toutes conclu à 14 à 16 %, la demande est en ligne avec les précédents même si elle sort du palier nominal. Le réviseur a besoin des deux signaux pour contre-proposer intelligemment.
Appliquer le référentiel de manière déterministe. Chaque ligne du devis proposé est vérifiée contre le référentiel. Pour chaque dimension (% de remise, durée, conditions de paiement, montée en puissance, co-durée) le skill calcule conforme / exception-nécessaire / hors-politique et cite le § spécifique du référentiel. Le skill ne réinterprète pas les seuils ; il rend le verdict du référentiel avec citations. Quand le référentiel est silencieux, la ligne indique « le référentiel n’adresse pas ce cas » plutôt que le skill improvisant un chiffre.
Calculer la contre-proposition recommandée. Étant donné le verdict du référentiel et les preuves comparables, le skill produit une seule contre-proposition exprimée comme un delta par rapport à la demande du commercial. Deux règles : atteindre le prix effectif cible de l’acheteur (ou atterrir à deux points près) quand le référentiel supporte une structure qui y arrive ; ne jamais recommander une contre-proposition qui cumule toutes les concessions disponibles jusqu’au plafond du référentiel — c’est mathématiquement correct contre le référentiel et commercialement terrible.
Vérification d’escalade. La recommandation rendue est relue contre les critères d’escalade. Les déclencheurs stricts (remise au-dessus du plafond, durée enterprise sous 12 mois, conditions juridiques personnalisées, client logo stratégique, seuil de pattern commercial) définissent escalation: required et nomment l’approbateur. Une preuve mince (moins de trois analogues) sur une demande hors-politique escalade également, avec la raison « outlier — preuves analogues insuffisantes ». Les outliers vont vers un humain qui peut raisonner sur eux ; le skill n’invente pas de précédent.
Rendre la recommandation structurée. Markdown avec en-tête, bloc d’escalade, tableau de résumé de la demande, section de contre-proposition recommandée, tableau de preuves de transactions comparables, justification, et notes du réviseur. Chaque ligne cite soit un § du référentiel, soit un ID d’analogue. L’en-tête inclut toujours « Aide à la décision, pas une approbation. »

Réalité des coûts

Le coût en tokens est la variable dominante, et il évolue avec la taille du référentiel et le nombre de comparables extraits, pas avec la transaction elle-même. Une exécution typique charge un référentiel de 2 à 3 000 tokens, extrait 5 à 10 lignes d’analogues du CSV (≈ 500 à 1 500 tokens), reçoit un deal_record de 1 à 2 000 tokens, et rend une sortie de 1 à 2 000 tokens.

Profil	Tokens approx. par révision	Coût par révision (Sonnet)	Coût par révision (Opus)
Référentiel compact, 5 analogues	~6 000 / 1 500	~0,03 $	~0,16 $
Référentiel standard, 8 analogues	~10 000 / 2 000	~0,05 $	~0,25 $
Référentiel complet + contexte concurrentiel, 10 analogues	~16 000 / 2 000	~0,07 $	~0,36 $

Le temps économisé par transaction est la partie qui paye la facture de tokens. Une demande non standard typique consomme 30 à 90 minutes de temps deal desk : extraire le référentiel, trouver des analogues dans Salesforce, vérifier contre la matrice DOA, rédiger la justification de la contre-proposition. Le skill compresse la préparation à moins de cinq minutes ; le réviseur passe le temps économisé sur le jugement, pas sur l’assemblage des inputs.

Pour un volume RevOps mid-market typique de 60 demandes non standard par mois (40 exception-nécessaire, 15 hors-politique, 5 stratégiques), le coût mensuel sur Sonnet tourne autour de 3 à 5 $ ; sur Opus autour de 15 à 25 $. Les deux plages sont négligeables par rapport au coût salarial d’une heure de travail d’un réviseur deal desk.

Mesure de succès

Suivez deux métriques. Elles devraient évoluer en directions opposées ; si les deux évoluent dans le même sens, vous avez un problème de calibration.

Temps jusqu’à la contre-proposition. Durée totale depuis « le commercial a soumis la demande » jusqu’à « le réviseur a envoyé la contre-proposition au commercial ». La référence avant ce skill est typiquement 4 à 48 heures (mise en file, extraction, rédaction). L’objectif après adoption est moins de 30 minutes pour les demandes courantes (exécution du skill + modification du réviseur + envoi).
Taux d’escalade sur les demandes non triviales. Parmi les demandes que le skill signale comme exception-nécessaire ou hors-politique, quelle fraction atteint l’approbateur nommé dans la matrice DOA ? Ce taux devrait augmenter quand le skill est correctement calibré — les déclencheurs d’escalade existent pour remonter les demandes qui nécessitent un regard senior et qui auparavant étaient entérinées parce que personne n’avait le temps d’extraire les analogues. Si le taux baisse, le skill sur-lisse et les critères dans references/3-escalation-criteria.md doivent être resserrés.

Si le temps jusqu’à la contre-proposition baisse et que le taux d’escalade augmente, le skill fonctionne. Si seulement le premier se produit, vous avez construit une machine à confiance qui cache un risque de marge.

Par rapport aux alternatives

Règles CPQ (Salesforce CPQ, DealHub, etc.). Le CPQ est le bon outil pour l’application déterministe des politiques : catalogues de prix, routage d’approbation sur les paliers de remise, validation automatique de configuration. Utilisez le CPQ pour le chemin rapide. Utilisez ce skill au-dessus du CPQ pour les demandes que le CPQ signale comme nécessitant une approbation — où la décision est « que controns-nous », pas « est-ce conforme à la politique ». Le CPQ vous dit que la demande est hors-politique ; le skill vous aide à la contre-proposer.
Flows d’approbation de remise Salesforce. Les flows d’approbation natifs routent une exception vers le bon approbateur. Ils ne produisent pas la contre-proposition recommandée ni ne remontent les preuves de transactions comparables. Utilisez les flows d’approbation comme couche de routage ; utilisez ce skill pour alimenter le contexte que l’approbateur lit avant de décider.
Révision manuelle du deal desk. Un réviseur deal desk formé produit la meilleure contre-proposition quand il a le temps d’extraire les analogues et de relire le référentiel. La contrainte est le débit : un réviseur typique traite 8 à 15 demandes non standard par jour avant que le travail d’extraction ne supplante le travail de jugement. Utilisez le skill comme couche d’extraction-et-premier-brouillon ; le réviseur passe son temps sur la contre-proposition, pas sur l’assemblage des inputs.
Calculateur de référentiel en feuille de calcul. Certaines équipes construisent un fichier Excel qui prend l’ACV, la durée, et la remise et retourne « conforme / exception ». Rapide, simple, et fragile : il ne connaît pas les analogues, le contexte concurrentiel, ou les déclencheurs de pattern commercial, et il meurt à la première fois que le référentiel gagne une nouvelle dimension. Utilisez la feuille de calcul pour l’auto-service des commerciaux ; utilisez le skill quand la demande atteint le deal desk.

Points de vigilance

Recommandation de sur-remise. Le skill peut produire une contre-proposition qui comble l’écart avec l’objectif de prix de l’acheteur en cumulant toutes les concessions disponibles (remise maximale, incitation de durée maximale, concession de conditions de paiement maximale). C’est mathématiquement correct contre le référentiel et commercialement terrible — cela ne laisse rien sur la table pour la négociation. Garde : la recommandation plafonne les concessions cumulées totales au moindre du (plafond du référentiel) ou de la (médiane comparable + un écart type). Tout ce qui est au-dessus déclenche le flag d’escalade avec la raison « concessions cumulées dépassant les précédents ».
Référentiel obsolète. La politique tarifaire change chaque trimestre, parfois plus vite (un nouveau conditionnement se lance, un concurrent bouge sur les prix, un segment est redécoupé). Un skill s’exécutant contre un référentiel vieux de six mois recommandera une contre-proposition que l’équipe ne propose plus. Garde : le skill vérifie la date last_edited dans le frontmatter du référentiel et affiche un avertissement « Référentiel potentiellement obsolète (dernière modification AAAA-MM-JJ) » dans les notes du réviseur quand il a plus de 90 jours. Le réviseur est responsable du rafraîchissement du référentiel selon un calendrier ; le skill remonte l’obsolescence pour qu’elle ne se cache pas.
Contexte concurrentiel manqué. Une transaction où l’acheteur a nommé un concurrent et une date de clôture serrée mérite une contre-proposition différente d’une transaction dans le vide, même quand les verdicts du référentiel sont identiques. Garde : quand competitive_context est fourni, la section de justification le référence explicitement et la recommandation vérifie si un analogue sous une pression concurrentielle comparable a pris une forme différente. Si deal_record signale un concurrent mais que competitive_context est vide, le skill retourne un prompt demandant au réviseur de ré-exécuter avec le contexte renseigné plutôt que de produire une contre-proposition sans contexte.
Biais de sélection des analogues. Un CSV de transactions comparables plein de « nous avons tout approuvé » entraîne le skill à entériner les demandes futures. Garde : chaque analogue dans le tableau de preuves inclut son statut d’approbation (approuvé, rejeté, perdu-au-concurrent, retiré). Le réviseur voit le mix d’approbation et peut repérer le problème de curation ; le skill signale également « aucun analogue rejeté dans les 20 derniers » comme note de calibration dans les notes du réviseur.
Recommandation citée comme approbation. Les lecteurs en aval (commercial, client, parfois le responsable du commercial) traitent parfois la recommandation comme la contre-proposition approuvée. Garde : chaque en-tête de sortie inclut « Aide à la décision, pas une approbation. » et le bloc d’escalade nomme l’approbateur réel dans la matrice DOA. Si la recommandation est transmise comme contre-proposition sans passer par le réviseur humain, la ligne de l’approbateur nommé rend la lacune de processus évidente.

Stack

Associez-le au redlining de contrat avec Claude pour le workflow de phase de négociation qui s’exécute après l’accord sur la contre-proposition, et au résumé de contrat avec Claude pour le résumé adapté à l’audience post-signature. Le skill deal desk se situe au milieu : après que le CPQ a signalé la demande, avant le redlining.

Salesforce — données d’opportunité et de devis, routage d’approbation
Claude — évaluation du référentiel, extraction de transactions comparables, recommandation de contre-proposition, vérification d’escalade

Modifier cette page sur GitHub

Files in this artifact

Download all (.zip)

---
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.

# Discount rubric — TEMPLATE

> Replace this template's contents with your team's actual discount
> rubric. The deal-desk-pricing skill reads this file on every run
> and applies it deterministically. Without your real thresholds, the
> recommendation is generic and almost certainly wrong.

## Last edited

{YYYY-MM-DD} — the skill warns the reviewer when this date is more than 90 days old. Update it whenever any threshold below changes, even by a point.

## §1. Segments

The thresholds in §§2-5 are segment-specific. Define your segments once here and the skill will apply the right column.

| Segment | ACV band | Typical term | Typical sales motion |
|---|---|---|---|
| SMB | $0-30k | 1yr | self-serve / inside |
| Mid-market | $30k-250k | 1-3yr | inside + AE |
| Enterprise | $250k-2M | 2-5yr | AE + SE + exec sponsor |
| Strategic | $2M+ | 3-5yr | named-account team |

## §2. Term incentive

Discount allowed in exchange for multi-year commit, by segment.

| Segment | 1yr | 2yr | 3yr | 4yr | 5yr |
|---|---|---|---|---|---|
| SMB | 0% | 5% | 8% | n/a | n/a |
| Mid-market | 0% | 7% | 12% | 15% | 18% |
| Enterprise | 0% | 8% | 15% | 18% | 22% |
| Strategic | 0% | 10% | 18% | 22% | 25% |

Term incentives stack with §3 volume discounts up to the per-segment ceiling in §6.

## §3. Volume discount

Discount allowed on list price by ACV band, single-year basis.

| ACV band | Discount allowed | Approver |
|---|---|---|
| $0-50k | 0% | n/a — list only |
| $50k-150k | up to 10% | AE manager |
| $150k-500k | up to 15% | VP Sales |
| $500k-1M | up to 20% | VP Sales + CRO sign-off |
| $1M+ | case-by-case | CRO + CFO |

## §4. Payment terms

Default Net-30. Concessions allowed below.

| Net-X | Approver | Notes |
|---|---|---|
| Net-30 | n/a — default | Standard |
| Net-45 | Deal desk | Up to 3 per quarter per AE |
| Net-60 | CFO | Requires upfront-payment trade or other concession |
| Net-90 | CFO + CRO | Strategic deals only |
| Custom (milestone, deferred) | CFO + GC | Contract amendment required |

## §5. Ramp structures

| Ramp shape | Allowed | Approver |
|---|---|---|
| Flat (no ramp) | yes | default |
| Y1 50% / Y2 100% | yes | Deal desk |
| Y1 25% / Y2 75% / Y3 100% | yes | VP Sales |
| Custom | requires VP Sales + Finance | named exception |

Ramp deals require the §2 term incentive to be re-computed against the *contractual* term, not the ramped-up term.

## §6. Maximum stacked discount per segment

When term incentive (§2), volume discount (§3), and payment-term concession (§4) are stacked, total effective discount cannot exceed:

| Segment | Stacked ceiling | Approver to exceed |
|---|---|---|
| SMB | 12% | VP Sales |
| Mid-market | 22% | CRO |
| Enterprise | 28% | CRO + CFO |
| Strategic | 35% | CEO + CFO |

The skill caps recommendations at this ceiling. Anything above fires the escalation flag with reason "stacked concessions exceed ceiling."

## §7. Disqualifiers — do not recommend, escalate

The skill must escalate (not recommend) when any of these is true:

- Discount > stacked ceiling in §6
- Term < 12 months on a deal > $100k ACV
- Payment terms beyond Net-90
- Custom legal terms (MFN clause, uncapped indemnity ask, custom data-residency commitments) — these need GC, not deal desk
- Customer is on the strategic-logo list maintained at `references/strategic-accounts.md` (one entry per line)
- AE has submitted more non-policy asks this quarter than the threshold in `references/3-escalation-criteria.md` §2

## §8. DOA matrix (delegation of authority)

Used by the skill to name the approver in the recommendation header.

| Authority | Approver | Backup |
|---|---|---|
| In-policy deals | Deal desk reviewer | n/a |
| Exceptions up to §6 ceiling | VP Sales | Deal desk lead |
| Above §6 ceiling | CRO | VP Sales |
| Custom legal / payment | CFO + GC | n/a |
| Strategic logos | CRO + CEO | n/a |

# 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.