---
name: deal-desk-workflow-management
version: 1.0.0
deployment_target: plugin
status: PROPOSED
description: "Manages the complete deal desk approval routing workflow: submit → review → route → decide → log. Assembles context brief (discount rationale, competitive context, Tier 1 churn risk signal) before routing to approver. Enforces SLA (24h standard, 4h final 2 weeks of quarter). SLA breach escalates to #revops-ops. Triggers: 'deal desk', 'approval workflow', 'route for approval', 'deal approval status', 'process a deal desk request'."
---
[PROPOSED]
# Deal Desk Workflow Management
The approval routing workflow — not the approval itself. Deal Desk assembles
context, routes to the right person, and tracks to resolution.
**Reference:** Governance tiers → `../../../shared/revops-domain-model.md §9`
**Config reads:** `discount_standard_threshold_pct`, `discount_elevated_threshold_pct`,
`linear_connected`, `slack_connected`
---
## Pre-flight
Read `~/.claude/plugins/config/claude-for-customer-success/rev-ops/CLAUDE.md` and
`~/.claude/plugins/config/claude-for-customer-success/company-profile.md`.
If either is missing or contains `[PLACEHOLDER]` markers, stop and prompt for
`/rev-ops:cold-start-interview`.
Note from config: `discount_standard_threshold_pct`, `discount_elevated_threshold_pct`,
`linear_connected`, `slack_connected`
**G-code dependency:** All G-code guardrails referenced in this skill (G1–G9) are defined in the CLAUDE.md config loaded above. If Pre-flight halts or config is missing, G-codes are undefined — do not proceed with partial config.
---
## Use when
- Deal requires formal approval routing through the deal desk
- Discount level crosses standard or elevated threshold requiring approver assignment
- User needs to check status of an active deal desk submission
- Deal desk submission requires context brief assembly before routing
## Do NOT use for
- Approving deals (this skill routes only — never approves)
- Discount threshold calculation in isolation (use discount-threshold-monitoring)
- Non-standard terms detection without approval routing context (use non-standard-terms-detection)
## Typical Activation
"Submit to deal desk", "route for approval", "deal desk for [account]", "deal approval status", "process a deal desk request"
---
## Reasoning Protocol
Before generating output, apply these primers:
1. **CLASSIFY**: What type of deal desk request is this?
- New submission (threshold crossed or manual request — assemble context brief + route)
- Status check (active submission — report current stage, SLA remaining, approver)
- Re-route (approver unavailable or SLA approaching — identify backup authority)
- Outcome log (decision received — record in CRM and update discount frequency report)
2. **CONSTRAINTS**: What limits the solution space?
1. Confirm activation — user submitting a deal for desk review or checking status
2. Read deal fields from HubSpot — deal link, ACV, discount %, close date, rep required
3. Run sub-skills: discount-threshold-monitoring, non-standard-terms-detection,
revenue-leakage-scanning to assemble context brief
4. Route to correct approval authority per discount tier from company profile
5. Apply G1 — desk review does not constitute deal approval or revenue commitment
6. Track SLA — flag breach to #revops-ops; 24h standard / 4h final 2 weeks of quarter
3. **EXPERT CHECK**: What would a veteran RevOps deal desk analyst verify first?
- Is the discount tier confirmed from the company profile thresholds — not estimated?
Routing to the wrong approver tier wastes SLA time and creates audit gaps.
- Is the context brief complete before routing? An incomplete brief (missing competitive
context or churn signal) sends the approver back to the rep — extending SLA.
- Is the SLA deadline calculated from submission timestamp, not discovery timestamp?
Quarter-end 4h window starts from when the desk submission is logged.
- Are any non-standard terms or leakage flags from sub-skills surfaced before routing?
Approvers need the full picture in the brief — not post-routing addenda.
4. **ANTI-PATTERNS**: Common mistakes to avoid:
- Approving a deal through the brief (G1 violation — desk review ≠ revenue commitment)
- Routing without running all three sub-skills — incomplete context brief reaches approver
- Logging a CRM update without Write-tier confirmation (G9 violation)
- Missing the quarter-end SLA window by using wrong timestamp as SLA start
- Omitting comp flag when deal structure has comp implications (G3 violation)
**After execution**, verify:
- G1 qualifier present: context brief does not constitute approval or revenue commitment
- G9 Write-tier confirmation gate applied to all CRM and Linear writes
- SLA deadline calculated from submission timestamp; quarter-end window identified if applicable
- Confidence: High when HubSpot is connected and all sub-skills return data; Moderate when
any sub-skill is unavailable or deal fields are partially populated
- Confidence: [High] when HubSpot is connected and all sub-skills return data / [Medium] when any sub-skill is unavailable or deal fields are partially populated / [Low] if all inputs are manual or unverified
---
## Workflow Stages
```
Stage 1 — Submission (automatic on threshold crossing or manual)
Confirm: deal link, ACV, discount %, close date, rep
Stage 2 — Context brief assembly
Run: discount-threshold-monitoring → tier and approver
Run: non-standard-terms-detection → any legal/finance flags
Run: early-churn-downgrade-signal-detection (Tier 1) → structural risk signal
Run: revenue-leakage-scanning → any structural leakage
Stage 3 — Routing
Create Linear issue with context brief attached
Assign to: [determined by discount tier from company profile]
Set SLA: 24h standard / 4h final 2 weeks of quarter
Stage 4 — Decision
Approver resolves Linear issue: Approved / Approved with conditions / Rejected
Decision and rationale logged in CRM (Write-tier — confirm before writing)
Stage 5 — Outcome log
Log: timestamp, deal ID, discount %, approver, decision, rationale
Update CRM deal record (Write-tier — confirm before writing)
Flag pattern: discount frequency report updated
```
---
## Context Brief Format
```
DEAL DESK BRIEF — [Account Name]
Submitted: [timestamp] SLA: [deadline]
Deal: [link] ACV: $XXXk Discount: XX% Close: [date] Rep: [name]
Approval tier: [Elevated / Executive] Required: [Role(s)]
Discount rationale: [from deal notes / rep-stated]
Competitive context: [from deal notes]
Tier 1 churn signal: [FIRING: reason / Clear]
Non-standard terms: [list or None]
Revenue leakage: [list or None detected]
Recommended decision: [Approve / Approve with conditions / Investigate]
Basis: [structured rationale — not opinion]
```
---
## SLA Monitoring
```
If SLA approaching (4h remaining): Slack ping to approver
If SLA breached: Post to #revops-ops with deal link and approver name
```
---
## Reference Files
| File | Purpose |
|------|---------|
| `references/reasoning-blueprint.md` | Problem classification taxonomy, domain heuristics, common failure modes, and expert judgment patterns for this skill |
## Security & Permissions
**Network access:** None direct — all external data access is mediated by host-provided MCP connector tools (HubSpot, CS platform, Slack, Linear). This skill makes no direct outbound HTTP calls.
**Filesystem scope:** None — this skill does not read or write local files. All data is provided at runtime via parameters or MCP connector responses.
**Subprocess execution:** None.
**Dynamic code execution:** None — pseudocode in this skill represents the logic contract and is not executed at runtime.
**Data sensitivity:** Inputs may contain confidential deal, customer, and revenue data. Handle with RevOps-level confidentiality.
## Trust & Verification
**Input trust model:** All user-provided parameters are treated as untrusted at intake. Numeric inputs are validated for plausible range before use in calculations. String inputs are not evaluated as code.
**Output trust model:** All outputs are proposals or analytical inputs — no outputs constitute approved decisions, revenue commitments, or system actions without explicit human confirmation.
**Connector data:** Data retrieved via MCP connectors is treated as read-only observed state. Timestamps and data-as-of labels are applied to all connector-sourced values per G6.
**Write-tier confirmation:** Any proposed write to HubSpot, Linear, or Slack is surfaced as a draft requiring explicit user confirmation before execution.
**Distribution:** Outputs contain revenue projections and pipeline data. Confirm receiving audience is authorized before sharing. All forward-looking figures carry `[review — internal planning data]` tags.
## Guardrails
- Never approve deals — route only
- G1: Context brief does not constitute revenue commitment
- G9: CRM updates are Write-tier — confirm before execution
- G3: If comp implications exist in deal structure → flag for HR + Finance