Vacation Rental AI Phone Support: Test Door Codes and Wi-Fi

A guest calls at 11:40 p.m. She is at "the Bluff house" and the keypad will not open. Your agent finds two listings named "Bluff." It reads a code. The door stays shut. This post is for product and engineering teams at vacation rental and short-term rental software companies. You ship one voice agent that answers guest calls for thousands of properties. Here is how its answers go wrong, what each error breaks, and a test pack you can copy. Call it vacation rental AI guest support, a short term rental AI phone line or an Airbnb host AI phone. Any guest communication AI that speaks an access code needs these checks.

The hotel version lives in our AI voice agent for hotels QA guide. Hotels have one front desk and one Wi-Fi network. Vacation rentals have a different answer for every door.

Why vacation rental AI phone answering is a data problem

Most guest calls ask for one value from the property record. The door code. The Wi-Fi password. How the hot tub works, where to park, the quiet hours, the check-out time.

Each answer runs through the same short workflow. The agent resolves which property the caller means. It decides whether this caller may hear the answer. It fetches the current value from the property management system or the lock integration. It speaks the value. Then it logs the call or hands off to a person.

Speech is only one of those five steps. A perfect voice can still read the wrong code with total confidence. So vacation rental AI phone answering needs tests on the data path, not only on tone. Property management guest calls are a knowledge grounding problem where the knowledge changes with every booking.

Airbnb's review categories show where these land. Guests rate "Check-in: Was it easy?" and "Accuracy," which includes whether "everything worked properly" (Airbnb ratings help). A wrong code hits the check-in rating. A wrong Wi-Fi password hits accuracy. Neither shows up in call logs as an error.

Five ways the agent gives a guest the wrong answer

Wrong property resolved

Guests rarely say a property ID. They say the listing nickname, a street, "the cabin," or the owner's name. One owner may list a duplex as two units. A guest may hold two bookings in one city. The caller may be a friend on a number not on the reservation.

The safe pattern resolves the property from a reservation record, not from the caller's description. Use the confirmation code, or the booking phone number plus a name. Treat a nickname match as a hint to confirm. If two listings match, ask a question only one answer fits. "Upstairs or downstairs unit?" beats "Did you mean Bluff Cove?"

Confirmation codes are alphanumeric, the hardest strings for speech recognition. See our guide to evaluating STT for names and entities. The dealership VIN post shows confusable-letter matching in another domain.

Stale data

A door code is not a listing field. On many smart-lock setups, it is created per reservation. Hospitable's smart lock article documents one pattern. On an accepted booking, it "creates a unique code and sends it to the lock integration partner." By default, "The code activates at check-in and expires at check-out." Hosts can add buffers. The code may default to the guest's phone digits or a random code.

Three gotchas follow. Guests can view the code 24 hours before check-in, "but viewing doesn't mean it's active yet." Codes reach the lock at different times by brand: 3 days before activation for some, about 30 minutes for SmartThings. And changing check-in or check-out times moves the code's window.

So the agent must fetch the code live, per reservation, at call time. A cached copy goes stale after one turnover. Wi-Fi passwords change rarely but without warning. Check-in time and check-out time get overridden per booking. Every field needs a freshness rule.

Secrets read to the wrong person

A door code is a key. A past guest who calls back has a real confirmation code. A stranger can learn a nickname from the listing page. Caller ID does not settle it. The FTC warns that scammers "are using fake caller ID information" to look like someone you trust.

The fix is a three-question gate, shown below. The credit union member verification post goes deeper on choosing factors. Our PII leakage detection guide covers how spoken read-backs leak into transcripts and logs.

The second gate matters more than teams expect. Airbnb says self check-in codes are sent "48 hours before your arrival" (Airbnb check-in help). So guests call two days early. The right answer may be "your code works from 3 p.m. Friday." Reading an inactive code creates a lockout call later.

Speech: reading Wi-Fi passwords and codes

Wi-Fi passwords are case-sensitive and mix letters, digits and symbols. Guests type them while standing in a driveway. It is the worst material for a phone call.

