How does a hotel / hospitality property use intusell? Daily operations guide
Training is done; now comes operations. From a room question in the DMs to a reservation, from payment to a human handoff — the daily intusell flow of a hotel and hospitality property.
In the first article, you trained the intusell AI: you uploaded your room types and property information to the knowledge base, flagged sales conversations, and configured the persona and response rules. Training was a one-time setup. Now the real work begins: how does a hotel or hospitality property use intusell — that is, how does using intusell at a hotel work in daily operations? This article shows, step by step, what the assistant you trained does and how, over the course of a workday in the field — from an incoming DM to a reservation, from payment to a human handoff.
This article is the second part of the hotel and hospitality section of our sector-by-sector "how to train your AI" series. The first part, how to train the intusell AI, covered the setup; this one covers turning that setup into daily operations.
Quick answer
A hospitality property uses intusell to answer the room, date, price, and availability questions guests ask via Instagram DM and WhatsApp 24/7, to present the correct nightly price from the rate plan you have defined, to check availability and take guests to the reservation step, and to route payment to the property. The AI does not invent prices and availability; in off-tariff situations it escalates the conversation to the live team. The seller is always the property.
A day in the flow
The typical day of a property running intusell is very different from before. In the past, the front desk or reservation manager would arrive in the morning and scan dozens of unread DMs and unanswered WhatsApp messages one by one. Now the messages that came in overnight are already answered, leads are categorized, and some reservations are already underway. The backbone of a day looks like this:
| Time | Customer side | What intusell does |
|---|---|---|
| 02:14 | "Got a sea-view room for July 14-17?" | Checks availability, gives the nightly price from the tariff |
| 09:00 | Front desk/reservation team logs in | Overnight leads are ready in the single inbox |
| 11:30 | Customer says "can we hold it?" | Room is temporarily allocated, moves to the payment step |
| 14:00 | Customer makes payment | awaiting_payment → IBAN details are shared |
| 16:45 | Group/event request | AI escalates the off-tariff case to the live team |
| 23:30 | Customer who went quiet | Proactive follow-up message, lead kept alive |
The team is no longer occupied with scanning messages, but with the conversations that genuinely require a decision.
Who is it for?
This usage model makes particular sense for these properties:
- Properties that receive heavy demand from Instagram and WhatsApp — those that cannot keep up with dozens of "do you have a room free, what's the price?" messages a day.
- Operations that lose after-hours demand — those that miss sales because reservation questions coming in evenings and weekends are answered late.
- Properties with fixed room types and seasonal tariffs — those that sell standard, deluxe, suite room types through repeated questions.
- Boutique hotels, aparts, and guesthouses managing many channels with a small team — those forced to track DMs, WhatsApp, comments, and email separately.
If you have a demand volume that a single reservation manager cannot keep up with, intusell works like a senior salesperson handling that demand.
Incoming request: the customer asks about a room, the AI recommends a suitable room type
The flow begins with the customer sending a message. Imagine someone writing from Instagram DM, "We're thinking of a 3-night stay in early August, 2 adults and 1 child." The AI reads this message, scans your property information and room types in the knowledge base, and recommends the room type that fits the customer's need.
An important point: whatever language the customer writes in, the AI replies in that language. For properties that host foreign guests, this is critical — a room question that comes in English gets an English answer, with no extra setup required.
If you added the "ask about the need before giving a price" response rule during training, the AI first clarifies the check-in/check-out dates, the number of guests, and the room type preference. Thanks to this rule, the offer is not random but based on the customer's real need. We also explain separately how all these channels are unified in a single inbox in the Instagram and WhatsApp automation article.
Price and availability: the AI offers from the rate plan
This is the most sensitive point for hospitality properties. The AI does not invent the price and availability. It gives the offer only from the rate plan and availability calendar you have defined. Pricing works by date and room type; seasonal differences also come from this tariff:
| Question type | Where the AI answers from |
|---|---|
| Nightly price | Room type × date range (rate plan) |
| Season difference | Season price in the rate plan |
| Child/extra bed | The child and extra-bed policy you defined |
| Availability | Live room inventory for that date |
For a "3 nights, 2 adults and 1 child" request, the AI clarifies the check-in/check-out dates, checks whether the room is available in that range, and gives the total offer including the season difference in one go. The currency comes in the way you defined by default.
If something not in the tariff is asked — for example, a date range you have not defined, a group reservation, or a special-event price — instead of inventing a price the AI suggests connecting the customer to the live team. This behavior prevents you from giving the customer a wrong price and then having to correct it; this is the foundation of trust.
You'll find in detail how room types, rate plans, and the availability calendar are set up, and how the reservation engine works with atomic allocation, in the room reservation automation article.
Availability and reservation: room allocation and overbooking
When the customer likes the offer and says "can we hold it?", the reservation lifecycle kicks in. The flow proceeds in a clear sequence:
offer (room + date + price)
→ option_hold (room temporarily allocated)
→ awaiting_payment (awaiting payment)
↔ partially_paid (partial payment)
→ fully_paid (full payment)
→ confirmed (confirmed)
→ checked_in → checked_out
The cancellation, refund, and no_show branches are also within this cycle. When the reservation starts, room allocation kicks in, and this is mathematically safe: availability is protected atomically by a database constraint. Overbooking is impossible. Even if two guests want the last room for the same date at the same time, the system sells it to only one of them; the second is told it is not available and is offered a suitable alternative. This eliminates the most common nightmare for properties working with a manual calendar or Excel — selling the same room twice.
You are not limited to a single property: if you manage more than one property (for example, two separate guesthouses or aparts), each property's room types, tariffs, and availability are kept separate, all managed from the same inbox.
Payment: bank transfer/IBAN by default, iyzico optional
When the customer reaches the awaiting_payment stage, the payment step begins. Here you have two options:
- Bank transfer/IBAN (default): Requires no integration. The AI shares the IBAN details with the customer; when payment is made, the status is updated to partially_paid or fully_paid.
- iyzico card payment (optional): If you want to take card payments, you connect iyzico, and the customer pays instantly by card from the payment link.
In both cases the core rule does not change: the seller is always the property. Payment goes directly to the property's account, and the invoice is issued in the property's name. intusell never steps in between or takes a seller position at any stage. For product and pricing details, you can see the solutions and pricing pages.
KVKK consent and guest information
As the reservation progresses, guest information is collected. For accommodation registration, the first name, last name, and required details are taken; personal data is stored encrypted. The system provides protection on two KVKK fronts:
- Explicit consent: Before guest information is collected, explicit KVKK consent is obtained.
- Encrypted storage: Identity and PII fields are end-to-end encrypted; sensitive fields cannot be freely exported by the AI and require approval.
This lets you answer the "what did the guest accept and when?" question with evidence in case of an audit or dispute.
During the stay: room service and request management
intusell works not only before the reservation but also after the guest checks into the property. When a guest writes from WhatsApp "is a late checkout possible tomorrow?", "could I get extra towels in the room?", or "can we book a dinner reservation?", the AI takes these requests and relays them to the team as a service request. This concierge-style flow reduces the front desk being swamped by phone calls and ensures the guest's request is recorded.
The rule here is the same: before committing to anything, the AI checks the knowledge base and your policies. In a situation it does not know or that requires approval — for example, a paid late checkout — it routes the request to the team.
Following up the quiet customer: proactive follow-up and CRM
In hospitality, the most leads are lost on guests who say "let me think about it" and disappear. intusell does not forget these leads. Customers who got an offer and went quiet receive a proactive follow-up message; the lead is kept alive. Every conversation is logged into the CRM, so the customer's history, which date and room type they were interested in, and what stage they stopped at remain on record.
A boundary needs to be drawn clearly here: intusell does not maintain a managed "waitlist." What it does is make an opportunistic re-offer to suitable WhatsApp customers in follow-up — for example, a reminder to a guest who got a price and went quiet, in the tone of "The room for the dates you asked about is still available, shall I help?". This way, when you settle into operations in the morning, it is clear which lead is hot and which is awaiting follow-up. You do not need to keep a manual reminder list.
Appointment and reminder engine (if needed)
Most of hospitality's flow revolves around room reservations, but some properties also use appointments: a spa/massage session, restaurant reservation, tour, or transfer planning. intusell's universal appointment engine works in these cases too.
The AI does not give a time out of thin air; it looks at the working hours and booked slots you defined during training, and if it finds a suitable slot, it creates the appointment. An automatic reminder (for example, a day and 2 hours ahead) goes out for each appointment, and the customer manages their appointment themselves via the /manage-appointment/{token} link — cancellation or rescheduling is done in one click. Appointments are copied one-way to Google Calendar (intusell → Calendar); the team sees them in their own calendar. This module can be enabled in any plan; if you do not need it, you simply never use it.
Human handoff: lock modes
You decide how autonomously the AI works. There are three lock modes:
| Mode | Behavior | When |
|---|---|---|
| ai_only | The AI handles all conversations | Peak season, when you want full autonomy |
| hybrid | The AI runs the normal flow and escalates when needed | Ideal for most properties |
| human_only | All conversations go to the live team | Sensitive period, group/event request |
In hybrid mode, the AI hands off a group reservation request it cannot answer or an off-tariff price question to the live team. At the moment of handoff, the entire history of the conversation is in front of the team; the customer does not have to start over. You can switch the mode at any time — for example, ai_only during peak season, human_only during a sensitive group negotiation.
One additional note: when a customer sends an ID photo, a payment receipt, or a document, that alone is not a reason to hand off to a human. The AI takes the attachment, understands the context, and continues the flow; it hands off only if there is a situation that genuinely requires a decision.
How the AI is constrained: the guardrail layer
In hospitality, wrong information is costly: promising a view that does not exist, confirming a date that is not available, or quoting the wrong price. intusell manages this risk with two layers. The primary control is the sector-specific system prompt: from the start, the AI is constrained to speak only with the room types, tariffs, and policies you defined; it is set up so that inventing something outside the inventory is prevented. On top of this, a guardrail layer scans the responses and flags risky statements — instead of imposing a hard block, it detects and flags them to make them visible to you.
In other words, the system's safety works on the logic of "a setup that keeps the AI within correct boundaries from the start + a scanner," not "a filter that blocks the AI after the fact." The practical result is this: the AI does not invent something it does not know, says it does not know, and hands off to a human.
Reports: what's working, what to fix?
For operations to be visible, you track core metrics on the panel. How many messages came in from which channel, how many were answered by the AI, how many were handed off to a human, which questions recur most — seeing these serves two purposes:
- Finding knowledge-base gaps: If there is a topic the AI frequently says "I don't know" about and hands off, that information is missing from the knowledge base; once you add it, the handoff rate drops.
- Improving response rules: You review the labels and correct misclassified conversations; the AI learns from these corrections. If you like, you compare two different response approaches with an A/B test.
In other words, reports are not just a summary but the feedback loop for sharpening the assistant over time.
What it isn't
To put intusell in the right category, let's clarify what it is not:
- It is not a chatbot. It is not a flow bot answering by canned templates; it is a fully autonomous AI sales assistant working with the knowledge and sales techniques you trained.
- It is not an OTA / channel manager. It does not provide marketplace inventory like Booking or Expedia; it uses your room types and tariff, and the seller is the property.
- It is not a source of prices and availability. It does not invent information; it speaks only from the tariff and availability you have defined, says it does not know, and hands off.
- It is not a product priced specifically for hospitality. The price model is based on messages and voice minutes and does not change by sector. The hospitality module can be enabled in any plan.
So that you do not start with the wrong expectation, let these boundaries be clear from the outset.
Frequently asked questions
Does the AI complete the reservation on its own?
The AI recommends a suitable room type, asks for the price by date, checks availability, and takes the customer all the way to the payment step. Room allocation and availability checks run in an atomic system, so the same room cannot be sold twice. In risky or off-tariff situations, it escalates the conversation to the live team. The final confirmation can always stay with the property.
Does the AI invent prices and availability?
No. The AI states the nightly price and room availability only from the rate plan and availability calendar you have defined. It does not invent a date, room type, or price you have not defined; it says it does not know and hands off to the live team. This is the most important trust rule.
Can overbooking happen?
No. Room allocation runs atomically and availability is protected by a database constraint. The last room for a given date cannot be sold to two guests at the same time; overbooking is mathematically impossible.
Can a customer be connected to a human?
Yes. In hybrid mode the AI runs the normal flow and escalates the conversation to the live team when needed. In human_only mode all conversations go straight to the team, and in ai_only mode the AI handles everything. You can switch the mode at any time.
What happens to a message that comes in overnight?
The AI replies 24/7. A "do you have a room free on these dates?" question that comes in at 2:00 a.m. gets an availability and price answer within seconds; if it works, it routes to a reservation. When you open up in the morning, ready leads and offers are waiting for you.
Which channels does it unify in a single inbox?
WhatsApp, Instagram DM, Facebook Messenger, Telegram, web chat, and email are unified in a single inbox. Instagram comment automation rolls out gradually depending on Meta approval; the first step is WhatsApp and Instagram DM.
Next step
If you have not yet trained your assistant, start first with the how to train the intusell AI article — the foundation of this operation is built there. If you want to go deeper on the channel side, you can move on to the Instagram and WhatsApp automation article, and to see the room reservation engine in detail, the room reservation automation article; you can see the hotel and hospitality solution page and the whole series on the all posts page. If you're curious how the same approach is applied in other sectors, the tour agency training guide and the clinic training guide are good examples.
To see live how it would work at your own property, get a demo or write directly to hello@intusell.com. In a 20-minute session, we open your inbox together and test the first offer in the system.
You read the blog — now see it live.
Test intusell live with your own sector scenario in a 20-minute demo.