Multilingual AI sales agents depend on speech, offers, knowledge, tools, compliance, and measurement sharing the same market context. The practical model is a shared runtime and business-logic layer with a versioned locale package, release gate, fallback path, and scorecard for each market.
What makes an AI sales agent multilingual
A translated script is only one layer. A production agent has to preserve intent and complete an approved action across several systems:
- Speech: recognize the customer's language, dialect, accent, names, numbers, and interruptions.
- Conversation: respond in the accepted language and follow market-specific sales rules.
- Knowledge: retrieve the right product, price, policy, and availability data for that market.
- Action: write clean data to the customer relationship management (CRM) system, schedule the right calendar, and transfer to the right team.
- Control: apply consent, disclosure, recording, calling-hour, and suppression rules before and during the interaction.
- Measurement: attribute outcomes to the correct language, market, campaign, provider configuration, and agent version.
This distinction matters because translation can produce fluent speech while the workflow still fails. A date may be interpreted in the wrong order. A product may be unavailable in the caller's country. A meeting may land on an English-speaking queue. A discount or disclosure may change meaning after two translation steps.
Initial sales workflows should be bounded. Lead qualification, appointment booking, event follow-up, inbound product discovery, renewal outreach, and reactivation are suitable starting points when each one has defined inputs, tools, exit conditions, and human handoff points. Complex negotiation, regulated eligibility decisions, and unapproved pricing exceptions should stay with trained people.
How Dasha fits a multilingual sales stack
We built Dasha as a managed production platform for real-time voice AI. Technical teams can run inbound and outbound conversations through a managed runtime, REST APIs, a web application, and existing SIP or Voice over Internet Protocol (VoIP) telephony. Business systems connect through APIs and webhooks, which lets the agent read an approved lead record, book a meeting, write a disposition, or request a human transfer.
Our current product information publishes support for 30+ languages and mid-call language switching. The documented switching feature is request-driven. The customer must ask to switch in the language the agent is already using, and automatic cross-language detection is unavailable. The same configured voice continues after the switch, so that voice and the configured language model must support the target language. Dasha does not publish a complete locale-by-locale matrix. Language count alone also says little about a particular combination of accent, voice, domain vocabulary, phone network, model, and traffic region. Each combination belongs in the market's release criteria.
Dasha publishes Salesforce, HubSpot, and Zapier integration support, along with custom connections through the REST API and webhooks. The published material does not define whether every named path is a native connector, a partner workflow, or an API and webhook implementation. Confirm current connector availability and scope with Dasha before making one an architectural dependency. Custom integrations remain an engineering workstream with explicit data contracts and failure behavior.
Performance has a similar dependency. End-to-end response time includes audio transport, speech recognition, model work, tool calls, and speech synthesis. Dasha builds and maintains Voice Benchmark, and its current public method measures US English calls only. Those results do not establish performance for another language or region. A multilingual rollout needs its own median and tail-latency measurements using the target call path.
Choose the right multilingual architecture
There are three common ways to build the language path. They create different failure modes.
| Architecture | How it works | Best fit | Main tradeoff |
|---|---|---|---|
| Native-language pipeline | Speech is recognized, reasoned over, and spoken in the target language | Markets with meaningful volume or strict experience requirements | Every locale needs its own evaluation set, vocabulary, voice, and release process |
| Translation relay | The caller's speech is translated into a pivot language, processed there, then translated back | Early exploration when the core system exists in one language | Extra hops add delay and can alter names, offers, intent, and required wording |
| Separate market agents | Each market gets its own agent configuration, providers, telephony, and release cycle | Markets with distinct products, regulation, or operating teams | Duplicated logic and configuration drift become expensive |
For most sales programs, the maintainable design is a hybrid. Keep identity, tool schemas, CRM fields, event names, and reusable conversation logic in one shared layer. Package prompts, approved claims, pronunciation rules, voices, knowledge sources, calendars, handoff queues, and compliance controls by locale. A market can then change without forking the whole platform.
Build a locale package for every market
Use a specific locale such as es-MX or fr-CA, rather than a broad label such as Spanish or French. BCP 47 language tags give systems a consistent way to identify language and regional variants.
A useful locale package contains:
- supported language tag, dialects, accents, and common code-switch patterns;
- approved opening, AI disclosure, recording notice, opt-out wording, and closing;
- product names, acronyms, competitor names, street names, and pronunciation hints;
- market-specific products, prices, currencies, taxes, availability, and promotion rules;
- local date, time, number, address, and name formats;
- qualification questions and disallowed inferences;
- common objections, idioms, politeness conventions, and terms to avoid;
- business hours, holidays, calendars, service areas, and transfer queues;
- CRM field mappings, required values, and idempotency keys for repeated tool calls;
- safe responses for missing data, unsupported languages, failed tools, and unavailable humans;
- an evaluation set recorded by native speakers across devices and realistic phone conditions; and
- an owner, version, approval history, and rollback target.
Keep commercial facts in structured systems whenever possible. A SKU, price, tax rule, or available appointment should come from an approved tool response, not from a translated paragraph in the prompt. The agent can localize the explanation after it receives the authoritative value.
Long-form knowledge needs a retrieval policy. The system may use multilingual retrieval or translate the customer's query into the knowledge base's language. In either case, logs should retain the original utterance, the retrieval query, the source passage, and the final language. Evaluate local synonyms, transliterations, and mixed-language searches. A fluent answer from the wrong market document is still wrong.
Route by the customer's query language
Treat language as conversation state rather than a one-time guess. The routing policy should use signals in a clear order:
- an explicit language choice from the customer;
- a confirmed preference in the customer record;
- the campaign, inbound number, site locale, or market queue;
- language identification from an upstream or separately configured service, when present; and
- a short clarification when the signals conflict.
Open in the market's expected language and make switching easy. Avoid a long greeting repeated in several languages. Once the customer accepts a language, persist the locale across prompts, knowledge retrieval, tools, CRM writes, transfers, and follow-up messages.
Code-switching needs its own rules. Product names and company names may remain in their original language. Addresses, email addresses, amounts, and dates should be repeated back in an unambiguous form before an action. A brief phrase in another language should not automatically reset the session. An explicit request to switch should.
When the requested language is unsupported, the agent should say so plainly in the language it can use and route to a suitable person or channel. It should never improvise with an unqualified language path.
Use a staged implementation workflow
1. Select one market and one outcome
Prioritize markets using eligible demand, expected value, operational readiness, and legal feasibility. Raw population size and a vendor's language count are weak selection criteria. Choose one observable outcome, such as a qualified lead handed to sales or a confirmed appointment written to the calendar.
2. Capture the existing baseline
Record how the current human or single-language workflow performs. Define every denominator before deployment. Connected conversations, eligible leads, qualified leads, booked meetings, attended meetings, transfers, and revenue are different stages.
3. Build the locale package and tool contracts
Create the market assets above. Give every tool an explicit request and response schema. Define what the agent says when the CRM, calendar, consent service, or transfer queue is slow or unavailable. Duplicate writes should be prevented outside the language model.
4. Evaluate the complete call path
Evaluation should cover accents, background noise, interruptions, silence, voicemail, mixed-language turns, names, dates, amounts, ambiguous consent, opt-outs, stale CRM data, tool timeouts, and unavailable agents. Native reviewers should score meaning and cultural fit, while automated checks enforce required events and prohibited actions.
5. Release in controlled stages
Start with internal calls, then approved low-risk traffic, then a limited production allocation. Keep human takeover and rollback available. Increase traffic only after language quality, tool reliability, compliance events, and sales outcomes meet the market's release thresholds.
6. Operate each market as its own release lane
Locale packages need versioning and regression control. A shared model or runtime update can affect one accent, voice, or tool path differently from another. Deployment gates and dashboards should preserve market-level visibility even when the underlying platform is shared.
Measure what can be fixed
A single global conversion rate hides the cause of failure. Use a scorecard that connects language behavior to the sales funnel.
| Layer | KPI | What it reveals |
|---|---|---|
| Routing | Correct-language acceptance, clarification rate, unsupported-language handoff | Whether the session starts in the right lane |
| Speech | Critical entity accuracy, repair turns, interruption recovery | Whether names, dates, amounts, and intent survive the voice path |
| Conversation | Required-step completion, unsupported-claim rate, escalation rate | Whether the agent follows the approved market flow |
| Systems | Tool success, duplicate-write rate, CRM completeness, transfer completion | Whether the agent completes the promised action |
| Experience | Response latency at the median and 95th percentile, hang-up point, complaint rate | Whether the interaction is usable and respectful |
| Sales | Qualification per eligible conversation, booking per qualified lead, attendance per booking | Where commercial performance changes |
| Economics | Cost per connected conversation and cost per completed outcome | Whether the workflow is viable at the observed quality level |
| Compliance | Disclosure completion, consent exception, opt-out capture, repeat contact after suppression | Whether controls work in the live path |
Segment these measures by locale, campaign, call direction, telephony route, voice, model, agent version, and time band. Sentiment labels and session duration can help investigation, but neither proves a good sales conversation. A short call may be a clean disqualification. A long call may be repeated repair.
The figures and scenarios below are representative examples informed by Dasha’s experience across deployments and common industry workflows. They are not customer testimonials or guaranteed outcomes; actual results vary by implementation, traffic, and baseline.
Illustrative scenario assumption
Assume a team compares three release lanes using these illustrative funnel counts:
| Locale | Eligible conversations | Qualified leads | Meetings booked | Meetings attended |
|---|---|---|---|---|
| en-US baseline | 800 | 96 | 48 | 36 |
| es-MX pilot | 240 | 34 | 16 | 11 |
| de-DE pilot | 160 | 19 | 6 | 5 |
The English baseline qualifies 12% of eligible conversations and books 50% of qualified leads. The Spanish pilot qualifies 14.2%, books 47.1%, and has lower attendance after booking. That points toward reminder timing, calendar fit, or expectation setting rather than a qualification problem. The German pilot qualifies 11.9% but books 31.6% of qualified leads. The next review should focus on the local call to action, available slots, objection handling, and booking tool logs.
These assumed samples are too small to support a broad market verdict. Their value is diagnostic: each funnel stage suggests a different owner and fix.
Plan compliance as market logic
A translated disclosure does not create permission to call. Each market package needs counsel-approved rules for who may be contacted, why, when, with which voice, under what consent, and how recording and opt-out requests are handled.
Legal applicability depends on the call purpose, direction, recipient, consent, exemptions, and jurisdiction. In the United States, the FCC ruling on AI-generated voices explains that calls using AI-generated voices fall under Telephone Consumer Protection Act restrictions for artificial or prerecorded voice calls. The FTC telemarketing guidance covers disclosures, calling windows, Do Not Call controls, abandoned calls, and records. State and sector rules may add obligations. The EU AI Act also includes AI interaction transparency requirements. Our compliance-first pilot guide turns the US requirements into an operational sequence for permission, suppression, handoff, and stop conditions.
For applicable outbound flows, make consent and suppression deterministic services outside the model. If required permission data is missing, or a required suppression check or write fails, the outbound sales flow should stop. Store approved disclosure text by locale, record the version used, and monitor completion as an event.
Dasha does not currently publish a SOC 2 Type II or ISO 27001 attestation, a HIPAA Business Associate Agreement, or documented retention, residency, and subprocessor terms. A SOC 2 Type II audit is in progress, with the observation window scheduled to complete in late 2026. Regulated deployments therefore depend on the agreements, architecture, data controls, and procurement requirements for the specific workload. Our current security and compliance posture states these limits directly.
The operating model that scales
Multilingual sales works best when central and local teams own different layers. A platform team should own the runtime, integrations, event taxonomy, release tooling, and incident process. A market owner should own language, offers, knowledge, calendars, cultural fit, compliance text, and funnel targets. Both should approve changes that cross the boundary.
This model avoids two expensive mistakes: one global agent that treats every market as translated English, and a fleet of unrelated agents that cannot share fixes. A common production layer with market-specific control gives teams a faster path to expansion without losing traceability.
Dasha provides that shared runtime, API, telephony, and operational layer. If you are planning a multilingual voice sales lane, start building with Dasha and bring one target locale, one approved workflow, and one measurable outcome.