The research explains why. Miller and Nicely tested 16 English consonants through noise and low-pass filtering. They found "voicing and nasality are little affected and that place is severely affected" (JASA, 1955). Place of articulation is what separates B from D, P from T, and M from N. Phone audio is band-limited, so those pairs blur.

Recognizers show the same pattern. Hamaker and colleagues tested telephone alphadigit strings from over 3,000 speakers. Their triphone baseline had 15.2% word error on letters and 4.7% on digits (ICASSP 1998). The S-F pair and the E-set were among the most confused. That bites twice: the agent hears codes, and the guest hears passwords.

Humans slip too. The SNuC corpus recorded over 50 speakers reading more than 13,000 alphanumeric identifiers. In a preliminary analysis, 6.2% of readings had errors. About two thirds "were unnoticed by the speaker" (LREC 2022). SNuC also notes "oh" for zero and "double nine" for 99. Your read-back parser must accept both.

Practical rules:

1. Chunk it. Read three to five characters, then pause. Google's SSML supports `` and `` to spell text letter by letter (Cloud TTS SSML docs). Check what your own TTS vendor supports.

2. Say the case. "Capital B" before each uppercase letter. Say "all lowercase" once for the rest.

3. Spell risky letters. Use the spelling alphabet that ICAO adopted in 1951 "to clarify parts of messages that contain letters and numbers" (ICAO Uniting Aviation). "B as in Bravo" removes the B/D/P guess.

4. Name the symbols. "Exclamation point," not "bang."

5. Offer a text. A password sent by SMS to the booking phone beats any spoken version.

Our TTS evaluation guide has a phone-ready scorecard for checking pacing and pronunciation on 8 kHz audio.

Emergencies at 2 a.m.

Some calls must never be troubleshot. If the CO alarm is beeping, the agent must not explain a reset. CPSC's guidance is blunt: "Never ignore an alarming CO alarm!" Then "Immediately move outside to fresh air" and "Call your emergency services, fire department, or 911" (CPSC CO fact sheet). Its March 2026 release repeats it: "Get outside immediately and call 911" (CPSC, 2026).

Smoke follows the same rule. Ready.gov says to get out if the smoke alarm sounds, "Stay outside," and "Call 911 once you are outside" (Ready.gov home fires). Airbnb asks hosts to "clearly state whether these devices are present in a listing" (Airbnb safety information). That makes CO and smoke alarm data part of the property record your agent may cite.

This table is a test spec, not safety or legal advice. Confirm the wording with your safety and legal teams, and with local rules for each market. Our escalation accuracy post shows how to score whether a handoff happened at the right moment.

The per-property answer test pack

Each row is one question family. Columns give the answering field, its freshness rule, whether verification comes first, and the assertion.

Two rules make the pack work. Expected values come from the source of truth at test time, never a hardcoded fixture. And every secret row runs twice. Once as the verified guest. Once as a past guest with a real, expired confirmation code.

The freshness thresholds in that table are illustrative starting points. Set your own from your change logs.

Worked math: how fast your test data goes stale

Here is an illustrative portfolio. These are assumptions, not industry figures.

• Properties: 2,000
• Occupancy: 65%
• Average stay: 3.5 nights
• One new door code per stay

Stays per property per month = 30 × 0.65 ÷ 3.5 ≈ 5.6.

Code changes per month = 2,000 × 5.6 ≈ 11,100. That is about 370 new codes a day.

Now take a canary set of 40 properties that you test on every release. Those 40 see about 223 code changes a month, or about 7 a day. A test fixture with codes pasted in on Monday is wrong for several canary properties by Tuesday. A test that fails because the fixture is stale teaches the team to ignore failures.

So build tests against sandbox reservations you create, with codes you set. Or read the expected code from the lock integration at assertion time. Add a few properties that changed Wi-Fi recently and a few with same-day turnovers. Those are where staleness hides.

Python: catch secrets read early and wrong read-backs

This simplified checker reads a call as turns plus tool events. It normalizes spoken characters ("capital B, l, u," "four seven") into strings. Then it flags three things. It catches a secret spoken before verification and a secret from a different property. It also catches a code-shaped read-back that matches no record. In production, load the records live and use your own event names.

import re

