Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Deal desk: reviews, approves, and structures non-standard sales deals. Use when standing up a deal desk, building approval-threshold matrices, designing deal-review packets, routing deals, or auditing deals for compliance.
.claude/skills/borghei-deal-desk/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 173% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 454% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 450% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 103% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 457% | 0% |
End-to-end deal-desk operational practice: charter, approval thresholds, deal-review packet design, routing automation, velocity analysis, and the governance that turns "every deal is a snowflake" into "we close non-standard deals in 48 hours predictably."
This skill is provider-agnostic: works whether your CRM is Salesforce, HubSpot, Pipedrive, or homegrown. The patterns and decisions transfer.
| Situation | Skill applies | |-----------|---------------| | Starting a deal-desk function from scratch | Yes — start with charter design | | Reviewing existing deal-desk for slowness / inconsistency | Yes — use scripts/deal_velocity_analyzer.py + bottleneck patterns | | Defining who can approve what discount / term | Yes — use approval threshold matrix + scripts/discount_authority_router.py | | Building the deal-review packet template | Yes — see deal-review packet section + scripts/deal_review_packet.py | | Approving / declining a specific deal | Use the packet generator + approval router | | Setting pricing strategy | Use business-growth/pricing-strategy first | | Forecasting / measuring pipeline | Use business-growth/revenue-operations | | Negotiating an individual contract | Pair with business-growth/contract-and-proposal-writer |
Does:
Doesn't:
A clean deal-desk = the lubricant. Without it, every non-standard deal turns into a multi-week negotiation among engineering / product / legal / finance / executive. With it, those people are consulted by deal desk as needed and the rep gets a yes/no in days.
Every deal desk needs a written charter. Use this template:
yamlpurpose: Deal Desk reviews, approves, and structures non-standard deals to enable sales to close faster while keeping commercial / legal / financial risk within company tolerance. scope: In-scope: - All deals > $X ARR - All deals with discount > Y% - All deals with non-standard terms (custom SLAs, custom legal language, payment terms beyond Net 30, ramp deals, multi-year discounts > 12 months of standard, bundles spanning multiple product lines) - All renewals with > 20% expansion or > 10% contraction - All deals to enterprise (>1000 employees) or regulated industries Out-of-scope: - Self-serve / PLG transactions - Standard renewals within auto-renewal terms - Trial extensions < 30 days - Add-ons < $X per existing customer sla: - Standard deal-desk review (no exec approval needed): 1 business day - Deal needing CFO/CRO approval: 2 business days - Deal needing CEO/Board approval: 5 business days - Legal-only review (no commercial concession): 2 business days intake_format: Sales submits via [Salesforce form / CPQ tool / Slack form]. Required fields: - Customer name + size + industry - Product(s) + ACV - Requested deviation from standard (specific list) - Justification (competitor situation, customer constraint, strategic value) - Standard-pricing total + requested total - Contract length + payment terms - Implementation / SLA requirements decision_inputs: - Customer LTV estimate - Strategic value (logo, reference, vertical foothold) - Risk (credit, compliance, integration) - Margin impact outputs: - Approve / decline / counter - If approve: signed approval packet with terms, conditions, expiration date - If counter: list of negotiable items + non-negotiables - If decline: reasoning + alternatives team: Deal-desk lead: <name> Deal-desk analysts: <names> Standing approvers: CRO, CFO, General Counsel, VP Product (escalation paths) Consulted as-needed: Engineering Lead, Security Lead, Customer Success Lead metrics: - Median time-to-decision (target: 1 business day) - Decision distribution (% approved, % declined, % countered) - Discount-on-discount % (deals where requested discount was further negotiated up) - Discount % vs ACV (correlation; outliers reviewed monthly) - Win rate of deal-desk-approved deals - Concession follow-through (did the customer keep their side?)
See references/deal-desk-charter-and-process.md for the full charter template, including sub-charters per region, intake form spec, and the standard SLAs.
The matrix defines: for each deal characteristic (discount %, contract length, custom term type), who can approve it.
| Deal characteristic | Rep | Sales Manager | Director | VP Sales | CRO | CFO | CEO | |---------------------|-----|---------------|----------|----------|-----|-----|-----| | Discount 0-10% | ✓ | | | | | | | | Discount 10-20% | | ✓ | | | | | | | Discount 20-30% | | | ✓ | | | | | | Discount 30-40% | | | | ✓ | | | | | Discount 40-50% | | | | | ✓ | | | | Discount > 50% | | | | | | | ✓ | | ACV > $250k | | ✓ | | | | | | | ACV > $1M | | | | ✓ | | | | | ACV > $5M | | | | | | | ✓ | | Multi-year > 12mo standard | | ✓ | | | | | | | Non-standard payment terms | | | | | | ✓ | | | Custom SLA / penalties | | | | (with CCO) | | | | | Custom legal language | | | | | | | (Legal must concur) | | MSA red-line on liability cap | | | | | | | (Legal must concur) | | Most-favored-nation clause | | | | | | ✓ | | | Acceptance criteria / payment-on-acceptance | | | | | | ✓ | | | Multi-product / cross-BU bundle | | | (each BU lead approves) | | | | | | Whitelabel / OEM rights | | | | | | | ✓ |
Customize per company stage, ACV distribution, and authority preference (some orgs want CRO at 30%, others delegate further down).
When multiple non-standard items apply, the highest required approver applies. A $1M deal at 25% discount with custom SLA needs VP Sales (ACV) AND Director (discount) AND VP Sales+CCO (custom SLA) → effectively requires VP Sales sign-off + CCO + Legal concurrence.
Use scripts/discount_authority_router.py --deal deal.yaml to compute the required approvers for any deal.
See references/approval-thresholds-and-routing.md for the full matrix design guide, regional variants, escalation paths, and routing automation patterns.
Every non-standard deal gets a packet. Without it, approvers ask the same questions repeatedly and decisions take days instead of hours.
markdown# Deal Review: <Customer Name> ## Summary - Customer: <name, size, industry> - ACV: $<amount> - Discount %: <%> (vs standard $<list-price>) - Contract: <length>, <payment terms> - Decision needed by: <date> ## Standard vs Requested | Item | Standard | Requested | Delta | |------|----------|-----------|-------| | ACV | $X | $Y | -Z% | | Term | 12mo | 36mo | +24mo | | Payment | Net 30 | Net 60 | +30d | | SLA | 99.5% | 99.9% | +0.4% | | Liability cap | 1x fees | 2x fees | +1x | | Termination for convenience | No | Yes (90d) | New | ## Justification - Why customer wants this: <competitor situation, budget cycle, etc.> - Why we're considering: <strategic value, logo, vertical> - Customer leverage: <alternatives they have> ## Financial impact - Standard ARR: $X - Discounted ARR: $Y (Z% off) - Net new gross margin: $A (with cost overlay) - Projected LTV with this discount: $B - Discount payback if customer renews: <years> ## Strategic value - Logo value: <high/medium/low — reasoning> - Reference value: <will they be a public ref? case study?> - Vertical foothold: <do we want this vertical?> - Competitive replacement: <who are we displacing?> ## Risk - Credit risk: <score / payment history> - Compliance risk: <regulated? data residency?> - Technical fit risk: <integration complexity> - Concession follow-through: <are they likely to honor commitments?> ## Required approvers (per matrix) - [ ] Director: <name> - [ ] VP Sales: <name> - [ ] CFO: <name> - [ ] Legal: <name> ## Recommendation (from deal desk) <Approve / Counter / Decline> — with reasoning ## Conditions if approved - Discount expires <date> - Customer must agree to: <reference call, case study, etc.> - Customer agrees this is single-instance (not precedent) - Payment must close by <date>
Use scripts/deal_review_packet.py --deal deal.yaml to generate this packet from a deal spec.
A slow deal desk strangles sales. Measure and tune.
| Metric | Healthy | Warning | |--------|---------|---------| | Median time-to-decision | < 1 business day | > 3 days | | 90th percentile time-to-decision | < 3 business days | > 7 days | | % of deals waiting on a single approver > 24h | < 10% | > 30% | | Deals stuck > 7 days | 0 | > 5 | | Sales rep satisfaction with deal desk (NPS) | > 50 | < 0 | | % approved (high approval rate may mean threshold too low) | 60-80% | > 95% or < 40% | | Discount-on-discount: deals where customer negotiated up after deal-desk approval | < 10% | > 30% |
Run scripts/deal_velocity_analyzer.py --deals deals.csv to compute these from a CRM export.
| Bottleneck | Diagnosis | Fix | |------------|-----------|-----| | Single approver bottleneck (one person on everything) | Routing matrix concentrated authority | Delegate; add back-ups; raise thresholds | | Legal review takes a week | Legal sees every deal | Standard MSA + pre-approved clause library; Legal only on deviations | | Engineering needed for SLA review | Custom SLAs every time | Publish standard SLA tiers; only deviations route to eng | | Approval cycle back-and-forth | Packet missing key info | Use the standard packet template; reject incomplete submissions | | Long executive lag | Exec doesn't have context for every deal | Weekly deal review meeting for batch decisions on smaller items | | Sales submits incomplete packets | Reps don't know what to include | Intake form that enforces required fields | | No SLA enforcement | Deals sit in queue with no urgency | Publish + report SLA; aging dashboard visible to leadership |
See references/discount-and-concession-playbook.md for the discount/concession patterns: legitimate reasons for each concession type, how to evaluate, alternatives to discounting, and how to structure performance-based discounts.
Before generating the deal-desk artifact, confirm these inputs. If any is unknown or vague, ASK — do not assume:
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
scripts/discount_authority_router.py)Thresholds drift. Quarterly:
| Script | Input | Output | |--------|-------|--------| | scripts/deal_review_packet.py | Deal spec YAML | Markdown deal-review packet with summary, financials, strategic value, risk, approver list, recommendation template | | scripts/discount_authority_router.py | Deal spec YAML + approval matrix YAML | Required approver(s), routing order, escalation path, SLA-aware ordering | | scripts/deal_velocity_analyzer.py | CSV of deals from CRM export | Median / p90 time-to-decision, aging dashboard, approver bottleneck identification, discount-on-discount analysis |
All scripts: stdlib only, argparse CLI, JSON or markdown output.
business-growth/pricing-strategy — sets the prices that deal desk enforces deviations frombusiness-growth/revenue-operations — measures the pipeline; deal-desk metrics flow into RevOps dashboardsbusiness-growth/contract-and-proposal-writer — drafts the final contract once deal desk approvesbusiness-growth/channel-economics — channel deals have their own deal-desk patternsbusiness-growth/partnerships-architect — partner-mediated deals route through both deal desk + partnershipsbusiness-growth/commercial-policy — the broader governance framework deal desk enforcessales-success/sales-engineer — provides technical validation in packetsales-success/sales-operations — owns CRM / forecast accuracy that deal desk feeds| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 21,600 | 30,765 | +42% | 1 | 1 | 0% | 3,512 | 9,575 | +173% | 0 | 0 | — |
case-02 | fail→fail | 26,388 | 22,700 | -14% | 1 | 1 | 0% | 4,057 | 8,267 | +104% | 0 | 0 | — |
case-03 | fail→fail | 25,383 | 33,959 | +34% | 1 | 1 | 0% | 3,776 | 10,453 | +177% | 0 | 0 | — |
case-04 | fail→fail | 19,279 | 18,181 | -6% | 1 | 1 | 0% | 2,879 | 7,314 | +154% | 0 | 0 | — |
case-05 | pass→pass | 14,276 | 14,091 | -1% | 1 | 1 | 0% | 1,922 | 6,390 | +232% | 0 | 0 | — |
case-06 | fail→fail | 12,490 | 25,941 | +108% | 1 | 1 | 0% | 1,953 | 8,957 | +359% | 0 | 0 | — |
case-07 | pass→pass | 14,316 | 13,037 | -9% | 1 | 1 | 0% | 2,162 | 6,489 | +200% | 0 | 0 | — |
case-08 | fail→pass | 14,567 | 4,482 | -69% | 1 | 1 | 0% | 956 | 5,297 | +454% | 0 | 0 | — |
case-09 | fail→pass | 6,172 | 2,777 | -55% | 1 | 1 | 0% | 913 | 5,021 | +450% | 0 | 0 | — |
case-10 | fail→pass | 15,375 | 6,924 | -55% | 1 | 1 | 0% | 2,794 | 5,666 | +103% | 0 | 0 | — |
case-11 | fail→pass | 6,304 | 3,840 | -39% | 1 | 1 | 0% | 947 | 5,278 | +457% | 0 | 0 | — |
case-12 | pass→pass | 10,867 | 3,704 | -66% | 1 | 1 | 0% | 1,543 | 5,109 | +231% | 0 | 0 | — |
case-13 | pass→pass | 9,094 | 7,629 | -16% | 1 | 1 | 0% | 1,236 | 5,752 | +365% | 0 | 0 | — |
case-14 | pass→pass | 17,037 | 17,067 | +0% | 1 | 1 | 0% | 2,327 | 6,899 | +196% | 0 | 0 | — |
case-15 | pass→pass | 12,754 | 12,896 | +1% | 1 | 1 | 0% | 1,784 | 6,379 | +258% | 0 | 0 | — |
case-16 | pass→pass | 9,592 | 10,851 | +13% | 1 | 1 | 0% | 1,340 | 6,049 | +351% | 0 | 0 | — |
case-17 | fail→pass | 19,082 | 21,471 | +13% | 1 | 1 | 0% | 2,663 | 7,549 | +183% | 0 | 0 | — |
case-18 | fail→fail | 11,529 | 5,468 | -53% | 1 | 1 | 0% | 1,611 | 5,280 | +228% | 0 | 0 | — |
case-19 | pass→pass | 15,936 | 14,284 | -10% | 1 | 1 | 0% | 2,242 | 6,633 | +196% | 0 | 0 | — |
case-20 | pass→pass | 13,130 | 13,958 | +6% | 1 | 1 | 0% | 1,861 | 6,472 | +248% | 0 | 0 | — |
case-21 | pass→pass | 13,951 | 14,578 | +4% | 1 | 1 | 0% | 1,965 | 6,655 | +239% | 0 | 0 | — |
case-22 | fail→pass | 16,103 | 14,104 | -12% | 1 | 1 | 0% | 2,313 | 6,548 | +183% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +32 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.