Development of an AI system for automating table and room bookings

AI booking of tables and rooms: where manual processing breaks

A request for a table or room almost never arrives through a single channel: the guest calls, writes in a messenger, fills out a form on the website, and some bookings are made right at the front desk.

Each channel lives separately — there is no single occupancy log, and the manager manually reconciles the picture from calls and messages, no longer seeing it as a whole.

In peak hours, this turns into a bottleneck. The administrator simultaneously holds a call, replies in a messenger, and checks in a guest at the desk — some inquiries remain unanswered, and verbal agreements never make it into the system.

This is how lost requests happen during peak hours: the guest did not wait for an answer and went to someone who responded faster.

The cost of such an error is higher than one unanswered call. Two requests for the same table or room, accepted by different people, produce a double booking: the guest has to be told there is no space, while the calendar and reputation diverge.

The load on the administrator grows with the flow, and during peak windows they physically cannot process bookings at the same speed — manual booking processing rests only on the memory and attention of the shift.

Automation of request intake removes exactly this layer: inquiries from all channels enter one stream, resource availability is checked at the moment of request, and standard confirmations and reminders go out without human involvement.

Below we break down how this is handled in AI booking — from the first request to confirmation for the guest.

What automation delivers: measurable effects of implementation

Booking automation is measured not by the number of scenarios in the system, but by four values: what share of requests is closed without a human, how long the guest waits for the first response, what happens during peak hours, and which class of failures disappears.

We take these metrics before implementation and compare them after a month of operation — on a live flow of requests from the web form, Telegram, and phone calls.

Share of automatic confirmations

The system checks the request against actual availability of tables and rooms, applies venue rules — minimum party size, free cancellation period, allocation by hall — and confirms the booking itself.

On an established flow, 70–85% of inquiries pass without shift involvement; the rest go to the manager with context: date, number of guests, visit history, and the reason the rule did not trigger.

First response time

The guest receives confirmation in seconds instead of 5–15 minutes on a busy shift, and requests that arrive at night do not wait for opening.

The share of cancellations from "changed their mind while waiting" drops: a booking confirmed immediately becomes an anchor for further arrangements.

Shift relief and peak hours

At peak times — Friday evening, holidays, season — the system takes over intake, confirmation, and reminders, including confirmation a day ahead and a cancellation survey.

The shift stops drowning in repetitive replies and focuses on guests in the venue; the request queue does not grow linearly with the flow because processing happens in parallel, not one call at a time.

Eliminated failures

Specific classes of failures are closed: double booking of the same table, a lost nighttime request, a forgotten cancellation that leaves a table idle.

Each booking is recorded in a single event log, so the discrepancy between what was promised to the guest and what is actually available is visible immediately, not at seating time.

AI booking formats: rules, model, or hybrid

The format is chosen based on how predictable the incoming flow is. If a booking follows one scenario — date, time, number of guests — a scenario-based booking bot closes it without human involvement and costs the least to support.

As soon as free-form requests appear ("we need a quiet room away from the elevator, we'll arrive after midnight"), the rules begin to stumble on every exception, and the queue goes to the administrator.

A language model for hotels parses free text and extracts booking parameters from it, but without strict guardrails it can confirm a date that is not available.

That is why real systems more often use a hybrid processing scheme: the model understands the meaning of the request, while rules check availability and record the booking in the accounting system.

Comparison of automation options

We choose the format not by preference, but by the share of inquiries the system closes itself and by the cost of an error: for a room, it is a double booking; for a table, it is turning a guest away. The layers are separated, so later the model can be strengthened without rewriting the rules.

How implementation proceeds: stages of engineering work

AI booking implementation is divided into stages with a verifiable result at each.

First we record where inquiries come from and what happens to them now, then we describe scenarios, and only after that we connect the system to the accounting platform — in this order, bottlenecks are visible before launch, not after.

1. Audit of inquiry channels. We calculate the share of phone, messengers, email, and website forms, and analyze cancellations and repeat inquiries. The output is a map: what goes into automation and what remains with people.
2. Scenario design. Dialogue branches: date, number of guests, room or table type, confirmation. We separately describe incomplete data and escalation rules to the administrator.
3. Integration with accounting systems. Two-way exchange with the occupancy calendar and booking system: free slots are visible immediately, double bookings are excluded.
4. Training on historical inquiries. An archive of messages and calls provides real wording, typos, and mixed languages — we use it to configure intent recognition.
5. Test dialogues. A run on a labeled set: payment failure, cancellation, group booking, simultaneous requests. We look at the share of correct responses and escalation points.
6. Pilot on one channel. Launch on a narrow area with operator supervision; we compare with standard processing by the share of dialogues closed without a human.
7. Handover to operation. Escalation regulations, integration scheme, access, team training, and support with review of disputed dialogues.

Each stage ends with an artifact: a channel map, scenario design, a set of test dialogues, a regulation. Therefore handover to operation does not turn into handing over a "black box."

Delivery package: configurations, integration schemes, regulations

The booking assistant does not work in a vacuum: it relies on the accounting system, occupancy calendar, payment flow, and notification channels.

So that the solution can be developed in-house or handed to another team, this entire loop is recorded in settings and documents, rather than remaining in the developers' heads. Below is what exactly remains with the client after delivery.

