Are Your Hotel AI's Guest Requests Reaching the Right Team?

A guest calls at 9 p.m. "The AC in 1214 is blowing hot air." The agent says, "I've let engineering know. Someone will be there in 30 minutes." The call sounds perfect. Then nobody comes. The work order went to room 1240, or to housekeeping, or never got written at all. The guest calls back angry, and the front desk finds out from the guest.

This post is for the product team behind hotel guest-messaging or hotel operations software. You run a voice agent that takes in-stay requests by phone for many properties. Canary Technologies, for example, launched AI Voice in February 2025 to answer calls and handle "a variety of guest needs." Akia launched AI Voice in August 2026, which passes each caller "to the right team member with a short summary." Call it an AI concierge phone line or an AI front desk. The question is the same. Is the hotel guest request AI putting the right ticket in front of the right team?

Our hotels pillar on QA for AI voice agents covers reservations, dates, rates and card capture. Our vacation rental AI phone support guide covers door codes and Wi-Fi. This post goes deep on one call type: guest request routing.

The guest request call is a six-step workflow

Guest request routing: turning a spoken in-stay request into a work order with the right room, department, priority and promised time, then closing it with the guest.

The call is short. The workflow behind it is not. Each step writes something another system or person trusts.

1. Identify. Capture the room number. Verify it against the guest name on the in-house list.

2. Classify. Map the request to a type: amenity, housekeeping, maintenance, front desk, F&B, noise or safety.

3. Route. Pick the department and priority from this property's config.

4. Write. Create the hotel work order in the PMS or work-order system. In Oracle OPERA Cloud, a service request carries a room, a code, a priority and remarks. Amadeus HotSOS takes service requests and orders from partner systems by API.

5. Confirm. Read back the room and request, and give a time the team can meet.

6. Close. Mark the work done and check with the guest.

A towel request touches steps 1 to 5. A broken AC touches all six. Late checkout writes to the reservation itself, not a work order. Room service may create an order in a separate F&B system. A wake-up call sets a timer in the phone system or a task for the desk.

The failures that hurt are silent. The agent sounds confident at every step. The transcript reads clean. The damage shows up only in the work-order queue. That is why tool-argument checks matter more than tone. Our guide to tool-argument accuracy from speech explains the general method.

Six silent failures in hotel service requests

Misheard room number

Room numbers are short digit strings with no checksum. "Twelve fourteen" and "twelve forty" differ by one weak syllable. On 8 kHz phone audio, the "-teen" ending is easy to lose under a TV or a running shower. Hotels also mix styles: "twelve-oh-four," "one-two-oh-four" and "suite 12." Digits are a known weak spot. Chhablani et al. built a digit micro-model with a 1.8% digit error rate, against 5.8% for Whisper. That was clean, task-focused audio, not a noisy hotel room.

Number formatting also hides errors in your metrics. A September 2026 study found that skipping number normalization shifts WER by over two points. That is enough to reorder system rankings. Score the room number as an entity, not as WER. Our post on STT accuracy for names and entities shows how.

Three guards cut this failure:

• Check the in-house list. If 1240 is vacant or the name does not match, re-ask.
• Read back digit by digit. Say "one, two, one, four," not "twelve fourteen."
• Use caller ID when present. A call from a room extension already tells you the room.

Here is the trap. If speech-to-text heard 1240, the transcript says 1240. The ticket says 1240. Both agree, and both are wrong. Only the audio shows the guest said 1214. A transcript-only check passes this call. Our post on transcript vs audio evaluation covers why.

Wrong department

Guests describe symptoms, not departments. "The shower is cold" is engineering. "We need more towels" is housekeeping. "Can I get a crib?" is housekeeping at one property and the front desk at another. "There's a weird smell" could be housekeeping, engineering or a safety issue. An LLM picks the most likely label. It does not know this hotel's rules unless you pass them in.

Wrong-department tickets are not lost. They are slow. Housekeeping opens a ticket for a leaking pipe, walks up, then re-routes it. The guest waited twice.

