An AI booking assistant guests actually use

A mid-sized hotel ran its own custom activity booking system — spa, kayaks, dinners, tennis, fishing trips, a vintage movie theatre — with a staff tool and a guest PWA. It worked, but it had been built fast: performance suffered at peak times and every new feature was harder than it should have been.

I was brought in to stabilize the backend first, then build an AI booking assistant on top of it. The assistant shipped in about two months. The engagement never ended — I still work with this client, and what started as one hotel's chat widget is now a multi-tenant platform being sold to other hotels.

The decisions that mattered

Foundation before intelligence

The assistant was the exciting part; the refactoring was the valuable part. Availability logic for activities with genuinely complex rules — restaurant table joining, group sizes, holidays, slot durations — was cleaned up and made fast, and the APIs used by the staff tool and guest PWA were stabilized. That ordering was deliberate: an AI assistant bolted onto a shaky backend just automates the production of wrong answers.

The assistant lied, and the fix defined the architecture

Early versions hallucinated success: the assistant would tell a guest their booking was confirmed or updated while having done nothing at all. This is the failure mode almost every "we added a chatbot" project ships to production without noticing.

The fix was architectural, not prompt-tweaking: the assistant can only act through the same validated APIs as the regular app. Every booking, change, or cancellation passes the same rules and capacity checks, and the assistant is never allowed to claim an outcome the system didn't confirm.

Knowing when the AI should hand over

Rather than pretending the assistant could handle everything, we built an explicit escape hatch: staff can take over any conversation through a realtime chat (Pusher-based, Intercom-style) embedded in their tool. The assistant handles the routine volume; humans handle the moments that need judgment. Guests get one continuous conversation either way.

One brain, many doors

The same assistant now answers in the guest PWA, on the hotel's website for pre-arrival guests, and over WhatsApp. One backend, one set of rules, multiple surfaces — which is also what made the next step possible: rearchitecting the platform as a multi-tenant product that other hotels can sign onto.

What changed

The assistant is in production and guests use it end-to-end: discovering activities, booking, paying, rescheduling, cancelling — through chat.
Staff field fewer routine "can you book this for me" requests, and take over conversations when it matters.
The clearest outcome is commercial and verifiable: the platform became a multi-tenant product and new hotels are signing up.
The client relationship itself: this began as a stabilization contract and became an ongoing engagement measured in years.

Technical notes

Existing platform: custom booking backend + guest PWA; integrations with Mews and payment processing were cleaned up as part of the stabilization phase.
Assistant built on Claude; shipped in ~2 months, AI-assisted development throughout.
Realtime staff handoff via Pusher; WhatsApp as an additional assistant channel.
Assistant permissions are a strict subset of the public API surface — it cannot do anything the app couldn't.
Now multi-tenant: single codebase serving multiple hotel properties.