Pizza Delivery Address AI Errors and Callback Numbers

Pizza delivery address AI errors are the costly kind. A pizza order has forgiving fields. A wrong topping gets noticed at the door. A wrong address does not get noticed until a driver circles the block, or until the pie goes to a stranger. This post covers the part of the call that decides where the food goes and how the store reaches the caller. It does not repeat the toppings side, which we cover in the half-and-half ordering post.

This post is for teams that own the agent. You built phone ordering inside a pizza POS or a multi-store platform, and it is live across many stores. Every prompt change reaches every store that night. You need to know how often the address is wrong, and how to test a change first.

Why a wrong address does not look like an error

On a phone order, the address travels through five hops. The caller speaks. Speech-to-text turns audio into text. The agent extracts fields. Your system validates or stores them. The point-of-sale ticket prints and the driver app opens.

At no hop does anything throw an exception. A wrong house number is still a string. A wrong suffix is still a string. In many builds the POS ticket stores the address as free text unless your integration validates it. The call ends normally and the ticket looks complete. That is how ai order taking address errors survive until delivery.

Three things make phone audio worse than a typed form.

• Narrowband audio. Twilio's Media Streams docs say the payload "must be encoded `audio/x-mulaw` with a sample rate of `8000`" (Twilio WebSocket messages). Narrowband audio strips high-frequency detail, and some of the consonant cues that separate "fifteen" from "fifty" live there. Our phone audio quality guide covers codecs.
• Numbers are short and dense. A word like "pepperoni" has many sounds for the model to lean on. "Fifty" has two syllables, and an accent or kitchen noise can change them.
• Numbers have two spoken forms. "Twenty-one fourteen" and "two thousand one hundred fourteen" are the same house number, and so are "two one one four" and "twenty-one-fourteen."

Researchers at AGH University of Krakow measured how much this formatting matters. In their 2026 paper on number normalization, "twelve twenty-five" can become "1225," and a basic normalizer can turn "10 am" into "10 a m" (arXiv 2609.21084). On a number-heavy Polish parliamentary set, digit versus verbatim references moved WER by 2.17%, and the authors show that this can flip system rankings. The lesson for you is practical. If your eval compares strings, you must normalize first, or you will count formatting as errors and miss real ones.

A 2024 paper trained small digit-only models on up to five-digit numbers resampled to 8 kHz. Its baselines scored 2.9% WER for Google STT configured for numbers, 4.6% for Whisper-Large and 5.8% for Whisper-Small (arXiv 2402.01931). These are word error rates on a mixed test set, not per-call address accuracy. They show that short numbers at telephone rate are not a solved problem. Run your own audio before trusting any vendor figure.

Pizza AI callback number errors are quieter still. A wrong address fails when the driver calls. A wrong callback number fails when nobody can call.

Eight failure classes in spoken addresses and callback numbers

The grid lists the eight classes we would put in any AI phone ordering delivery address test plan. Each has a different cause and fix.

1. Teens versus tens

"Fifteen" and "fifty" differ mostly in stress and in the final consonant. The same holds for 13/30, 14/40, 16/60, 17/70, 18/80 and 19/90. A house number like 1550 contains the pair twice, so a single mishearing gives 5050 or 1515. Both are plausible street numbers.

2. House-number grouping

Callers group digits by habit. "Twenty-one fourteen" is 2114. The risky ones are numbers with a zero: "one oh four two" can arrive as 142 if "oh" gets dropped. The AWS Lex street-address example adds a helper that turns "sixty eight hundred" into 6800 for this reason (AWS Machine Learning Blog, May 2022). Your grouping logic needs the same treatment, plus address normalization before comparison.

3. Street suffix and directional

One ZIP can hold Birch Court, Birch Drive and Birch Circle. USPS standard forms are CT, DR and CIR (USPS Publication 28, Appendix C1). The suffix is the unstressed tail of the phrase. Callers also drop it ("I'm on Birch") or add it wrong. Directionals fail the same way: "North Elm" versus "Elm" can be two different roads.

4. Unit and apartment designators

Can AI handle apartment numbers on phone orders? Often yes, when the caller volunteers a unit number. The failure is the unit that is never asked for. USPS Publication 28 section 213 says a designator such as APT or STE "must be printed on the mailpiece for addresses that include them," and discourages the pound sign when the correct designator is known (USPS Pub 28, section 213). When letters come after numbers, "4B" and "4D" and "4E" collide on a phone line. So do "B" and "3."

