A practical guide / Fonix.AI
Names and numbers: a practical implementation guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
Names and numbers need field-level confirmation
Voice agent names and numbers recognition should preserve the exact business entity the caller intends. A natural transcript is not enough when a serial number, amount, appointment date or person name drives the next action. Evaluate capture, normalisation and confirmation separately.
This Fonix.AI lab supplies a confusion-set design and scoring method. It complements the multilingual guide rather than repeating general language coverage. The examples are synthetic and contain no customer identities.
Define acceptable forms before scoring
For each field, specify what differences are acceptable. “Twenty-five” and “25” can represent the same quantity; two different account identifiers cannot. Dates need a month and timezone context, while an amount needs a currency and unit. A display-friendly spelling should not silently replace a legal or customer-confirmed name.
Build cases with similar sounds, repeated digits, letters that can be confused, local names and mixed-language number expressions. Add correction turns and partial restarts. Keep a documented reference value for every sample.
Worked example: current users versus future users
A fictional buyer says “twenty users now, maybe two hundred later”. The correct current quantity is twenty; two hundred is a possible future scenario. Capturing the larger number as today's requirement is a semantic error even if both numbers appear in the transcript.
| Field | Scoring rule | Clarification example |
|---|---|---|
| Identifier | Exact approved character sequence | Read back grouped characters |
| Amount | Value, currency and unit | Distinguish thousands/lakhs |
| Date/time | Exact contextual interval | Read day, month and timezone |
| Name | Agreed reference/confirmation rule | Ask spelling only when needed |
Preserve corrections through the write
Record initial capture and final confirmed value independently. A system can ask the right clarification and still write the earlier value from cached tool arguments. Inspect the actual booking, lead or claim record after the correction.
If uncertainty remains, keep the field pending and assign the appropriate next step. Do not reward an invented value simply because it makes a form complete. Count unnecessary clarification as a separate usability cost.
A critical-field confusion and correction worksheet
Create synthetic confusion sets for amounts, dates, names and alphanumeric references. Define exact-match, normalisation and clarification rules before scoring. Keep current requirements separate from hypothetical future values in the reference labels.
| Pilot case | Required behaviour |
|---|---|
| The buyer mentions current and possible future quantities | Write the current quantity in its field and retain the future statement separately. |
| A serial number is corrected character by character | Replace the superseded candidate and verify the final action uses the corrected value. |
| An amount is spoken with a local numbering convention | Preserve numeric value, currency and unit through normalisation and readback. |
Score each consequential field against the agreed reference, then inspect downstream task impact. Report error severity and correction success rather than hiding wrong identifiers inside a general word-accuracy average. Use confirmed values where spelling is genuinely ambiguous.
Should the agent ask everyone to spell everything?
Not automatically. Apply clarification to ambiguity and consequence, using the approved reference format. Grouped readback may help identifiers, while repeating a full date and unit may help quantities. Excessive confirmation can make simple calls unnecessarily difficult.
Report per-field errors and task impact
Measure exact critical-field accuracy, successful correction and unresolved rate by field type and language condition. Review errors that cause a wrong action separately from harmless formatting differences. Publish counts and corpus scope, not a universal recognition guarantee.
Review a critical-field evaluation set with synthetic examples from your workflow. Barge-in testing covers interrupted corrections; function reliability checks whether the accepted value reaches the tool.