Your voice agent understood the call. Did it capture the customer?

A voice agent can understand why somebody called, hold a natural conversation, and still lose the customer because it saved the wrong email address.

That is a quieter failure than a dropped call. The conversation sounds successful. The record even looks complete. Nobody notices the mistake until a confirmation goes to the wrong inbox, dispatch cannot find the address, or the team calls a number with one digit missing.

Customer details are not small talk. They are inputs to the next system, and they deserve their own acceptance test.

Customer-detail capture is a data-entry workflow conducted through speech

When a caller says ashir.shaikh@example.com, the agent does not receive a neat form field. It may receive words such as “ashir dot shaikh at example dot com,” partial spelling, a correction, background noise, and a pause that sounds like the end of the answer.

Names and addresses create similar problems. A familiar surname can have several spellings. A street name may sound like an ordinary word. A phone number can be grouped in different ways, and a caller may correct only the last two digits.

The useful mental model is a small pipeline:

caller audio
    ↓
transcribed candidate
    ↓
normalized value
    ↓
caller confirmation
    ↓
validated customer record

Each transition can fail. Treating the first transcription as final skips most of the controls that make the record dependable.

Confirmation should match the cost of getting a field wrong

Reading every sentence back would make the call painful. Confirming nothing makes the system careless.

I would use stricter confirmation for fields that control identity, contact, location, or an external action:

| Field | Practical confirmation | | --- | --- | | Customer name | Ask about spelling when uncertain or when the record must match an existing account. | | Email address | Normalize spoken symbols, then read the address back in clear segments. | | Phone number | Read the digits back in short groups and ask for confirmation. | | Service address | Confirm the street number, street name, city, and postal code before dispatch or booking. | | Problem description | Summarize the important facts without forcing a word-for-word readback. |

The goal is not to make every field perfect. It is to spend confirmation time where a wrong value breaks the workflow.

LiveKit's email-capture task, currently marked beta, handles spoken forms such as “dot,” “underscore,” and “dash,” recognizes letter-by-letter spelling patterns, and defaults to reading an email back for confirmation in audio sessions. That is a useful implementation pattern, although it still needs testing with the people and environments a specific agent will encounter. LiveKit GetEmailTask documentation

A correction must replace the earlier value everywhere

Consider this call:

“The address is 15 Lake Street.”

“Sorry, that is 50 Lake Street.”

A transcript can contain both numbers correctly while the dispatch record still keeps the first one. The test is not whether the correction appeared in the conversation. The test is which value reached the tool and which value the team sees.

For every critical field, I would keep at least three pieces of information during the call:

• the latest candidate value
• whether the caller confirmed it
• the revision that was sent to the business system

Once the caller changes a field, any earlier confirmation for that field should no longer authorize the write. The new value needs its own confirmation.

This is especially important when the agent collects details over several turns. A caller might give the street first, change the unit number later, and correct the phone number just before hanging up. The final record must be assembled from the latest confirmed values, not whichever values happened to be present when the workflow began.

Vocabulary hints help, but they can introduce new mistakes

Speech-recognition systems can be given phrase sets or custom classes for rare names, product terms, restaurant names, and other domain vocabulary. Google Cloud documents this as model adaptation and notes that it can improve recognition for proper nouns and unclear audio. Google Cloud Speech-to-Text adaptation

There is a trade-off. Increasing the bias toward expected phrases can reduce missed terms, but it can also increase false positives. A system tuned for a service area might become too eager to hear a familiar street or town even when the caller said something else.

I would treat vocabulary adaptation as one input to recognition, not permission to skip confirmation. Test it against similar-sounding alternatives and locations outside the service area.

Give the caller another path when voice capture keeps failing

Repeating “Could you say that again?” is not a recovery strategy.

After one or two failed attempts, the agent should offer a fallback that fits the business workflow. That might be an SMS link, keypad entry for numbers, or a human callback task with the uncertain field clearly marked.

The handoff needs the context already collected. Asking a caller to repeat the entire request to a person turns a technically successful transfer into a poor customer experience.

A useful fallback record might include:

• the original spoken value
• the normalized candidate
• which part remained uncertain
• the confirmed phone number or another way to follow up
• the reason the automated flow stopped

The receiving person can then resolve one field instead of reconstructing the whole call.

Test customer details with audio that resembles real calls

Clean microphone audio is a starting point. It is not a release test for a phone agent.

I would build a small, repeatable test set containing fictional information:

1. A common name with an uncommon spelling.
2. An email containing a dot, underscore, or plus sign.
3. Two similar-sounding street names.
4. A phone number corrected near the end of the call.
5. A caller spelling a name while background noise is present.
6. A caller who declines to provide an email address.
7. A failed capture that must create a human follow-up.

Run each scenario through the complete integration. Then inspect the customer record, booking, CRM entry, or dispatch note that the business would actually use.

The test report should separate first-pass accuracy, corrections, confirmed values, abandoned captures, and human handoffs. A single “call completed” count hides too much.

Before a pilot takes real calls, spell an email address over a noisy phone connection, correct one character, and inspect what the system saved. That small test can reveal more than another perfectly scripted demo.

For the next part of the workflow, read when an AI receptionist can safely say a booking is confirmed. If you want to test your own call flow, start with a missed-call audit.