5. ZIP and delivery zone

Callers give the ZIP code late, or not at all. Two towns can share a street name. A caller may also sit just outside the zone and not know it.

6. Gate, buzzer and building codes

These arrive as free speech: "buzz 1420 pound" or "call me from the lobby." A gate code or buzzer code is a digit string with no check digit. Nothing can validate it, so read-back is the only defence.

7. Callback number digit swaps

A US number has ten digits, and the first digit of the area code and of the exchange must be 2 through 9 (NANPA). That gives you a free check. A 0 or 1 in either position means the number is invalid, so re-ask. It will not catch a swapped 4 and 7. Callers also say "double five" and "oh" for zero.

8. Read-back that confirms the wrong thing

A read-back only helps when the caller listens. Many callers say "yeah" to anything that sounds like their street. The agent's own speech can fail too: 1550 may be read as "fifteen fifty" or "one thousand five hundred fifty."

Worked math: why digit errors compound

Count the digits on a delivery order: a four-digit house number, a five-digit ZIP and a ten-digit callback number make nineteen. Gate codes add more. Treat each digit as independent with accuracy p. The chance that all n digits are right is p to the power of n.

This is an illustrative model, not a measurement. Real errors cluster on teens, zeros and noisy calls.

Look at the 99% row. That sounds excellent for a speech model. The phone number alone is wrong on about one call in ten. Across the three fields, it is wrong on about one call in six. If a store took 200 delivery calls a week, about 35 would carry at least one wrong digit.

Per-field accuracy hides the problem. Score the call, not the digit, and give every miss a second chance.

What a geocoder can and cannot catch

Spoken address validation turns "15 Birch Ct" into a checked record. Google's Address Validation API is one option, and its docs show the logic well. Start with the `verdict`, which the docs say "should be the first property to evaluate when building address checking logic" (Google, understand a response). Key fields:

• `addressComplete` is true when there are no missing, unresolved or unexpected components.
• `hasUnconfirmedComponents` and `hasInferredComponents` flag parts the API could not confirm or had to guess.
• `validationGranularity` of `PREMISE` or `SUB_PREMISE` "indicates a quality address that is likely deliverable."
• `geocodeGranularity` can be less specific than the validation level.

The last bullet matters for drivers. A verdict can say the address is real while the map pin sits on a street segment. The older Geocoding API describes `ROOFTOP` as a precise result and `RANGE_INTERPOLATED` as "an approximation (usually on a road) interpolated between two precise points," and sets `partial_match` when the geocoder "did not return an exact match" (Google Geocoding docs). Store the granularity with the ticket. A driver given an interpolated pin deserves a hint.

Google's validation-logic page maps the response to four actions: Fix, Add subpremises, Confirm and Accept (build validation logic). A missing unit shows as `subpremise` in `address.missingComponentTypes`. For US addresses, a `uspsData.dpvConfirmation` of `S` also signals a secondary number was expected. The docs carry two warnings worth copying. Accepting without prompting is "at your own risk," and it is good practice to accept the original entry when the customer does not respond to a prompt.

Now the limit. A geocoder checks that an address exists, not that it is the caller's. "50 Birch Ct" and "15 Birch Ct" may both validate. It catches the invented address, not the plausible wrong one. Only the caller can, so read-back matters.

Then the delivery zone check. Test the geocoded point against your polygon, or compute drive distance. Flag points near the boundary, because an interpolated pin can sit on the wrong side. Tell the caller the outcome before the order total.

Read-back design that makes callers catch errors

How does AI confirm a delivery address over the phone without annoying people? Use a chunked read-back with a correction path. Here is how we would design it.

• Collect the ZIP code first. The AWS example can do this and discards any match whose postal code differs from the caller's (AWS blog). It narrows the street names the model must pick from.
• Read numbers digit by digit, with pauses. "One. Five. Zero." beats "one-fifty." In SSML you can use `` for phone numbers and `` between chunks (Google Cloud TTS SSML). A gotcha from that page: without the `google:style` attribute, zero is spoken as the letter O.
• Run a pizza order address confirmation in chunks. Read the unit and suffix as words. "Birch Court, apartment four B, as in boy."
• Ask for correction, not confirmation. "What should I fix?" works better than "Is that right?" because it gets a real answer. Use "Is that right?" for the final pass only.
• Offer the number they are calling from. When your telephony provider passes caller ID, ask "Should we use the number you're calling from?" It removes ten spoken digits from the call.
• Say-spell fallback. The AWS flow restates the street, then spells it by letter, then asks for the number again, then transfers to a person. A fixed escalation ladder beats looping on the same prompt.

