Crqlar

The challenge

Hotels sit on more guest data than almost any other consumer business and can use almost none of it. Our research put the average property on thirteen separate software systems: a property management system, restaurant reservations, spa booking, guest messaging, marketing tools, revenue management, and a long tail of spreadsheets.

None of them talk to each other. The result is a hotel that technically knows a guest's room preference, dietary restrictions and booking history, but cannot assemble that picture while the guest is standing at the desk. Staff retype the same data into three systems. Marketing goes out generic. Upsell opportunities expire unnoticed.

A hotel manager framed it exactly right: they knew everything about their guests, and it was scattered across a dozen systems, so by the time anyone found the information the moment had passed.

What I built

As co-founder and technical architect I led the platform through integration, unification and the guest-facing layer.

A universal connector framework. The hard problem in hospitality is not features, it is that every PMS models a guest differently. I analysed the data structures of 20+ major systems, mapped their integration points and API limits, and built a universal data model that normalises them into one shape. Connectors are standardised, version-agnostic and bidirectional, with automatic error handling and retry. Adding a new PMS became a configuration exercise rather than a project.

One guest profile, assembled automatically. On top of the connector layer sits deduplication and merge logic that resolves the same human across a PMS record, a restaurant booking and a spa appointment. AI enrichment infers interests and preferences from behaviour, which then drives dynamic segmentation and campaigns pushed straight into Meta and Google. Revenue attribution tracks what each campaign actually returned.

Operational modules that feed the profile. Restaurant handles à la carte and half-board guests with automatic PMS recognition and billing, plus multi-day reservation logic for packages. Services runs one availability calendar across spa, sports, kids club and activities, with staff and resource scheduling. Both are real operational tools, and both capture preference data back into the guest profile as a side effect of daily use, which is the only data collection strategy that survives contact with a busy front desk.

A white-label guest app. Fully branded per property, with one-click booking for every hotel service, targeted push offers, booking widgets for the hotel's own website, and live room and billing information from the PMS.

Underneath: multi-tenant architecture with isolated data environments per hotel on shared infrastructure, automatic scaling, zero-downtime deploys, and GDPR compliance designed in from the first sprint rather than retrofitted. That last one is non-negotiable when you are handling guest health and dietary data across the EU.

Results

Operational efficiency

• 260 hours per year saved in spa management through automation
• 139 hours per year saved in restaurant operations
• 80% reduction in manual booking administration
• Paper-based processes eliminated across connected outlets

Revenue

• 30%+ increase in marketing campaign effectiveness
• Higher upsell rates from personalised recommendations
• Fewer no-shows through automated confirmation
• New direct booking channels through app and web widgets

Guest experience

• A complete view of each guest instead of a dozen partial ones
• Faster check-in from pre-populated information
• Service that anticipates preferences rather than asking again

What I took from it

Integration platforms live or die on the connector abstraction. Getting the universal data model right early meant every subsequent PMS was cheap; getting it wrong would have meant thirteen bespoke integrations and a maintenance burden that grew with every customer.

The architecture also generalises further than hotels. Multi-property resort chains, cruise lines, restaurant groups and wellness retreats all have the same shape of problem: fragmented guest data, and no single place where it becomes useful.