SOP-REV-assessment-handoff-v0¶
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 the Phase 1 Revenue work. 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 ALL of the following conditions are met:
- Assessment sold -- customer has verbally committed to the $2,500 Ecosystem Revenue Architecture Assessment
- SOW signed -- both parties have executed SOW-Assessment-Template (current version at
/Claude/knowledge/company/legal/Contract-Templates/SOW-Assessment-Template-v0.1.md) - Payment confirmed -- full $2,500 payment received or payment processing initiated per SOW Section 5 terms
Timing: The handoff packet must be assembled and delivered to customer.success within 2 business days of payment confirmation. Discovery session scheduling (per SOW Section 4: within 5 business days of SOW execution) cannot begin until customer.success acknowledges receipt of the handoff packet.
3. Assessment Handoff Packet Contents¶
The CRO (or sales.ops on CRO's behalf) assembles the following packet. Every field is required unless marked optional. An incomplete packet triggers the quality gate rejection in Section 6.
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 at /Claude/knowledge/company/icp-positioning/ |
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 |
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 |
| 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¶
| 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 | If applicable |
| eco | monetize primary contact during sales | Who ran the deal (CRO directly, or sales.ops on CRO's behalf) |
| Scheduling contact | Who to coordinate calendar with for discovery session | Yes |
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:
5. Handoff Execution¶
Step 1: CRO assembles the packet (Day 0-1)¶
- CRO (or sales.ops on CRO's behalf) fills out the Assessment Handoff Packet per Section 3
- CRO reviews the packet for completeness against the quality gate checklist (Section 6)
- CRO files the packet at the path in Section 4
- CRO files the Section 6C Handoff Report
Step 2: Notification (Day 1)¶
- CRO posts to
#agent-handoffsin Slack per CLAUDE.md Section 9 Rule 6: - For: customer.success
- Type: Assessment Handoff Packet
- File path:
/Claude/operations/handoffs/assessments/{SOW-YYYY-NNN}-handoff-packet.md - Blocking: Yes -- discovery session scheduling blocked until acknowledged
- CRO updates the Monday.com revenue board item: status to "Handoff Initiated," owner field updated to include customer.success
Step 3: customer.success acknowledges (within 1 business day)¶
- customer.success reads the handoff packet
- customer.success runs the quality gate checklist (Section 6)
- If the packet passes: customer.success signs the
Acknowledged Byfield on the Section 6C Handoff Report and posts acknowledgment to#agent-handoffs - If the packet fails: customer.success files a rejection per Section 6 and notifies CRO
Step 4: Delivery kickoff scheduled (within 2 business days of acknowledgment)¶
- customer.success contacts the customer's scheduling contact to book the discovery session
- customer.success confirms the discovery session date in Monday.com and notifies CRO
- SOW Section 4 timeline clock starts at SOW execution, so customer.success must hit "within 5 business days of SOW execution" for scheduling
Step 5: CRO warm introduction (optional but recommended)¶
- CRO sends a brief email to the customer introducing customer.success as their delivery lead
- This bridges the relationship from sales to delivery and signals to the customer that a real team is behind the Assessment
6. Quality Gate¶
customer.success checks the following before accepting the handoff. ALL items must pass.
| Check | Pass criteria |
|---|---|
| All required fields populated | No blank required fields in the packet |
| SOW copy accessible | Executed SOW linked and readable |
| Payment confirmed | Payment status verified (not just "pending") |
| Timeline alignment | Delivery timeline promised to customer is achievable within SOW Section 4 constraints |
| Scope alignment | Assessment modules match what the SOW covers; no undocumented scope expansion |
| Expectation alignment | What the customer expects to receive matches what customer.success will deliver |
| Contact info complete | Champion and executive sponsor contacts are valid (not placeholder text) |
| Monday.com item exists | Deal is tracked in Monday.com with correct status |
Rejection procedure¶
If any check fails:
- customer.success posts to
#agent-handoffs: "Handoff packet {SOW-YYYY-NNN} rejected -- {which checks failed}" - 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 but handoff attempted | Handoff blocked; CRO resolves payment status before resubmitting |
| Discovery session not scheduled within SOW Section 4 timeline | Incident report filed (SEV2); CRO and customer.success jointly own remediation |
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:
- Packet: {SOW-YYYY-NNN}-handoff-packet.md
- 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) 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.
Change log¶
| Version | Date | Change |
|---|---|---|
| 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 pending: customer.success Executive sponsor: cro Chief of Staff governance: chief.staff (Eva) -- RACI Informed per R6 Approved by: pending (requires council review + CEO approval) Effective: TBD Version: 0