Hotel software architecture for AI: define each action once

Hotel software architecture is the set of decisions about where each hotel action is defined, who may reach it and what it records. Defining an action once, with its inputs, rules, approvals and record, and giving staff screens, partner systems and AI assistants each their own door to it, keeps one policy instead of three drifting copies.

A guest cancels two days before arrival. The receptionist's screen applies the one-night penalty. The travel agency's connection releases the room without it. The assistant asks for a confirmation and then writes nothing down. Three answers to one question, and the hotel has to choose which one was its policy. This article explains why that happens, what it means to define a hotel action once, and how to test any system, bought or built, for it.

Why does one hotel action end up built three times?#

Because each new channel is usually built as its own small system, and each one re-implements the rule it needs. Nothing forces the three versions to agree.

The front desk screen, the partner connection and the assistant are three code paths to the same business event, and each was written by someone solving a local problem. The screen was written for a receptionist in a hurry. The partner path was written to satisfy an agency's file format. The assistant layer was written to answer a guest's question. Each is reasonable on its own.

For example, take a booking cancelled 48 hours before arrival with a one-night penalty. The screen reads the rate plan's policy code and charges the night. The partner path was written before that policy code existed and releases the room free. The assistant asks the guest to confirm, then records the cancellation without the approver's name. Every version is locally correct and globally inconsistent, which is why testing each one separately never catches the problem.

The question that exposes drift is simple: if we changed our cancellation policy tomorrow, how many places would we edit? One is architecture. Three is drift.

Each new surface adds a fourth copy. In August 2026, one search company began rolling out hotel booking inside its AI mode for US travelers, with the traveler choosing and paying and the assistant not booking on its own (Skift, 27 August 2026), but every such surface is another door that must reach the same rules. The cost appears late: a dispute, an audit or a guest complaint asks which version was in force, and no one can answer from the system. If you want the wider picture of how the core systems in a hotel technology stack fit together, the same principle applies across all of them.

What does it mean to define a hotel action once?#

It means writing the action down in one place with four parts: what it takes in, which rules decide the outcome, who must approve it, and what record it leaves. Every door then calls that one definition.

Inputs are the facts the action needs: the booking reference, the arrival date, the rate plan's cancellation policy, and who is asking. Rules are the conditions and the arithmetic, held once, so a penalty is calculated by one piece of code and not by three. Approvals are the tier the action sits in: whether it runs directly, waits for one person or waits for two. The record is what is written afterwards, by whom or by what, with the previous value and the new one, and whether the change can be reversed.

The definition is not a document. A policy PDF drifts as fast as code does; the definition has to be the code path every door actually calls. The practical test is the edit count: change one rule and count the places you must touch. One is the target. Three is drift.

A second test is the read-back: ask the system to show the rule that produced a given charge, and see whether it can. A system that holds rules in one place can explain its own outcomes. A system with three copies can only explain whichever copy you happen to be looking at.

How does each audience get its own door?#

Each audience gets a separate entrance with its own identity check, its own permitted set of actions and its own limits, all pointing at the same definitions behind them.

Staff screens are the familiar door: a named person logs in with a role, and the screen offers only the actions that role may take. The screen is a view, not the rule. If the receptionist's screen hides the refund button for junior roles, that is presentation; the rule is what the refund action itself enforces.

Partner connections are a versioned interface where the partner proves who it is and states what it wants to do. OAuth 2.0, the IETF standard published as RFC 6749 in October 2012 (opens in a new tab), does exactly this: a third-party application obtains limited access to a web service, either on behalf of the resource owner after an approval step or on its own behalf, and states the scope of access it asks for. The scope is the door's width, and it can be narrowed without touching the action behind it.

Events instead of polling: a system that needs to know about check-in, check-out or a room going out of service subscribes to those events and is notified when they happen. This is the publish-and-subscribe method set out in HTNG's Event Notification Specification, version 3.0, 24 April 2015 (opens in a new tab). The event is announced once, by the action that caused it, and every subscriber hears the same thing.

