OpenAI's voice API for UK business phone and support lines

The demos are genuinely impressive. Someone talks to a laptop, the laptop talks back without an awkward pause, and it books an appointment. Then you imagine your own inbound line: a caller in a van with the window down, a surname nobody spells the way it sounds, a postcode read out too fast, and somebody who wants a human within four seconds of realising they are not talking to one.

The gap between those two scenes is where the money goes. This is what OpenAI's voice capability actually does on a UK phone line, what it makes you responsible for, and when an IVR or a callback beats it.

Product names, endpoints and behaviour below were checked against OpenAI's own documentation on 08 Aug 2026. It moves roughly monthly, so re-check before committing.

It is a telephony product now, not a demo

The thing that changed is the connection to the phone network. OpenAI's Realtime API supports SIP, the protocol your phone system already speaks, so the path is: a SIP trunking provider converts an inbound call to IP traffic and routes it to OpenAI's endpoint, addressed with your project ID.

That means your network team has real work: outbound TCP over TLS on port 5061 to OpenAI's SIP endpoints, bidirectional UDP for media to four published address ranges, and firewall rules to match. There is a global endpoint and a separate European one for European data residency, both GeoIP routed to the nearest region. OpenAI does not publish a UK-specific SIP endpoint, so if data location is on your list, put that question in writing before you design anything.

On an inbound call, OpenAI fires a webhook to your system and hands you the decision. You can accept the call and configure the session that answers it, reject it with a SIP status code, hang up, or transfer it. The transfer is the one worth noting early: you supply a target such as a phone number or a SIP address, OpenAI issues a SIP REFER, and the call moves downstream to whatever handles it from there.

The architecture is not exotic. It is a call-handling application and should be judged like one.

Worth saying plainly, because a lot of AI work does not need engineering: this one does. Nothing in OpenAI's subscription products answers a telephone number. A phone line is API territory.

Latency and interruptions are configuration, not a model property

This is what separates a voice agent people tolerate from one they hate, and it is almost entirely your engineering decision rather than the model's.

The mechanism is turn detection, and OpenAI gives you two modes. Server VAD "uses periods of silence to automatically chunk the audio". Semantic VAD "uses a semantic classifier to detect when the user has finished speaking, based on the words they have uttered". Silence-based detection is predictable and cuts people off mid-thought. Semantic detection waits for the sentence to sound finished, which is better for a caller who pauses to find a word and worse when you need a fast, clipped exchange.

Each is tunable. An activation threshold, where a higher setting requires louder audio and copes better with noise. Padding before detected speech, so you do not lose the first syllable. A silence duration, where shorter values end the caller's turn faster. And on semantic detection, an eagerness setting that tunes how quickly the model is willing to jump in: low "will let the user take their time to speak", high "will chunk the audio as soon as possible".

Those are not sensible-default territory. A claims line and an order line want opposite settings, and getting them wrong produces the two failure modes callers actually complain about: being interrupted, and dead air.

Barge-in has a detail that catches teams out. When a caller talks over the agent, your application has to stop playback and then tell OpenAI how much audio the caller actually heard, in milliseconds. Get that wrong and the agent believes it said things the caller never heard, then behaves that way for the rest of the call. Small piece of code, common source of "why does it think I already told it that".

One hard constraint: OpenAI documents a maximum realtime session duration of 60 minutes. Most support calls are nowhere near it. Anything that could run long needs a plan rather than a surprise.

Accents and names are where UK deployments actually fail

OpenAI publishes no accuracy claim for regional British accents, and you should not accept one from anybody else either. This is unknown until you test it on your own callers, which is why the recorded-call set described below is not optional. What the vendor gives you instead is more useful than a claim: instructions for stopping the predictable failures.

The current realtime model is described as improving alphanumeric recognition, which is the category that matters here. Postcodes, order references, account numbers, registration plates. OpenAI's prompting guidance tells you to confirm digit by digit for numeric identifiers, and to repeat the full corrected value when a caller fixes part of it. That read-back loop is the difference between booking the right job and quietly booking the wrong one.

Names get the same treatment. The guidance is to keep a short list of reference pronunciations for tricky terms and update it as you hear errors, which is a maintenance job somebody has to own rather than a one-off configuration.

