Testing AI Tour Booking: No-Shows, ID Checks, Wrong Units

AI tour booking looks simple on a transcript. So does any self guided tour AI scheduling flow. The prospect asks for a two-bedroom, picks Saturday at 10, and hears "you're all set." The failures live in what happens next. The record says Unit 3B. The access code went out before the ID check cleared. The reminder job never fired. Nobody notices until a prospect stands at a locked door, or a stranger walks into a vacant unit.

This guide is for product teams at self-guided tour software and leasing platforms. Your agent books tours for hundreds of property managers. Each one has its own units, tour rules and verification settings. A single prompt change ships to all of them at once. Below you'll find the six failures that pass a transcript review, a code-release gate, a Fair Housing paired test, a test matrix per property config, and the math that separates real no-shows from booking errors. For the wider program, start with our property management AI answering QA playbook.

What an AI tour booking call actually writes

A tour call is the front door to a four-step workflow. Capture, act, confirm, write back. Each step can fail on its own while the conversation sounds fine.

1. Capture. The agent resolves "the two-bedroom on the corner" to a unit ID. It resolves "Saturday morning" to a date, a time and a time zone.

2. Act. It checks unit availability, holds a slot, and starts identity verification.

3. Confirm. It reads back the booking, then sends a confirmation text. Later it sends a reminder text and, for self-guided tours, an access code window.

4. Write back. It creates or updates the prospect in the leasing CRM, with lead source, unit, tour type and status.

Booking record: the set of fields your system stores after the call. It includes unit ID, floorplan, tour start in UTC, property time zone, tour type, ID status, code status, reminder job ID and CRM record ID.

The booking record, not the transcript, is the thing to grade. A transcript can say "two-bedroom" while the record says 3B. A transcript can say "I've sent your code" while the code service returned an error. Our post on detecting silent tool failures covers that second pattern in depth.

Six failures that look like success on the transcript

Each failure below has three parts: what the caller hears, what the record holds, and what breaks later. All examples are illustrative, built from common booking flows.

Wrong unit: "the two-bedroom" resolves to 3B

Spoken unit labels collide. "Two B" and "three B" blur together on a noisy cell line. "The two-bedroom" is ambiguous when a building has four of them. "Unit 2B" might be a unit number on the second floor or a floorplan code. Many property configs use both.

The agent often picks the first match its search tool returns. The prospect hears "great, the two-bedroom is available Saturday." The record stores 3B, a three-bedroom on a different floor. The prospect tours the wrong home, or the access code opens the wrong door.

Test it by scripting ambiguous references against real unit lists. Use "the two-bedroom," "2B," "two B as in boy," and "the one with the balcony." Pass means the agent asks a clarifying question when more than one unit matches. It must also read back unit number and bedroom count together: "Unit 2B, the two-bedroom on floor two." Our guide to STT entity accuracy explains why short alphanumeric labels fail more often than full words.

Unit no longer available

Availability changes between the search and the booking. Another prospect books the last slot. The property manager marks the unit leased in their system. If the sync job runs every 15 minutes, the agent's view can be 15 minutes stale.

The failure is a booking against a unit that is gone. Test it with a race. Mark the unit unavailable after the agent's availability check and before its booking call. Pass means the booking tool rejects it, and the agent says so and offers another unit or time. Fail means a confirmation text for a home nobody can tour.

Access code sent before ID verification

This is the most serious failure in self-guided tour booking. Self-guided tour software typically gates the lock code behind identity checks. ShowMojo's help center says access codes come after verification: "Once documents are approved, ShowMojo continues with any additional scheduling steps," including code distribution (ShowMojo). Rently's identity provider, Persona, says Rently uses it to confirm the person who signs up is the person who arrives (Persona).

A voice agent can break that order. The prospect says "I already uploaded my license." The agent believes them and calls `send_access_code`. Or the ID check returns `pending`, and the agent reads that as a pass.

The FTC describes why this matters. Rental scammers "may set you up with a self-guided tour to help convince you they're legit." Then "they send you a code (or tell you how to get one) to open a lockbox holding the keys" (FTC). A code released without verification hands that playbook a real key. It also puts an unverified person inside a vacant home.

Wrong day or time zone

"Saturday at 10" has three hidden parts: which Saturday, 10 in which time zone, and 10 under which UTC offset. A leasing platform serving many property managers spans several zones. The prospect might call from Chicago about a unit in Phoenix.

Arizona keeps standard time all year under the state exemption allowed by 15 U.S.C. 260a. A system that assumes Mountain time follows daylight saving time will be an hour off for half the year. Daylight saving time also ends on Sunday, November 1, 2026. A tour booked in October for that morning can store the wrong offset.

Reminder never sent, then a no-show

The agent says "you'll get a reminder text the morning of." The reminder job never gets created. Maybe the tool call timed out. Maybe the phone number was saved without a country code. Maybe the prospect's carrier rejected the message.

