SOP-REV-win-loss-data-exchange-v0

Status: v0 Skeleton. This SOP was committed in Michelle's council review implementation guide (2026-04-19) as a P3 authoring requirement. The specific data fields, timing, and exchange format cannot be fully defined until eco|monetize™ has completed at least one Assessment delivery. The governance structure and exchange protocol are scaffolded here; CMO, CRO, sales.ops, and customer.success should complete the operational sections after the first Assessment post-mortem.

Promotion trigger: First Assessment delivered + Q2 post-mortem synthesized (customer.success, early Q3 2026). Promote to v1.0 at that time.

1. Purpose

Define how win/loss intelligence flows bidirectionally between sales.ops (pipeline-side signals) and customer.success (delivery-side signals), so that both functions improve from each deal cycle.

The problem this solves: Without a defined exchange, sales wins/losses become closed-loop within CRO. Delivery patterns that correlate with deal quality (e.g., customers who match certain ICP signals tend to extract more Assessment value) never reach sales.ops to refine qualification. And delivery friction that originates in how a deal was scoped never reaches the pipeline to sharpen the pitch.

2. Data Exchange Directions

sales.ops → customer.success (pre-delivery)

What sales.ops provides before customer.success takes a deal:

Data element	Format	Timing
Deal qualification score (ICP dimensions)	Pattern-coded per SOP-REV-lead-qualification-v1.0	At Assessment Handoff (per SOP-REV-assessment-handoff)
Signals that drove the deal forward	Signal-note format (per lead qualification SOP)	At Assessment Handoff
Objections raised and how addressed	Free text note	At Assessment Handoff
Expectations set during pitch	(to be defined after first deal)	At Assessment Handoff

customer.success → sales.ops (post-delivery)

What customer.success provides after Assessment delivery:

Data element	Format	Timing
Pattern-code findings	Customer.success taxonomy codes (v1.1 contract)	Within 5 business days of Assessment delivery
Delivery friction points	(to be defined after first Assessment)	Post-delivery
ICP signal validation	Did deal-stage signals predict delivery quality?	Post-mortem
Buyer-revealed context (new signals not in pre-deal data)	(to be defined after first Assessment)	Post-mortem
Recommendation for future qualification refinement	One paragraph max	Q2 post-mortem

Cadence

Exchange	Frequency	Owner
Pre-delivery handoff (sales.ops → customer.success)	Per deal	sales.ops initiates
Post-delivery summary (customer.success → sales.ops)	Per deal + quarterly rollup	customer.success initiates
Qualification model refinement	Quarterly (after Q2 post-mortem minimum)	sales.ops proposes, CRO approves

3. Exchange Format

(To be finalized after first Assessment delivery. The format will be defined by the pattern-coding taxonomy artifact that customer.success must author as their first-week deliverable per v1.1 contract.)

Placeholder structure:

WIN/LOSS DATA EXCHANGE
──────────────────────────────
Deal ID: {Monday.com item}
Direction: {sales.ops → customer.success / customer.success → sales.ops}
Stage: {pre-delivery / post-delivery / quarterly rollup}
ICP dimension scores: {5-dimension model}
Pattern codes: {customer.success taxonomy codes}
Key signals: {list}
Delivery friction: {if any}
Qualification refinement recommendation: {if any}
Filed by:
Date:

4. Storage and Access

Win/loss data exchange records are filed to: - Per-deal: Monday.com sub-item under the deal's CRM item - Quarterly rollup: /Claude/operations/reports/revenue/win-loss-{YYYY-QN}.md

Both sales.ops and customer.success have read access to all win/loss records. CRO has read access. CMO has read access to quarterly rollups (for positioning calibration).

5. Qualification Model Refinement

When post-delivery data suggests the ICP qualification model should be updated:

1. customer.success flags the signal in the post-delivery summary
2. sales.ops synthesizes across deals (minimum 3 data points before proposing a model change)
3. CRO approves qualification model changes
4. sales.ops updates SOP-REV-lead-qualification per the amendment path in SOP-OPS-sop-change-management
5. council review recommended for any change that reclassifies a scoring dimension

6. Open Items for v1.0 Promotion

The following cannot be completed until after the first Assessment:

• [ ] Exact data fields for pre-delivery signal notes
• [ ] customer.success taxonomy codes (pattern-coding taxonomy artifact — first-week deliverable)
• [ ] Post-delivery friction field definitions
• [ ] Qualification correlation format (how delivery outcomes are expressed as ICP signal feedback)
• [ ] Quarterly rollup template structure
• [ ] Timing SLAs for post-delivery summary (currently placeholder "5 business days")

Promotion path: After first Assessment + Q2 post-mortem → sales.ops and customer.success jointly complete the open items → council review → CRO approves → v1.0.

---

Change Log

Version	Date	Change
v0	2026-04-21	Skeleton draft — sop.manager. Per Michelle's council review implementation guide Section 4. Operational sections deferred pending first Assessment data.

---

Owner: sales.ops Co-owner: customer.success Drafted by: sop.manager Status: v0 Skeleton — not governing any behavior; operational sections incomplete pending first Assessment data Version: v0