Urgency downgraded

"There's water on the bathroom floor" can be a spill or a burst pipe. Agents trained to sound calm often file both as normal priority. Test the phrases that should raise priority: "coming through the ceiling," "won't stop," "near the outlet," "my child." Test the reverse too. A guest who says "it's urgent" about extra pillows should not jump the engineering queue.

OPERA Cloud lets each chain define its own service request priority codes. "HIGH" at one brand may be "P1" at another. A priority the agent chose correctly can still land wrong if the code map is stale.

Ticket never created

This is the costliest failure. The tool call times out, returns a 4xx error, or never fires. The agent still says "Done, engineering is on the way." Research now puts numbers on it. Advani's study of false success in LLM agents analyzed 9,876 tau2-bench runs. In single-control domains, 45–48% of failed runs still claimed success. No LLM judge tested beat 0.65 AUROC at spotting them on tau2-bench. The judges keyed on confident closing language, not on state changes.

The lesson for hotels is direct. Do not ask a model whether the ticket exists. Query the work-order system. Our guide to detecting silent tool failures has more patterns.

A promise the team can't meet

"Someone will be there in 15 minutes" is a commitment. If housekeeping has two runners at 9 p.m., housekeeping requests pile up and that promise breaks. Here is a worked example with illustrative numbers. Requests arrive at 12 per hour in the evening peak. Each takes 20 minutes, walking included. Little's law gives L = λ × W = 12 × (20 ÷ 60) = 4 runners busy on average. With two runners on shift, the queue grows all evening. Any fixed "15 minutes" promise is fiction.

The fix is to quote times from property config, by department, priority and hour. Better still, quote a window the system computes from the open queue.

Language and accent

Hotels serve travelers from everywhere. A Spanish-speaking guest may switch to English for the room number. A guest with a strong accent may say "toilet" and get "towel." Our post on accent robustness for voice agents has a testing method. SpokenWOZ shows how hard spoken task dialogue still is. Its best model reached only 25.65% joint goal accuracy on spoken conversations. Test each language you claim, with the room number spoken in each.

Emergencies skip the ticket

Some calls must never become a work order. Smoke, fire, a medical event, a threat or a gas smell go to people now. The agent's job is to say the safety line, alert staff and stay out of the way.

Hotel room phones sit on a multi-line telephone system (MLTS). Two federal rules shape how 911 works on those phones. Kari's Law, codified at 47 CFR 9.16(b)(1), requires that "a user may directly initiate a call to 911 from any station." No "9" prefix. Section 9.16(b)(2) requires notification "to a central location at the facility," such as the front desk. RAY BAUM'S Act rules add "automated dispatchable location" for fixed MLTS phones, required by January 6, 2021. That location can include the room number. The FCC's 2019 order even notes a hotel with one overnight worker can send that alert to a mobile phone.

These rules apply to the hotel's phone system, not to your voice agent. But they shape what the agent should say. A 911 call from the room phone carries the room location and alerts the desk. A call the agent bridges from a cloud number may not. So the safest pattern is simple. Tell the guest to hang up and dial 911 from the room phone. Then page the duty manager. Confirm with your telephony provider what location data a transferred call actually carries. This is a test spec, not legal advice. Check your design with counsel and each property's safety team.

Score these calls on time to the safety line, in seconds. Score whether the staff page fired. Never let the agent ask diagnostic questions first. Our post on escalation accuracy and handoffs shows how to score handoff timing.

Per-property config is where multi-property agents break

One prompt serves hundreds of hotels. Each hotel is different. The agent needs a config record per property:

• Department names and codes. "Engineering," "Maintenance" or "Facilities." HSK or HK.
• Hours. Room service closes at 11 p.m. The spa has no phone desk on Sundays.
• Amenity inventory. Cribs, rollaway beds, irons, phone chargers, extra pillows.
• Response-time targets. By department, priority and hour.
• Policies. Late checkout rules by loyalty tier, and any fee.
• Escalation contacts. Duty manager, security and engineering on call.