Reminders do move attendance. In a Cochrane review of 7 healthcare trials with 5,841 participants, text reminders raised attendance from 67.8% to 78.6% (risk ratio 1.14, moderate certainty) (Cochrane). That is healthcare, not leasing. It still tells you a missing reminder is not a neutral event. When it fails, the prospect's no-show gets blamed on the prospect.

Different answers to different prospects

The agent tells one caller three units are open and another caller only one. It mentions a move-in special to one and not the other. The reason might be noise, model randomness, or a pattern tied to name, accent or family size. Either way, inconsistency is a Fair Housing exposure, covered in its own section below.

The access code gate

The fix for early code release is structural. The agent should never decide on its own that a code can go out. The code tool should check the verification record itself and refuse otherwise.

Here is a simplified server-side gate. It runs inside the tool, not the prompt.

# Simplified example: gate inside the send_access_code tool
from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo

CODE_WINDOW_BEFORE = timedelta(minutes=15)  # property config value

def release_code(booking, verification, now_utc=None):
    now_utc = now_utc or datetime.now(timezone.utc)
    if verification.status != "verified":          # "pending" is not a pass
        return {"ok": False, "reason": "id_not_verified"}
    if verification.booking_id != booking.id:      # no reuse across bookings
        return {"ok": False, "reason": "verification_mismatch"}
    if not booking.unit_available:
        return {"ok": False, "reason": "unit_unavailable"}
    start = booking.start_utc
    if now_utc < start - CODE_WINDOW_BEFORE:
        return {"ok": False, "reason": "too_early", "retry_at": start - CODE_WINDOW_BEFORE}
    local = start.astimezone(ZoneInfo(booking.property_tz))
    return {"ok": True, "unit": booking.unit_id, "local_start": local.isoformat()}

Three test cases matter most. Send `pending` and `failed` statuses and assert `ok` is false. Have the simulated prospect insist "I already verified" and assert no code call happens at all. Then check the spoken response. The agent must not say "your code is on the way" when the tool returned `id_not_verified`. A judge that reads only the transcript catches the third case. Only the tool log catches the first two.

Fair Housing consistency: paired testing for your agent

The Fair Housing Act makes it unlawful "to represent to any person because of race, color, religion, sex, handicap, familial status, or national origin that any dwelling is not available for inspection, sale, or rental when such dwelling is in fact so available" (42 U.S.C. 3604(d)). Section 3604(b) covers discrimination "in the provision of services or facilities." A tour is an inspection. A tour booking agent is making availability statements all day.

Housing regulators have measured this exact failure in humans. HUD's 2012 study ran more than 8,000 paired tests in 28 metro areas. Matched testers asked about the same advertised unit. Black renters were told about roughly 11% fewer available units than white renters. Hispanic renters heard about roughly 12% fewer, and Asian renters about 10% fewer (HUD).

The same method works on an AI agent, and it's cheaper. Run pairs of simulated calls that differ in one attribute only: name, accent, a mention of children, or a mention of a service animal. Keep the unit, date and questions identical. Then compare:

• Units disclosed as available
• Tour slots offered
• Fees, deposits and specials mentioned
• Whether ID requirements were described the same way
• Whether the agent steered toward a different building

Pass means zero factual differences. Wording can vary. Facts cannot. Run each pair at least five times, because model output varies between runs. Our post on AI interviewer bias testing has the same paired design for hiring calls.

One regulatory note. HUD moved to withdraw its 2024 guidance on digital housing advertising in April 2026 (NAHRO). The statute itself did not change. This section is not legal advice; ask your counsel how it applies to your product.

A test matrix per property configuration

Your agent serves many property managers. Their configs differ, so one apartment tour scheduling test suite is not enough. Group configs by the settings that change behavior, then run the failure scenarios against each group.

Rescheduling deserves a note. When a prospect moves a tour, the old code must be revoked. The old reminder must be cancelled. The CRM must show one tour, not two. Many teams test the new booking and forget the cleanup.

Each scenario also needs caller variety. Run it with a fast talker, a caller who interrupts the read-back, a caller on a noisy street, and a Spanish speaker. Evalgent generates scenarios like these from the agent's prompt and flows. It runs them with caller profiles for accent, pace, interruptions and background noise, over phone, SIP or WebRTC. That covers the matrix without a person placing every call.

Separating no-shows from booking errors

Most platforms report a tour no-show rate. Few split it by cause. That hides agent errors inside prospect behavior.

Join each no-show to its booking record and logs. Then sort it into buckets:

• Agent-caused: wrong unit, wrong time or zone, unit unavailable, reminder not created, code not delivered.
• Delivery-caused: reminder created but carrier rejected it, or code text undelivered.
• Prospect-caused: everything confirmed and delivered, prospect didn't come.

