Back to Blog
Tutorials

Test Names, Email Addresses and Digits in AI Phone Calls

Create an accuracy test for spoken names, email addresses and numbers that checks corrections, readbacks and final records rather than transcripts alone.

Burki
Article date:
4 min read

AI phone call data accuracy matters most where a single character changes the destination or the person. A polished conversation can still produce an unusable email address, the wrong callback number or a record attached to a different customer. Testing these fields requires more than asking whether the transcript looks plausible.

Define accuracy at the point where the information will be used. For a callback number, that is the final confirmed number passed to the permitted workflow. For an email lookup, it is the exact address searched. For a name, the expected behaviour may be to ask for clarification rather than force a match.

Choose a small but varied field set

Create fictional examples with characteristics your business encounters. Include short and long names, initials, repeated digits, letters that sound similar and email addresses with dots or hyphens. Do not use real customer contact details just to make the test feel realistic.

A hypothetical test list could contain a surname pronounced differently from its spelling, a code ending in “fifteen” versus “fifty,” and an email whose spoken username contains “dash.” Specify the intended written value before the conversation begins. Otherwise reviewers may unconsciously accept whatever the assistant guessed.

Avoid making a list exclusively of unusual edge cases. Keep ordinary examples alongside challenging ones so changes do not improve the hardest cases by making every normal call unnecessarily slow.

Test the correction path

For each field, run a clean case and a correction case. In the correction case, supply one value, allow a readback and replace a specific part. Observe whether the assistant preserves the unchanged portion or loses the whole value.

For an email, “Change the domain, keep everything before the at sign” is a useful conversational challenge. For a number, correct the middle group rather than always the final digit. For a name, ask the assistant to separate a family name from a company name.

These cases examine conversational state as much as speech recognition. Burki's speech recognition overview can help frame provider questions, but the business test remains the final intended value.

Use a four-column evidence sheet

Record the intended value, what the caller actually said, the assistant's readback and the final value used. Add a fifth column for whether the caller explicitly confirmed it when confirmation was required.

This exposes different failures. A wrong transcript followed by a successful clarification is a recovered error. A correct transcript followed by a wrong tool argument is a downstream failure. A confident readback that the caller never had a chance to correct is a process problem.

Do not collapse these into a single transcription score. The distinctions tell you whether to improve listening, prompts, validation or action handling.

Add realistic audio conditions carefully

Run the same examples through a clean baseline and a limited set of changed conditions. Background speech, a poor microphone or packet loss may affect individual characters differently. LiveKit's simulation documentation describes audio degradation options for supported testing environments; those facilities are not automatically a Burki user-facing feature.

When testing manually, use a repeatable procedure and note the device and connection. Avoid asking one speaker to imitate accents. Recruit appropriate consenting speakers or use suitable licensed test material, then review errors without treating any accent as inherently defective.

Decide when uncertainty is acceptable

A business can often accept an assistant asking for a repeated digit. It should not accept invented certainty. Write a limit for how many clarification attempts are reasonable before offering an alternative supported path.

Also decide which fields are truly necessary. Collecting five precise identifiers for a general opening-hours question increases effort and creates avoidable errors. Keep the interaction proportional to the task.

Before expanding a pilot, review a sample of final records against the corresponding audio and confirmations. Use Burki's voice testing guide to keep these cases in the release process. The useful measure is whether the correct information reaches the correct action, with uncertainty handled honestly.

Ready to try Burki?

Create an assistant and check your available browser practice allowance.

Start Free Trial

Trial eligibility and available practice are shown in your workspace.

Related Articles