AI systems for hotels and restaurants.

Where the reservation actually lives

In a hotel the reservation lives in the property management system, or, for a group, in the central reservation system that holds inventory across properties, with each property management system holding the in-house stay. In a restaurant it lives in a table-management or reservation system, or a paper book; the point of sale holds table state during service, not future bookings.

A channel manager distributes availability and restrictions to the OTAs and the GDS and pulls their reservations back; a booking engine serves the brand site. An AI system holds no availability of its own: the front desk, the booking engine and every channel write reservations against the same inventory in the same minute.

Availability is contended inventory

Other channels claim the same rooms and tables in the same minute, so a booking is a quote and then a commit that re-reads price and inventory as it writes. Restaurant platforms commonly expose a slot lock; many hotel interfaces have no soft hold, so nothing is promised until the write returns, and a wrong write is reversed.

Where the reservation API accepts an idempotency key, every write carries one; where it does not, the retry path searches for an existing reservation by external reference before writing again, and an unknown outcome is reconciled rather than repeated. Overselling the last room means walking a guest and double-seating means two parties arriving for one slot, so the commit path fails closed. A deliberate oversell limit stays where it already lives: the channel manager, central reservation system or revenue management system.

Rate rules govern the quote and the change

A room rate is produced by a rate plan rather than stored as a single price: occupancy, length of stay, minimum-stay and closed-to-arrival restrictions, taxes and fees all change what the guest pays. The agent queries the reservation system for a rate code, dates and occupancy and repeats the total returned.

The same rules decide what a change costs: shortening a stay can break a minimum stay, and a cancellation can fall either side of a cutoff set relative to arrival in the property's local time rather than the caller's.

Card details are out of scope: the agent does not take a card number by voice or store one. A guarantee or deposit goes through a payment link or secure capture page and the reservation is written against the resulting token, or the booking goes to the front desk.

One number, many properties and outlets

A group answering on one number resolves which property the caller means before looking anything up, and the integration target is normally the central reservation system rather than each property's management system. Front desk, restaurant, spa, banquets and room service may also run on different systems, so a request for a table at eight means nothing until the outlet is known.

Configuration is data rather than prompt text because it churns: rate plans and restrictions change weekly, outlets change service hours seasonally, and groups open properties. Room types, outlets, service hours, policies and escalation numbers sit in a store the property team can review, while rate and availability rules are read from the reservation system at the point of use, because a copy goes stale the moment a restriction changes.

Peak hours, seasons and concurrency

Volume is concentrated rather than steady, and its shape is specific to the property: a restaurant's phone can peak before service and again during it, a hotel's around check-in, check-out and whatever fills its calendar. Sizing comes from your own call records for the busiest week of the year, because calls above the concurrency ceiling are dropped rather than queued.

Enquiries that have to reach a person

Group and event enquiries are qualified and handed over, not quoted: room blocks, banquet space, food and beverage minimums and contracted rates are negotiated, so the agent collects dates, room nights or covers, budget and decision date for sales. Allergies and dietary restrictions, accessibility and medical needs, service animals and complaints that imply compensation are recorded verbatim for a person. The agent confirms the request has been noted, not that it can be met.

Guest data, recordings and jurisdictions

The guest profile is a long-lived marketing record, not a file closed at checkout, so what the agent writes back is scoped separately from the reservation write: stay preferences, dietary flags and complaint notes outlive the stay, a loyalty or CRM system copies the profile elsewhere, and group and OTA bookings arrive with data the property never collected.

A property also holds data about guests resident in several jurisdictions, so a recording's obligations are not settled by where the property is. Indian deployments handle personal data under the DPDP Act, which does not grade personal data into tiers, so passport and visa copies collected for foreign-national reporting carry the same obligations as everything else. Consent rules for recording differ between the caller's location and the property's.

Whether calls are recorded, what callers are told and how long audio and transcripts are kept are explicit decisions rather than provider defaults, scoped as engineering requirements rather than legal advice.

Evaluate the reservation the system created

The release gate scores the reservation the system created, not the conversation that created it: a fixed set of enquiries is replayed against a test property and the reservation produced is compared field by field, covering dates, room type or table and covers, occupancy, rate code, total, policy text and special requests.

The set has to include the cases that cost money: two concurrent requests for the last available unit, where exactly one must succeed and the other must be told so; a cancellation at the boundary hour in the property's local time, where the fee either applies or does not; a shift at its pacing limit, where no time may be offered; and the reservation system failing mid-booking, where the guest must not be told a reservation exists.

What a hospitality project costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, acceptance criteria, a running-cost model and a fixed price for the build; the fee is deducted from the build. It settles the integration question first, because what your reservation system or reservation book permits determines what can be built.

Running cost follows conversation volume rather than room count, and where volume is seasonal the sprint models a shoulder month and a peak month separately.

Part of the AI Feature Implementation Sprint → · Explore our work → · Discuss an AI project →