AI Otel’s PMS assistant: what a hotel team can ask and what needs a person
The AI Otel PMS assistant answers questions from your hotel's own records and executes routine tasks. Learn which actions need approval and how to verify every answer.
Contents
Key takeaways
- The PMS assistant is built: it answers questions about a hotel's own property in plain language, carries out routine actions, and a person confirms anything sensitive.
- Its actions sit in three safety tiers: 107 run directly, 90 need one confirmation and 10 need two (registry snapshot, June 2026).
- Small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone except a message already sent to a guest.
- The Hotel Brain is architected and entering training; we have no trained model yet, and the product says so on screen.
- The question that separates a useful assistant from a confident one: which report or record does this answer come from?
The AI Otel PMS assistant is a built assistant inside the hotel operating system that answers questions about a hotel's own property in plain language and carries out routine actions, while a person confirms anything sensitive. It is not the Hotel Brain and not a trained model; no trained model exists yet.
A general manager wants three numbers before the morning meeting, and the person who usually produces them is on a day off. The useful question is not whether an assistant can answer, but whether the answer can be traced to a record, and whether anything moves without a person saying yes. This article explains what the AI Otel PMS assistant is built for, which actions need a person, and how to check any answer it gives you.
What is the AI Otel PMS assistant, and what is it not?
It is a built assistant that sits inside the hotel operating system, answers questions about one hotel's own property in plain language, and carries out routine actions while a person confirms anything sensitive. It is not the Hotel Brain, and it is not a trained model.
Plain language means you type or say a question the way you would ask a colleague, and the answer comes back as a sentence or a short list, not as a report you have to configure first. It reads the hotel's own records: reservations, guest bills, housekeeping status, restaurant sales, night audit and the reports the system already produces.
The status word matters. Built means working software, ahead of launch, not in customers' hands. Nothing in AI Otel's technology is live; OtelCiro, the ecosystem's hotel growth and consultancy arm, works with paying hotel clients today.
Key pointOne-sentence definition
The PMS assistant answers questions about a hotel's own property in plain language, carries out routine actions, and a person confirms anything sensitive. It is built and ahead of launch. It is not the Hotel Brain and not a trained model.
It is not the Hotel Brain. The Hotel Brain is architected and entering training; today the PMS assistant answers from each hotel's own data. It is not autonomous and does not run the hotel: it proposes, answers and executes within limits, and a person confirms anything sensitive.
It is also not a trained model. What exists is the architecture, the decision infrastructure a model would run inside, and a benchmark to choose the model. The distinction matters commercially. A system that answers from your records can be checked against those records. A system that produces a number from nowhere cannot.
What can a hotel team ask it?
It is built for questions about your own property, answered from records you already keep, by department and by period. It is not built for competitor rates, market comparisons or predictions.
A good question names a period and a unit: last week, tonight, third floor, open bills from yesterday. Vague questions get vague answers, exactly as they would from a new colleague.
Front office and housekeeping questions are about state: what is arriving, what is ready, what is still open, what was left unfinished at the end of the day. Revenue and finance questions are about movement: what changed between two periods, which bills are still open, where a figure came from. Food and beverage questions are about what sold, from the restaurant and bar sales records the system already holds.
Questions it is not built for: what a competitor charges, what the market will do next season, what a guest will spend. Those need data the hotel does not hold. When an answer surprises you, ask which report it came from and open that report; the answer should reconcile to it. For more on this habit, see plain-language questions on your own hotel data.
Questions by department, as hypothetical examples
Every example below is illustrative. It shows the shape of a question, not a promise about a specific hotel's data.
| Department | Example question (hypothetical) | What the answer rests on |
|---|---|---|
| Front office | Arrivals still expected after 22:00 tonight, and which rooms are ready? | Reservations and housekeeping status |
| Housekeeping | Which rooms on the third floor are still marked dirty? | Housekeeping status |
| Revenue | Average room rate last week against the week before? | Reservations and night audit |
| Finance | Which guest bills from yesterday are still open? | Billing records |
| Food and beverage | What did the restaurant sell most of on Saturday? | Restaurant and bar sales |
| General manager | What changed since yesterday that I should know about? | The day's records and the decision record |
Which actions need a person, and which run directly?
Every action the assistant can take sits in one of three safety tiers: some run directly, some need one person's confirmation, and the most sensitive need two. The tier is fixed in the software today, not a slider the hotel sets.
Tier one, run directly, covers reading, looking up and reporting. Nothing changes in the hotel's records, so nothing needs approval. Tier two, one confirmation, covers actions that change a record, such as adjusting a rate for a date range or sending a guest a message: the assistant prepares it and a person approves it. Tier three, two confirmations, covers the most sensitive actions, where a mistake would touch money, a legal document or a guest directly.
| Tier | What happens | Count, June 2026 | Illustrative example |
|---|---|---|---|
| Run directly | Nothing in the records changes | 107 | Looking up a reservation, reading a report |
| One confirmation | The assistant prepares, a person approves | 90 | Adjusting a rate for a date range, sending a guest a message |
| Two confirmations | The most sensitive actions need two people | 10 | An action that touches money and a legal document at once |
The registry snapshot of June 2026 counts 207 actions: 107 run directly, 90 need one confirmation and 10 need two. The threshold is fixed in code. If a vendor tells you the hotel sets its own threshold, ask to see where that setting lives.
If nobody confirms, the action waits. It does not quietly become a yes after a timeout, and it does not escalate on its own. The practical consequence for a team: somebody must be reachable to approve, or the queue simply grows. Plan who that is before you rely on the assistant. The wider question of which hotel AI actions need a person is worth reading alongside this section.
What do the morning briefing, price suggestions and alerts look like?
They are three plain-language outputs written from the hotel's own numbers: a short briefing each morning, price suggestions that arrive with their reasons for a person to approve, and an alert when a number moves outside its normal range.
The briefing is written from the hotel's own figures, not from a market feed. It tells you what moved and where to look, and it should point back to the reports behind it.
A price suggestion arrives with its reasons: which rule fired, which dates, which starting figure. A person approves it; the assistant does not set the price. An alert fires when a number leaves its normal range. Ask how that range is set, because a range built from your own history behaves differently from one built from a market average.
These are decision aids, not forecasts. Nothing here predicts demand, and no part of the product is described as a pricing engine. The value is in the reason, not the number: a suggestion you cannot explain to your revenue manager is a suggestion you should decline. Read one suggestion a week against the rate rules it cites; that single habit catches most of the cases where a rule is doing something nobody intended.
ChecklistBefore accepting any suggestion or alert, run these checks
- Which figure is this based on, and which report holds it?
- Which period, and does that period include today's unfinished business?
- Which rule produced this, and is that rule still the one we want?
- Who on the team approves it, and is that person reachable today?
What gets recorded, and what can be undone?
Small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone except a message already sent to a guest.
The decision record is built and runs in a demo environment. Each entry lets you see what changed, from what to what, and who or what proposed it. The record of past entries can only be appended: changing or deleting an entry is closed in the database, and if someone still alters one, the chain shows it. That is tamper-evident, not tamper-proof.
Undo is the point. A rate change applied by mistake should be reversible in a way that leaves both the mistake and the correction visible, not a silent overwrite. The exception is a message already sent to a guest; you cannot unsend it, so the confirmation step before sending deserves more care than any other. Before approving a guest-facing message, read it as the guest, with the room number, the name and the amount in front of you.
Watch outThe one irreversible action
The one change that cannot be undone is a message already sent to a guest. Every other change in the decision record can be reversed. Treat the send confirmation as the most serious click in the system.
Ask any vendor to show you one undone change and the two entries it left behind. If the correction erases the original, you are looking at a log, not a record. The reasoning behind this design is explained in why the safety layer came before choosing a model.
What should a hotel team still check, and what does not exist yet?
Check every answer against the record it came from, and know that no trained model exists yet: what exists is the architecture, the decision infrastructure and a benchmark that has not been run.
The honest zero: we have no trained model yet, and the product says so on screen. The Hotel Brain is architected and entering training. The Platform Brain is designed, the Industry Brain is on the roadmap, and none of them is a finished thing you can buy.
We built a 30-case benchmark with 5 traps to decide which models can serve each layer. It has not been run, and results will be published when measured. Our architecture is model-agnostic: we choose models per deployment by measured evaluation, which is why no model or vendor name appears in this article. Integrations are built and fixture-tested; going live needs the authority and integrator credentials, which is a different sentence from "connected". More on this in how AI Otel will choose a model by measured evaluation.
ChecklistThe team's own checks matter more than any claim. When evaluating any assistant, including this one
- Reconcile five answers to the reports they cite.
- Ask the same question for two periods and see whether the answer moves as the report does.
- Ask what happens when a record is missing or the business day is not closed.
- Read one price suggestion and verify its stated reason against the rate rules.
- Confirm who approves the sensitive tier and what happens when nobody does.
- Ask whether the model evaluation has actually been measured, and ask to see the results.
What to do next
The assistant is useful in proportion to how checkable it is: a question tied to a report, an action tied to a tier, a change tied to an entry you can undo. Start with one department and one weekly habit, reconciling answers to the reports behind them. If you want to see the assistant and the decision record together, request a briefing at https://ai-otel.com/contact.
Frequently asked questions
Does the PMS assistant learn from our hotel?
No. There is no trained model yet, and the product says so on screen. The assistant answers from the hotel's own data using the decision infrastructure around it. The Hotel Brain, which is meant to understand one property, is architected and entering training.
Can it change our rates or send a guest a message without approval?
Price suggestions arrive with their reasons and a person approves them. Actions that change a record sit in the confirmation tiers, and the most sensitive need two confirmations. The tier is fixed in the software today, not set by the hotel. A message already sent to a guest is the one change that cannot be undone.
Which AI model does it use?
The architecture is model-agnostic: models are chosen per deployment by measured evaluation. A 30-case benchmark with 5 traps is built and has not been run, and results will be published when measured. No vendor or model names are given, because the choice is made by measurement, not by brand.
Is it in use at hotels today?
The PMS assistant is built: working software, ahead of launch, not in customers' hands. OtelCiro, the ecosystem's hotel growth and consultancy arm, works with paying hotel clients today. No count of hotels, bookings or users on AI Otel technology exists to quote.
What should we ask before trusting an answer?
Ask which report or record the answer came from, and open it. Ask which period it covers and whether the business day is closed. Ask what the assistant does when a record is missing. An answer that reconciles to a report is checkable; one that does not is a guess with good grammar.