---
name: pipeline-velocity-tracking
version: 1.0.0
deployment_target: plugin
status: PROPOSED
description: "Tracks average sales cycle time by segment, rep, and deal size. Flags deals aging past 1.5x historical average for their current stage. Surfaces velocity trend vs. prior quarter. Triggers: 'pipeline velocity', 'cycle time', 'deals aging', 'stalling pipeline', 'how long are deals taking'."
---
[PROPOSED]
# Pipeline Velocity Tracking
Surfaces where pipeline is slowing before it shows up in a missed quarter.
Aging threshold: 1.5x historical average for stage and segment.
**Reference:** Confidence bands → `../../../shared/revops-domain-model.md §2`
**Config reads:** `avg_sales_cycle_days`, `primary_segment`
---
## 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: `avg_sales_cycle_days`, `primary_segment`
**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
- User needs to understand how fast deals move through pipeline stages
- Velocity degradation analysis needed (deals slowing, stage duration increasing)
- Cohort comparison of pipeline velocity across segments, reps, or time periods
## Do NOT use for
- Coverage ratio analysis (use pipeline-coverage-analysis)
- Individual deal health (use deal-health-scoring)
- Stage integrity verification (use stage-integrity-audit)
## Typical Activation
"Pipeline velocity", "how fast are deals moving", "velocity by stage", "where are deals getting stuck", "track pipeline velocity for [segment/period]"
---
## Reasoning Protocol
Before generating output, apply these primers:
1. **CLASSIFY**: What type of pipeline velocity request is this?
- Single-rep velocity review (one rep's deals — stage-age ratios across active pipeline)
- Segment-level velocity analysis (Enterprise vs. SMB cycle time comparison)
- Quarter-over-quarter trend (velocity acceleration or deceleration vs. prior period)
- Aging flag sweep (all open deals exceeding 1.5x stage-avg threshold)
2. **CONSTRAINTS**: What limits the solution space?
1. Confirm activation — user asking about deal velocity, aging, or cycle time
2. Pull HubSpot stage entry/exit history for scope; declare connector status and data-as-of timestamp per G6
3. Apply G5 — velocity signals are analytical inputs; manager owns the coaching response
4. Apply G7 — aging flags must include a named escalation path (manager) per at-risk signal protocol
5. Confirm `avg_sales_cycle_days` from config before computing stage-age ratios
6. Apply `primary_segment` from config to scope segment-level comparisons correctly
7. Confirm output destination before delivering — internal RevOps vs. manager coaching vs. leadership
3. **EXPERT CHECK**: What would a veteran RevOps pipeline analyst verify before surfacing findings?
- Is the stage-age ratio segment-aware? Enterprise deals have longer median stage duration than SMB —
applying a single `avg_sales_cycle_days` baseline to a mixed-segment pipeline produces false positives
on enterprise deals and misses SMB stalls. Confirm segment before applying the 1.5x flag.
- Is the HubSpot stage history scoped to the current active cycle? Pulling all-time stage history
surfaces legitimate re-stages (deals reopened after closed/lost) alongside current velocity data —
filter to current active deal cycle, not full deal lifetime.
- Is the velocity trend directionally consistent with pipeline composition changes? A cycle-time
increase that coincides with an enterprise mix shift is not the same as a coaching problem —
distinguish composition effects from rep performance signals before surfacing to management.
- Is the escalation path named before surfacing aging flags? G7 requires a named owner and channel,
not a generic "review with manager" instruction.
4. **ANTI-PATTERNS**: Common mistakes to avoid:
- Applying `avg_sales_cycle_days` without segment-level breakdown (produces noise in mixed pipelines)
- Surfacing aging flags without a named escalation path (G7 violation)
- Pulling HubSpot stage history without data-as-of timestamp (G6 violation)
- Presenting velocity as a rep performance signal without accounting for pipeline composition changes
- Routing aging flag findings directly to reps — escalation path is manager, not rep
**After execution**, verify:
- G5 qualifier present — velocity signals named as analytical inputs; manager named as decision owner
- G6 data-as-of label applied to all HubSpot stage history reads
- G7 escalation path present on every aging flag (named manager + channel)
- Stage-age ratio computed against segment-appropriate baseline, not blended `avg_sales_cycle_days`
- Confidence: High when HubSpot connected and stage history current; Moderate when connector unavailable or `avg_sales_cycle_days` is estimated
- Confidence: [High] when HubSpot connected and stage history current / [Medium] when connector unavailable or cycle data estimated / [Low] if all inputs are manual or unverified
---
## Workflow
Pull stage entry/exit dates for all open opportunities from HubSpot.
Calculate:
```
Days in current stage = Today − Stage entry date
Segment avg for stage = Historical median days in this stage for this segment (trailing 4Q)
Stage-age ratio = Days in current stage ÷ Segment avg
```
Flag when stage-age ratio > 1.5x. Surface deals by aging severity.
Compare overall cycle time trend: current quarter avg vs. prior quarter avg.
---
## Output
```
PIPELINE VELOCITY — [Scope] [HubSpot ✓ live — as of YYYY-MM-DD]
Avg cycle time this quarter: [N] days (vs. [N] days prior quarter ↑/↓)
Aging flags (stage-age ratio > 1.5x):
Deal Stage Days in stage Avg Ratio Owner
[Account A] Negotiation 34d 18d 1.9x [Rep]
[Account B] Proposal 28d 14d 2.0x [Rep]
Total aging deals: [N] ($XXXk ACV)
Velocity trend: [Slowing / Stable / Accelerating]
[DRAFT — RevOps internal] [Confidence: High/Moderate]
[G5: Velocity flags are analytical inputs. Manager owns the response.]
```
## 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, G6 apply. Aging flags require manager as escalation path (G7).