The consent angle on confirmation texts

Many stores send a confirmation text or a "driver is outside" message to the callback number. A transcription error texts a stranger. Under 47 CFR 64.1200, automated calls and texts to wireless numbers are tied to the "prior express consent of the called party," and paragraph (m) has a reassigned-number provision (47 CFR 64.1200 at Cornell LII). The text does not address wrong numbers as such.

The FCC also adopted revised revocation rules on September 30, 2026, which take effect 30 days after Federal Register publication (Kelley Drye summary). This is not legal advice, so ask counsel how your texts fit. The engineering point is simple: read the number back before you text it.

How to test pizza delivery address and callback capture

Here is a seven-step protocol. It assumes a live agent you can call over a real phone path.

1. Build a fixture of fictional addresses. Use 40 to 60 records in a test geocoder or a seeded table, not real homes. Include duplicates across suffixes (Birch Ct, Birch Dr), two towns with one street name, units with letters, an apartment number, a gate code and addresses outside the zone.

2. Write the expected record as fields. Store house number, street, suffix, unit, ZIP, zone result and callback number. Never use the transcript as the answer key.

3. Add confusable twins. For each house number, generate the number a mishearing would produce. The sketch below is simplified.

4. Cross with caller conditions. Vary accent, pace, background noise, interruptions and response delay. Run Spanish-accented English and, if you serve them, Spanish and Hindi/Hinglish callers. Add a speakerphone case.

5. Run through the real path. Go through PSTN or SIP, not a text harness. Narrowband audio is half the bug.

6. Score the stored record and the behaviour. Normalize both sides (CT equals Court, digits equal words), then compare field by field. Separately score whether the agent read back, offered a correction path and re-asked an invalid callback number.

7. Gate every change. Re-run the full set when you change the prompt, the STT model, endpointing or the geocoder. Keep a hold-out set you never tune against.

# Simplified: twin house numbers and field-level scoring.
import re

TEENS = {"13": "30", "14": "40", "15": "50", "16": "60",
         "17": "70", "18": "80", "19": "90"}
BACK = {v: k for k, v in TEENS.items()}
SUFFIX = {"court": "ct", "drive": "dr", "circle": "cir", "street": "st"}

def twin_numbers(n: str) -> list[str]:
    out = set()
    for i in range(len(n) - 1):
        pair = n[i:i + 2]
        swap = TEENS.get(pair) or BACK.get(pair)
        if swap:
            out.add(n[:i] + swap + n[i + 2:])
    return sorted(out)          # twin_numbers("1550") -> ["1515", "5050"]

def norm(field: str, v: str | None) -> str:
    s = re.sub(r"[^a-z0-9 ]", "", (v or "").lower()).strip()
    if field == "callback":
        s = re.sub(r"\D", "", s).removeprefix("1")
    if field == "street":
        s = " ".join(SUFFIX.get(w, w) for w in s.split())
    return s.replace(" ", "")

def score(expected: dict, stored: dict) -> dict:
    fields = ("house_number", "street", "unit", "zip", "callback")
    return {f: norm(f, expected.get(f)) == norm(f, stored.get(f)) for f in fields}

Two statistics notes. First, a call is a pass only if every field passes, so report call-level accuracy, as the math above explains. Second, zero failures does not mean zero risk. By the rule of three, 0 failures in 150 clean runs still leaves an upper 95% bound near 2% (3 divided by 150). That is a standard approximation, not a vendor claim. Size the run to the error rate you must rule out.

Where Evalgent fits: it generates test scenarios from your agent's prompt and flows, covering states, branches and hard constraints. Its caller profiles set accent, speech pace, interruption level, response delay, behaviour, background noise and language. It reaches your agent over PSTN, SIP or WebRTC. That covers steps 4 and 5 without hand-building every caller. Evalgent works with teams to set up evals for their first agent, so it is a sales-led engagement, not a self-serve tool.

Judging from audio, not the transcript

There is a trap in step 6. If your judge reads the STT transcript, it reads what the agent already believed. When the caller said "fifty" and STT wrote "fifteen," the transcript, the extracted field and the judge all agree. The call looks perfect.