• Working assistant settings: dialogue scenarios, rules for processing dates, groups, and deposits, response texts for frequent questions, threshold for transferring a conversation to a human.
• Integration scheme with the accounting system, occupancy calendar, and notification channels — exchange points, request formats, and behavior when an adjacent system is unavailable.
• Access rules: roles for administrators, shift managers, and support, scope of rights to read and modify a booking, issuance and revocation procedure.
• Escalation regulation: which inquiries and under what conditions go to an employee, response time, responsible person at each step, method of recording the result.
• System documentation: scenario processing logic, assistant limitations, behavior during failures, and diagnostic procedure.
• Staff instructions: how to check a dialogue, correct a response, remove a booking, and what to do in case of a guest complaint.
• Change procedure: how scenario changes are approved, tested, and released so new rules do not break working ones.

We write documents for a specific role — administrator, support, on-duty engineer — and not as "one file for everyone." Describe the task, and we will come back with an estimate and plan, including the composition of the delivery package.

Case: share of automatic confirmations grew from 34% to 87%

An automation case at the hotel and restaurant complex "Lazurny": table and room bookings came from several channels and were handled manually.

The share of automatic confirmations stayed at 34% — the rest was processed by the shift administrator: checking occupancy, clarifying time and party composition with the guest.

In high season, the queue of requests overwhelmed the shift, and some guests were refused even when inventory was actually available.

What was changed in the scenarios

Allocation rules were moved from the administrator's head into explicit conditions: table type, seating duration, cleaning pause, combining a room and table in one order.

Confirmation and clarification were separated — standard requests closed immediately, non-standard ones went to a human along with a summary: what was checked, what is missing, what response is proposed.

Each step got a rollback: if an external channel did not respond within the allotted window, the request returned to the queue with its priority preserved, rather than "hanging."

Metrics before and after

The share of automatic confirmations grew from 34% to 87%, guest response time dropped from hours to minutes, and the load on the shift during peak windows fell by roughly half — the administrator returned to the floor instead of sorting through requests.

The "busy" failure class caused by error disappeared: the decision is made based on a single inventory state, not two separate lists, so double confirmations no longer occur.

Resilience in high season is ensured by the fact that during overload, requests queue with a clear waiting time instead of being lost.

If an external channel is unavailable, confirmations continue based on local data, and discrepancies go into a separate list for review — system behavior during a failure is predictable, without manual "rescue" by the shift.

How does a scenario bot differ from a language model assistant?

A scenario bot is a finite state machine: a set of states, transitions, and checks at each step. It is predictable, the same request always follows the same path, and automated tests cover every branch.

The downside is that any phrase outside the specified wording requires a new branch, and after a dozen edits the scheme grows so much that checking it as a whole becomes difficult.

A language model assistant is structured differently: it parses free speech and extracts booking parameters from the phrase "for the weekend, two of us, with a dog and late check-in" — dates, number of guests, room type, restrictions.

The flexibility of speech understanding comes at the cost of non-determinism: responses vary from run to run, and the model cannot be allowed to write directly. It needs value validation against reference data and explicit guest confirmation before recording a booking.

The choice of option for the task is determined by where the error boundary lies.

If the booking state changes after the bot's response, a deterministic executor is needed — the model forms intent and parameters, while recording, cancellation, and confirmation follow fixed rules with an operations log.

That is precisely why the hybrid scheme covers the tasks of both approaches: free speech remains at the input, predictability at the output.

Such a dialogue passes acceptance scenarios in full, including failures and retries, while edits affect either the parsing rules or the recording scenario, but do not break both parts at once.

Technical concerns: integrations, data, and fault tolerance

Technical concerns about AI booking are usually the same: what happens if the model is unavailable, where guest data goes, how several inquiry channels are reconciled, and how to make sure the assistant has not degraded after another update. Below are substantive answers, without phrases like "everything will work."

How is guest data protected?

Personal data is placed in a separate environment: only what is needed for the booking goes into the dialogue, and numbers and addresses are masked in logs. Message materials do not enter training datasets, access is role-based with action logging. The retention period is set by a rule and cleaned automatically.

Will several inquiry channels create conflicts?

All channels converge into a single dialogue layer with a shared guest history and a single booking state, so confirmation in one channel is immediately visible in another.

When there is a simultaneous request for the same room or table, locking triggers, and the second guest receives a clear alternative rather than a double booking.

How do you check response quality?

Before each release, we run a set of reference dialogues — from standard to disputed: rescheduling, late cancellation, non-standard dates. We calculate the share of correct responses and analyze discrepancies.

After launch, disputed dialogues regularly go into review, and the rules are retrained in a targeted way.

What about response delays?

The time budget for a response is fixed before development: some operations — availability checks, booking recording — are performed outside the model and do not add waiting. The response is issued as it becomes ready, and long clarifications are split into steps. If the response exceeds the budget, the scenario is simplified.

Let's discuss the task: what to prepare for review

A review of an AI booking task is substantive when the real picture is visible: how requests are accepted, where they are lost, and what has already been attempted with automation. Below are the inputs that shorten the path from review to estimate.

• Guest journey map: booking channels (website, phone, messengers, aggregators) and points where a request waits for a response.
• Export of inquiries for 2–3 months: share of standard requests, first response time, cancellation reasons.
• Availability rules: how a free table or room is calculated, what happens when bookings overlap and in case of late cancellation.
• List of systems for integration: booking accounting system, channel manager, inquiry management system, telephony, and access to them.
• Regulations: what cannot be confirmed automatically and in which cases a human is mandatory.
• Examples of 10–15 dialogues with guests — we use them to check intent recognition and response tone.
• Responsible people on both sides and the window in which you accept the result.

After the review, we come back with a work plan: stages, the result of each, and points for agreeing the scope. The next step is a short call with your team, then an estimate based on the received data and scope fixation before the start.

"The review was based on our data, not general considerations, so the plan matched what actually needed to be changed," — head of accommodation division.