SOP-REV-assessment-handoff-v0.1¶
1. Purpose¶
Define the procedure that governs how a sold Ecosystem Revenue Architecture Assessment™ ($2,500) gets handed from the sales process (CRO / sales.ops) to the delivery team (customer.success). This SOP exists because the sell-to-deliver handoff is the highest-risk gap identified by council review of Phase 1 Revenue. Without a codified procedure, deal #1 has no defined handoff process, customer context leaks between sales and delivery, and expectations set during the pitch may not survive the transition.
This SOP must be active BEFORE the first Assessment deal closes. Target: mid-May 2026.
Structural note. Per DR-011 and the CRO contract (v1.1), CRO personally owns deal execution during the absorption period. Chief of Staff (Eva) has RACI visibility on the CRO-to-customer.success handoff per the R6 council recommendation, addressing the structural conflict where sales.ops enforces handoff quality on its own reporting executive.
2. Trigger¶
This SOP fires when any of the following conditions is met (v0.1: expanded from v0's all-of-three):
- SOW executed — both parties have signed SOW-Assessment-Template (current version at
/Claude/knowledge/company/legal/Contract-Templates/SOW-Assessment-Template-v0.1.md). This is the primary trigger. Preliminary handoff activities begin here so SOW Section 4 scheduling clocks are honored. - Payment confirmed — full $2,500 payment received or payment processing initiated per SOW Section 5 terms. This is the full-handoff trigger (preliminary packet promoted to complete, discovery confirmed).
- Discovery session scheduled — when the customer.success-customer scheduling is confirmed, handoff promotion is mandatory (cannot deliver an unscheduled discovery).
Two-phase handoff (v0.1 — addresses SOW clock gap)¶
v0's single-trigger model at payment-confirmed created a timing gap: SOW Section 4 starts the discovery-session clock at SOW execution, but payment-processing lag (ACH, wire, card auth) could push discovery scheduling past the 5-business-day SOW commitment. v0.1 splits the handoff into two phases:
- Phase A — Preliminary handoff (at SOW execution). CRO files a preliminary packet with consent fields marked TBD pending payment. customer.success receives the preliminary packet, contacts the scheduling contact to book discovery provisionally. If payment subsequently fails, the discovery is cancelled with customer communication handled by CRO.
- Phase B — Full handoff (at payment confirmation). CRO promotes the preliminary packet to complete: populates Consent Status (Section 3.5) with confirmed values, files the Section 6C Handoff Report, runs the full quality gate per Section 6. customer.success confirms the discovery session with the customer.
Timing, v0.1: - Phase A preliminary packet filed within 1 business day of SOW execution - Provisional discovery scheduling initiated within 2 business days of SOW execution - Phase B full packet filed within 1 business day of payment confirmation - Discovery session confirmed within 5 business days of SOW execution (SOW Section 4 compliance)
If payment confirmation exceeds 5 business days post-SOW, CRO owns customer communication to reset expectations and logs a SEV3 incident per Section 7.
3. Assessment Handoff Packet Contents¶
The CRO (or sales.ops on CRO's behalf) assembles the following packet. Every field marked Required must be populated before Phase B promotion. Phase A preliminary filing may leave Section 3.5 Consent Status marked "pending payment" and may have Technical POC flagged as provisional.
3.1 Customer Context Brief¶
| Field | Description | Required |
|---|---|---|
| Company name | Legal entity name (must match SOW) | Yes |
| Industry | Primary industry vertical | Yes |
| Company size | Employee count range and/or annual revenue range | Yes |
| ICP fit score | Score from ICP qualification criteria per SOP-REV-lead-qualification current version | Yes |
| Partner ecosystem complexity | Number of active partner relationships, ecosystem maturity level (nascent / emerging / established / complex) | Yes |
| Current ecosystem revenue model | How they monetize partnerships today (if at all) | Yes |
| How they found us | Lead source (LinkedIn content, referral, outbound, event, etc.) | Yes |
| CRM/Monday.com deal ID | Link to the Monday.com revenue board item | Yes |
| Account history notes | Any prior engagement (Diagnostic, Briefing, previous conversations) | If applicable |
3.2 Scoping Decisions¶
| Field | Description | Required |
|---|---|---|
| Assessment modules included | Which of the 3 architectural domains (Ecosystem Leverage, Revenue Governance, Signal Intelligence) are in scope — standard is all 3 | Yes |
| Modules excluded or de-emphasized | Any domains the customer asked to skip or de-prioritize, with rationale | If applicable |
| Custom questions added | Any specific diagnostic questions added at the customer's request beyond the standard 25 | If applicable |
| Scope deviations from standard SOW | Anything promised that differs from the SOW template scope (Section 3.1/3.2) | If applicable |
Assessment template reference: Assessment modules and standard diagnostic questions are defined at /Claude/knowledge/company/offer/ecosystem-revenue-architecture-assessment/ — [TBD if not yet published at the time of first handoff]. Until the template is formally published, the CRO and customer.success jointly confirm module scope on a per-deal basis and log the scope in a scope-confirmation.md file alongside the packet. Authoring the Assessment Template is a dependency on first-deal-readiness, tracked separately.
3.3 Expectations Set¶
| Field | Description | Required |
|---|---|---|
| Delivery timeline promised | Specific dates or "within X days" commitments made to the customer | Yes |
| What the customer expects to receive | Customer's understanding of deliverables — in their words, not ours | Yes |
| Readout format preference | Virtual (default per SOW), in-person, or hybrid | Yes |
| Stakeholders expected at readout | Who the customer plans to bring to the findings presentation | Yes |
| Follow-on expectations | Did the customer express interest in ERI Essentials or higher tiers? What was said about next steps? | If applicable |
3.4 Constraints¶
| Field | Description | Required |
|---|---|---|
| Data access limitations | Any restrictions on what data the customer can share (regulatory, NDA-gated, internal policy) | If applicable |
| NDA status | Is a separate NDA required beyond the SOW confidentiality clause (Section 9)? If so, status (drafted / signed / pending) | Yes |
| Technical environment notes | CRM platform, partner management tools, data warehouse — anything relevant to the diagnostic | If applicable |
| Scheduling constraints | Customer availability windows, timezone, blackout dates | If applicable |
| Language or cultural considerations | Non-English stakeholders, regional business norms | If applicable |
3.5 Consent Status¶
| Field | Description | Required |
|---|---|---|
| SOW signed | Date signed, SOW version number, link to executed copy | Yes |
| Payment confirmed | Date payment received or processing initiated, payment method | Yes (Phase B) — may be "pending" at Phase A |
| Data sharing agreement | Separate DPA required? (per SOW Section 12) Status if applicable | Yes |
| Satisfaction guarantee acknowledged | Customer is aware of the 14-day guarantee (SOW Section 6) | Yes |
3.6 Key Contacts (v0.1 — Technical POC promoted to Required)¶
| Field | Description | Required |
|---|---|---|
| Customer-side champion | Name, title, email, phone — the person who drove the purchase decision | Yes |
| Executive sponsor | Name, title — the person with budget authority | Yes |
| Technical POC | Name, title, email — the person who can answer ecosystem/data questions during discovery | Yes (v0.1) |
| eco|monetize™ primary contact during sales | Who ran the deal (CRO directly, or sales.ops on CRO's behalf) | Yes |
| Scheduling contact | Who to coordinate calendar with for discovery session | Yes |
Technical POC exception (v0.1): If the executive sponsor serves as technical owner (common in founder-led companies or small teams), document this explicitly in the Technical POC field: "Executive sponsor doubles as technical owner — confirmed by [CRO / sales.ops] on [date]." A handoff packet without a Technical POC or documented exception is not deliverable. customer.success cannot map ecosystem signals, CRM data, and partner revenue attribution without someone who can answer ecosystem questions.
4. Packet Template¶
The handoff packet is filed as a single markdown document at:
Where {SOW-YYYY-NNN} matches the SOW number. The file uses the field structure from Section 3 above as its template.
A Section 6C Handoff Report (per CLAUDE.md Section 6C) is filed alongside the packet at:
Section 4 Packet Template — Language Patterns Checklist (v0.1)¶
Per Workstream C2 Assessment Language Guide v0.1, the packet includes a 2-tier language-patterns checklist:
Tier 1 — Pre-delivery review (CRO runs before handing to customer.success)
- [ ] Executive summary uses observation-framed language ("pattern we observe in companies with your profile"), not social-proof language ("most CROs we talk to") — social-proof works verbally in pre-sale, fails in written deliverables
- [ ] No parallel-axis violations (no "next gen RevOps," "post-RevOps," "RevOps 2.0")
- [ ] No diagnostic critical language ("your pipeline is missing," "your forecast is broken")
- [ ] "The architecture reveals" swept to "surfaced" in all written content
- [ ] Any delivery-context risk findings (attribution gap, data quality, active signal) follow the four-step language structure in C2 Guide
- [ ] Ecosystem Revenue Architecture Assessment™ trademark usage consistent
Tier 2 — Delivery call prep (customer.success self-checks before each session)
- [ ] Discovery framing shifted to delivery framing — no "see what you can't currently see" in post-sale calls
- [ ] Opening line drafted using delivery-register opener ("Let's walk through what the architecture surfaced..."), not sales-register opener
- [ ] Active risk flags have "active flag + normalize + action" language pattern drafted before the call, not improvised in the room
- [ ] If any data quality gaps were found in the Assessment, the "directional rather than precise" framing is prepared and ready
- [ ] Top three findings ranked and prepared — client engages with 2-3 findings deeply, not 10 shallow ones
- [ ] Follow-up language drafted for each finding — "Recommend: [action]" phrasing, not diagnostic phrasing
Full guide at Workstream C2 reference in frontmatter.
5. Handoff Execution¶
Step 1: CRO assembles the preliminary packet (Phase A — at SOW execution)¶
- CRO (or sales.ops on CRO's behalf) fills out the Assessment Handoff Packet per Section 3
- Consent Status (3.5) Payment field may be marked "pending" at Phase A
- Technical POC may be flagged "confirmation pending" at Phase A if not yet identified in the sale
- CRO files the preliminary packet at the path in Section 4
Step 2: Notification and provisional scheduling (Phase A — within 1 business day of SOW execution)¶
- CRO posts to
#agent-handoffsin Slack per CLAUDE.md Section 9 Rule 6: - For: customer.success
- Type: Assessment Handoff Packet — preliminary (Phase A)
- File path:
/Claude/operations/handoffs/assessments/{SOW-YYYY-NNN}-handoff-packet.md - Blocking: No — provisional scheduling may begin (confirmation blocked until Phase B)
- CRO updates the Monday.com revenue board item: status to "Handoff Initiated (Phase A)," owner field updated to include customer.success
- customer.success contacts the customer's scheduling contact to book the discovery session provisionally (calendar hold; final confirmation after Phase B)
Step 3: customer.success acknowledges (within 1 business day of Phase A notification)¶
- customer.success reads the preliminary handoff packet
- customer.success runs the quality gate checklist (Section 6) at the Phase A level (required fields that can be checked pre-payment)
- If the preliminary packet passes: customer.success acknowledges on Section 6C Handoff Report and posts ack to
#agent-handoffs - If the preliminary packet fails: customer.success files a rejection per Section 6 and notifies CRO
Step 3b: Pre-delivery signal logging (v0.1 — new)¶
- customer.success logs pre-delivery signals from the handoff packet to the Airtable customer feedback record using the pattern-coding taxonomy (v0 at
/Claude/system/agents/revenue/customer.success.mdPrompt Body, pre-first-Assessment prerequisite section) - At minimum: ICP fit code, ecosystem maturity code, lead source code, any follow-on expectation signal
- Timing: before the discovery session, not after
- The feedback record must exist (with consent status populated per DPA) before customer.success acknowledges the Phase B full handoff
Step 4: CRO warm introduction (v0.1 — required, not optional)¶
- Required for all first-contact handoffs. CRO sends a brief email introducing customer.success as the delivery lead before customer.success makes first contact with the customer. customer.success does not reach out cold.
- Recommended language pattern for the introduction (from C2 Language Guide v0.1, delivery-register opener):
"Introducing [name], who leads delivery on the Ecosystem Revenue Architecture Assessment™. [Name] will reach out within 48 hours to schedule the discovery session and walk through what to expect. [Name] has the full context from our Briefing and the SOW, and can answer any questions about the delivery process."
- The warm intro bridges the sales-to-delivery relationship and signals to the customer that a real team is behind the Assessment. It also triggers the register shift from pre-sale ("see what you can't currently see") to delivery ("walk through what the architecture surfaced") — positioning customer.success as a co-interpreter, not a new salesperson.
Step 5: Payment confirmation and full handoff (Phase B)¶
- At payment confirmation, CRO promotes preliminary packet to full:
- Section 3.5 Consent Status Payment field populated
- Section 3.6 Technical POC field confirmed (or documented exception)
- Full Quality Gate per Section 6 re-run
- Section 6C Handoff Report signed off by both CRO and customer.success
- customer.success confirms discovery session date with customer (lifting the "provisional" hold from Step 2)
- CRO updates Monday.com revenue board item: status to "Handoff Complete (Phase B)" and logs the discovery session date
6. Quality Gate¶
customer.success checks the following before accepting the handoff. ALL items must pass at Phase B; starred (★) items must pass at Phase A.
| Check | Pass criteria | Phase |
|---|---|---|
| All required fields populated | No blank required fields in the packet (Phase A may show Consent Status Payment "pending") | A ★ / B |
| SOW copy accessible | Executed SOW linked and readable | A ★ |
| Payment confirmed | Payment status verified (not just "pending") | B |
| Timeline alignment | Delivery timeline promised to customer is achievable within SOW Section 4 constraints | A ★ |
| Scope alignment | Assessment modules match what the SOW covers; no undocumented scope expansion | A ★ |
| Expectation alignment | What the customer expects to receive matches what customer.success will deliver | A ★ |
| Contact info complete | Champion and executive sponsor contacts are valid (not placeholder text) | A ★ |
| Technical POC present | Technical POC populated OR executive sponsor documented as technical owner (v0.1) | B |
| Airtable feedback record created | Customer record exists in Airtable feedback table; consent status field populated per DPA (v0.1) | A ★ |
| Monday.com item exists | Deal is tracked in Monday.com with correct status | A ★ |
| Warm introduction confirmed | CRO warm intro sent (v0.1 Step 4) | B |
Rejection procedure¶
If any check fails:
- customer.success posts to
#agent-handoffs: "Handoff packet {SOW-YYYY-NNN} rejected — {which checks failed} — {Phase A or B}" - CRO has 1 business day to remediate and resubmit
- If remediation requires information from the customer (e.g., missing contact), CRO owns the outreach
- Resubmitted packet goes through the quality gate again
- If the packet fails quality gate twice, escalate to Chief of Staff per Section 7
7. Escalation¶
| Condition | Action |
|---|---|
| Packet incomplete after 2 remediation attempts | Chief of Staff (Eva) notified; incident logged per CLAUDE.md Section 6E (SEV2) |
| Expectations set by CRO are misaligned with standard Assessment scope | CRO and customer.success resolve jointly; if unresolved within 1 business day, Chief of Staff mediates |
| Customer timeline promise is unachievable | CRO owns customer communication to reset expectations; customer.success drafts revised timeline; Chief of Staff informed |
| Scope deviation from SOW (CRO promised something not in the SOW) | Escalate to CEO — non-standard terms require CEO approval per CRO contract Decision Rights |
| Payment not confirmed within 5 business days of SOW execution | SEV3 incident filed; CRO owns customer communication; provisional discovery scheduling held pending resolution |
| Payment not confirmed and handoff Phase B attempted | Phase B blocked; CRO resolves payment status before resubmitting |
| Technical POC not identified and exception not documented | Phase B blocked; CRO coordinates with customer to name a Technical POC |
| Discovery session not scheduled within SOW Section 4 timeline | Incident report filed (SEV2); CRO and customer.success jointly own remediation |
| Warm introduction not sent before customer.success makes first contact | SEV3 incident filed; customer.success flags to Chief of Staff as a process breach |
All escalations feed into the standard CLAUDE.md Section 11 Escalation Framework. Council review does not apply to individual handoff execution, but patterns of handoff failure across multiple deals should trigger a Section 6E SOP Delta proposing process improvements.
8. Archive¶
Handoff packets and handoff reports are stored at:
Naming convention:
- Preliminary packet (Phase A): {SOW-YYYY-NNN}-handoff-packet.md (promoted in place at Phase B — single file tracks both phases in a v0.1 + change log style)
- Handoff Report: {SOW-YYYY-NNN}-handoff-report.md
Archives are retained for the life of the customer relationship plus 2 years (aligned with SOW Section 9 confidentiality survival period). They serve as:
- Audit trail for delivery quality reviews
- Input to customer.success quarterly post-mortems
- Reference for subsequent engagements with the same customer (upgrade to ERI Essentials, etc.)
- Evidence for CRO-to-customer.success handoff quality metrics tracked by Chief of Staff
9. Chief of Staff Governance Visibility¶
Per the R6 council recommendation (CRO contract v1.1), Chief of Staff (Eva) has structural governance visibility on this handoff:
- Eva is Informed on RACI rows 1-3 (deal execution) during the DR-011 absorption period
- Eva reviews handoff quality as part of the daily cadence sweep
- Eva can flag quality concerns that sales.ops may hesitate to escalate given the CRO reporting relationship
- Handoff quality metrics (pass rate, remediation frequency, time-to-acknowledge, Phase A→B conversion lag) are included in the CEO Weekly Summary when Assessment deals are active
This governance layer exists because the CRO personally owns deal execution during the DR-011 absorption period, creating a structural conflict where the seller is also the handoff packager. Chief of Staff visibility is the check.
10. Companion SOP — SOP-REV-assessment-delivery (pending)¶
This SOP covers the handoff. A companion SOP — SOP-REV-assessment-delivery — will cover the delivery process (discovery through readout), including:
- Discovery session agenda and preparation checklist
- Pre-read materials for the customer
- Delivery-call language discipline (full C2 Tier 2 checklist, not just the handoff extract)
- Findings interpretation and risk-escalation protocol
- Readout format and post-delivery action handoff back to CRO (for ERI Essentials upgrade conversations)
Timing of companion SOP: deferred until after the first 3 Assessment delivery cycles complete, so the pattern library emerges from real data rather than theory. Customer.success owns authoring; CRO and Chief of Staff consulted. Target: mid-Q3 2026.
11. Deferred items (flagged for post-first-Assessment review)¶
| Item | Trigger for revisit |
|---|---|
| ICP fit score minimum threshold (quality gate) | After 3-5 deals' worth of ICP scoring data; define the threshold empirically |
| Companion SOP-REV-assessment-delivery authoring | After 3 Assessment delivery cycles complete |
| Phase A→B conversion SLA tightening | After 5 deals; currently "within 5 business days of SOW execution" aligned to SOW Section 4 |
| Assessment Template publication | Blocks first-deal readiness; tracked separately as a pre-first-deal dependency |
Change log¶
| Version | Date | Change |
|---|---|---|
| v0.1 | 2026-04-23 | Co-authored integration pass with customer.success review 2026-04-21. Three must-fix items resolved (two-phase handoff aligning SOW clock; Technical POC promoted to Required with exec-sponsor-as-technical exception; CRO warm intro promoted to Required). Three good-additions integrated (Airtable feedback record in quality gate; Step 3b pre-delivery signal logging; Assessment template reference note). Two deferred items flagged in Section 11. Section 4 Packet Template extended with Tier 1/Tier 2 language-patterns checklist from Workstream C2 Assessment Language Guide v0.1. Section 10 Companion SOP added. Quality gate reformatted with Phase A/B columns. |
| v0 | 2026-04-19 | Initial draft by CRO (Marcus). Pending council review and customer.success co-authoring before promotion to v1.0 Active. |
Owner: cro (Marcus) Co-author: customer.success Executive sponsor: cro Chief of Staff governance: chief.staff (Eva) — RACI Informed per R6 Approved by: pending (requires council review bundle wk 2026-04-28 + CEO approval) Effective: TBD Version: v0.1