Re: Coaching calendar-and-roster app proposal; Sales supports the two-pattern split
Summary
Sales supports the proposal. The architectural argument is correct: data ownership and UI ownership should align, Coaching owning the calendar-and-roster surface fits ADR-0008 cleanly, and the two-pattern partition (Workbench for queue-and-action, Coaching app for calendar-and-roster) is a clean split that covers the operator-surface space without leaving a third pattern lurking. The major architectural call rightly sits with Coaching; Sales has nothing to add to the case for or against acceptance on Coaching's seat.
Sales' answers to the two Sales-specific asks are below. Two are roughly affirmative with small refinements; one UX question worth surfacing that the proposal leaves implicit; one small factual correction about the "Sales supply tab" the proposal references.
Answers to the two Sales-specific asks
Sales-mode default filter
The proposed default ("next 14 days, all coaches, available windows") is roughly right with two refinements worth flagging.
The "next 14 days" window matches Sales' typical offer-construction horizon. Most lessons get booked within 1 to 2 weeks of the operator-customer call; pushing the default further out (30 days, 60 days) would add noise without operator value, and shorter (next 7 days) would cut off legitimate offers. 14 is a reasonable default; the operator should be able to extend or compress it via a date-range control.
The "all coaches" default is right because the offer-construction job is "find the best fit," and pre-filtering to a coach subset before the operator has read the eligibility shape would bake in a bias.
The "available windows" filter is right; Sales has no reason to see booked windows in the offer-construction view (those are Delivery's concern).
The two refinements:
When the calendar is opened from a Lead context (the operator has a specific Lead in flight and is constructing an offer for that customer), the Sales-mode default should also pin a service-area filter to the Lead's service area. Showing eligibility for coaches who can not cover the customer's service area is noise that would mislead the operator into proposing an unbookable slot. The service area is a known fact on the Lead (per Sales' provisional-Service-Area-guess pattern from ADR-0012); the deep-link could carry it. When the calendar is opened standalone (operator browsing without a specific Lead), the filter falls back to "all service areas" because there is no Lead context to infer from.
A preferred-coach toggle would help the continuity case. When a Lead has a prior coach association (a previous lesson, a customer-stated preference captured in intake notes, or a sales-side note flagging continuity), the operator typically wants to see that coach's availability first before browsing alternatives. An off-by-default toggle that filters to "preferred coach if any, else all coaches" would serve the case without changing the default for fresh Leads.
Neither refinement blocks acceptance. The default filter shape can ship as proposed and the refinements can land as Sales-mode iterations once operators are using the surface.
Deep-link handoff shape
The proposed (coach_id, window) deep-link is the right shape with one parameter addition and one observation worth naming.
The addition: the parameter set should include lead_id. Sales' close-orchestration flow needs to know which Lead is being booked for; the operator's path through the Coaching app should preserve that context rather than dropping the operator into close-orchestration without a Lead context. The full deep-link parameter set would be (lead_id, coach_id, window_start, window_end) (and lesson_site_id if the Coaching app surfaces site selection at the calendar layer; otherwise close-orchestration picks the site from the Lead's service-area). Coaching's app emits the link; Sales' Workbench receives it at the close-orchestration entry route.
The observation: the slot selected at deep-link time is a hint, not a reservation. Between the operator selecting the slot in the Coaching app and the operator committing to close-orchestration in the Workbench, the slot may be taken by another operator or by an out-of-band path. This is the canonical concurrency case the sales-scheduling-surface §6.6 retry pattern handles (HTTP 409 with conflict_reason: slot_taken_concurrently, retry against a fresh eligibility read and a new reservation request); no new contract semantics are required to support the deep-link flow. Sales' close-orchestration UI will need to handle the 409 surface gracefully (re-open the Coaching app calendar with the current eligibility state, or fall back to a Sales-side offer-construction popup with refreshed eligibility), but that handling is Sales-internal and falls out of the close-orchestration build.
The link-out vs embedded calendar UX question
The proposal assumes link-out: Sales operator clicks out from the Workbench to Coaching's app, finds a slot, returns via the deep-link. The unstated alternative is embedded: Coaching's calendar view lands as a panel inside the Sales Workbench (via shared component, iframe, or whatever the share-shape conversation falls out to), and the operator never leaves their primary tool.
Link-out is simpler architecturally (clean app boundaries, the Coaching app owns its own routing and state, no cross-app component sharing). Embedded is richer UX (no context switch, no cross-app navigation cost, no "lost my Workbench position when I went to Coaching's app" friction). Both are legitimate; neither is obviously right.
Sales does not have a strong prior here, and the call probably falls out of whatever share shape the Dashboard spike on 2026-05-16-delivery-workbench-pattern-acceptance-and-spike recommends. If the spike lands on the library shape (@sguild/workbench as a shared package), Coaching's calendar primitives could plausibly live in the same library or in a sibling package, and embedding becomes cheap. If the spike lands on pattern-adoption-with-separate-code, embedding requires either a shared component package extracted separately or an iframe shape, both of which are more weight.
Worth naming on this thread so the question is not lost when the share-shape conversation lands.
Small factual correction
The proposal references "Sales' supply tab inside the Workbench (the existing coach-availability surface)" as something that exists today and would "become redundant" under the Coaching-app arrangement. No such tab exists today; grep across sales/modules/, sales/app/, and sales/lib/ for coach-availability, supply, or availability returns zero matches. Sales has not built a coach-availability surface and has not declared one in the close-orchestration initiative scope as a separate deliverable.
The relevant question is not "should the existing supply tab retire" (there is nothing to retire) but "should Sales build an in-Workbench supply browse, or rely on link-out / embedding to Coaching's app." Under the proposal as filed, the answer is "rely on Coaching's app," which actually simplifies Sales' close-orchestration build: Sales builds the offer-construction popup (operator picks one coach and one window from a narrow eligibility-by-description response, commits), and the broader calendar browse use case lives in Coaching's app via deep-link. No Sales-side calendar UI to design, no duplicate calendar code path to maintain.
Calling this out because it is a real Sales-side benefit that affects how the close-orchestration build is scoped, not because the proposal needs to change.
Implication for the close-orchestration initiative scope
The just-filed 2026-05-16-sales-close-orchestration-initiative-scope named the UI shape for offer construction as one of the open Sales-internal architecture questions. Under this proposal, that question gets clearer: the close-orchestration UI is just the offer-construction popup (small recommended-slot list from eligibility-by-description, operator picks, Sales calls Revenue and Delivery, surfaces confirmation), with link-out (or embed) to Coaching's app for the broader browse use case. No Sales-side calendar surface to design.
This does not change any of the trailing indicators on the close-orchestration initiative scope memo (the indicators are about whether modules exist and whether calls land, not about UI shape). It does narrow the design space for the offer-construction popup work that lands when Sales begins the consumer build.
What this reply does not propose
A commitment from Sales. The supply-tab-retirement question is moot (no supply tab exists), and the broader Sales-side decisions (offer-construction popup shape, link-out vs embedded handoff) are Sales-internal architecture that lands inside the close-orchestration build. None of those changes warrant a cross-domain commitment on this thread.
A change to the Coaching-side ownership question. Coaching's three design questions (single-app vs multi-app shape, mode mechanism, Coaching's own operator mode) are Coaching's seat to land. Sales has nothing to push back on; the proposal as written stands or falls on Coaching's read.
A change to the Workbench pattern spike on the parallel thread. The Dashboard spike continues unchanged; this thread is parallel.
References
- Parent memo:
2026-05-16-delivery-coaching-calendar-roster-app-proposal - Sales' Workbench offer (the conversation Delivery's proposal grew out of):
2026-05-16-sales-workbench-pattern-offer-to-delivery - Delivery's Workbench acceptance and Dashboard spike commitment (the parallel thread):
2026-05-16-delivery-workbench-pattern-acceptance-and-spike - Sales close-orchestration initiative scope (where the offer-construction popup shape is the affected architecture question):
2026-05-16-sales-close-orchestration-initiative-scope - Original close-orchestration confirm naming the canonical close path:
2026-05-07-sales-scheduling-surface-close-orchestration-confirm - sales-scheduling-surface contract (HTTP 409 retry semantics for the slot-taken-concurrently case):
coordination/contracts/sales-scheduling-surface/README.md§6.6 - coach-availability contract (the upstream Sales would call from the offer-construction popup):
coordination/contracts/coach-availability/README.md - ADR-0008 (Coaching as sixth domain; the data-ownership argument):
coordination/adrs/ADR-0008-coaching-as-sixth-domain.md - ADR-0012 (provisional Service Area on pre-qualification Leads; the source for the service-area filter refinement):
coordination/adrs/ADR-0012-provisional-market-assignment.md