Email capture fails because errors compound. At the 96.6% per-token accuracy a baseline recogniser scored on an industrial partner’s spoken alphanumeric identifiers in the University of Sheffield’s SNuC study, a 22-token address like [email protected] survives intact 46.7% of the time. ITU-T G.711 samples the phone channel at 8000 samples per second, which deletes the frequencies that separate S from F.
Two things go wrong at once and teams usually fix only the second. First, physics: a narrowband codec throws away the spectral region that separates the confusable letters. Second, arithmetic: whatever per-token accuracy survives is raised to the power of the number of tokens in the address. Coval’s benchmark, published in AssemblyAI’s Voice Agent Accuracy Report, puts the best of 28 pooled models at 3.2% word error rate in a field averaging 6.7%. Neither end is close to what whole-address capture needs.
Why my AI agent keeps getting the email address wrong
A recogniser transcribing ordinary speech is not listening character by character. It is predicting. Speechmatics puts the mechanism in one line: “‘for two’ beats ‘for too’ because the surrounding context makes it more probable.” Spell an email address and that advantage disappears.
The authors of the SNuC corpus — Emma Barker, Jon Barker, Robert Gaizauskas, Ning Ma and Monica Lestari Paramita at the University of Sheffield, published at LREC 2022 — put it precisely. Absent an organisation-specific grammar, “the probability of each possible alphanumeric sequence is equivalent. In the case of a 10 character sequence, say, this would be equal to 1/3610. I.e. language models play no role at all, making recognition extremely challenging.”
They name the confusable set too: “The set of spoken forms of English letters contains many highly confusable words pee vs bee, em vs en, tee vs dee, see (c) vs zee, which vary by a single phoneme, or even by a single phonetic feature (e.g., presence or absence of voicing within a single phoneme).”
Speechmatics, writing on why voice assistants mangle SKUs on 7 May 2026, adds the collisions that are not letter-versus-letter at all: “Letter O vs digit 0, letter I vs digit 1” are “Phonetically identical in spoken English. Resolved only by structure or context.” Separators vanish silently too — their example is “MBR-99021” read back as “99021” — and on a phone “‘XL’ and ‘XS’ sound alike at telephone bandwidth.”
The 8 kHz phone codec deletes the frequencies that tell S from F
No prompt engineering fixes this, because the information is gone before the model receives it. ITU-T Recommendation G.711, approved 25 November 1988 and still in force, states: “The nominal value recommended for the sampling rate is 8000 samples per second.” By the Nyquist limit, a signal sampled 8000 times a second cannot represent anything above 4 kHz. ITU-T Recommendation G.712 specifies the channel’s attenuation behaviour “over the frequency range 300 Hz to 3400 Hz”, narrower still.
Now the acoustics. In his review Phonetics of Fricatives for the Oxford Research Encyclopedia of Linguistics, Allard Jongman of the University of Kansas reports that in Hughes and Halle (1956) “the highest percentage of /f/ responses was obtained for peak locations below 2 kHz … and the highest percentage of /s/ responses was found for peak locations above 4 kHz.” Heinz and Stevens (1961) narrowed it: “fricatives with a peak in between approximately 4.5 and 6.5 kHz were identified as /s/.”
The band listeners use to decide a sound is ess and not eff sits entirely above the ceiling of a G.711 channel. That is a filter, not a metaphor.
The stops go the same way. Miller and Nicely ran 16 consonants through low-pass filters with cut-offs from 300 to 5000 cycles per second for the Journal of the Acoustical Society of America in 1955, in “An Analysis of Perceptual Confusions Among Some English Consonants”: “The data indicate that voicing and nasality are little affected and that place is severely affected by low-pass and noisy systems.” Place of articulation is what separates B from D from G, P from T from K, and M from N. It is the feature the codec takes first.
The capture reliability budget: work out your own whole-address success rate
Here it is end to end. We call it the capture reliability budget.
Step 1 — count tokens, not characters. Spell [email protected] and you get j / dot / s / m / i / t / h / at / b / i / g / p / o / n / d / dot / c / o / m / dot / a / u — 22 independently recognised tokens. Call it n.
Step 2 — get a per-token accuracy, p, in the same unit. SNuC defines word-level accuracy as “the accuracy of recognising individual spoken letters or digits” — one letter or digit, which is one token here. Table 2 gives two: 98.4% on the SNuC test set, 96.6% on the industrial partner’s recordings. Two caveats. Both were recorded on a headset and down-sampled to 16 kHz, twice the bandwidth a G.711 phone leg carries, so on a real call they are ceilings. And at and dot are tokens above but are not letters or digits, so p is applied to two units SNuC never measured; both are distinctive whole words, which makes the result more conservative, not less.
Step 3 — raise it to the power of the length. Whole-address success is pn. At p = 0.966 and n = 22, that is 46.7%.
Step 4 — check the model against reality. Most compound-error arguments skip this. SNuC publishes word-level and sentence-level accuracy on the same audio, and reports that its identifiers “range in length from about 6 to 14 ‘words'”. Its three ID formats average 11.0 tokens if none of the optional suffixes appear and 12.33 if all do, and the paper does not publish how often they do, so take the whole range. The budget then predicts 82.0–83.7% intact on the SNuC test set against 81.7% measured, and 65.3–68.4% on the partner recordings against 77% measured. The authors read their own table the same way: the SNuC figure “matches that which would be expected in the conditions where word errors are occurring independently within every sentence at the word-level error rate”, while “the higher sentence level accuracy in the partner data is explained by word-errors clustering in certain utterances”. Treat pn as a planning floor: near-exact on clean audio, conservative on messy audio.
| Address length (tokens) | p = 99.5% (the target) | p = 98.4% (SNuC, sound booth) | p = 96.6% (SNuC, partner audio) |
|---|---|---|---|
| 6 — short handle, short domain | 97.0% | 90.8% | 81.3% |
| 10 | 95.1% | 85.1% | 70.8% |
| 14 | 93.2% | 79.8% | 61.6% |
| 18 | 91.4% | 74.8% | 53.7% |
| 22 — [email protected] | 89.6% | 70.1% | 46.7% |
| 30 | 86.0% | 61.6% | 35.4% |
One cross-check, by a different method. AssemblyAI’s benchmark, published 14 April 2026 in “Word error rate is broken”, reports a 34.3% missed entity rate for Email/URL for Universal-3 Pro over 250+ hours of real customer audio — 65.7% of those entities surviving intact, which is the quantity the budget computes, reached without any compounding assumption. It sits inside the 46.7–70.1% predicted for 22 tokens. Read it as corroboration of magnitude and nothing more: the interval is 23 points wide because it is simply the two SNuC rows above, the entity class mixes emails with URLs of unknown length, and it is AssemblyAI’s own model on audio AssemblyAI chose — the same page warns that “models are sometimes trained on the same public datasets used for evaluation, which inflates scores”.
The Half-Percent Rule: when read-back stops being optional
Invert the budget and you get a decision rule rather than a complaint. The Half-Percent Rule: to capture nine out of ten 22-token email addresses correctly on the first pass, your per-token error rate has to be below 0.478% — roughly one-seventh of the 3.2% word error rate posted by the leading model in Coval’s 28-model pool. For 95% first-pass capture on the same address you need 99.767% per token. Nothing published is close.
| Per-token accuracy | Longest string still above 90% first-pass | Longest string still above 95% | What that means for email |
|---|---|---|---|
| 99.5% | 21 tokens | 10 tokens | Confirm anything longer than a short handle |
| 98.4% | 6 tokens | 3 tokens | Confirm every address, without exception |
| 96.6% | 3 tokens | 1 token | Do not capture by voice unconfirmed at all |
At the per-token accuracy a baseline recogniser achieved on real industrial audio, no email address is short enough to pass unconfirmed. The question is not whether to confirm but how, without burning ninety seconds of call time.
If a read-back catches 70% of the errors it is shown, a 22-token address at p = 0.984 goes from 70.1% to 91.0%; at p = 0.966, from 46.7% to 84.0%. One confirmation turn buys about twenty points. A second buys far less and costs the same in call duration.
The fixes, ordered by how much error they remove
| Fix | What it changes in the budget | Cost |
|---|---|---|
| 1. Do not capture it by voice | Removes n entirely. Send an SMS or WhatsApp with a one-field form and let the person type it. | A second channel and a trusted mobile number |
| 2. Constrain the vocabulary | Restores the missing prior. Speechmatics reports that older Microsoft Research work using W3C SRGS regex-derived grammars “can cut semantic error rates by more than 50% on alphanumeric inputs”, and that focused beats large: a 50,000-entry vocabulary “can degrade accuracy by flooding the model with low-prior strings”. | A maintained list. Speechmatics caps its Custom Dictionary at 1,000 words or phrases per job. |
| 3. Read back and confirm | Adds roughly twenty points on a 22-token address, per the arithmetic above. | One extra turn, every call |
| 4. Phonetic confirmation | Alpha, Bravo, Charlie differ across several syllables and features; SNuC showed plain letter names can differ by one. | Slow, and unnatural for a caller unprompted — use it for the agent reading back, not the caller |
| 5. DTMF for the numeric parts | Bypasses recogniser and codec. Digits only, and only if the transport survives. | Fragile in specific ways — see why keypad digits go missing on AI voice calls |
The fix at the top removes the problem; the ones below manage it. That ordering is why teams spend a quarter tuning a recogniser that was never going to get there. Then measure on your own audio. Coval’s guide of 4 June 2026 is blunt about why vendor figures travel badly: “Streaming WER is typically 1–3 percentage points worse than batch WER on the same model; a vendor quoting only batch numbers is comparing apples to oranges with a streaming competitor.” Build a spelled-address test set from your own recordings before launch — the same discipline as testing an AI voice agent before go-live, applied to the entity that carries the transaction.
When the right answer is not to capture the address by voice at all
Part of this cannot be engineered out. Even the human on the other end is unreliable: SNuC’s authors found “93.8% of the numbers were correctly read and spoken by participants without mishap … The remaining 68.2%, or roughly 2/3, of the errors were unnoticed by the speaker.” That is a 4.2% floor of silently wrong input, from native speakers reading off a screen in a sound booth. No recogniser beats it, because the wrong string was spoken.
So the honest threshold. If the address is the point of the call — a quote, an invoice, a contract, an account recovery — do not capture it by voice. Send a link. If it is incidental, and a wrong one costs a follow-up rather than a transaction, capture it with one read-back and accept the 84–91%. If you are building this yourself, budget for the test set, the allow-list and the confirmation logic rather than the recogniser; the recogniser is already as solved as it is going to be.
Which is why channel mix matters more than model choice. An agent that can also send an SMS, a WhatsApp message or an email mid-call routes the address around the codec instead of fighting it. Zian AI’s digital team agents run live phone, SMS, email and WhatsApp on the same conversation, landing the result in HubSpot, Salesforce, HighLevel or Zapier through the same CRM integration patterns that carry the rest of the record.
Where each number on this page comes from
Date checked for every row below: 12 September 2026.
| Figure | Published by | Measured on | What the figure excludes |
|---|---|---|---|
| 96.6% word / 77% sentence; 98.5% / 91.7% adapted | University of Sheffield, LREC 2022 | Partner audio, spoken serial numbers | Phone audio. SNuC used “a headset microphone in a sound attenuating booth at 44kHz, down-sampled to 16kHz” — twice the bandwidth of a G.711 leg |
| 3.2% best WER; 6.7% average, 28 models | Coval, via AssemblyAI’s Voice Agent Accuracy Report | 3,500 samples, “six real-world conditions — clipping, far-field mics, phone-codec reverb, accents, and noise” | Spelled letters — it is conversational WER. The eight models listed span 3.2–6.0%; the average includes 20 not shown |
| 34.3% missed entity rate, Email/URL | AssemblyAI, own benchmark, 14 April 2026 | Universal-3 Pro, 250+ hrs, 26 datasets | Independence. AssemblyAI warns “models are sometimes trained on the same public datasets used for evaluation, which inflates scores” |
| 96.9% / 98.0% / 85.4% sequence accuracy | Speechmatics, internal, 7 May 2026 | “K L X F P R T M Z U”, “U6APO9HT79” | Per-character detail. Self-reported; a hit is any form that “can be reconstructed exactly” |
| 8000 samples per second; 300 Hz to 3400 Hz | ITU, Recommendations G.711 and G.712 | The narrowband PCM telephone channel | Wideband and HD-voice legs, which sample higher |
| /s/ from peaks above 4 kHz, and 4.5–6.5 kHz | Allard Jongman, University of Kansas, reporting Hughes and Halle (1956) | Fricatives, human listeners | Machines. Jongman notes Hughes and Halle “do not report the identity of the fricatives” |
| Place “severely affected by low-pass” | Miller and Nicely, JASA, 1955 | 16 consonants, cut-offs 300–5000 cps | Any modern model; nonsense syllables only |
Frequently asked questions
Why does my voice agent hear F when the caller says S?
Because the evidence is filtered out before the model hears it. Listeners identify /s/ from spectral energy peaking above 4 kHz, per Allard Jongman’s review for the Oxford Research Encyclopedia of Linguistics, and ITU-T G.711 samples the phone channel at 8000 samples per second, which cannot represent anything above 4 kHz.
Will a better speech-to-text model fix email capture?
Not on its own. To capture nine in ten 22-token addresses on the first pass you need a per-token error rate below 0.478%. The best model in Coval’s 28-model pool posts 3.2% word error rate on conversational audio, and spelled letters are harder than conversation, not easier.
Does the NATO phonetic alphabet actually help?
Yes, for the agent reading back, because alpha, bravo and charlie differ across several syllables rather than the single phonetic feature that separates pee from bee. It works far less well when you ask a caller to produce it unprompted.
Should I use DTMF instead?
For digits, yes, where the transport is reliable. Keypad entry bypasses both the recogniser and the codec. It cannot carry letters, an at-sign or a dot, so it solves part of a phone number and almost none of an email address.
Apply For Partnership
Zian AI builds autonomous AI sales agents that run live phone, SMS, email and WhatsApp on one conversation, in 30+ languages, with CRM integrations into HubSpot, Salesforce, HighLevel and Zapier. Zian AI is in partnership-application beta. Apply For Partnership.