Config drift is the quiet killer. A property renames "Maintenance" to "Engineering" in its work-order system. The agent keeps writing to the old code. Tickets land in a dead queue. Nothing errors, because the old code still exists. Run a config probe set against every property after any config change. Our go-live checklist for each new customer's agent covers onboarding a new property.

Late checkout deserves a note. It is not a ticket. It changes the departure time on the reservation. The agent must check the policy and the next arrival before saying yes. If it says "yes, 2 p.m." and never writes it, housekeeping knocks at 11.

The guest request routing test matrix

Build the suite as request families crossed with caller conditions. Eight families and five conditions give 40 core cells. Then add per-property probes.

Run each family under five conditions: clean, accented, noisy (TV, kids, shower), self-correcting ("1214, no, 1240"), and a second language. Add six config probes per property: a closed outlet, an amenity out of stock, a renamed department, after-hours engineering, a room number that does not exist and a checked-out room.

Here is the worked math, with illustrative numbers. Say 300 properties share 12 config templates. Run the 40 core cells on each template: 480 calls. Add 6 probes for every property: 1,800 calls. That is 2,280 calls per full regression.

How many runs prove a cell? If a cell passes n runs with zero failures, the rule of three gives a 95% upper bound of about 3 ÷ n. To claim a failure rate under 1%, you need about 300 clean runs. So run 300 on the cells that matter most: room number capture and emergency escalation. Run 5 to 10 on the rest.

Reconcile every call against the work order

The core check is a join. On one side, what the caller actually asked for, judged from the audio. On the other, what the work-order system holds. Here is a simplified Python reconciler. It assumes each ticket stores the call ID.

from datetime import datetime, timedelta

def reconcile(calls, tickets, sla_min, max_lag=timedelta(minutes=2)):
    by_call = {t["call_id"]: t for t in tickets}
    for c in calls:
        t = by_call.get(c["call_id"])
        issues = []
        if t is None:
            if c["agent_said_done"]:
                issues.append("FALSE_SUCCESS: agent confirmed, no ticket")
        else:
            lag = (datetime.fromisoformat(t["created"])
                   - datetime.fromisoformat(c["ended"]))
            if lag > max_lag:
                issues.append(f"LATE_WRITE: {lag}")
            for field in ("room", "dept", "priority"):
                if t[field] != c[field]:
                    issues.append(f"{field.upper()}_MISMATCH: "
                                  f"call={c[field]} ticket={t[field]}")
        target = sla_min.get((c["dept"], c["priority"]))
        if target is not None and c["promised_min"] < target:
            issues.append(f"PROMISE_TOO_SHORT: said {c['promised_min']}m, "
                          f"team target {target}m")
        print(c["call_id"], "OK" if not issues else "; ".join(issues))

Run on three sample calls, it prints:

c1 ROOM_MISMATCH: call=1214 ticket=1240
c2 FALSE_SUCCESS: agent confirmed, no ticket; PROMISE_TOO_SHORT: said 15m, team target 30m
c3 DEPT_MISMATCH: call=ENG ticket=HSK; PRIORITY_MISMATCH: call=URGENT ticket=NORMAL

Call c1 is the 1214 vs 1240 case. A transcript check would mark it clean. Call c2 is a false success: the agent said "done" and nothing was written. Call c3 sent an urgent leak to housekeeping as normal priority. Each one would have reached the front desk as a complaint.

The same join works for other agentic calls. Our post on home warranty claims AI applies it to coverage decisions.

How to test hotel guest request AI before every release

1. Pull each property's config. Departments, codes, hours, amenities, response-time targets and escalation contacts. Group properties into config templates.

2. Generate scenarios from the prompt and config. Cover all eight request families and every branch, including "out of stock" and "closed." Evalgent generates test scenarios from an agent's prompt and flows, including branches, policies and coverage gaps.

