AI Interview Scheduling Errors Across Many Locations

Last verified October 18, 2026. Regulatory status, API behavior and statistics are dated where they can change.

Your AI phone agent books interviews for employers with hundreds of stores. The call sounds fine. The candidate says "great, see you Thursday." Then nobody shows up, or the candidate shows up at the wrong store. Nobody connects the no-show back to the call. This post is for the product and engineering team at a high-volume hiring platform that built that agent. It covers where the booking breaks, how to test it per location, and how to monitor it once it is live.

What an AI interview scheduling call actually writes

An AI interview scheduling call is the front door to a workflow. The agent captures intent, resolves a location, checks a calendar, books a slot, confirms aloud, schedules reminders and writes back to the ATS. The conversation is maybe 90 seconds. The record it leaves behind drives everything after.

Booking record: the structured object your scheduler writes after a call. It holds location ID, time zone, start time, interviewer, interview type, reminder plan and ATS stage. Every field is a place where a speech error can land.

The danger is that each field can be wrong while the call transcript looks perfect. The agent said "Store two twenty-one on Main Street." The candidate said "yes." The calendar invite went out. Every system reports success. That is why silent tool failures matter more in scheduling than almost anywhere else.

If you have read our hiring pillar on AI phone screening QA, you know the screen itself has its own failure modes. Our guide to AI phone screeners for hourly workers covers the knockout questions. This post starts where the screen ends: the moment the candidate passes and the agent says "let's get you an interview."

Seven interview scheduling errors that reach live candidates

These are the failures that show up in hourly hiring for QSR franchises, retail chains, warehouses and home care agencies.

Wrong location

This is the error candidates feel first, standing at the wrong door. Store numbers collide in speech. "Two twelve" and "two twenty-one" share most of their sounds. "Main Street" exists in two towns in the same franchise group. A candidate who applied to #212 may mention #221 because it is closer to home. The agent then books the wrong store with full confidence.

Time zone at border stores

Franchise groups often span a time zone line. The agent resolves "Thursday at 2" in the wrong zone. The manager expects the candidate at 2:00 Central. The invite says 2:00 Eastern. One of them waits an hour.

Manager off or double-booked

Hiring managers in frontline roles work shifts. Their calendar often lags the schedule. The agent books a slot the calendar shows as free. The manager is off that day or already interviewing someone else.

Reminder never sent

The reminder job is created after the booking. If the booking write retries, the reminder can be lost. If the candidate's number is flagged as opted out, the reminder can be suppressed with no trace. The candidate forgets, and the record says "no-show."

Reschedule cancels the wrong slot

The candidate calls back to move the interview. The agent finds "the interview" by phone number. That number has two bookings, or it belongs to a shared family phone. The agent cancels the wrong one.

Wrong interview type and stale ATS stage

Some roles need an in-person interview. Others use a phone or video interview. The agent confirms "video" but the template sends an address. Separately, the ATS write-back fails and the candidate stays in "Applied." A recruiter then calls to schedule an interview that already exists.

Location resolution: why Store #212 becomes #221

Location errors start in speech recognition and finish in your lookup logic. Numbers are short, low-redundancy tokens. A language model can fix "recieve" to "receive" from context. It cannot know whether "two twelve" or "two twenty-one" is right. Both are valid store numbers.

Noise makes this worse. Candidates call from a car, a bus or a break room. Our guide to testing STT with background noise covers how to build those conditions. Accent matters too. Koenecke et al. tested five commercial ASR systems on 19.8 hours of audio. They found an average word error rate of 0.35 for Black speakers versus 0.19 for white speakers (PNAS, 2020). A store number is one or two words. One error there changes the whole booking.

The fix is a resolution rule, not a better model. Treat the applied store as the default. Treat any spoken store number as a claim to verify. Never confirm a location by number alone. Read back the street and the town.

