The problem: guests write wherever it is convenient

The small Romanian hotel Majestic Jupiter received questions and booking requests by phone, email, WhatsApp, and Facebook Messenger. According to the European innovation hub CiTyInnoHub, messages were handled mostly by hand. Dates, party size, and special requirements arrived in different formats; staff had to clarify details, switch channels, and reconstruct each enquiry's history. During peak demand, this can slow the first response and put prospective bookings at risk.

It is important not to attribute results that the case does not report. The hub describes an implemented proof of concept and qualitative process improvements, but explicitly says measurable outcome data are not available yet. Claims such as a 30% increase in conversion or a one-month payback would therefore be invented. The practical value is in how a small service business bounded the role of AI while retaining control of reservations.

What the pilot did

The team first mapped the enquiry journey from first message to booking confirmation. A conversational bot across WhatsApp, Facebook Messenger, and email collects stay dates, guest numbers, contact details, and special requests. Required fields and simple checks reduce incomplete enquiries. A shared workflow layer then tracks the status of each request, retries, and hand-offs. Robotic process automation checks availability, calculates prices, and creates records in the hotel's existing systems. AI-enabled logic helps validate and route data. Complex requests, billing questions, and exceptions go to a staff member together with the conversation context.

This is not an account of an autonomous agent allowed to promise any price to a guest. The documented architecture is closer to dialogue plus verifiable rules, integrations, and an exception queue. The source names the cloud communications service Twilio, but does not disclose the AI model, exact RPA stack, or project cost. A Russian hotel or other service business would need to select those components afresh, taking into account available channels, data requirements, and its own systems.

Where AI is actually useful

Much of the reliability comes from tools simpler than a language model. If a guest supplies dates in a standard format, a form, validation, and ordinary rules suffice. If the request is free-form — “two nights after the conference, with a child, ideally a quiet room” — a model may suggest extracted fields and the next clarifying question. But final availability and price must come from the booking system, not generated text. Dates, time zones, numbers of adults and children, rate restrictions, and existing reservations should be checked separately.

A local model makes sense when the company does not want to send conversation contents to an external AI provider and has a steady enough volume to justify operating its own environment. In that setup the model receives only the required fields and instructions, while integrations run through controlled functions. At low volumes, a local server may cost more than a selective API or a workflow without a model. RAG helps only if answers depend on frequently changing house rules, service terms, or internal instructions; it cannot replace a live check for vacant rooms. An autonomous agent with permission to change bookings is unnecessary in the first phase.

Data and integrations before a polished interface

The primary unit of work is not a message but an enquiry with a unique identifier. It needs the channel and intake time, contact details with controlled access, requested dates, guest composition, preferences, validation status, source of the quoted price, assigned employee, and change history. A follow-up message or duplicate webhook delivery must not create a second reservation: the write action needs an idempotency key and a check against existing orders. Twilio's documentation separately describes incoming webhooks, delivery statuses, and a way to distinguish retries.

On an architecture diagram, the communications gateway should be separate from the enquiry workflow and the property-management or booking system. That lets channels change without rewriting business rules. Give price and availability checks only the permissions they need; making or changing a reservation is a distinct action with a log and limits. If the property-management system has no API, temporary RPA may be workable, but interface changes, field changes, and time-outs will require monitoring. The most expensive bot is the one that promised a room that no longer exists.

For a deployment in Russia, check where conversations and personal data are stored, who controls the data, which supplier agreements apply to each channel, and how deletion works. The foreign service named in the Romanian case cannot simply be assumed suitable for a Russian environment. Where local deployment is required, a customer channel may remain external while storage, orchestration, rules, and the model move inside the company's infrastructure; the data transfer boundaries must be documented.

Measure outcomes before claiming payback

The published case provides no figures for response times, successfully handled enquiries, or incremental bookings. A company therefore needs a baseline before rollout. Take two comparable weeks and record unique enquiries by channel, median and 90th-percentile first-response time, share of requests missing required fields, confirmed bookings, human escalation rate, and price or availability mistakes. During the pilot, keep a control group or at least compare matching weekdays and types of enquiry.

Economics should also be based on accepted outcomes rather than the number of messages a bot “processed”. An illustrative model: with 300 enquiries a month, three minutes saved on each yield 15 staff hours. At a fully loaded hourly cost of 600 roubles, that is 9,000 roubles a month before channel fees, development, integration, answer review, and support. This is not a Majestic Jupiter result or a payback promise. A few bookings lost to incorrect prices could erase the time saving. Count booking conversion separately and only from confirmed data.

Limits and a first step

Gather 50–100 anonymised real enquiries from two channels. Label required fields, reasons for follow-up, and exception types; decide which actions can happen without staff approval. Then build a narrow pilot: one enquiry record, field extraction, an availability check from the system of record, and a draft response. During the first weeks, keep price sending and reservation creation behind human approval. For each failure, record whether data were missing, a date was misread, an integration failed, a rule was absent, or the case was ambiguous.

If the data show fewer missed requests and faster replies without more errors or manual correction, expand automation one action at a time. Otherwise, fix the process and data first. The lesson is not that every small hotel needs an “AI agent”. It is that a transparent queue, verifiable integrations, and a human right to decide turn scattered chats into a manageable sales process.