Enterprise Case Study: Running an AI Receptionist on a Thai Local Number

Most AI receptionist deployments are straightforward: buy a number, point it at an agent, go live. Then a request arrives that involves a country with real telecoms regulation, a language your text-to-speech vendor does not speak, and a buyer who wants the whole thing itemised — and the interesting engineering starts.

This is a walkthrough of a recent enterprise enquiry we scoped: an AI phone receptionist answering on a local Bangkok number, capturing caller details, and emailing a summary after every call. No client details here — just the constraints, the architecture and the real numbers, because all three generalise to any regulated market.

The requirement

Five things, which is a fairly typical enterprise brief:

• A local telephone number in Bangkok — specifically an 02 landline, not a virtual number from another country
• Inbound calls answered by AI, around the clock
• Every caller's name, telephone number, company and reason for calling captured as structured data
• An email after each call with those details and a short summary
• English essential, Thai desirable

Points one and five are where the difficulty lives.

Constraint 1: you cannot simply buy a Thai number

In most markets, provisioning a number is an API call. Thailand is not most markets.

Twilio does sell Thailand local numbers, and they are voice-capable. But a local number requires a regulatory bundle whose registered address falls within the locality covered by the number's prefix — a PO box will not do. For a business, that means submitting a commercial register excerpt, the registration number and legal-representative identification.

The practical consequence: a vendor cannot register a local number on a client's behalf using the vendor's own address. The documents must belong to an entity with a real presence in that city.

What is often missed is that this does not force the client to open their own telephony account. Twilio's regulatory bundles include an End User object designed for precisely this situation: the provider holds the account, and the bundle carries the client as the end user, with the client's address and company documents. The account can be the vendor's; the compliance documents must be the client's. Those are separate questions, and conflating them leads people to build the wrong commercial model.

Two further things worth knowing before quoting anyone a Thai deployment:

• Regulatory review takes time you do not control. It sits between the carrier and the national regulator. Build it into the schedule as a dependency, not a task.
• Toll-free is not a cheap fallback. A Thai local number costs roughly $0.011 per inbound minute. Thai toll-free is around $0.32 — close to thirty times more. On a line designed to answer every call, that difference dominates everything else in the budget.

Constraint 2: Thai breaks the standard voice pipeline

A typical low-latency voice stack pairs Deepgram for speech recognition with Deepgram Aura for speech synthesis. Same vendor, one key, sub-100ms synthesis.

For Thai, that pairing falls apart in an asymmetric way:

• Speech recognition: supported. Deepgram's Nova-3 added Thai. At $0.0048/min for monolingual streaming and $0.0058/min multilingual, the cost difference is rounding error.
• Speech synthesis: not supported. Aura and Aura-2 voices cover English, Spanish, German, French, Dutch, Italian and Japanese. There is no Thai voice.

So a bilingual Thai deployment cannot use one vendor end to end. Speech output has to come from OpenAI, ElevenLabs or a comparable multilingual engine, which means the pipeline carries two synthesis paths and switches between them by language.

The counterintuitive part: this does not make Thai more expensive. OpenAI's tts-1 runs about $0.015 per thousand characters against Aura-2's $0.030. The Thai path is cheaper per call than the English one. What it costs is engineering time and tuning — which is the honest reason to phase a second language rather than promise it on day one.

The architecture decision: dedicated or shared

Enterprise buyers ask for a dedicated deployment, and sometimes they genuinely need one — data residency requirements, procurement policy, or a security review that will not accept shared infrastructure. Often, though, they are asking out of habit.

The two models diverge more than people expect:

Dedicated, single-tenant

Everything — application, voice bridge, media server, database — on one instance in the client's region. Roughly $80 per month of infrastructure at current on-demand rates, before any telephony or AI usage.

One decision here is worth more than it looks. AWS opened an Asia Pacific (Bangkok) region, and for a Thai deployment it beats Singapore on both axes: a t3.large is $0.0950/hour there against $0.1056 in Singapore, and the media path to Thai callers is materially shorter. In a real-time voice pipeline, where the target for the full speech-to-response loop is 400–600ms, tens of milliseconds of network latency are not a rounding error — they are the difference between a conversation and an awkward pause. Cheaper and faster is a rare combination; take it when a region offers it.

Shared, multi-tenant

The same agent capability on shared infrastructure, with tenant data isolated and credentials encrypted at rest. On our platform that is $79 per month including a thousand answered minutes.

The fixed infrastructure cost is the entire difference, and it is the reason a dedicated deployment only makes sense above a certain volume — or when a policy requires it. Below that line, a client paying for a dedicated server is paying for an idle CPU.

What a call actually costs

Here is a full itemisation for a three-minute receptionist call in English, with the agent speaking roughly 45% of the time — about 1,300 characters of synthesised speech — over ten conversational turns:

Nine cents. Roughly three cents a minute.

Two observations matter more than the total. First, speech synthesis is the largest line item — larger than the phone call itself. Voice selection is a cost decision, not only a brand one; the cheaper Aura-1 tier halves that line. Second, the language model is almost free. At three-tenths of a cent per call, the intelligence in an AI receptionist is the cheapest thing about it. Nearly all the cost is moving audio around.

That shapes the whole economics. Costs are dominated by fixed infrastructure, not by volume. A dedicated deployment at 100 calls a month works out around $1.14 per call; at a thousand calls a month the same deployment is about $0.20. Utilisation, not unit price, is what makes an AI receptionist cheap.

What we would tell anyone scoping this

• Check the regulator before you check the price list. In regulated markets, number availability and documentation drive the timeline far more than engineering does.
• Separate "whose account" from "whose documents." They are independent, and assuming otherwise produces a clumsier commercial model than necessary.
• Verify language support per component, not per vendor. "Vendor X supports Thai" is not a fact about a vendor; it is a fact about one model within it. Recognition and synthesis are supported independently.
• Choose the region for latency first. A local region is often cheaper too, but even when it is not, conversational quality is worth paying for.
• Phase additional languages. A second language needs live tuning against real callers. Committing to it in the first delivery serves nobody.

None of this is exotic. It is the ordinary shape of taking a voice agent into a market with real telecoms rules — and it is entirely tractable, provided the constraints are discovered during scoping rather than after a contract is signed.

OpenVoice Agents runs AI phone agents on shared infrastructure from $79/month, and as dedicated single-tenant deployments for organisations that need them. All pricing above reflects published vendor rates at the time of writing; verify current rates before budgeting.

Scoping something similar — a regulated market, a second language, or a deployment your procurement team needs to sign off? Get in touch at info@babbagenz.com.