AI assistants get a door like any other, with a narrower permitted set and a person behind anything sensitive. An assistant is a client of the system, never a second system of record. Least privilege applies to software as well as people: NIST's glossary, citing CNSSI 4009-2022, defines it as restricting the access privileges of users, and of processes acting on their behalf, to the minimum necessary to accomplish assigned tasks.

Doors beat walls. The aim is not to keep assistants out but to know precisely which actions each one may reach, and to change that list without rewriting the action itself. For the plumbing behind these doors, see hotel PMS integrations explained, APIs in plain words.

How do limits and approvals travel with the action?#

The limit belongs to the action, not to the screen. If a refund above a threshold needs a second person, that holds whether a receptionist, a partner system or an assistant triggers it.

In plain words, three tiers: some actions run directly, some wait for one person's confirmation, the most sensitive wait for two. Separation of duty supports this. NIST's glossary, citing NIST SP 800-192 (opens in a new tab), defines it as giving no user enough privileges to misuse the system alone, enforced either statically through conflicting roles or dynamically at the moment of access, with the two-person rule as the dynamic form.

The data protection side reaches the same conclusion. The Turkish data protection authority's Personal Data Security Guide (Technical and Administrative Measures, April 2025) (opens in a new tab) advises giving employees access only to the extent their tasks, authority and responsibilities require, through a username and password. It recommends an access authorisation and control matrix built on "everything is forbidden unless permitted", says administrator rights should be opened only when needed, that leavers' accounts should be closed without delay, and calls for regular logs of all users' actions.

The approval must be written into the same record as the action. An approval that exists only in a chat message or a phone call is not an approval the system can show later. Tiers must also be owned: someone inside the hotel has to hold the list of actions that run without a person, and review it when a new door opens.

A new channel silently bypasses any control that was implemented in the old channel's screen. That is the failure mode this design exists to remove.

What should the record show, whoever acted?#

It should show what changed, who or what asked, who approved, and what the previous value was, in a form that can still be read later without trusting the person who wrote it.

Because the record is written by the action definition, every door produces the same shape of record. A cancellation from the desk and a cancellation from a partner connection are comparable line by line. That comparability is what makes a month of records useful rather than a pile of anecdotes.

Undo needs a rule, not a hope. Small changes can be reversed, and some cannot, such as a message already sent to a guest. Say which is which before you need it. Append-only records can be added to but not edited or deleted, and if someone alters one anyway, the chain shows it. That is tamper-evident: an alteration leaves a mark, and no honest system promises more than that.

An assistant's action must be attributable: which assistant, on whose authority, within which scope, and which person confirmed it if a person was required. The guide cited above also calls for regular logs of all users' actions, which is the same requirement seen from the data protection side rather than the operations side.

What a dispute or an auditor actually needs is the policy version in force at the time of the action, not the policy as it reads today. A record that stores the rule that fired, not just the outcome, answers that question. For the difference between this and a conventional property management setup, see hotel operating system versus PMS, and what changes in daily work.

What does this architecture cost, and how do you test a vendor for it?#

It costs design time before the first release and makes early releases slower. It pays back when the second and third channel arrive and the rules do not need rewriting.

Up front, someone must write down every action with its inputs, rules, tier and record before the screens are built. That work is slow and invisible in a product demonstration. The first release lands later than a channel-by-channel build, and a buyer comparing timelines will notice.

The payback is structural: a new channel becomes a door onto existing definitions rather than a project with its own copy of the rules. The cost of skipping it is not a crash. It is three policies, a support team that cannot explain a charge, and no answer to which version was official.

Ask for one action end to end rather than a feature list. A vendor that has done this work can show it in minutes; one that has not will show screens instead. The same questions apply to your own team if the software is built in house, and to any integrator who proposes a separate path for a new channel.

Seven questions to ask a vendor#

What to do next#

Pick one action, cancellation is the usual candidate, and trace it through every door you have: the desk screen, each partner connection, each assistant. If the four parts, inputs, rules, approvals and record, are not in one place, you have found the work. Then put the seven questions above to your vendor, or to your own team, and judge the answers rather than the demonstration.