Hotel AI needs an operating model before it earns autonomy

The constraint on hotel AI is no longer access to tools. It is the operating model around them: what work is defined, which data is trusted, who owns a decision, and when a system is allowed to act without asking.

That distinction matters because the market is full of products that can generate an answer. Fewer hotel organizations have decided what happens after the answer appears. A revenue recommendation still needs an accountable owner. A housekeeping agent still needs to understand rooms, supplies, assignments, exceptions, and the physical path between them. A front-desk integration still needs a process that staff can follow under pressure.

Hotels that skip this work do not get autonomy. They get another dashboard, another alert stream, and another system that employees work around.

Reports are not decisions

SiteMinder’s Dynamic Commerce Engine is explicit about the problem. The company says hotel distribution has moved beyond a simple data shortage. Hotels already receive reports. The gap is identifying which pricing and distribution opportunity matters now, then getting a change made correctly.

The engine scans pricing and distribution signals, prioritizes recommended actions, and flags practical failures such as broken channel connections and unmapped room types. That last category deserves more attention than it usually gets. A rate strategy cannot perform if the distribution layer is misconfigured. A sophisticated recommendation does not repair a room type that was never mapped correctly.

SiteMinder is deploying this across roughly 56,000 properties and 2.6 million rooms, processing close to 4 billion availability-rates-inventory signals, 140 million reservations, and 300 million room nights a year. Scale does not remove the execution problem. It makes the cost of unresolved system friction easier to see.

The commercial question is not whether an AI system can find a signal. It is whether the hotel has a defined path from signal to action, including who validates it, who makes the change, and how the property knows whether it worked.

A recommendation needs an owner

SiteMinder requires operator approval before its recommended pricing and distribution changes execute. That is not an incomplete version of automation. It is a sensible design choice for decisions that carry revenue, channel, and guest-experience consequences.

The same pattern appears in revenue management. Duetto’s new forecasting engine reported 95.22% average forecast accuracy across its customer portfolio and added a driver waterfall chart so revenue managers can see what drove a forecast. Explainability is not decoration. It gives the person accountable for the decision a basis to challenge, accept, or investigate the recommendation.

Mews offers the other half of the picture. Its Autopilot pricing feature produced a 13% lift in revenue per square meter over 18 months in a 6,000-hotel study. But only 55% of eligible customers were running it in full-autopilot mode. The remaining customers kept a hand on the wheel.

That is not evidence that operators are irrationally resistant to technology. A system that predicts a rate and a system that changes a rate without asking are different propositions. The latter requires a clear policy on limits, exceptions, overrides, and accountability when conditions change.

Autonomy is not a setting a hotel turns on. It is a level of authority the operation earns through repeatable, observable decisions.

Start with decision rights. For a pricing recommendation, define the approver, the conditions that require review, the changes the system cannot make, and the time window in which an unreviewed recommendation expires. For a distribution fix, define whether revenue, e-commerce, or the property owns the correction. The system can accelerate the work. It cannot resolve an ownership gap that management has left ambiguous.

Room 407 has to exist as operational knowledge

Room 407 needs an ontology before it needs an AI agent. Martin Soler’s example makes the point better than any technology architecture diagram.

Room 407 is a Deluxe King. It takes 31 minutes to clean. It connects to Room 408. Its AC was serviced recently. It is 75 meters from linen storage. Each fact is useful, but none is enough on its own. The useful operating picture also includes what an executive housekeeper knows: a layout that adds cleaning time, floor equipment that slows the work, the supply location, the room sequence that causes unnecessary backtracking, and the exceptions hidden in routine practice.

This is what Soler means by ontology. It is not a fashionable label for a data project. It is the structured connection between rooms, tasks, equipment, people, spaces, and the knowledge staff use to get work done.

Without that structure, an agent can produce plausible instructions while missing the conditions that determine whether those instructions work on a real shift. It may assign rooms efficiently on a spreadsheet while sending attendants across floors for supplies. It may schedule maintenance based on an equipment record while ignoring the relationship between a recent repair, room status, and a guest-facing operational constraint.

Soler cites a more grounded starting point: discover that housekeepers spend 18 minutes per shift retrieving supplies, or identify room-cleaning sequences that create unnecessary cross-floor movement. These are not dramatic AI demonstrations. They are specific operating losses with a named cause.

The documentation work comes first. Map rooms, employees, tasks, equipment, and spaces. Capture the exceptions that experienced staff apply repeatedly. Do not collect detail for its own sake. Collect the detail required to explain why the work takes the time it takes, and where the handoffs fail.

Friction is a financial problem, not an IT inconvenience

Shiji’s analysis of technology friction puts an owner-level number behind this work. Alejandra Pueblita calculates that a representative 200-room hotel at 70% occupancy and a $162 ADR generates about $8.29 million in annual room revenue. A 1% operational efficiency improvement is worth roughly $82,700 a year.

That reframes workflow and data cleanup. It is not unglamorous IT overhead that must be tolerated before the interesting AI project begins. It is the business case.

The examples Pueblita cites are mostly integration and process improvements, not grand claims about autonomous hotels. American Liberty Hospitality improved service speeds by 10% to 20% and increased F&B revenue by 10% to 15% across five properties after deploying mobile point-of-sale. Grand Hyatt Singapore reduced in-room dining order errors from 5% to 10% to near zero, while menu updates moved from weeks to hours after digitizing operations across 699 rooms. Hotel Corallo Sorrento increased ADR by 20% while holding online reputation scores steady.

The common thread is simple. Staff had less manual re-entry, fewer order errors, and less time lost crossing between disconnected systems. Those are operating improvements before they are technology stories.

A hotel does not need an AI program to justify fixing a broken handoff. It needs an owner for the handoff, a baseline for the cost, and a measurement plan for the improvement.

Readiness is a workflow redesign exercise

Are Morch’s AI readiness framework provides a useful sequence: leadership direction, data foundations, team skills, workflow integration, and governance. The order is important. A vendor shortlist cannot answer questions that leadership has not settled about authority, data quality, or acceptable risk.

Choose one measurable friction point rather than beginning with a broad AI mandate. It could be a recurring channel mapping failure, a manual front-desk re-entry step, supply retrieval in housekeeping, or a labor risk that becomes overtime because it is spotted too late. Document the current workflow from trigger through completion. Name each system, handoff, exception, and decision owner.

Then establish the baseline. How long does the work take? How often does it fail? What revenue, labor, guest-service, or error cost follows? This is where employee resistance can be useful information rather than a change-management nuisance. Morch argues that resistance often reflects failed technology rollouts or job-security concerns. In operating terms, it can also reveal the undocumented exception that a proposed workflow has missed.

Only after that should the hotel introduce an AI recommendation, because only then can it tell whether the tool improved the work or simply changed the appearance of the process.

Let autonomy earn its way into the operation

The practical path is not to choose between manual work and full autopilot. It is to move one reversible action at a time.

Begin with explainable recommendations and human approval. Measure acceptance rates, overrides, exceptions, time to action, and the financial or service outcome. Review the cases where staff reject the recommendation. Some will expose a weak model. Others will expose missing operational data or an approval policy that has not been defined well enough.

When a decision becomes routine, low-risk, measurable, and easy to reverse, consider automating it within explicit guardrails. Keep the audit trail. Keep an override path. Keep a human owner for the policy, even when no human needs to approve each individual action.

This quarter, pick one workflow where staff are still moving information between systems or making the same judgment repeatedly. Map it with the people who do the work. Assign decision rights before buying anything new. Then test one recommendation with approval required.

That is less exciting than promising an autonomous hotel. It is also how an AI system becomes part of an operation that can trust it.