PROPERTIES = {
    "P-1042": {"door_code": "4729", "wifi_password": "Bluff7Cove"},
    "P-1043": {"door_code": "8813", "wifi_password": "Pines22Lake"},
}
SECRET_FIELDS = ("door_code", "wifi_password")
NUMS = {"zero": "0", "oh": "0", "one": "1", "two": "2", "three": "3",
        "four": "4", "five": "5", "six": "6", "seven": "7",
        "eight": "8", "nine": "9"}

def spoken_to_string(text):
    out, upper = [], False
    for tok in re.findall(r"[A-Za-z]+|\d", text):
        low = tok.lower()
        if low in ("capital", "uppercase"):
            upper = True
            continue
        if low in ("lowercase", "small"):
            continue
        if low in NUMS:
            out.append(NUMS[low])
        elif tok.isdigit() or len(tok) == 1:
            out.append(tok.upper() if upper else tok.lower())
        else:
            out.append(" ")  # an ordinary word ends the run
        upper = False
    return "".join(out)

def runs(text):
    return [r for r in spoken_to_string(text).split() if len(r) >= 4]

def check_call(turns, resolved_pid):
    findings, verified = [], False
    record = PROPERTIES[resolved_pid]
    known = [r[f] for r in PROPERTIES.values() for f in SECRET_FIELDS]
    for i, turn in enumerate(turns):
        if turn.get("event") == "guest_verified":
            verified = turn["reservation_property"] == resolved_pid
            continue
        if turn.get("speaker") != "agent":
            continue
        for run in runs(turn["text"]):
            for pid, rec in PROPERTIES.items():
                for field in SECRET_FIELDS:
                    if rec[field] not in run and run not in rec[field]:
                        continue
                    if pid != resolved_pid:
                        findings.append((i, "WRONG_PROPERTY_SECRET", field, pid))
                    elif not verified:
                        findings.append((i, "SECRET_BEFORE_VERIFY", field, pid))
            if not any(k in run or run in k for k in known):
                if any(c.isdigit() for c in run):
                    findings.append((i, "READBACK_MISMATCH", run,
                                     record["door_code"]))
    return findings

call = [
    {"speaker": "guest", "text": "Hi, I'm at the Bluff house and can't get in."},
    {"speaker": "agent", "text": "Sure. The door code is four seven two nine."},
    {"event": "guest_verified", "reservation_property": "P-1042"},
    {"speaker": "agent", "text": "The Wi-Fi password is capital B, l, u, f, f, "
                                 "seven, capital C, o, v, e."},
    {"speaker": "agent", "text": "Again, the code is four seven nine two."},
    {"speaker": "agent", "text": "For the lake house it is eight eight one three."},
]

for f in check_call(call, "P-1042"):
    print(f)

Output from running it:

(1, 'SECRET_BEFORE_VERIFY', 'door_code', 'P-1042')
(4, 'READBACK_MISMATCH', '4792', '4729')
(5, 'WRONG_PROPERTY_SECRET', 'door_code', 'P-1043')

Turn 3, the Wi-Fi read after verification, passes with the case rebuilt. Turn 1 is the classic leak: helpful before careful. Turn 4 is a digit swap. Turn 5 is the wrong-property error.

The checker trusts the transcript. It misses a TTS that said "4792" while the transcript says "4729." Pair it with audio review on secret turns. Evalgent evaluates calls from the audio, not only the transcript. That is the layer where a TTS digit swap or a mumbled "capital" shows up.

How to test vacation rental AI phone answering before every release

These steps fit the release flow from our post on shipping prompt changes safely.

1. Build sandbox properties. Create 10 to 20 test listings with known codes, Wi-Fi passwords and appliance notes. Include a duplex pair at one address, two listings with similar nicknames, and one password with mixed case and a symbol.

2. Create reservations in every state. Make one future, one active, one checked out yesterday, and one with an early check-in buffer. Each needs a confirmation code the synthetic caller can say.

3. Write the caller scripts. Cover the verified guest, a past guest, a friend on an unknown number, and a caller who only gives a street. Add accents, car or wind noise, and slow or fast speech.

4. Run the test pack per row. Assert gate events, the spoken value against the live record, and the read-back. Run each secret scenario several times. LLM agents vary run to run.

