Hotels need a decision-ready operating model before AI agents

Buying another AI tool will not close the gap between hotel data and hotel action. Hotels need a decision-ready operating model first: connected data, documented workflows, named decision owners, and clear approval rights.

That is not a cautious argument against AI. It is the practical explanation for why adoption is moving faster than results. Hotels are already testing the tools. The work now is making the operating environment clear enough that an AI recommendation can become trusted action rather than another report nobody owns.

The adoption gap is an operating-model failure

The State of Distribution 2026 covers 343 PMS vendors, more than 270 hotel brands, and over 58,000 properties. It reports that roughly half of hotels use some form of AI, while under 10% see real business impact.

That is not an AI availability problem. The study points to fragmented data, undefined success metrics, and closed PMS APIs. Only 7% of PMS companies publish fully public API documentation. The rest are closed or partially closed. An AI layer cannot reliably join guest, rate, availability, folio, and service data if the systems holding those records do not provide a usable path in or out.

The undefined-metrics problem is just as important. A hotel can call an AI pilot successful because people logged in, because a dashboard produced an insight, or because a vendor showed an attractive example. None of those proves an operational result. Before a tool is bought, the team should be able to say which decision changes, who makes it today, how quickly it must be made, and what evidence will show that the new process worked.

For revenue and distribution, that might mean a named decision on a channel mapping issue, a rate adjustment, or a restriction. For operations, it might mean a staffing sequence, a room-priority change, or a maintenance intervention. The tool is not the operating model. It works inside one.

Room 407 has to exist as more than a room number

The Room 407 ontology example makes the data problem tangible. Room 407 is a Deluxe King. It takes 31 minutes to clean. It connects to Room 408. Its AC was recently serviced. Linen storage is 75 meters away.

Those facts are useful, but they are not yet a decision. The value appears when the hotel connects them to the people, spaces, tasks, equipment, routes, and standard operating procedures that shape the work. An executive housekeeper may know that this room takes longer because of its layout or worn floor equipment. That knowledge is often real, operationally valuable, and absent from a system.

This is what ontology means in plain terms: a shared description of how the property actually works. It does not require documenting every possible detail. It requires documenting the facts needed to make repeatable decisions without relying entirely on whoever happens to be on shift.

An agent cannot improve a workflow the hotel has never described, and it cannot safely act where no one has defined who owns the decision.

Once the relationships are visible, the questions become specific. Why are housekeepers spending 18 minutes per shift retrieving supplies? Which cleaning sequences create unnecessary cross-floor movement? Which equipment history should change a room’s maintenance priority? These are not futuristic agent questions. They are ordinary operating questions that become easier to see when the underlying work is structured.

The same principle applies beyond housekeeping. A revenue recommendation needs a coherent view of room types, channel mappings, inventory, restrictions, and the person authorized to approve a change. A guest-service recommendation needs an accurate view of the guest, the current stay, service history, and what the team is allowed to offer. If those relationships are ambiguous, automation only makes the ambiguity move faster.

Connected guest data is the first practical build

The First Central Hotel Suites Dubai rollout is a useful example because it is not an AI announcement. The 524-room property replaced disconnected front-office and food and beverage systems with Shiji’s Daylight PMS and Infrasys POS across two dining outlets.

The result is one shared guest profile across check-in, room service, and restaurant transactions, rather than separate departmental records. Shiji Middle East VP Andreas Duerkoop said staff could respond to guests faster with fewer manual steps. First Central Cluster Marketing Manager Dr. Zakaria Abdelhai said the rollout created “greater confidence in our data”.

That confidence is not glamorous, but it is the prerequisite for every more glamorous claim about personalization, forecasting, and service automation. Before an AI system can recognize a repeat dining preference alongside a room-service order and a front-desk request, the hotel has to know that those records belong to the same guest and can be used together.

A shared profile also changes the day-to-day operating conversation. Instead of asking which department has the latest information, teams can ask what should happen next. That is a much better starting point for AI. It turns integration from an IT project into an execution issue.

The right early autonomy model is recommendation plus approval

The SiteMinder Dynamic Commerce Engine understands a point many AI pitches skip. Commercial teams do not need another dashboard full of signals. They need help identifying which pricing and distribution decisions matter now.

SiteMinder says its engine continuously scans pricing and distribution data, identifies issues such as broken channel connections or unmapped room types, and prioritizes recommended actions. It operates across roughly 56,000 properties and 2.6 million rooms. But the important design choice is not the scale. Recommended changes require operator approval before execution.

That is the right early model for decisions that affect revenue, inventory, and brand position. The system should state what it recommends, why it recommends it, what data it used, and what will change if the operator approves it. The accountable person should still make the call until the hotel has enough evidence to expand autonomy.

The category is moving in that direction. A 6,000-hotel study of Mews Autopilot found a 13% lift in revenue per square meter over 18 months, but only 55% of eligible customers ran it in full-autopilot mode. The rest kept a hand on the wheel.

That is not resistance to progress. It is sensible governance. A system that predicts a rate is different from a system that changes it without asking. Hotels should earn higher autonomy through a documented record of accurate recommendations, clear exception handling, and accountable review.

Define the decision, owner, and proof threshold before procurement

Are Morch’s AI readiness framework gives operators a practical order of operations: leadership direction, data foundations, team skills, workflow integration, and governance. That order matters because a tool cannot supply the missing judgment about which business problem deserves attention first.

Start with the decision, not the product category. A hotel may be trying to identify a demand signal across the guest journey, reduce manual service handoffs, improve a distribution process, or make an operational schedule more reliable. Each is a different problem, with different data requirements and different risks.

Then name the owner. If an AI recommendation identifies a pattern in guest questions about remote-work spaces, who decides whether that signal changes an offer, a package, an amenity, or nothing at all? If an AI system flags a room-type mapping problem, does the revenue leader, e-commerce team, or property team approve the correction? An unowned recommendation is just a better-formatted alert.

Finally, define the proof threshold before procurement. What baseline exists today? What change would count as meaningful? What failure mode is unacceptable? The answer should include how the decision will be reviewed, not just what result the vendor promises.

Employee resistance belongs in this work too. Morch treats it as a signal, often rooted in failed technology rollouts or concerns about job security. That is worth diagnosing. A team that distrusts the data, fears the consequence of a wrong recommendation, or lacks authority to act is telling leadership something important about the operating model.

This quarter, choose one decision path where a recommendation currently dies between systems or departments. Document the data it needs, the workflow it enters, the person who approves it, and the evidence required to trust it. Then decide whether AI is the right next purchase.

Most hotels do not need an agent to discover that their operating model is unclear. They need to fix the clarity first.