Four ways to work with us

Often you should buy the platform. The vendors sell capable toolkits, and if you have an engineer who can own conversation design, telephony, and evaluation, you may not need us. What a platform does not sell is the judgement around it — which calls are worth automating, what the agent does when it cannot help, how you measure whether it is working, and what a call really costs once you account for the parts nobody advertises. Plenty of voice projects are best served by buying a platform and implementing it well. Where that is the right answer, we will say so, and we can help you choose and implement it.

We do not publish rates, because the honest answer depends on scope. What we can commit to: the readiness assessment is fixed-price and quoted in writing after the discovery call, before any work starts. Build engagements are quoted against a defined scope rather than billed hourly against an open one. Platform, telephony, and model costs go directly to those vendors — we take no margin on them, so we have no reason to steer you toward the expensive option.

CentraTalk is a small practice, deliberately. The person on your discovery call is the person who does the work — there is no handover from a salesperson to a delivery team, because there is no salesperson. We keep client work off the website by default, and the same discretion applies to yours. Background and prior work are things we are glad to go through properly on a call.

No, and the engagement is structured to prevent it. You get the source code, an operational runbook, and a working session with whoever will own it afterwards. We are not a reseller for any platform and hold no vendor quotas. The retainer exists because some teams want it, not because the handover leaves you stuck without it.

Code-switching — a caller starting a sentence in one language and finishing it in another — is normal in plenty of markets, and it is the thing most demos quietly avoid. It is solvable, but the speech recognition choice matters more than the language model choice, and accuracy varies considerably with accent, background noise, and line quality. Part of the assessment is testing against your actual call recordings rather than a clean sample, so you find out where it struggles before you commit rather than after.

It will, so the design question is what happens next rather than how to prevent it entirely. That means deciding what the agent is not allowed to attempt, how it recognises that it is out of depth, and how it hands off to a person with the context already gathered. Teams that skip this ship agents that fail confidently, which is worse for a caller than not answering the phone at all.

Often, yes. The first step is the same assessment: what is actually failing, whether the existing build is worth continuing, and what finishing it would take. Sometimes the answer is to carry on, sometimes to replace one component, occasionally to start again. Either way you get that answer in a couple of weeks rather than after another quarter of drift.

Recorded or processed calls need consent handling wherever you operate, but the rules are jurisdiction-specific. In India, automated outbound calling falls under the TRAI framework and requires DLT registration — both are India-only and have no bearing on a US deployment. In the US the equivalent constraints come from the TCPA, which the FCC has confirmed covers AI-generated voices, alongside state recording laws that split between one-party and all-party consent. Either way these belong in the design conversation rather than after it, so the assessment covers whichever regime applies to you. We are not lawyers, and anything contentious deserves your own counsel — but the regulatory shape of the problem will be on the table early rather than discovered late.