Sales offers the Workbench and Workbench Admin pattern as a candidate Delivery operator surface
Why
Sales' Q2 operating-surface build settled around two surfaces: /workbench (the operator's primary work queue plus Lead-detail drawer and search) and /admin/workbench (versioned config editor for stages, action definitions, surfaces, scripts, prompts, attention policies, menus, and form-fact options). The first is the operator's day-to-day; the second is how the operating shape is changed without a code deploy.
The Workbench has been in production use by a live Sales operator and has held up. Dense card-based queue with one primary queue-reason cue per card, scan-only cards with mutations happening in task popups, pictograms as the task queue, guided-interaction service as the primary write path composing call attempts, callbacks, pipeline state, geography, timeline, and event emission inside one Prisma transaction. The operator's read is that this shape works for them over the alternatives (Airtable and the legacy admin UI); the surface has been steady-state for several weeks and the operator preference is firm rather than provisional.
The point of this memo is that the Workbench's surface architecture is largely domain-agnostic. The card layout, popup pattern, queue grouping, surface policy, attention policy, and config-driven action and prompt rendering are all generic over a Lead-shaped DTO. Substituting Delivery's domain entity (Lesson, Coach Day Plan, whatever the Delivery operator works against) for Lead is the obvious experiment. If the experiment lands, Delivery's operators inherit a Workbench-shape surface without re-inventing the operator-queue UX, and the Sales-and-Delivery operator experience converges on a shared mental model that benefits cross-domain operators and shared training.
Filing this now because it falls out of yesterday's cross-domain conversation about the unbuilt sales-scheduling-surface and the operator surfaces around it; the substantive answer to "how should Delivery's operator interact with hold-create and cancel" might be "through a Workbench-pattern surface owned by Delivery, configured for Delivery's domain entities." Surfacing the offer before either side ships a parallel implementation.
What the surface is, concretely
Two top-level pages in the Sales repo.
/workbench is a dense, card-based operator queue. Rows are grouped by primary queue reason in a fixed priority order (customer-replied, callback-due, onboarding-issue, awaiting-confirmation, text-follow-up, due-cadence, fresh-leads, terminal). Cards scan as queue-reason, contact name, communication state, milestone and substage, market and service-area review state, attempt count, next action, source and intake date. Cards are scan surfaces, not broad click targets. Pictograms open the next task popup; the profile icon opens a fallback profile drawer. Cards do not mutate state inline.
/workbench/[lead_id] is the fallback profile drawer for inspection, audit, and unusual-case repair. Deliberately not the primary action surface; that stays in the popups.
/workbench/search is a search surface across the Lead set.
/admin/workbench is the versioned config editor. Admins edit a tenant draft, preview the resulting runtime config, publish one active version, and roll back to a historical published version. Operator UI reads only the active published version; drafts do not affect live behavior. The config set covers stages and substages, attention policies that drive queue grouping, outcome reasons, surfaces, action definitions, surface policy, cadence schedules, prompt templates, scripts, menus, and form-fact option lists.
The Workbench DTO contract pins the UI to stable shapes backed by source tables: Lead (current operating state), LeadIntake (original intake context), Touch (inbound or outbound communication), Task (callback, follow-up, manual work), Note (persistent context), CadenceAction (queued cue), LeadStageHistory (transitions), AuditEvent (business mutations), LeadHandoff (observed handoff from Revenue or Delivery). Operator UI reads through /api/workbenches/* rather than importing module services directly; the read model is stable across module-internal changes.
Code lives at sales/app/workbench/, sales/app/admin/workbench/, sales/modules/workbenches/, sales/modules/workbench-configs/, and sales/modules/lead-interactions/ (the guided-interaction service that fronts the write path). sales/OPERATING_SURFACE.md is the per-surface walkthrough; that file is the right place to start a read.
What is transferable, what is Sales-specific
Generic across domains: card layout primitives, popup pattern, queue-reason grouping, attention policy, surface policy, action-definition shape, versioned-config editor with draft and preview and publish and rollback, and the read-through-DTO-API discipline.
Per-domain: the DTO set itself (Lead in Sales, presumably Lesson and Coach Day Plan and similar in Delivery), the action vocabulary (Sales' guided-interaction kinds vs. Delivery's outcome and dispatcher actions), the surface policy gates (the existing sales-ops-admin gate vs. whatever Delivery's role vocabulary requires), and the integration shape with cross-domain consumers (Sales' Identity v1.1 reads, dispatcher subscribers, handoff consumer paths).
The configurability is the load-bearing thing. Today's Sales Workbench Admin can change stages, add new action kinds, edit scripts and prompts, adjust attention policies, and roll back, all without a deploy. The same configurability would let Delivery operate the Workbench surface against Delivery's domain shape without Sales blocking Delivery's UX iteration.
The open engineering question (how to share)
Three plausible share shapes, ordered from heaviest coupling to lightest.
The first is shared library. Extract the Workbench UI primitives, the config-driven rendering layer, and the DTO-contract scaffolding into an @sguild/workbench (or similarly named) package. Delivery installs the package, authors its own DTOs (Lesson, Coach Day Plan, the entities Delivery operators work), defines the action set, and configures the surface via its own /admin/workbench. Maximum code sharing, real cross-domain dependency, real maintenance discipline (versioning, deprecation window per the org standard, joint test surface for the package boundary).
The second is pattern adoption with separate code. Sales documents the Workbench pattern in coordination/standards/engineering/ (or as an ADR) at a level of detail that Delivery can rebuild against. Delivery owns its own implementation; the patterns converge by reference rather than by shared bytes. Lighter coupling, no maintenance entanglement, but operator UX consistency relies on Delivery following the standard rather than on a shared codebase enforcing it.
The third is code-as-reference handoff. Sales walks Delivery through the existing code, Delivery copies what is useful and adapts. No standard, no package, no convergence guarantee beyond what Delivery's read pulls forward. Cheapest to start, but tends to fork over time as each side evolves independently.
Sales has no strong prior on which shape fits. The first is right if Delivery thinks the pattern lands and we want cross-domain UX consistency to harden into an architectural guarantee. The second is right if Delivery wants the pattern but per-domain divergence is meaningful enough that shared code would be more friction than help. The third is right if Delivery's existing operator surfaces are far enough along that a full pattern import is not worth the rework.
Asks
What does Delivery's current operator surface look like, in concrete terms (what pages, what is the queue or work-list shape, how does the operator transition state today)? Sales does not have visibility into Delivery's UI side and the right shape for this offer depends on what is already in place.
Does the Workbench pattern, as described, fit the shape of work a Delivery operator does? The Sales operator works a pipeline of Leads with a primary queue reason per card; Delivery operators work lessons, coach day plans, and outcomes, which may or may not share that grain. If the grain is similar, the pattern transfers; if Delivery's work is more dispatcher-shaped or calendar-shaped, the Workbench's card-and-popup primitives may need rework before they fit.
If the pattern does look like a fit, which share shape (library, pattern adoption, code-as-reference) does Delivery prefer? Sales is open to all three and the decision is largely about Delivery's read on coupling and rework cost.
A spike would be the obvious experiment to validate the offer concretely: Delivery picks one operator surface (the Coach Day Planner, the dispatcher inbox, lesson outcomes, whatever is the most Workbench-shaped on Delivery's side), implements it against the Workbench primitives, and reports back on whether the pattern held. Sales would pair on the spike if useful; the offer is open whether Delivery wants pairing or not.
What this memo does not propose
A commitment from either side. The offer is open and the share-shape question is real; substantive commitments fall out of Delivery's response and any spike Delivery chooses to run.
A change to the sales-scheduling-surface contract or any other Delivery-owned surface. The Workbench pattern is a UI and configuration story; the contract surfaces are unchanged.
That Sales' Workbench is the only valid operator-surface pattern. The offer is "this is what worked for our operator, here is the shape, see if it fits." Delivery's read may legitimately be "the pattern does not fit our work" and that is an acceptable outcome.
References
- Sales operating-surface walkthrough (the right place to start a read):
sales/OPERATING_SURFACE.md - Workbench code:
sales/app/workbench/,sales/app/admin/workbench/ - Workbench config and DTO modules:
sales/modules/workbenches/,sales/modules/workbench-configs/ - Guided interaction service (the primary write path):
sales/modules/lead-interactions/ - Sales postgres initiative scope (the directive frame under which the Workbench shipped):
2026-05-23-sales-postgres-initiative-scope - Engineering module layout standard (the shape any extracted library would follow):
coordination/standards/engineering/module-layout.md - Today's close-orchestration initiative scope memo (which names Sales' UI placement for hold-create / cancel as an open architecture question):
2026-05-16-sales-close-orchestration-initiative-scope