Multilingual voice agents: preparing and testing customer service
Prepare instructions, sources and examples to validate service for each audience.
- Author
- Tigy AI team
- Published
- Updated
A multilingual voice agent serves more than one language, but coverage needs validation by language and task. In Tigy AI, test instructions, sources, recognition, voice and tools with people familiar with the audience. A translated greeting does not establish accurate understanding of dates, names or commercial terms.
Choose an audience and an initial task
Voice service in another language needs validation of a complete task, rather than only a translated greeting. Choose the language and initial request, prepare questions using audience vocabulary, and check answers, names, numbers and external actions. Verify available platform options before announcing coverage.
Check the voice and configuration options available in Tigy for your scenario. The platform manages its voice catalog; this does not mean arbitrary external voices can be added.
Review content with someone fluent
Prepare consistent sources about hours, services and rules. Dates, units and product names must remain understandable. A reviewer needs to assess the complete answer rather than grammar alone.
Define behavior for mixed-language requests and terms the agent does not understand. A clarification question can be better than proceeding with an uncertain interpretation.
Test names, abbreviations and numbers aloud
Compare speech, transcript and response. Tigy's dictionary terms help recognition when used by the transcriber; they are not a phonetic dictionary that changes voice pronunciation.
Read an order code, correct a name and pause naturally. Check that the integration receives the confirmed value and the response stays in the intended language.
Expand based on evidence
Ask fluent speakers to assess clarity, pacing and task completion. Record recurring mistakes and rerun those cases after adjustments.
Offer a defined alternative for a language and task combination that has not been validated. Additional languages increase source maintenance and testing work; treat that coverage as an operational responsibility.
Test complete tasks in each language
Use known-data lookups with identifiers, corrections and explanations, inspecting parameters as well as pronunciation.
Approve interpretations of foreign-language tool states rather than literal internal-message translations.
Test representative accents and pacing independently per language, recording pending conditions.
Update languages together
Update every affected language when policies change. Old versions can produce inconsistent guidance.
Compare outcomes and repetition within similar tasks.
Provide alternatives for unvalidated languages rather than promising unsupported full service.
Define how the conversation selects a language
Offering more than one language requires an understandable opening rule. Someone may begin in Portuguese and mention a product in English; another may use a greeting too short to establish preference. Do not treat every foreign word as a request to switch conversation language. Define supported languages and how to confirm preference when the opening is ambiguous.
A short question can prevent confusion: ask which language the person prefers when uncertain. Then remain consistent while respecting explicit changes. Automatically switching after each borrowed term can obstruct understanding and data collection. Include this behavior in instructions and test sentences mixing product names with local language.
Consider people who do not speak a supported language as well. The approved exit should explain the limitation and identify a real alternative. Do not promise perfect translation or service in every language. Recognizing a few words does not establish the ability to complete a task, confirm numbers and explain commercial conditions with required accuracy.
Consider a fictional hotel reception. A guest begins in Spanish, asks about a service named in English and then requests Portuguese. Conversation should follow the explicit preference while retaining confirmed details. Testing must verify that dates and room category remain unchanged after switching.
Review introductions for each audience too. Literal translation may become long or unnatural. Preserve the purpose: explain who is answering, what help is available and how to begin. Quality means enabling a clear request, without an unnecessarily lengthy introduction in every language.
Maintain the same policy across versions
Service consistency means equivalent rules even when wording changes. A cancellation deadline must not differ between Portuguese and English because of poorly reviewed translation. Words such as “until,” “after,” “may” and “must” change conditions. Ask someone competent in the subject and language to check these differences, especially where content determines a customer's decision.
Create a short glossary for recurring terms. Service names, order categories and operation states need understandable wording in each language. The glossary need not force translation of brands or codes; it can explain pronunciation and meaning instead. This prevents one category from acquiring different translations within a conversation.
For dates, units and numbers, preserve meaning before format. Short dates can be interpreted differently across countries. Where ambiguity is possible, state the month and confirm the day. Prices need currency and billing period. Incorrectly translating “monthly” or omitting units changes an offer even when the sentence sounds fluent.
Do not confuse language with location. An English-speaking caller may need service at a Brazilian branch. A Portuguese-speaking caller may ask about another country's operation. Policy should follow service context rather than assumptions based on language. Confirm location or region when it determines the answer.
Review multilingual sources for update conflicts. If original policy changes while translation remains old, the agent can encounter incompatible answers. Define an approved version and a process updating the others. Test questions citing old conditions in each language, because automatic agreement may conceal conflict.
Determine the procedure when approved translation is unavailable. Explaining an approved source in another language may be acceptable, or the subject may require human review. Do not leave that decision implicit for important information. The operation should know what was validated and where gaps remain.
Test recognition and pronunciation with real vocabulary
Multilingual service depends on more than a language model producing sentences. Recognition must represent speech, and the selected voice must make responses understandable. Correct text can be pronounced confusingly; pleasant speech can read an incorrect transcript. Evaluate stages separately before attributing every failure to the prompt.
Choose domain examples: surnames, cities, services, abbreviations and numbers. Include local terms absent from generic demonstrations. If the agent confirms email addresses or codes, test character explanations in supported languages. The objective is reaching the same confirmed value, rather than demonstrating a particular accent.
Include speech variation relevant to the audience without treating a small trial as a universal guarantee. Observe repetition, substituted words and misunderstanding. When callers correct a field, inspect the parameter sent to the tool. Both final transcript and operation should reflect the correction.
Test switching language mid-sentence and questions containing borrowed terms. The agent should seek clarification when needed instead of inventing meaning. Where pronunciation of proper names matters, approve a confirmation method allowing customers to recognize or correct the information.
When comparing voice or transcription settings, repeat the same tasks under similar conditions. Better results on short sentences do not establish improvement for codes and dates. Retain cases representing actual service difficulty and listen to complete calls, including waiting messages and endings.
Compare equivalent tasks across languages
During the pilot, separate outcomes by language and intention. One group may ask only general questions while another attempts complex bookings. Overall rates cannot establish that one language works better. Compare equivalent tasks and make sample size, failures and audio conditions visible.
Have complete answers reviewed by someone who understands the language. Assess policy fidelity, naturalness, data collection and fallback when sources are insufficient. Translation may be grammatically correct while hiding an important condition or using vocabulary unsuitable for service context.
Expand coverage when the task collection has been validated. Announcing another language requires more than a translated greeting: operations must preserve quality through confirmation and ending. Record known limits and update tests when services or sources change.
Receiving teams need compatible continuity too. If a caller requests a person in the selected language, the destination or alternative must actually support that service. An agent's multilingual ability does not automatically give the rest of the operation the same coverage. Confirm hours, destination and expected next step before making that promise.
Use a bilingual case with the same system result
Prepare two versions of the same fictional request, preserving intention, identification and tool result. For example, a customer asks about an order expected on Friday. In each language, verify that the answer retains the estimate, correct date and approved condition. Comparing unrelated stories cannot establish equivalent service.
Then introduce a corrected number and a question absent from the source. Both languages should preserve the corrected value and acknowledge the same limitation. If one invents a condition, investigate instructions, sources and explanation separately. Wording may need review even when retrieval was correct.
Record divergences by service effect: omitted conditions, added promises, confusing terminology or unconfirmed information. This allows prioritizing meaning before stylistic details. A natural answer changing policy needs correction before expansion.
Use the resulting collection when changing available voices, instructions or approved documents. You are not seeking identical wording, because natural expression differs by language. You are seeking equivalent decisions, supported claims and available next steps. Keep reviewer notes about why an answer is acceptable, so future revisions do not accidentally restore an older translation error. This evidence makes multilingual coverage a maintained service capability rather than a label based solely on an opening greeting.
