The challenge
Physical venues hold a lot of guest data, but it sits inside POS and reservation systems where it is hard to act on. Spotting that a regular has stopped coming, reaching that guest with the right message and proving the message brought them back are usually three separate jobs, if they happen at all. Without that last step, operators cannot tell which outreach is worth the effort.
Venues also differ in how much they want to do themselves. Some have staff who want hands-on control of campaigns. Others want the result, more returning guests, without learning another tool. And guest data needs careful handling: the product had to work from the venue’s own first-party data, with privacy treated as part of the design rather than added later.
- Guest data locked inside POS and reservation systems
- No easy way to run recovery and retention outreach from that data
- Little visibility into which guests returned, and why
- Two kinds of customer: hands-off operators and in-house teams
What I built
I designed and built CityOS around each venue’s existing systems rather than asking operators to replace them. The platform connects to POS or reservation systems through API integrations, brings in first-party guest data and enriches it, so each guest record carries more of the context needed to decide who to contact and when. Integrating rather than replacing matters in hospitality: the POS and reservation systems are already part of daily service, and a product that asks staff to change them is a much harder sell.
On top of that data sit the engagement workflows: guest recovery for lapsed guests, retention triggers, handling of FAQs and inquiries, and distribution of event or menu updates. These run from one platform rather than from separate tools for messaging, lists and reporting.
The product supports two delivery models on the same platform. With the Managed Service, the venue stays hands-off and pays on an outcome basis. With Tools access, an in-house team gets the full toolset directly: inbox, campaign builder, segmentation and analytics. Building both on one platform means the same data, workflows and measurement serve both models, rather than maintaining two products that drift apart.
Measurement is built in, not bolted on. A real-time dashboard shows operators which guests returned, what drove them back and the revenue impact. The front end is React, and the whole platform works from first-party data in line with its privacy-by-design positioning.
- POS and reservation system integrations
- First-party guest data enrichment
- Guest recovery, retention triggers, FAQs and inquiries, event and menu distribution
- Managed Service and Tools access on one platform
- Inbox, campaign builder, segmentation and analytics for in-house teams
- Real-time dashboard for returning guests, what drove them and revenue impact
Architecture and stack
- Front end
- React
- Integrations
- POS system APIs · Reservation system APIs
- Data
- First-party guest data · Guest data enrichment
- Product modules
- Inbox · Campaign builder · Segmentation · Analytics · Real-time performance dashboard
Outcome
CityOS turns guest data that venues already hold into recovery and retention they can act on and measure. Operators can see which guests came back, what brought them back and what it was worth, in a real-time dashboard rather than as a guess. Recovery and retention stop being occasional one-off pushes and become a routine the venue can track.
Venues choose how involved they want to be: a hands-off Managed Service with outcome-based pricing, or full Tools access for an in-house team. Because both run on the same platform and the same first-party data, both are measured the same way.
Outcome-based pricing only works if the outcome can be measured reliably, so showing what drove each return is part of the business model, not just a reporting feature. That link between the data model and the commercial model is the kind of decision I look for early in any SaaS build or review.
Last updated 2026-10-03