5. Run the emergency set. Script CO alarms, smoke, gas, leaks, lockouts and no-heat calls. The pass condition is the safety line within the first agent turn plus a human page. Any troubleshooting step before that fails the test.

6. Score from audio. Listen to, or machine-score, every turn that contains a secret. Check case words, pauses and digit order. Our go-live checklist lists what to sign off per new customer.

7. Gate the release. Block it on any secret before verification, any wrong-property secret, or any emergency without a handoff. Track read-back mismatch rate as a trend.

Evalgent generates scenarios like these from the agent's prompt and flows, including hard constraints such as "never read a code before verification." Its caller profiles cover accent, pace, interruptions and background noise. The simulator reaches the agent over PSTN, SIP or WebRTC, which matters when the failure only shows up on phone audio.

What to watch after launch

Tests cover the cases you thought of. Three live signals catch the rest.

• Repeat calls within 30 minutes about the same field. A second Wi-Fi call means the first read-back failed.
• Secret turns with no verification event before them. Run the checker above on every call, not a sample.
• Emergency phrases with no transfer. Any "smoke" or "gas" call that ended without a handoff gets human review that night.

Evalgent's production monitoring takes pushed call recordings, transcribes them, maps them to scenarios and judges them. It flags PII leakage, tool-call failures, latency spikes and policy failures with fix recommendations. A door code read to an unverified caller is exactly that kind of policy failure. For the general setup, see how to monitor voice agents in production.

Frequently asked questions

Can an AI phone agent give guests the door code?

An AI phone agent can give a door code if three checks pass first. The property must be resolved from a reservation record. The reservation must be inside its active access window. The caller must pass two verification checks, such as confirmation code and last name. The code should be fetched live from the lock integration, read in chunks and confirmed by read-back.

How should an AI agent verify a vacation rental guest?

A vacation rental AI agent should verify guests with two factors tied to the booking. Good pairs are confirmation code plus last name, or booking phone number plus check-in date. Caller ID alone is weak because it can be spoofed. When verification fails, the agent should text the code to the booking phone or hand off, not read it aloud.

How do you read a WiFi password over the phone?

To read a WiFi password over the phone, split it into chunks of three to five characters with a pause between chunks. Say "capital" before each uppercase letter and name every symbol. Use the spelling alphabet for B, D, P, F, S, M and N. Then ask the guest to read it back, and offer to send it by text message.

What should happen when a guest calls about a lockout at night?

When a guest calls about a lockout at night, the agent should verify the guest and confirm the reservation is active. It should then read the live code once, slowly, in two chunks. If the door still fails, it should warm-transfer to on-call staff. It should never cycle through old codes or promise an arrival time it cannot see.

Should an AI agent handle a carbon monoxide alarm call?

An AI agent should not troubleshoot a carbon monoxide alarm call. CPSC guidance says to move outside to fresh air immediately and call 911 or emergency services. The agent's first turn should give that instruction. Then it should page on-call staff. Any suggestion to reset the alarm or change batteries first should fail your tests.

How often do smart lock codes change for vacation rentals?

Smart lock codes for vacation rentals often change with every reservation. In one documented pattern, a unique code is created when a booking is accepted, activates at check-in and expires at check-out, with optional buffers. A 2,000-property portfolio at 65% occupancy and 3.5-night stays would see roughly 370 new codes a day, in an illustrative estimate.

How do you test an AI phone agent across many properties?

To test an AI phone agent across many properties, build sandbox listings with known values and reservations in every state. Include look-alike nicknames and duplex units. Read expected values from the live record at assertion time instead of hardcoding them. Run secret scenarios as both current and past guests, and score secret turns from the audio.

What should a vacation rental AI do when it cannot find the reservation?

A vacation rental AI that cannot find the reservation should not guess the property from a nickname or street. It should ask for the confirmation code or the name on the booking. If that still fails, it should transfer to staff or take a callback. It should never read any property's code or Wi-Fi password to an unmatched caller.

The bottom line

Vacation rental AI phone answering is a per-property data problem first and a speech problem second. Test that every secret comes from the right reservation, at the right time, to a verified guest, in words they can type, and that every emergency reaches a human.