The operator’s day used to be three or four different consoles. The booking diary in one tab, the marketing CRM in another, the EPOS in a third, the reviews dashboard in a fourth. Each was keyed off a different fragment of the guest. The first thing Stampede changes is that fragment problem.
Every interaction — a Wi-Fi sign-in, a booking taken, an order rung up, a review left — writes to the same Guest Profile. The diary tab and the CRM tab and the EPOS tab read from the same record. The operator sees one Sarah M, not five.
What that changes on the floor
When the host opens a booking, the guest history is already there — every previous visit, the usual table, the allergens flagged from the booking page, the last review they left. No cross-referencing. No CRM hunt. The information that should be obvious is obvious.
When the marketing manager runs a win-back to lapsed VIPs, the segment is built over the same graph that the front-of-house team is reading from. The win-back lands; the open and click are edges back to the same profile; the next visit attributes to the campaign by walking the same graph.
Where to look next
/docs/operations documents the team-facing surfaces. Bookings, reviews, marketing, Wi-Fi, hardware, orders, loyalty admin — one page per surface, each describing what the surface does and how it writes to the profile.
/docs/guest-profile explains the spine. Worth reading once even if you never touch a schema explorer — it’s the thing that makes the day above possible.