# Simplified location resolver. Not production code.
def resolve_location(applied_store, spoken_number, spoken_street, stores):
    """Return (store, action). action is 'confirm' or 'clarify'."""
    if spoken_number is None and spoken_street is None:
        return applied_store, "confirm"          # default to where they applied

    candidates = [s for s in stores
                  if s.number == spoken_number
                  or (spoken_street and spoken_street.lower() in s.street.lower())]

    if len(candidates) == 1 and candidates[0].id == applied_store.id:
        return applied_store, "confirm"
    if len(candidates) == 1:
        # Different store than the application: never silently switch.
        return candidates[0], "clarify"          # read back street + town, ask yes/no
    return None, "clarify"                       # zero or many: ask for town or cross street

# Confirmation line the agent must say, built from the record, not the transcript:
# "That's the store at 410 Main Street in Springfield, Ohio. Is that right?"

Two details matter here. First, the readback must come from the resolved record, not from what the agent heard. Otherwise a wrong lookup gets read back in the candidate's own words and sounds correct. Second, a changed store should trigger a requisition check. The candidate may be moving to a store with no open role.

Time zones at border stores

Time zone bugs hide in "obvious" defaults. The most common one uses the candidate's area code or the employer's head office zone. Both are wrong for a border store. The interview happens at the store, so the store's zone is the only one that counts.

The US zone lines are set in federal rules. The eastern and central zone boundary in 49 CFR 71.5 runs through Indiana, Kentucky, Tennessee, Georgia and Alabama. The IANA time zone database splits Indiana into several zones. `America/Indiana/Indianapolis` is Eastern. `America/Indiana/Knox` is Central. Arizona's `America/Phoenix` has no daylight saving time.

That last one produces a seasonal bug. We ran the conversion below with Python's zoneinfo module.

from datetime import datetime
from zoneinfo import ZoneInfo

def to_utc(local_iso, store_tz):
    return datetime.fromisoformat(local_iso).replace(tzinfo=ZoneInfo(store_tz)).astimezone(ZoneInfo("UTC"))

for day in ["2026-10-22T14:00", "2026-11-05T14:00"]:
    print(day, to_utc(day, "America/Phoenix").time(), to_utc(day, "America/Denver").time())
# 2026-10-22T14:00 21:00:00 20:00:00   <- differ by one hour before Nov 1
# 2026-11-05T14:00 21:00:00 21:00:00   <- identical after daylight saving time ends

A test run in November passes. The same booking logic fails in March. Store each location's IANA zone in the location record. Never store a fixed offset like "-07:00."

Calendar APIs add one more trap. Microsoft Graph's getSchedule returns start and end times in UTC unless you send a `Prefer: outlook.timezone` header. If one code path sends the header and another does not, free/busy and booking disagree by hours. Our post on tool argument accuracy shows how to assert on these arguments in tests.

Hiring manager availability, reschedules and the wrong-slot cancel

Hiring manager availability is the field your agent can least verify. The calendar says free. The manager may be off, covering a shift or sharing interview duty across two stores. Three checks catch most of it:

• Working-hours check. Graph returns `workingHours` with each schedule. Reject slots outside them, even if the calendar is empty.
• Hold-then-book. Place a tentative hold, re-read free/busy, then confirm. This catches two agents booking the same hour.
• Shared-manager check. A district manager who interviews for three stores has one calendar. Check it once, not per store.

Reschedules need stable identifiers. The iCalendar standard, RFC 5545, gives each event a persistent `UID` and a `SEQUENCE` revision number. A reschedule should update the same UID and bump the sequence. It should never search by phone number and delete the first match.

Our rule is simple. The agent reads back the booking it will change before it changes it. "I see your Thursday 2 PM interview at the Main Street store. Move that one?" If the phone number maps to two bookings, it asks which one. Then the write uses the booking ID, with an idempotency key so a retry cannot cancel twice.

Interview reminders and the TCPA

Interview reminders are outbound calls or texts. If an AI voice places them, the TCPA applies. In February 2024 the FCC ruled that AI-generated voices are "artificial" voices under the TCPA (FCC 24-17). Under 47 CFR 64.1200(a)(1)(iii), artificial or prerecorded voice calls to wireless numbers need the called party's prior express consent. Telemarketing needs prior express written consent under (a)(2). A pure interview reminder is informational. A reminder that pitches a referral bonus may not be.

