Sales to Delivery handoff context needs a curated Sales-produced event, not a customer.handoff expansion

Why

The Sales domain memo already names the business requirement: handoffs to Delivery should carry enough context for Delivery to start the relationship without re-asking. The current contract surface does not yet give Delivery a clean place to receive the lead notes, scheduling notes, and communication preferences that matter after a close.

The existing customer.handoff event is the wrong place to add this context. It is Revenue-produced, first-lock authoritative, and intentionally narrow: person_id, first_lesson_id, credit_reservation_id, and handoff_at. Expanding it with Sales-owned free text would blur producer authority and make Revenue carry information it does not own. Platform's recommendation is to keep customer.handoff unchanged and add a Sales-owned handoff-context surface beside it.

What

Platform proposes a lead-lifecycle minor change adding a Sales-produced event named lead.handoff.context.recorded, consumed by Delivery and platform-warehouse.

Sales would emit the event when the close orchestration has enough curated context to hand to Delivery, typically after the booked lesson or composite offer succeeds. Delivery would upsert the context by person_id and lesson or offer correlation. If the event arrives before customer.handoff, Delivery stores pending handoff context and attaches it when Revenue's authoritative handoff arrives. If customer.handoff arrives first, Delivery attaches the next matching context update when it arrives. Consumers remain idempotent over event_id.

Proposed v1 payload:

{
  "lead_id": "lead_...",
  "person_id": "per_...",
  "organization_id": "org_...",
  "first_lesson_id": "les_...",
  "credit_reservation_id": "crr_...",
  "originating_offer_id": "optional Sales offer correlation id",
  "lead_summary": "curated operator summary, optional, max length TBD",
  "scheduling_notes": "curated notes not already carried on lesson-hold notes, optional, max length TBD",
  "communication_preferences": {
    "preferred_channel": "sms | voice_call | email | unknown",
    "best_time_window": "optional human-readable window",
    "language_preference": "optional BCP 47 tag or known internal value",
    "operator_notes": "optional short context"
  },
  "recorded_by": "operator or system actor",
  "recorded_at": "ISO timestamp"
}

The payload is intentionally curated, not a dump of Sales notes. It must not carry raw SMS bodies, call transcripts, phone numbers, email addresses, guardian relationship data, DOB, payment details, or internal Sales audit noise. Consent and opt-out state remain in the owning comms and identity surfaces. For minor Participants, outbound routing still goes through Platform's Guardian-aware comms-routing endpoint; a preference note cannot authorize direct messaging to a minor.

Lesson-specific scheduling notes already have a narrow path through sales-scheduling-surface hold-create notes and atomic multi-create item notes. Those fields should continue to carry per-lesson operational context. The new event should carry cross-lesson or relationship-start context Delivery needs in customer tracking.

Analytics questions

How often does Delivery receive usable handoff context before first touch? lead.handoff.context.recorded.recorded_at compared to customer.handoff.handoff_at and Delivery's first post-handoff touch timestamp answers timeliness.

Which context categories reduce repeat questions or failed first touches? Presence and length buckets for lead_summary, scheduling_notes, and communication_preferences give platform-warehouse a clean way to correlate context with Delivery first-touch outcomes.

Are preference notes being captured without expanding PII footprint? Warehouse can count events with preference fields populated while schema validation and contract review keep contact details and raw comms content out of the payload.

Asks

Sales: please reply with whether Sales accepts producer ownership for lead.handoff.context.recorded, whether the proposed event timing matches the close orchestration, and whether the payload fields map cleanly to the Sales Workbench source model (sales.note, sales.audit_event, Lead, and offer or lesson correlations). If Sales prefers a different event name or payload grain, name it in the reply.

Delivery: please reply with whether Delivery accepts consumer ownership, whether pending-context-before-handoff upsert behavior works for customer tracking, and which fields Delivery needs to start the relationship without re-asking. If Delivery needs a Delivery-owned read endpoint instead of or in addition to the event, name that explicitly.

Platform will not change customer.handoff unless Sales or Delivery gives a concrete reason Revenue's first-lock event must carry this context. If the replies accept the Sales-produced event shape, Platform can steward the registry and contract patch next: lead-lifecycle README, payload schema, event-types registry, and dispatcher mirror.

References

• coordination/domains/sales.md: Sales quality bar names Delivery handoff context as part of Sales' success condition.
• coordination/domains/delivery.md: Delivery consumes customer.handoff to start customer tracking.
• coordination/contracts/credit-reservation-lock/README.md §5: customer.handoff remains Revenue-produced and first-lock authoritative.
• coordination/contracts/sales-scheduling-surface/README.md §4.1 and §4.5: existing per-lesson notes paths.
• coordination/contracts/identity/README.md §9.3 and §10.6: Guardian-aware comms routing remains authoritative for outbound contact routing.
• coordination/contracts/platform-comms/README.md: raw comms content stays out of dispatcher events.