This case study focuses on the system behind the interface. I designed and built the guest and staff experiences end to end, while leading the decisions that shaped how the system works: how AI turns conversations into operational requests, routes them across hotel teams, and keeps working through the four kinds of uncertainty that break it.
At its simplest, the experience looks like this: a guest makes a request, AI turns it into something the hotel can act on, and staff handles it.
You call the front desk. They call the kitchen. The kitchen manager passes it to staff. One request, several handoffs. Call back five minutes later, and the whole chain starts over.
International tourism was lower, and enough hotel staff could absorb the repeated communication. Then in 2025, tourism surpassed its all-time record, including every pre-pandemic peak, reaching 1.52B travelers. The growth continued into 2026. Hotels are no longer serving the same volume, or the same diversity, of international guests they did just a few years ago.
To understand how this shift affected day-to-day hotel operations, I interviewed staff members at Samjung Hotel, a four-star business hotel in Seoul. Many international guests walked to the Front Desk with a translation app already open. Service requests now shared the same queue as check-ins and check-outs, creating an operational bottleneck during peak hours.
The hotel manager described staffing shortages as one of their biggest operational challenges, particularly during overnight shifts. This isn’t unique to one hotel. The COVID-19 pandemic drove many hospitality workers into other industries, and despite the rapid return of travelers, hotels have struggled to bring them back. In the US, 65% of surveyed hotels reported staffing shortages in 2025, and the OECD continues to identify labor shortages as a persistent challenge across the hospitality sector.
Task analysis revealed that over one-third of daily front desk operations consists of repetitive guest communication.
These requests were repetitive, language-heavy, and required clear handoffs between shifts. This is exactly where LLMs excel: real-time translation, handling repetition consistently, and keeping automated records.
I sat down with the general manager and a front desk employee at Samjung Hotel on 22 April and walked through how a guest request actually moves through a shift. Two of the things they raised came before I could pitch anything, and both of them changed what I built.
The manager raised this before I could pitch anything. Lower the barrier with a QR code and a chat box and you do not just capture existing demand, you create new demand. Someone pays for the extra bottles of water.
Bottled water and towels, the two items the hotel named as most requested, carry a daily allowance per room. Ordering inside it is frictionless. Crossing it becomes a question the guest has to answer with the surcharge stated, and agreeing once does not carry over to the next request. The barrier was not removed, it was moved to where it belongs. Which items have a limit, and what the limit costs, is configuration rather than a decision baked into the product, because a property would set its own on the way in.
The property management system is where a hotel already keeps guests, rooms, charges and remarks. The manager was blunt that a tool which does not connect to it is not something a hotel would run.
Guest records, room state, menus and billing are modelled as first-class data rather than something bolted on later. Guests sign in with their stay, not an account. Charges post against the room, and checkout resets what the room is holding. It made the build heavier and it is the reason a real hotel could plug this in.
The full study, including what it could not tell me.
No matter how much knowledge existed before launch, guests would inevitably ask questions the AI had never seen before. I prioritized reliable boundaries over maximizing automation. When the AI reaches the limits of what its knowledge can support, it stops rather than filling the gap with an assumption and hands the conversation to the Front Desk. This decision also shaped what happened after the handoff: unanswered questions became opportunities to expand what the AI could handle over time.
Explore the full matrix to see how handoff rules were defined for other operational scenarios.
AI could propose new knowledge, but staff remained the final authority on what became operational truth. Every AI-generated knowledge draft required human approval before entering the knowledge base. This prevented automated updates from introducing errors or contradictions while preserving the hotel-specific context AI couldn’t reliably determine on its own.
Unlike traditional products, AI products don’t receive structured inputs. Guests describe what they want in natural language, where both their intent and the information needed to act may be unclear. I designed the conversation to progressively turn that ambiguity into an actionable request, from understanding what the guest wants to collecting the information required to fulfill it.
Once the guest’s intent was clear, the next challenge was determining what information was actually required to fulfill the request. I defined the minimum information required for each hotel service, creating a clear operational threshold for when a request was ready to proceed.
Explore the information requirements I mapped across hotel services.
A long conversation wasn’t necessarily a failed one. A conversation that stopped making progress was. Some requests naturally required several turns, like a taxi reservation that needed a destination, a departure time, and a passenger count. But repeatedly failing to collect the same information signaled that the conversation was no longer progressing. So I designed the stopping condition around progress, not turn count. Only when the same information remained unresolved across multiple turns did the AI stop asking and offer a handoff to the Front Desk. This let complex requests continue naturally while preventing stalled conversations from falling into repetitive loops.
My first rule stopped after three questions even when a booking was progressing. I changed it to count three attempts at the same missing detail instead.
Human intervention carried a real operational cost. If every unresolved conversation was transferred, staff would end up handling every situation the AI couldn’t resolve, creating more work instead of reducing it. Guests might also be casually exploring a service without ever intending to speak to a person. So I separated “the AI can no longer make progress” from “a human needs to take over.” Depending on the situation, the system could hand off immediately, confirm whether the guest still wanted help, or end the conversation without involving staff.
Explore the criteria I used to decide when to hand off, confirm first, or end the conversation.
Keeping the entire conversation in context meant the model had to process more information with every response, increasing latency and the risk of incorrect assumptions. From a hotel operations perspective, remembering the conversation itself was never the goal. The real challenge was deciding what needed to persist for the system to act correctly as requests evolved. So instead of relying on conversation history as memory, I provided the AI with structured operational context: the guest’s service request history, each request’s current status, and a small window of recent conversation.
Even with the right knowledge, context, and enough information, the AI could still make the wrong operational decision. A request could reach the wrong department, or real-world conditions could make the AI’s original decision no longer appropriate. But an incorrect AI decision shouldn’t automatically become an operational mistake. So I designed the final layer around recovery: catching incorrect decisions before they affected hotel operations, and giving staff the ability to correct them when reality required it.
Rather than relying on AI confidence scores, I gave each department agent one decision: Does this request belong here? If not, it could reject the request, but never choose another department. Every rejected request returned to the Front Desk before another routing decision was made, creating a single recovery path that prevented agents from passing requests back and forth.
The framework didn't come first. It emerged from the decisions I made while designing and implementing the product.
I stopped treating AI uncertainty as one problem and split it into four: what the AI knows, what the guest means, what it remembers, and whether its decision matches reality. Each required a different response: retrieval, conversation design, state, and recovery. There was no single safeguard for “AI uncertainty.”
Building the system revealed how much of the product lived beneath the screen: prompt design, the boundary between deterministic code and probabilistic logic. The interface is where people experience the product; the system is where that experience gets created.
The system's internal logic didn't always match how people understood the task. Replacing a request was technically a cancel-and-recreate flow, but guests experienced it as a single modification. Likewise, departments worked from task queues, while Front Desk worked through conversations. When the system model and the user's mental model diverged, I let the interface follow the person, not the data structure.
I intentionally kept certain decisions human: approving new knowledge, deciding whether an in-progress request could still be cancelled, and authorizing department reassignments. Human involvement wasn't a fallback for AI failure. When a decision required operational context or authority, I designed human judgment into the system from the start.
The architecture was designed for hotel operations, but the underlying problems weren’t hotel-specific: incomplete knowledge, ambiguous intent, fading context, and decisions that can diverge from reality. The same patterns appear wherever AI turns uncertain input into real-world action, from customer support and logistics to healthcare, finance, and enterprise operations.
This project was about how information moves inside a hotel: who has to carry it, what falls out along the way, and what a system has to hold so nobody repeats themselves. Sizing the opportunity is what justified building it. Since it has not run in a hotel, those are still predictions, so they sit here next to the readings that would tell me whether they were right.
Average request handling time
Daily operational work, 200-room hotel
Time from asking to being picked up
Today a request is posted in a group chat, and nobody records when it was read or claimed. Establishing this baseline is the first thing a pilot would do, because every other number is judged against it.
Requests that pass through the front desk
Every request currently goes through one person, who takes the call and relays it. This is the one baseline I can state with confidence, and it is the number the product exists to move.
Handovers typed a second time
Shift notes are written from scratch into a Word file or the remarks field of the property system, separately from the work itself. The briefing is meant to make that a byproduct.
A prediction without a test is a wish. Defining both before launch is the part I could do without a hotel, and if the readings come back against the model, the model was wrong and the design has to answer for it.
Those are readings I would take, not readings I have. This system has never run a real guest's request, and I would rather say that plainly than let a model stand in for evidence.
We did not secure a hotel pilot, so live adoption and operational impact remain untested. That is a fact about this market rather than an obstacle I could design around, and it is worth stating plainly: the barrier to validating an operations product is not the design, it is being trusted with a live shift.