Opt-out rules changed this fall. On September 30, 2026, the FCC adopted FCC 26-67. It replaces the 2024 "revoke-all" rule. An opt-out from an informational call may be scoped to that category of message. Callers may also name exclusive opt-out methods, such as a key press or a reply word, if they disclose them. The deadline to honor an opt-out stays at no more than ten business days. Earlier, DA 26-12 had delayed revoke-all to January 31, 2027. As of our last check in October 2026, FCC 26-67 had not yet been published in the Federal Register. It takes effect 30 days after publication.

For testing, that means four things. The agent must capture "stop calling me" in any phrasing and in Spanish. The opt-out must suppress the right category. The reminder must go out in the candidate's local hours. And a suppressed reminder must leave a visible trace on the booking, so a no-show can be explained. This is not legal advice; check your consent flows with counsel. Our speed-to-lead TCPA guide covers consent capture in more depth, and our sibling post on shift confirmation calls covers outbound confirmation for employees who are already hired.

Noisy calls and Spanish-speaking candidates

Frontline candidates rarely call from a quiet office. They call between shifts, on speakerphone, often with kids or traffic nearby. Many also prefer Spanish. In 2025, Hispanic or Latino workers held 30.1% of food preparation and serving jobs and 39.2% of cook jobs, per the BLS Current Population Survey. That is ethnicity, not language preference. It still tells you your Spanish path is not an edge case.

Spanish-speaking candidates break scheduling in specific ways. Numbers get said as "doscientos doce." Days shift with "el jueves que viene." Code-switching mixes "Main Street" into a Spanish sentence. Reminders often go out in English by default. Our guide to testing multilingual handling covers language detection and mid-call switching.

Test the full loop in Spanish: booking, readback, reminder, reschedule and opt-out. A Spanish booking with an English reminder is a likely no-show. Evalgent's caller profiles combine language, accent, speech pace, interruptions and background noise. That lets you run the same booking scenario across conditions instead of one clean English call.

A test matrix across location configurations

Most teams test one store. The bugs live in the configurations. Build your matrix from your customers' location data, not from your demo account. A platform serving many employers should treat each configuration as a test fixture, as described in our post on multi-tenant voice agent testing.

Run each row with at least three caller conditions: clean, noisy and Spanish. That gives 24 scenarios before you add reschedules. Evalgent generates scenarios from your prompt and flows, including branches and coverage gaps. It calls the agent over PSTN, SIP or WebRTC, the way a real candidate would.

Every assertion should check the record, not the transcript. Did the booking land on the right store ID? Is the UTC start right? Does the ATS stage say "Interview scheduled"? Our appointment scheduling testing guide has more booking assertions you can reuse.

Monitoring show rate by location against booking errors

Show rate is the metric your customers care about. It is also a slow, noisy signal. Here is a worked example with illustrative numbers.

Say Store #221 booked 40 interviews last month and 26 candidates showed. That is a 65% show rate. The 95% Wilson interval is roughly 49.5% to 77.9%. A network average of 75% sits inside that interval. You cannot tell if #221 has a problem.

To detect a drop from 75% to 65% with 80% power at α = 0.05, you need about 329 bookings per group:

n = (z_a * sqrt(2 * p_bar * (1 - p_bar)) + z_b * sqrt(p1(1-p1) + p2(1-p2)))^2 / (p1 - p2)^2
  = (1.96 * sqrt(2 * 0.70 * 0.30) + 0.8416 * sqrt(0.75*0.25 + 0.65*0.35))^2 / 0.10^2
  ≈ 329 bookings per store

Most stores never reach that in a quarter. So do not wait for show rate to move. Pair it with per-call booking-error flags. A judge that reviews each call can flag a store switch without readback, a missing reminder or a reschedule without a named booking. Three flagged calls at one store is a lead you can act on this week.

The quadrant tells you where to look. Low show rate with many booking-error flags points to the agent. Low show rate with few flags points to the store, the role or the pay. High show rate with many flags often means managers quietly fix errors by hand. That costs them time, and it will surface later.

