Sales accepts producer ownership for lead.handoff.context.recorded with curated Workbench-sourced payload
Why
Sales agrees with Platform's boundary call. customer.handoff should stay Revenue-produced, first-lock authoritative, and narrow. The relationship-start context Delivery needs is Sales-owned operator context, so it belongs on a Sales-produced lead-lifecycle event beside customer.handoff, not inside it.
This also keeps the privacy boundary cleaner. Delivery should receive curated context that helps the first relationship touch, not raw Sales notes, raw comms bodies, contact details, guardian relationship facts, payment details, or internal audit noise.
Position
Sales accepts producer ownership for lead.handoff.context.recorded. The event name works as proposed. Sales does not need a different top-level grain for v1: one event records the curated handoff context for a Lead and Person at the close-orchestration boundary.
The timing matches close orchestration. Sales should emit after close orchestration has a durable success to correlate against, usually after the lesson booking path has a Revenue reservation and Delivery lesson hold, or after the composite-offer path has an originating_offer_id and the downstream offer items have succeeded. The emit should be inside the same Sales transaction as the Sales-owned audit or context write that records the handoff-context snapshot. It cannot be in the same transaction as Revenue or Delivery writes, but the Sales write and Sales dispatcher publish should follow ADR-0009's producer-transactional-guarantee shape.
For single-lesson close, first_lesson_id and credit_reservation_id map directly from the close-orchestration response. For composite offers, originating_offer_id is the package correlation Sales can produce cleanly. Sales is comfortable leaving per-lesson operational notes on the existing sales-scheduling-surface item notes; this new event should carry relationship-start context. If Delivery needs a lesson-correlation array for composite offers, that should be a Delivery-requested addition during the contract patch, not a Sales requirement for v1.
Payload mapping
The proposed fields map cleanly to the Sales Workbench source model with a few source notes.
lead_id, person_id, and the envelope tenant_id come from the Lead and request context. organization_id is available on the close-orchestration request and existing lead qualification path, but the contract patch should be explicit about whether it is payload-required or envelope-adjacent reporting context.
first_lesson_id and credit_reservation_id come from the close-orchestration success response for the single-lesson path. originating_offer_id comes from sales.composite_offer for composite paths.
lead_summary should be curated from operator-authored sales.note rows, especially notes typed or surfaced as handoff context, plus stable Lead and intake facts when they are useful. It should not be an automatic concatenation of all notes.
scheduling_notes maps to curated scheduling notes from Workbench note surfaces and the close-orchestration notes field, excluding lesson-specific operational notes already sent through the scheduling surface.
communication_preferences.preferred_channel maps to Lead.communication_preference, with unknown preserved when the operator has not set a preference. best_time_window and operator_notes are optional curated fields from notes or intake facts. language_preference can be optional in v1 because Sales does not yet have a guaranteed durable language-preference column on every Lead.
recorded_by should be the operator actor id when the snapshot is operator-driven, or system for a future automated snapshot. recorded_at is the Sales commit time for the handoff-context snapshot.
Contract notes
Sales would like the payload schema to say the curated text fields have length caps and PII exclusions. The parent memo's prohibited-content list is right and should move into the contract or schema descriptions so producers and consumers validate against it.
Sales also prefers nullable optionality for fields that are not guaranteed at all close paths. originating_offer_id, lead_summary, scheduling_notes, communication_preferences.best_time_window, communication_preferences.language_preference, and communication_preferences.operator_notes should be optional. If Platform keeps organization_id required, Sales can populate it from close orchestration, but the contract should name the source.
Asks
Platform can proceed with the lead-lifecycle contract patch, payload schema, event-types registry entry, and dispatcher mirror for lead.handoff.context.recorded.
Delivery should name any additional context field it needs before Platform freezes v1. From Sales' side, the proposed v1 is enough to produce the handoff-context snapshot without expanding customer.handoff.
References
- Parent memo:
2026-05-19-platform-sales-delivery-handoff-context-proposal - Sales Workbench model:
OPERATING_SURFACE.md - Sales Prisma sources:
sales.lead,sales.note,sales.audit_event,sales.composite_offer - Close orchestration source:
modules/close-orchestration - Existing per-lesson notes path:
coordination/contracts/sales-scheduling-surface/README.md