Here is a worked example with illustrative numbers, not real data. A portfolio books 1,000 tours in a week. 230 are no-shows, a 23% tour no-show rate. Log joins show 38 had no reminder job, 14 had a stored time one hour off, and 9 were booked on units already leased. That is 61 agent-caused no-shows, or 6.1% of all bookings. Another 11 had a reminder created but undelivered. The prospect-caused rate is (230 − 61 − 11) ÷ 1,000 = 15.8%.

The 6.1 points are engineering work you can fix. Reported as a single 23%, they look like a market problem.

How many calls do you need to measure a wrong-unit rate? Use n = z² × p × (1 − p) ÷ e². If you expect 3% and want ±1 point at 95% confidence, n = 1.96² × 0.03 × 0.97 ÷ 0.01² ≈ 1,118 calls. If you can only score 200 calls, your margin is about ±2.4 points. That's too wide to see a regression from 3% to 4%. This is why scoring a small sample by hand misses small regressions.

In production, Evalgent's call monitoring ingests recordings, maps each call to a scenario and judges it. It flags tool-call failures and policy failures, such as a code tool called before verification, with a fix recommendation. Pair that with your own log join and you have both halves of the no-show picture.

How to test an AI tour booking flow before every release

Run these steps on every prompt, model or flow change. Each step names its pass condition.

1. Pull real configs. Sample property configs from each group in the matrix. Include at least one Arizona property and one with selfie verification enabled.

2. Build the expected record. For each scenario, write the booking record you expect: unit ID, start in UTC, property time zone, tour type, ID status, code status, reminder job and CRM fields.

3. Run simulated calls by phone. Use real audio, not text. Unit labels like "2B" fail in audio long before they fail in text.

4. Diff the record, not the transcript. Compare stored fields to expected fields. Any mismatch on unit, start time or zone fails the call.

5. Assert the code gate. Zero `send_access_code` calls before `verified`. Zero spoken claims that a code was sent when the tool refused.

6. Check reminders and cleanup. Every booking has a reminder job. Every reschedule revokes the old code, cancels the old reminder and leaves one CRM tour.

7. Run paired Fair Housing calls. At least five runs per pair. Zero factual differences in units, slots, fees or ID requirements.

8. Run each scenario more than once. Model output varies. Require every run to pass, not the average.

9. Gate the release. Block the deploy on any code-gate or Fair Housing failure. Track wrong-unit and wrong-time rates against your last release.

Steps 3 to 8 are where a small team runs out of hands. Our guides to scheduling voice agent testing and shipping prompt changes safely go deeper on the harness. The go-live checklist for each new customer covers onboarding a new property manager.

Frequently asked questions

How do you test AI tour scheduling?

Test AI tour scheduling by comparing each simulated call with the booking record it creates. Check unit ID, local date, time and zone, availability, ID status, code release, reminder job and CRM write-back. Run calls over real audio with varied callers. Repeat each scenario several times and require every run to pass.

How do self-guided tours verify identity?

Self-guided tour software usually asks the prospect to upload a government ID, sometimes with a selfie match. Some tools also check a card or phone location. ShowMojo releases access codes after documents are approved. An AI booking agent should read verification status from the system and never accept a caller's word that they verified.

What causes apartment tour no-shows?

Apartment tour no-shows come from two sources. Some prospects simply don't come. Others were set up to fail: wrong unit, wrong time or zone, a unit already leased, or a reminder that never sent. Join each no-show to its booking logs to separate agent-caused from prospect-caused cases.

How to stop self-guided tour fraud?

Self-guided tour fraud drops when access codes depend on verified identity and a valid tour window. Put that check inside the code tool, not the prompt. The FTC reports scammers use self-guided tours and lockbox codes to look legitimate. Test that the agent refuses codes on pending verification, even when callers insist.

Does Fair Housing apply to AI leasing agents?

The Fair Housing Act, 42 U.S.C. 3604, covers availability statements and services in renting a dwelling. It does not exempt automated agents. An AI leasing agent that tells some prospects fewer units are available creates exposure. Run paired test calls that vary one attribute and compare facts. This is not legal advice.

How should an AI agent handle time zones when booking tours?

An AI agent should book tours in the property's time zone, stored as an IANA zone like America/Phoenix. Store the start in UTC, computed for that date's offset. Read back the day, date and local time. Test daylight saving change days and Arizona properties, which keep standard time all year.

What should an AI tour booking write to the CRM?

An AI tour booking should write the prospect's contact details, lead source, unit ID, floorplan, tour type, start time with zone, ID status and booking status to the leasing CRM. Reschedules should update the existing tour, not create a second one. Diff these fields against expected values in every test.

How often should reminder texts go out before a tour?

Reminder timing is a property config choice. Many teams send a confirmation at booking and a reminder the day before or the morning of. What matters more is that the reminder job exists and delivers. Healthcare trials found text reminders raised attendance from 67.8% to 78.6%, so a silent failure costs tours.

The bottom line

AI tour booking fails in the booking record, not the transcript. Test the unit, the time zone, the code gate, the reminder and paired-prospect consistency on every release, and split your no-show rate by cause.