Evalgent's production call monitoring takes your call recordings, transcribes them, maps them to scenarios and judges them. It flags tool-call failures and policy failures with fix recommendations. Every flagged call can become a regression test, as described in our post on turning production failures into tests.

How to test AI interview scheduling before every release

1. Export your location configurations. Pull store numbers, street names, towns, IANA zones and interview types for every employer. Flag adjacent numbers and duplicate street names.

2. Write assertions on the record. For each scenario, define the expected store ID, UTC start, interviewer, interview type, reminder job and ATS stage.

3. Build caller conditions. Run clean, noisy and Spanish callers at minimum. Add fast speech and interruptions for store numbers.

4. Test both daylight saving seasons. Use one date before and one after the November change for every border and Arizona store.

5. Test reschedules and cancels. Include a phone number with two bookings. Assert that the other booking is untouched.

6. Test reminders and opt-outs. Assert that the reminder exists, fires in local hours, uses the candidate's language and stops after an opt-out.

7. Gate the release. Block any prompt or flow change that drops pass rate on the location rows. Compare against the last release, not against zero.

8. Monitor per location after launch. Track show rate and booking-error flags by store. Turn each confirmed error into a new test.

Frequently asked questions

Why do AI interview schedulers book the wrong location?

AI interview schedulers book the wrong location because store numbers and street names collide in speech. "Two twelve" and "two twenty-one" sound alike, and "Main Street" exists in many towns. The fix is a resolution rule: default to the applied store, verify any spoken change, and read back street and town from the resolved record before booking.

How do you test AI interview scheduling across many locations?

Testing AI interview scheduling across many locations means building a matrix of location configurations, not testing one demo store. Include adjacent store numbers, duplicate street names, border time zones, Arizona stores, shared managers and mixed interview types. Run each with clean, noisy and Spanish callers, and assert on the booking record, not the transcript.

How should an AI scheduler handle time zones for interviews?

An AI scheduler should use the store's IANA time zone for in-person interviews, never the candidate's area code or a fixed offset. Store the zone in the location record. Convert to UTC once, at booking. Test dates before and after daylight saving changes, because Arizona and border stores shift relative to their neighbors.

Do interview reminder calls need consent under the TCPA?

Interview reminder calls using an AI or prerecorded voice to a cell phone need the candidate's prior express consent under 47 CFR 64.1200(a)(1)(iii). The FCC treats AI voices as artificial voices. Reminders that include marketing need written consent. FCC 26-67 lets informational opt-outs be scoped by category. This is not legal advice.

What happens when an AI reschedules the wrong interview?

When an AI reschedules the wrong interview, the agent cancels a booking it was not asked to touch. That can strand a second candidate or a family member sharing the phone. Prevent it by reading back the exact booking before changing it, writing by booking ID, and using an idempotency key so retries cannot cancel twice.

Can an AI phone agent schedule interviews in Spanish?

An AI phone agent can schedule interviews in Spanish if the whole loop runs in Spanish. That includes number capture, date phrases like "el jueves que viene," readback, reminders, reschedules and opt-outs. The common failure is a Spanish booking followed by an English reminder. Test code-switching too, since street names often stay in English.

How do you measure interview show rate by location?

Interview show rate by location is shows divided by booked interviews per store. Small stores have wide confidence intervals: 26 of 40 gives roughly 50% to 78%. Detecting a ten-point drop needs about 329 bookings per group. Pair show rate with per-call booking-error flags so you can act before the statistics settle.

What should an AI interview scheduler write back to the ATS?

An AI interview scheduler should write back the booking ID, store ID, UTC start time, interviewer, interview type, reminder status and stage change to the applicant tracking system. It should also log consent and opt-out status. A failed write-back leaves the candidate in "Applied," and a recruiter may call to book an interview that already exists.

The bottom line

Most AI interview scheduling errors are correct-sounding calls that write the wrong store, time, manager or booking into the record. Test every location configuration with real caller conditions, assert on the record, and watch booking-error flags by store instead of waiting for show rate to move.