Two further instructions from OpenAI belong in your specification verbatim. First, "only respond to clear audio or text", asking for clarification rather than guessing. Second, "do not infer language from accent alone": switch language only when the caller asks or actually speaks another one. Anyone who has been switched into the wrong language on the strength of their surname will recognise why that is in the docs.

Recording and disclosure are operational requirements, not a legal footnote

Your DPO or solicitor owns the verdict here. But underneath it sit configuration decisions an engineering supplier has to get right, and those are the ones that get skipped.

The ICO's position on call recording is that you tell callers you are recording and why, with a recorded message treated as good practice. Whether that changes when the other party is software is a question for your DPO, because the ICO has published nothing specific to AI callers. What changes is that you now have a second disclosure to consider, which is whether the caller is told they are speaking to an AI system. Decide it deliberately and write the decision down. Callers work it out quickly, and the ones who feel misled are the ones who complain.

Then the practical consequences, all of which are build decisions:

• Audio leaves your estate. Your call audio is processed by a third party, which pulls in your processor terms, your privacy notice and your record of processing. If data location matters, the European SIP endpoint exists and a UK-specific one is not published.
• Retention becomes a design choice. Recordings, transcripts and the CRM record are three separate things with three separate retention answers. Left undecided, the default is "keep everything forever", which is the worst of the options.
• The ICO treats call recordings as personal information that can be disclosable in a subject access request. If a caller asks for their data, someone has to find the recording and the transcript. That is a search problem, and it is trivially cheap to solve at build time and expensive afterwards.
• Ask your DPO early whether this needs a DPIA, and budget the time in case it does.

Escalation is the feature, and it needs to be fast

The single most important thing a business voice agent does is know when to stop.

OpenAI's own guidance gives sensible triggers: escalate when the user explicitly asks for a human, and after two failed tool attempts on the same task. Add your own. Distress, complaints, anything involving money moving, anything where being wrong is expensive. What is realistic for a support team more broadly is covered in ChatGPT for UK contact centres.

Mechanically the transfer is the SIP REFER described earlier. What matters is what travels with it. If the caller has to repeat everything to the human who picks up, you have built something worse than no agent at all, and you have annoyed someone who was already asking to be transferred. The transfer should carry the caller's identity, what they wanted and what the agent already tried, which means writing to your CRM as the call happens rather than at the end.

That is the other half of the build. A call that leaves no record is a call your business did not have. The agent should be looking the caller up in your CRM mid-conversation and writing back the outcome, so the next person starts from something. Ordinary integration work, and usually a larger share of the project than the voice part.

When an IVR or a callback is the better answer

We would rather say this before you spend the money.

A well-built IVR wins when your call mix is a handful of deterministic routes. If most of your calls are "where is my order", "I want to pay a bill" and "put me through to accounts", a clean menu with a good CRM lookup behind it is cheaper, faster, entirely predictable and never invents anything. Replacing a good IVR with a voice agent is a lateral move dressed as a leap.

A callback wins when the problem is peak capacity. If your issue is that calls queue at 09:00 and abandon, offering a callback from a real person often measures better than answering instantly with a synthetic one, and it costs a fraction of an AI build.

Neither wins when the caller is distressed, vulnerable, or in a regulated conversation. Route those to a person by design.

A voice agent earns its place in the awkward middle: calls too varied to menu, too high in volume to staff comfortably, and mostly resolvable by looking something up and reading it back. Order status with exceptions, appointment changes, service triage, out-of-hours cover that currently goes to voicemail. If that describes your queue, the case is real.

The decision in front of you

Before you commission anything, do the cheap version. Pull twenty or thirty recorded calls that represent your actual queue: the accents, the noise, the interrupters, the long reference numbers. That set is what you judge any supplier's demo against, what you tune turn detection with, and what you re-test against when the model changes, which it will.

Then settle the three things that decide whether the project is worth it: which intents the agent may handle, how fast it hands over, and what it writes to the CRM.

For how this sits against the alternatives, see the full guide to OpenAI for UK businesses.

We are an OpenAI Select Partner and we build these systems, but we take no margin on your usage and we would rather tell you your IVR is fine than sell you a replacement for it. If you want the case assessed against your own call data, request a quote. The same team handles OpenAI implementation and Claude work on identical terms.

If you already have something running on OpenAI's voice surface, the more urgent question is whether it is on a model with a shutdown date. We have set out the dates and what to re-test in the realtime migration post.