AI in Hospitality — Where the Industry Gets It Wrong

When I discuss AI with hotel professionals, I typically encounter one of two reactions. Either they tell me they already use it — usually meaning a team member pastes guest reviews into ChatGPT and copies the response. Or they tell me they don't trust it, that hospitality is a human business and that guests don't want to talk to machines.

Both responses reflect the same misunderstanding.

The wrong question

The hospitality industry is currently asking: what can AI replace?

This is the wrong question. It reproduces the logic of 1990s automation — identify what humans do, substitute a machine, reduce labor cost. Applied to hospitality, that logic has historically produced call centers that frustrated guests and self-service kiosks that felt cold.

The productive question is different: what operational friction is preventing our teams from being fully present with guests?

This reframing leads somewhere entirely different.

The cost of interruption

To understand where AI creates real value in hospitality operations, it is useful to start with what researchers call cognitive switching cost.

Every time a staff member shifts from one task to another — from preparing a guest room to answering an incoming message, then back — they do not simply lose the time spent on the interruption. They lose the time required to rebuild their cognitive state. Studies on workplace attention document recovery times of approximately 20 minutes after a significant interruption before a worker returns to full task engagement.

In a hotel operation, this pattern repeats dozens of times per day across the team. Incoming messages arrive continuously across WhatsApp, Instagram, email, and booking platforms — and approximately 80% of them are variations of the same questions: check-in time, parking policy, WiFi access, pet rules, late checkout availability.

The mathematical cost is significant. But the less visible cost — the accumulated loss of focus, the cognitive fatigue that builds across a shift — is arguably greater.

The 90% threshold

Research from my information systems course materials and industry deployments points to a critical automation threshold: to meaningfully reduce cognitive load, an AI system must resolve at least 90% of incoming messages autonomously.

Below that threshold, the remaining unresolved exceptions arrive frequently enough to maintain the interruption pattern. Staff continue to switch context. The time saved by automation is cancelled by the cognitive cost of managing exceptions.

Above 90%, the dynamic changes fundamentally. Teams regain blocks of uninterrupted time. The nature of their interaction with incoming communications shifts from reactive to deliberate.

Over several years inviting platforms like HiJiffy to present their work in my information systems course, I have watched this threshold become the central question in every deployment discussion. The platforms that deliver real operational change — the ones where hotel teams report a genuine shift in how their day feels — are consistently the ones that have crossed it. Below 90%, partial automation creates its own friction: staff know the system is handling some messages, but they cannot relax their attention because exceptions arrive unpredictably. The cognitive burden shifts without disappearing.

What infrastructure makes this possible

Effective AI deployment in hospitality requires more than a communication tool. It requires an operational backbone capable of connecting systems and sharing data in real time.

What makes the difference, in practice, is operational connectivity. A guest communication platform that resolves incoming questions autonomously is useful. But if a front desk agent still has to leave the conversation to log into a separate system, call housekeeping, or manually update a reservation, the friction has moved rather than been resolved.

I use platforms like Mews in the classroom to illustrate this — not for their feature lists, but for the question they force students to ask: what does connected actually mean in a hotel operation? The guest sees smoother service. The transformation is invisible to them and entirely real for the team.

This is the principle I emphasize when teaching information systems in hospitality management: effective technology is invisible to the guest. When a system becomes visible — when a guest notices the technology instead of the service — it has failed at the operational level.

The principle that governs everything

There is a rule I apply consistently in operational analysis and in the classroom:

A hospitality organization can never, in front of a guest, attribute a service failure to its own system.

"The computer won't allow it." "The system doesn't let me do that." These are not technical statements. They are organizational failures — evidence that the system was designed without adequate consideration of the service scenarios staff would encounter. The organization built the system. The organization set its constraints. Externalizing responsibility onto the technology in a guest interaction is an abdication of service design.

AI deployment must follow the same principle. Human judgment remains sovereign. The technology exists to support it — never to replace or override it.

Before evaluating any solution

The diagnostic work I do with operational teams follows a consistent sequence.

First, we map the customer journey — every touchpoint from the first moment of awareness through post-stay. This gives the team a shared, visual understanding of the experience they are actually delivering, not the one they assume they are delivering. Gaps become visible quickly.

Second, we build a service blueprint for the moments of truth identified in that journey. The service blueprint separates what the guest sees — the frontstage — from what happens operationally to make it possible — the backstage. It surfaces the processes, the systems, and the handoffs that are invisible to the guest but entirely responsible for whether the experience succeeds or fails.

Only at that point does the question of technology become productive: where in this map is the friction? What is preventing the team from delivering on the promise at this specific moment?

The answer is rarely "we need a chatbot on the website." More often it identifies something precise — a manual handoff between departments, a communication channel generating the same questions every day, a system that forces staff to leave the floor to retrieve information.

Fix that first. The appropriate technology becomes obvious once the friction is correctly located.

Sources

• Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: More speed and stress. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI 2008). ACM.
• Shostack, G. L. (1984). Designing services that deliver. Harvard Business Review, 62(1), 133–139.
• Laudon, K. C., & Laudon, J. P. (2022). Management Information Systems: Managing the Digital Firm (16th ed.). Pearson.