This is the case for judging from the audio. Evalgent evaluates from the audio, not only the transcript, using an LLM plus Jev as a judge with evidence, and a human can review the verdicts. Its metrics include instruction adherence, hallucination and context retention, and you can add custom metrics that run on every call, such as "agent read the address back before confirming." For address work, the custom metric is the useful one: it checks behaviour, which a transcript match cannot.

What to monitor after launch

Pizza delivery address AI errors need production signals too. Production has no answer key. Use proxies, and audit a sample of real calls.

• Read-back correction rate. How often a caller fixes a field. A jump after a release means capture got worse. A rate near zero may mean the agent skips read-back.
• Geocoder verdict mix. Share of `partial_match`, non-`PREMISE` granularity and `CONFIRM_ADD_SUBPREMISES` outcomes by store and by week.
• Driver contact rate. Calls or texts where a driver reports "can't find it." Join it back to the order.
• Invalid callback captures. Numbers failing the NANP first-digit rule at capture time.
• Audited sample accuracy. Listen to a random slice of calls and compare the stored record against the audio.

Evalgent's production call monitoring takes recordings you push to it, transcribes them, maps each call to a scenario and judges it. It flags tool-call failures, policy failures, PII leakage and latency spikes, with fix recommendations. Set thresholds from your own baseline, not from a blog.

For the delivery-side symptoms that follow, see last-mile driver support and address fixes and where's-my-order calls. For the broader plan, our food ordering QA playbook and the allergy and add-on errors post cover the order side. For entity scoring methods, see STT entity accuracy and testing STT under background noise. The drive-thru version of the same problem is in drive-thru upselling accuracy.

Frequently asked questions

Why does AI get my delivery address wrong?

Speech-to-text hears short numbers and unit letters badly on narrowband phone audio. "Fifteen" becomes "fifty," "4B" becomes "4D," and Court becomes Drive. The record still looks valid, so nothing flags it. Without a chunked read-back and a geocoder check, the error stays in the ticket until a driver cannot find the house.

How to test AI phone ordering for address accuracy?

Build a fixture of fictional addresses with confusable pairs, such as 15 and 50 or Birch Ct and Birch Dr. Call the agent over a real phone path with varied accents and noise. Compare the stored fields, not the transcript, to the expected record after normalizing suffixes and digits. Re-run the set on every prompt or model change.

How does AI confirm a delivery address over the phone?

Good voice AI address capture reads the address back in short chunks, digit by digit, with pauses. It asks the caller what to fix instead of only asking "is that right?" It then validates the address with a geocoder and checks the delivery zone. If anything fails, it re-asks or spells the street before it takes payment.

Can AI handle apartment numbers on phone orders?

Yes, when the agent asks for a unit and reads it back as words, such as "apartment four B, as in boy." The common failure is never asking. A validator can flag a missing `subpremise` so the agent asks. Letters like B, D and E sound alike on phone audio, so confirm them by example.

How to validate a spoken address with a geocoder?

Send the captured fields to an address validation service and read the verdict first. Treat complete addresses at premise or sub-premise level as likely deliverable. Ask for a unit when one is missing, and confirm when components were inferred. Remember validation proves an address exists, not that it is the caller's, so the read-back still matters.

Why does voice AI mishear phone numbers?

Phone calls are 8 kHz audio, and digits are short, similar-sounding words. Callers say "oh" for zero, group digits oddly and speak fast. Formatting also confuses scoring: "twelve twenty-five" and 1225 are the same value. Add a NANP first-digit check and read the number back in three chunks.

How to stop wrong-address pizza deliveries from AI orders?

Layer the defences. Collect ZIP first, read back digit by digit, validate with a geocoder, test the point against the delivery zone, and store the geocode granularity for the driver. Then track read-back corrections and driver contact rate after release. No single check is enough, because plausible wrong addresses pass validation.

What happens when AI takes the wrong callback number?

The store cannot reach the caller about a late order, a missing item or a locked gate. A confirmation text may reach a stranger, which raises consent questions under rules such as 47 CFR 64.1200. Read the number back in chunks and offer the caller ID number. This is not legal advice.

The bottom line

Pizza delivery address AI errors are plausible wrong answers, not invalid ones, so validation alone cannot catch them. Test from audio with confusable address pairs, read back in chunks, and score the stored record against what the caller actually said.