Salon & spa

The shape

This is two coupled Seldon Offers per service — one with kind=appointment + durationShape={mode: range, minSec: 1800, maxSec: 7200, stepSec: 900} backed by a grid Availability per stylist, and one with kind=queue + a queue Availability projection for walk-ins. Stylists are Trantor Resources whose identity lives in Terminus. Retail and tip handling come through Hardin / Hober / Payments. The tip-on-card flow uses Payments captureMethod=manual.

• Seldon models both the appointment grid and the walk-in queue as Availability projections of the same Offer.
• Trantor has a ResourceType for "Stylist" and Resources per stylist. Each Resource carries terminusPersonId for identity and a per-stylist calendar.
• Terminus owns the stylist's name, role, employment status, and consents; Trantor only holds what's physical (current chair, current status).
• Hardin models the take-home shampoo as a Product with retail metadata; its RecipeIngredient links to Trantor inventory.
• Hober opens an Order on the client's arrival; the service line gets added at check-in, retail at checkout, tip on the OrderPayment.
• Payments runs auth-on-swipe + capture-after-tip so the card is only hit once at the right amount.
• Mallow generates the Invoice and tracks the stylist's worked hours against the Trantor Resource.

Walk-through

Online booking

A regular books a 90-minute color with her preferred stylist for next Thursday at 1pm. Seldon resolves the appointment grid for that stylist's Resource, finds the slot open, atomically holds it in Trantor, and confirms the Booking. The Booking's durationShape resolves to 5400 seconds for this instance — within the Offer's range bounds. Speaker sends the confirmation after Terminus reports consent.

Walk-in

That same morning, a walk-in asks for a blowout. The front desk creates a Booking against the queue Availability projection of the Blowout Offer. The Booking enters queued with a queue position. When a chair opens, Seldon's Promotion service moves the highest-priority queued Booking to confirmed and notifies the client through Speaker.

The service

The client arrives. The stylist taps "start" on the Booking, which auto-advances to checked_in and then live. A Hober Order opens against the Booking. The stylist swipes the client's card to authorize a $135 hold (Payments PaymentIntent with captureMethod=manual, creating an Authorization).

Retail add-on

Mid-service the stylist recommends a take-home shampoo. She adds the Hardin product variant to the Order. The OrderLine snapshots the price at $32. The Booking lifecycle is unaffected; the Order just grows.

Close out with tip

Service complete. Total is $135 service + $32 retail = $167. Client signs for a $25 tip. The desk captures the Payments Authorization for $192 in one call: the original $135 hold is consumed, and the additional $57 ($25 tip + $32 retail) is captured against the same auth (within the network limit). Hober's close generates the Mallow Invoice, posts the ledger entries (DR Cash / CR Service Revenue / CR Retail Revenue / CR Sales Tax Payable), decrements one shampoo from Trantor inventory, and triggers the receipt through Speaker.

Why this is hard without LatticeKit

Most salon software does either appointments or POS well, never both, and the integrations between booking, retail, and tip handling are notoriously fragile. The tip-on-card flow alone usually means a separate "post-service adjustment" record that drifts from the underlying payment processor's model. LatticeKit's split — the Authorization that holds funds, the Capture that consumes them, the Mallow ledger that posts the sale, the Trantor consume that drops the shampoo — mirrors how the underlying systems actually work, so the integration boundaries stay clean. And because stylist identity lives in Terminus once, marketing emails, payroll, and consent preferences all stay consistent without duplicate identity tables.