One Workflow Instead of Five Chats: How a Small Hotel Automated Bookings

The case: one process first, AI second

Majestic Jupiter, a small Romanian hotel, received enquiries by phone, email, WhatsApp, and Facebook Messenger. Each channel was handled separately. Staff manually collected travel dates, guest counts, and special requests, clarified missing details, checked room availability, and re-entered information into booking systems. During peaks, a slow response was not merely an operational burden; it could mean losing the guest.

The European Digital Innovation Hub case describes a company with 10–49 employees and 2024 turnover of about €1.1 million. Its initial digital maturity score was 24%. That context matters: the solution was designed for a small business with limited staff time for implementation, not for a technology company with a dedicated data team.

The central lesson is that automation did not begin with selecting a large language model. The team first mapped the end-to-end enquiry and booking flow: which fields are mandatory, which checks can be automated, when a retry is safe, and when a person must take over. The chatbot, workflow orchestrator, RPA, and AI-enabled logic were then placed around this operating model.

The architecture in five layers

The published description supports a five-layer view of the solution.

1. **Entry channels.** A chatbot is available through WhatsApp, Facebook Messenger, and email. The phone remains a human channel, but digital enquiries no longer sit in separate invisible queues.
2. **Structured conversation.** The system collects stay dates, number of guests, special requirements, and contact details. It validates formats before the request moves on, reducing repeated clarification by staff.
3. **Central orchestration.** Every enquiry has a state in one workflow. The orchestrator records the trace, manages the queue and retries, and lets a manager see where a request is stuck.
4. **Deterministic actions.** RPA checks availability, calculates prices, and creates reservations in existing systems. These operations should not be delegated to a generative model: inventory and rates must be determined by rules and current source data.
5. **Human hand-off.** Complex, sensitive, and billing-related requests are transferred to staff with the conversation context intact. The guest does not have to start over, and automation does not decide outside its authorised path.

The case names Twilio cloud communication services and AI-enabled decision logic for validation and routing. It does not disclose a particular model, its deployment model, or the share of requests handled by generative AI. It is therefore more accurate to treat this as process automation with AI components, not as evidence that one LLM outperforms another.

What is confirmed—and what is not

The EDIH report confirms a move from fragmented manual handling to a single traceable workflow. The early stages of an enquiry—data collection, field validation, availability checks, and price calculation—became faster and required less manual effort. Queue management, retries, and a processing log were added, while staff retained control of exceptions.

However, the source explicitly says that measurable result data is not yet available. It does not publish a percentage reduction in response time, a conversion uplift, the number of automated bookings, or a payback period. Reduced workload and greater capacity are qualitative results and expected economic effects, not verified financial outcomes.

That limitation is valuable to decision-makers. The case demonstrates a workable pattern but does not provide a ready-made business case. A hotel, clinic, service centre, or sales team must calculate the economics using its own traffic and labour profile.

Where a local model fits

A local model is not required at every step. A form with dates and guest counts can be processed with ordinary validation rules. Availability, price, discounts, and reservation creation should use APIs or a deterministic executor with explicit checks.

A local LLM can add value in three places:

• classifying free-form messages and extracting dates, party size, and preferences;
• drafting natural-language answers from an approved service and policy knowledge base;
• summarising a long conversation before a staff hand-off.

Running the model in a controlled environment may be appropriate when messages contain personal data, policy restricts external APIs, or volume makes local inference economically predictable. Yet a local model does not remove the need to integrate the property management system, CRM, ERP, or accounting platform. Without an authoritative source for availability and price, it can only phrase a guess more fluently.

For a small business, a hybrid design is usually practical: rules and APIs execute transactions, a compact model interprets language, and people approve exceptions. The model can then be replaced or moved between cloud and local infrastructure without rebuilding the operating process.

Risks to close before launch

The first risk is an incorrect action. A generative model must not set a price, confirm an unavailable room, change a refund, or initiate a charge on its own. It should return a structured draft that deterministic code validates. Payments, non-standard terms, and disputes require a mandatory human hand-off.

The second risk is prompt injection. A guest message is untrusted input. OWASP recommends constraining the model’s role, validating output formats with deterministic code, enforcing least privilege, and requiring human approval for privileged actions. The model should reach internal systems only through a narrow gateway with an allow-list of commands.

The third risk is lost or duplicated work. The queue needs idempotency so that a retry after a network error does not create a second reservation. Each step needs a status, a retry policy, a dead-letter path, and an alert when the automated chain stops.

The fourth risk is data handling. Before the pilot, map which fields arrive from each channel, where they are stored, who can view conversations, how long logs remain, and what is sent to external providers. Legal and sector requirements depend on the actual process and need separate review. The NIST AI RMF offers a neutral principle: risk management belongs in the design, use, and evaluation of an AI system, not only after an incident.

Calculating economics without fiction

Begin with two weeks of observation. For every enquiry, record the channel, first-response time, minutes of manual handling, number of clarification loops, outcome, and hand-off reason. Separate four types of impact:

• labour saved on standard data collection and validation;
• fewer missed enquiries and repeated clarification loops;
• change in enquiry-to-confirmed-booking conversion;
• cost of channels, integration, support, models, and quality control.

The following is a modelled example, not a Majestic Jupiter result. Assume a business receives 100 digital enquiries per day; automation saves four minutes on 60% of them; the operation runs 250 days per year; and the fully loaded staff cost is RUB 700 per hour. The result is 1,000 hours released, or RUB 700,000 per year. Subtract licences, message fees, integration, support, and review time. Add sales uplift only after a controlled comparison, not as a vendor promise.

The first-stage north-star metric is not “answers written by AI” but the cost of a successfully handled enquiry without a quality decline. Track human hand-off rate, incorrect actions, duplicate bookings, recovery time, and complaints alongside it.

A four-week pilot

**Week 1: map the process.** Select one scenario, such as an availability enquiry. Collect 100–300 anonymised conversations, list mandatory fields, exceptions, and hand-off reasons, and establish baseline metrics.

**Week 2: build a shadow workflow.** Connect one channel to a queue, but do not send automated answers. Let rules or a model extract data while staff compare the output with the real decision. Availability and prices are read only through a test interface to the system of record.

**Week 3: allow safe responses.** Automate acknowledgements, requests for missing fields, and approved FAQ answers. Keep reservation creation with staff or behind a deterministic command with preview and validation.

**Week 4: test failure and economics.** Simulate connectivity loss, duplicates, invalid dates, rate conflicts, and unusual requests. Calculate cost per enquiry and staff time. Scale only when quality is no worse than baseline, the queue recovers correctly, and the benefit exceeds recurring cost.

The management takeaway

The useful element of this case is not the chatbot storefront but the controlled workflow behind it. A small business should start with one process, deterministic rules, and a visible queue. Add AI where free text must be understood or phrased; keep money, inventory, and commitments under the control of systems and people.

If a four-week pilot cannot show a baseline, cost per enquiry, exception rate, and action log, it is too early to expand. Good automation first makes a process observable—and only then makes it intelligent.