3. Build caller profiles. Vary accent, pace, interruptions, background noise and language. Include self-corrections on room numbers.

4. Call the agent over the real phone path. Use PSTN or SIP, not a text harness. Phone audio is where digits break.

5. Score from the audio and the ticket. Compare what the caller said with what was written. Evalgent judges calls from the audio, not only the transcript, and flags tool-call failures.

6. Gate the release on critical cells. Room number capture, emergency escalation and false success must pass at 100%. Others need a set pass rate.

7. Run config probes after every config change. Not just after prompt changes. Our guide to shipping prompt changes safely covers staged rollouts.

Monitor ticket write-back against the call in production

Pre-release tests cover what you thought of. Production shows what guests actually say. Score every request call, not a sample, because failures cluster at single properties. Our post on scoring every call makes the cost case.

Track these per property, per week. Thresholds below are illustrative starting points, not industry benchmarks.

Why per property? Picture 300 properties, each with 400 request calls a week. A 2% missing-ticket rate means 8 guests a week per hotel waiting for nobody. Fleet-wide, that is 2,400 guests a week. A fleet average can hide one property at 15% after a bad config push.

Alert on three things right away: any false success, any missed emergency page, and a room-match drop at one property. Feed every failure back into the test suite as a new scenario. Evalgent's production monitoring takes pushed call recordings, maps calls to scenarios and flags tool-call failures with fix suggestions. For broader setup, see our guide to monitoring voice agents in production.

Frequently asked questions

How do you test an AI that takes hotel guest requests?

Testing an AI that takes hotel guest requests means calling it over the phone with varied callers and requests. Then compare each call with the ticket it wrote. Cover eight request families under five caller conditions. Add per-property probes for closed outlets, missing amenities and renamed departments. Gate releases on room number capture, emergency escalation and false success.

What happens when a hotel AI mishears the room number?

When a hotel AI mishears the room number, the ticket goes to the wrong door. The transcript and ticket often agree, so text checks miss it. Guard against it by checking the in-house list and name, and reading digits back one by one. Then score room capture from the audio, not the transcript.

Should a hotel AI phone agent handle emergencies?

A hotel AI phone agent should not handle emergencies beyond the first safety line. For smoke, fire, medical events, threats or gas, it should tell the guest to dial 911 from the room phone. Then it should page the duty manager or security. It should never ask diagnostic questions before the safety instruction.

Does Kari's Law apply to a hotel AI phone agent?

Kari's Law applies to the hotel's multi-line telephone system, not directly to the AI agent. Under 47 CFR 9.16, room phones must dial 911 directly and notify a central location like the front desk. That is why the agent should send guests to dial 911 from the room phone. This is not legal advice.

How do you know a hotel AI actually created the ticket?

You know a hotel AI actually created the ticket only by querying the work-order system. Join each call ID to its ticket and compare room, department and priority. Do not trust the agent's "done." Research on tau2-bench found 45–48% of failed runs still claimed success, and LLM judges missed most of them.

Can a hotel AI promise a late checkout?

A hotel AI can promise a late checkout only after checking the property's policy and the room's next arrival. It must then change the departure time on the reservation. A spoken yes with no write-back means housekeeping still knocks at the normal checkout time. Test both approved and denied cases.

How should a hotel AI route maintenance requests?

A hotel AI should route maintenance requests to the property's engineering code with a priority based on the symptom. Leaks through ceilings, sparks or no heat in cold weather go top priority. A dripping tap is routine. Quote a time from that property's response targets, not a fixed number in the prompt.

How do you monitor hotel AI guest requests in production?

Monitor hotel AI guest requests in production by scoring every call against its ticket, per property, each week. Track ticket match, room match, department and priority match, promise feasibility and write lag. Alert at once on false success or a missed emergency page. Turn every failure into a new test scenario.

The bottom line

A hotel guest request is only handled when the right team gets the right ticket for the right room. Test it by reconciling every call against the work-order record, and send every emergency to people first.