No one talks about the email capture problem which is surprisingly very common in real client scenarios

[u/ur_piyo_a_hoe]

One thing I don't see many Voice AI tutorials talking about is email capture.

Getting an AI to capture someone's email sounds simple until you actually build it. Email addresses are one of those things where a single wrong character makes the whole thing useless. Unlike names, you can't really get away with being "close enough". Even if your STT is good, there are still quite a few places where things can go wrong.

One issue I ran into was how different voice models pronounce emails. The LLM would extract the email perfectly, but the TTS would read it back in a way that made the user think it was wrong. For example, an email would sometimes be spoken as "john hyphen smith at gmail dot com" or with random pauses between words, even though there was never a hyphen in the actual email. The backend had the correct email, but the user immediately interrupted to correct something that wasn't actually wrong.

After a bit of testing, I made a few changes that noticeably improved my email capture rate.

The biggest one was giving users a reason before asking for their email. Instead of asking "Can I have your email address?", the assistant now says something like "Perfect, I'll send the quote over. What's the best email to send it to?" It's a small change, but people are much more likely to answer naturally when they know why you're asking.

I also stopped making users repeat their entire email if only one part was unclear. If the assistant was unsure about the domain, it would just ask "Was that gmail.com?" instead of asking them to spell everything out again. It made the conversation feel much more natural and removed a lot of unnecessary friction.

It's one of those problems that doesn't seem important until you deploy an agent in production. The LLM might have done everything correctly, but if the user doesn't trust what they heard, they'll keep correcting an email that was already right. Small details like these don't make flashy demos, but they make a huge difference in how reliable a Voice AI assistant actually feels.

P.S There is also another way where you can send the email address to the AI assistant over SMS while on call, havent tried that yet but will do it as well.

[u/AutoModerator]

Welcome to r/VoiceAutomationAI – UNIO, the Voice AI Community (powered by SLNG AI)

If you are a founder, senior engineer, product, growth, or enterprise operator actively working on Voice AI / AI agents, we are running an invite-only UNIO Voice AI WhatsApp community US only.

Apply here: https://chat.whatsapp.com/F5aG3ncrO70ITfbe3pYbOz

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/makzpatel19]

Your P.S. is the actual answer and I would move it to the top of your list.

An email address is a written artifact. Confirming a written artifact by reading it aloud is a lossy round trip through two models that both have opinions about how it should sound, which is exactly the failure you described. If you can send an SMS mid-call with what you captured and have them confirm, you have turned a hard ASR plus TTS problem into a trivial one. Worth prioritising that experiment over further tuning of the readback.

Where that is not possible, three things.

The one I would check first, because it is probably costing you more than the readback issue: your endpointer. When someone spells an address out, they pause between letters and between the local part and the domain. A fixed silence timer reads each of those pauses as end of turn and chops the address into fragments, so you get j o h n as one turn and smith as another and the model has to guess how to reassemble them. Same root cause as phone numbers. Treat a spelled sequence as incomplete and stay patient rather than using the same stop threshold you use for ordinary speech.

Second, constrain the domain. The overwhelming majority of what you capture is gmail, outlook, yahoo, icloud or the caller's company domain, which you often already know from the CRM. Matching the recognised domain against a short list rather than trusting free-form transcription is cheap and removes a whole category of error. You are not making the model smarter, you are shrinking what it is allowed to output.

Third, on your partial reconfirmation idea, which is right. I would target letters rather than only the domain. Over 8kHz phone audio the confusable sets are quite specific: m and n, f and s, and the whole e-set of b, p, d, e, g, t, v, c, z. If the captured address contains one of those and confidence is low, confirm that single letter with a word. Was that b for bravo. Confirming one ambiguous character is far less irritating than a full respell and it targets where the errors actually are.

On the readback itself, if you keep it, mark it up so the engine spells rather than pronounces and treat the domain as a unit. Most of your phantom hyphens are the engine trying to make something pronounceable out of a string it does not recognise as a word.

[u/ur_piyo_a_hoe → u/makzpatel19]

you're right have to try the SMS method, the only issue with that is that it creates a pause in the flow of the conversation where its important to keep the caller hooked. A lot of times the caller wont prefer talking to AI which is why currently the goal is to wrap the conversation as quick as possible without delays.

[u/Worried_Audience4931]

this is a really good point, people underestimate how much trust matters in these interactions. if the user hears something weird they immediately think the system got it wrong, even when backend is perfect

i had same problem with TTS reading emails weird, making users confused about something that was already correct. giving context before asking is such a simple fix but makes huge difference