Demonstration build
Mane & Honey
Mane & Honey is a made-up business we built to demonstrate the work. The site is live and you can try it. The numbers shown on it are illustrative sample data.
The problem
Mane & Honey runs four stylists with different specialties, color and balayage, cuts, facials and massage, bridal, but the old booking process was a phone call where the front desk had to remember who could do what. A guest who called after close with a pricing question just didn't get an answer until morning.
What we built
A service-then-stylist-then-slot booking flow (pick the service, pick a specific stylist or 'any available', pick an hourly slot Tuesday to Saturday, 9am to 7pm) plus an embedded concierge chat scoped to the salon's own price book. The concierge runs the same zero-error stack that answers on angrynirds.com, scoped to this salon's own price book, and it activates with the ship-gate, today that flag is unset, so the demo shows the offline panel with a link straight to booking.
Decisions & why
Specialty enforcement lives in the booking reducer, not only in the UI's filtered stylist list.
A filtered dropdown is a suggestion; a client could still fire a request for a stylist outside their lane. The reducer checks the same specialty roster and ignores a mismatched pick outright, so the guarantee holds even if the UI check is ever bypassed.
'Any available stylist' resolves to the first eligible stylist with an open slot that day, falling back to the first eligible stylist only if none do.
Picking 'any' should mean the guest gets booked with someone who can see them, not just the first name on the roster who happens to be busy that afternoon.
The salon's displayed price book is vendored from the same source that feeds the live concierge, with a dedicated drift test guarding the two never disagree.
A salon site quoting one price while its own front-desk assistant quotes another is exactly the kind of small inconsistency that breaks trust. One source of truth, checked by a test, keeps that impossible.
The concierge is narrated to the guest as the same stack, not a lookalike, and shown honestly in its current gated-dark state.
Overselling a demo assistant as something it isn't erodes the exact trust the concierge is supposed to build. Showing the real offline state, with a working path to book anyway, is more convincing than faking an online chat.
The result it aims for
The build aims to route every guest to a stylist who can do the work booked, and, once the concierge ships live, to answer after-hours pricing questions instead of leaving them for the next morning's callback.
This is the goal the build is designed to hit, not a measured client outcome.