deal-classification

$npx mdskill add t0ddc3by/claude-for-customer-success/deal-classification

Independently classifies open deals using CRM activity data.

  • Scores each opportunity as Commit, Best Case, or Pipeline without rep input.
  • Depends on CRM activity data and config for segment and sales cycle.
  • Compares classification to rep's stated category and flags large deltas.
  • Surfaces delta when classification disagrees by more than one tier.

SKILL.md

.github/skills/deal-classificationView on GitHub ↗
---
name: deal-classification
version: 1.0.0
deployment_target: plugin
status: PROPOSED
description: "Independently scores each open opportunity as Commit / Best Case / Pipeline using CRM activity data — without relying on rep self-reporting. Surfaces delta vs. rep's stated forecast category when classification disagrees by more than one tier. Triggers: 'deal classification', 'classify the pipeline', 'commit vs best case', 'independent forecast', 'override rep call'."
---

[PROPOSED]

# Deal Classification

Classifies open opportunities using CRM activity signals, not rep self-reporting.
Disagrees with rep calls only when evidence is clear — flags the delta, doesn't override.

**Reference:** Confidence bands → `../../../shared/revops-domain-model.md §2`
**Config reads:** `primary_segment`, `avg_sales_cycle_days`

---

## 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: `primary_segment`, `avg_sales_cycle_days`

**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 needs to be classified by type (New ARR, Expansion, Renewal, Reactivation) for ARR reporting accuracy and pipeline routing
- ARR classification is disputed or ambiguous for a specific opportunity
- Closed-won deal classification needs verification before CS handoff

## Do NOT use for
- Deal health or risk scoring (use deal-health-scoring)
- Revenue recognition decisions (classification is analytical input only)
- Bulk ARR reporting (classification feeds reporting but does not produce it)

## Typical Activation
"Classify this deal", "what type of ARR is [deal]", "is this new or expansion", "deal classification for [account]", "verify ARR classification"

## Classification routing
Deal type determines pipeline ownership and tracking destination:
- **New ARR / Reactivation** → Sales-owned pipeline; tracks to Sales new-logo forecast
- **Expansion** → CS-owned pipeline; tracks to CS expansion pipeline and CS deal desk for commercial terms; routes to `pipeline-coverage-analysis` for CS expansion attainment
- **Renewal** → CS-owned pipeline; tracks to CS renewal book of business and GRR monitoring

Classification is the routing mechanism. An Expansion or Renewal classification
means CS leadership and CS ops own the downstream tracking — not Sales.

---

## Reasoning Protocol

Before generating output, apply these primers:

1. **CLASSIFY**: What type of deal classification request is this?
   - Single deal scoring (one opportunity, independent signal)
   - Portfolio classification sweep (rep / segment / all open pipeline)
   - Call validation (rep's stated category vs. model signal)
   - Closed-won verification before CS handoff

2. **CONSTRAINTS**: What limits the solution space?
   1. Confirm activation — user wants independent deal scoring or call validation
   2. Check HubSpot for activity data — required for classification; declare fallback if absent
   3. Apply G5 — classification is analytical input; rep and manager own the judgment
   4. Apply G6 — surface data-as-of on all activity reads
   5. Do not present classification as override — present as independent signal

3. **EXPERT CHECK**: What would a veteran RevOps analyst verify first?
   - Is HubSpot activity data fresh enough to score? Stale data produces misleading signals — declare data age before presenting classification.
   - Is the scoring model applied consistently across all deals in a sweep? Rep-specific exceptions undermine portfolio-level credibility.
   - Is the delta between rep call and model call surfaced clearly without editorializing? The analyst's job is to flag — rep and manager own the resolution.
   - Is the classification being used in a forecast context? If so, G1 forecast language qualification is required before the output leaves RevOps.

4. **ANTI-PATTERNS**: Common mistakes to avoid:
   - Presenting model classification as a forecast override (G5 violation)
   - Surfacing classification output without data-as-of timestamp (G6 violation)
   - Running a portfolio sweep without declaring scope (segment, rep, date range)
   - Omitting the G1 forecast qualification when classification feeds a leadership or board view

**After execution**, verify:
- G5 analytical input qualifier present on all outputs
- G6 data-as-of label applied to all HubSpot reads
- Delta column populated when rep call and model call diverge
- Confidence: High when HubSpot is connected and activity data is current; Moderate when data is stale or connector is unavailable
    - Confidence: [High] when HubSpot is connected and activity data is current / [Medium] when data is stale or connector is unavailable / [Low] if all inputs are manual or unverified

---

## Scoring Dimensions (20 points each, total 100)

| Dimension | Commit signal | Best Case signal | Pipeline signal |
|-----------|--------------|-----------------|----------------|
| **Activity recency** | Contact in ≤7 days | Contact in 8–21 days | No contact >21 days |
| **Stakeholder coverage** | EB + Champion + TC all engaged | 2 of 3 engaged | 1 or fewer engaged |
| **Stage progression rate** | On or ahead of historical avg | 0–25% behind avg | >25% behind avg |
| **Competitive signal** | No active competitor / counter-play logged | Competitor mentioned, response logged | Competitor active, no response |
| **Rep forecast accuracy** | Rep's trailing commit accuracy ≥70% | 50–70% | <50% |

**Classification:**
- 80–100 → Commit
- 55–79 → Best Case
- <55 → Pipeline

---

## Output

```
DEAL CLASSIFICATION — [Rep / Segment / All]
[HubSpot ✓ live — as of YYYY-MM-DD] [Confidence: High/Moderate]

Deal             ACV      Rep Call    Model Call  Delta   Primary signal
[Account A]      $XXXk    Commit      Commit      —       Activity current, EB engaged
[Account B]      $XXXk    Commit      Best Case   ▼1      No EB contact in 18 days
[Account C]      $XXXk    Best Case   Pipeline    ▼1      Stage stalled 3x avg; no TC

Agreements:  [N] deals  (XX%)
Δ−1 (one tier down): [N] deals  (XX%)
Δ−2 (two tiers down): [N] deals  (XX%)

Adjusted pipeline summary (model-based):
  Commit:     $XXXk  (vs. $XXXk rep-reported)
  Best Case:  $XXXk
  Pipeline:   $XXXk

[DRAFT — RevOps internal] [Confidence: High/Moderate]
[G5: This is an analytical input. Rep and manager own the forecast call.]
```

---

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

## Guardrails

- G5: Always include: "This classification is an analytical input based on CRM
  signals. The rep and their manager own the forecast judgment."
- G6: Data-as-of timestamp required
- G1: If summary is used in a forecast context, apply forecast language qualification

More from t0ddc3by/claude-for-customer-success

SkillDescription
account-research>
annual-planning-workflowOrchestrates the six-phase annual (or mid-year) planning cycle: forecast scenarios → UoG three-scenario capacity modeling → quota sensitivity → comp simulation → baseline save → change communication. Each phase gates on human approval before the next begins. Invokes unit-of-growth-calculator for capacity modeling. Triggers: 'annual planning', 'planning cycle', 'run the plan', 'quota comp planning', 'mid-year replan'.
blocker-review>
call-prep>
change-communication-packagingProduces a three-part communication package for sensitive planning changes: (1) data-backed rationale memo for reps, (2) FAQ with top 5 anticipated objections and data responses, (3) rollout sequence with audience, channel, and order. Triggered automatically by annual-planning-workflow for territory, quota, or comp changes. Requires RevOps lead review before any distribution. Triggers: 'communicate changes', 'territory announcement', 'quota rationale', 'comp change communication', 'help me tell reps about [change]'.
churn-rcaRoot cause analysis for individual customer churn events and cohort-level churn pattern analysis. Produces structured RCA with root cause taxonomy, contributing factors, timeline reconstruction, and remediation pathway. Scoped to full cancellation — contract contraction redirected to renewals:downgrade-analysis.
closed-won-to-cs-capacity-modelingConverts rolling sales forecast into CS resource demand using UoG formulas. Runs three-scenario capacity check (P10/P50/P90 from scenario-modeling). Compares projected CSM demand to current headcount and UoG annual plan baseline. Surfaces CS capacity gaps with a hiring lead time flag. Updates when SA1 forecast moves >10%. Triggers: 'CS capacity', 'can CS absorb', 'CSM headcount needed', 'CS ceiling', 'will CS be able to handle new logos'.
cold-start-interview>
comp-simulationModels comp plan payout scenarios before plan is finalized. Stress-tests OTE, accelerators, and threshold structures against attainment distributions (50/65/75/85/100%). Surfaces cost-to-company and unintended payout behaviors. G3 applies — all outputs require HR + Finance dual review before rep distribution. Triggers: 'comp simulation', 'model comp payouts', 'comp plan cost', 'stress test comp plan', 'what does the plan cost at 80/100/120%'.
crm-hygiene-auditOverall CRM health score plus rep-level hygiene scorecard across three dimensions: completeness, accuracy, and recency. Produces weekly hygiene report for RevOps review before sharing with Sales managers. Never writes to CRM — all corrections are proposals. Triggers: 'CRM hygiene', 'data quality', 'hygiene report', 'field completeness', 'CRM health score'.