t0ddc3by/claude-for-customer-success/deal-desk-workflow-management

[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)

1. CONSTRAINTS: What limits the solution space?
2. Confirm activation — user submitting a deal for desk review or checking status
3. Read deal fields from HubSpot — deal link, ACV, discount %, close date, rep required
4. Run sub-skills: discount-threshold-monitoring, non-standard-terms-detection,

revenue-leakage-scanning to assemble context brief

1. Route to correct approval authority per discount tier from company profile
2. Apply G1 — desk review does not constitute deal approval or revenue commitment
3. Track SLA — flag breach to #revops-ops; 24h standard / 4h final 2 weeks of quarter

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

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

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