TL;DR: Almost every voice AI guide you will read is American, and so are the defaults in the tooling. When I built agents at Fortell AI for UK hospitals, vet practices, estate agents and car garages, hardly anything that broke was a model problem. It was locale: dates read back in the wrong order, postcodes captured as gibberish, "reply YES to confirm" sent from a sender nobody can reply to, a calendar quietly an hour out for three weeks of the year, and an agent that heard "book my dog in at the surgery" as a surgical procedure. Here is the list I work through before a UK agent takes a live call.
The model is not the problem. Modern models handle British English fine. What does not handle it fine is everything around the model: the telephony defaults, the SMS layer, the calendar configuration, the knowledge base written from an American template, and the test process run by someone with an American accent.
I have written most of my voice agent material without a locale caveat, on structuring the conversation, booking against a real calendar and capturing caller details. This is what goes underneath those when the phone line is British.
The stack ships with American defaults
The voice is the obvious default to audit. A US voice answering a Yorkshire vet practice does not sound premium, it sounds outsourced, and callers make that judgement in about two seconds. Pick a British voice, then listen to it say the business name, the street name and the town, because regional place names are where text to speech falls over hardest and none of it shows up in a transcript.
Less obvious is the speech recognition configuration. If the provider exposes a language or locale setting, set it to British English rather than leaving it on the default. It shifts the model's priors on vocabulary and spelling, which matters most for the things that are already fragile: names, places and anything alphanumeric. The model's written bias needs the same treatment, because left alone it produces American spellings in anything the caller receives in writing. That is a prompt instruction, and it belongs with every other pronunciation rule, which I covered in writing prompts for the ear.
Dates and times are a different language
This is the single highest damage category, because the failure is silent and lands as a missed appointment.
Never let the agent speak or write a numeric date. "05/09" is the fifth of September to the caller and the ninth of May to an American-configured system. The fix is not clever parsing, it is banning the format outright. The agent says "Friday the fifth of September" and the confirmation text says the same. The weekday is a checksum the caller can catch an error with.
Ordinal phrasing is different. British speakers say "the fifth of September", not "September fifth". It is a small thing that instantly marks an agent as a foreign template.
Colloquial time is constant. "Half four" means four thirty, not half past three, and callers use it without a second thought. So do "quarter past", "quarter to" and "first thing". Handle the common ones explicitly and have the agent confirm the resolved time back.
Bank holidays are not US federal holidays, and they are not even uniform inside the UK, because Scotland and Northern Ireland have their own. An agent working from an American holiday list will happily book a client into a closed Monday in August and refuse a perfectly normal fourth of July.
And the clocks change on different dates. The UK switches between GMT and BST at the end of March and the end of October, and the US switches in March and November. For those weeks the two are offset differently from the rest of the year, which is exactly how you get a calendar integration that is correct for eleven months and an hour wrong for three weeks. Store timestamps with offsets, resolve everything in the business's time zone, and inject the current local date and time at the start of every call.
Numbers, and the postcode problem
UK callers group digits their own way, say "oh" for zero, and say "double six" or "treble eight" for repeated digits, which a naive parser turns into a single character or drops entirely. The country code adds its own trap, because +44 replaces the leading zero, so the same number is 07700 900123 out loud and +447700900123 in the CRM. Normalise that once in the pipeline rather than hoping the model does it consistently.
Postcodes deserve their own paragraph. A UK postcode is alphanumeric, split into an outward and an inward part, and it contains exactly the letters that narrowband phone audio destroys. It is the worst field to capture by voice in any UK build. What works: look it up rather than asking wherever the caller is already a customer, take it in two chunks with a natural break between them, shape check it in the automation layer instead of in the prompt, and after one failed retry stop trying by voice and text the caller a link. That repair ladder is the one I described for emails and reference numbers, and postcodes are where it earns its keep.
The vocabulary changes what the agent understands
This one surprised me, because it is not a pronunciation issue, it is an intent and retrieval issue. In a vet practice, "surgery" means the building. "Can I book my dog in at the surgery on Thursday" is a routine appointment request, and an agent working from an American template can read it as a surgical procedure and escalate a nail trim to the emergency path. That was a real correction on the vet clinic agents I worked on, and the same word does the same thing in primary care, where a GP surgery is a place.
The rest of the list is less dangerous but breaks retrieval just as effectively, because a knowledge base written in American English does not match what callers say. Garage customers ask about an MOT, not an inspection. Property callers say viewing, let, lettings and chain. People say chemist as often as pharmacy, mobile rather than cell, and car park rather than parking lot. Intent routing and retrieval are keyed on wording, so write the knowledge base in the caller's vocabulary and add local synonyms explicitly rather than hoping semantic search bridges the gap.
The SMS half of the build works differently
Most of my agent builds have a text message in them somewhere: a confirmation, a link so the caller can type their own email, a follow up after a missed call. That layer is not portable. The American compliance machinery around business texting does not apply in the same shape, so anyone telling you to sort out 10DLC registration for a UK number is reading from the wrong script.
What replaces it is a different set of practical constraints. UK business messages are often sent from an alphanumeric sender ID showing the business name, which looks good and cannot receive a reply, so any flow with "reply YES to confirm" in it silently dies. If two way messaging matters, and for a booking confirmation it usually does, you need a real number rather than a branded sender. Then test delivery to real handsets on the major UK networks before launch rather than trusting the provider's success response. The wider setup logic is in the phone number piece and holds either side of the Atlantic.
Recording and data sit in a different legal frame
I am an engineer, not your solicitor, and UK clients should take their own advice. What I can tell you is which engineering decisions the frame changes.
American voice AI content talks about one party and two party consent states. The UK question is not framed that way at all: it sits under UK GDPR and the ePrivacy rules, so the operative questions are what your lawful basis is, whether people are told clearly, how long recordings and transcripts are kept, and who can reach them. The ICO is the regulator clients will ask you about.
In practice that produces the same build decisions every time. Disclose recording in the greeting, in one short sentence rather than a paragraph nobody listens to. Decide retention deliberately and implement it, because "we keep everything forever" is a decision too, just a bad one. Keep personal data out of logs and tools that do not need it, and make sure someone can find and delete a specific caller's data on request, which is a product requirement rather than a checkbox. If the client is a healthcare provider the caution level goes up, and the boundaries I set out for medical clinic agents apply with the regulator's name changed.
Test with the accents you will actually get
The UK packs an extraordinary range of accents into a small area, and recognition accuracy is not uniform across them. An agent validated by a tester with a neutral southern English accent, or worse an American one, has been validated against the easiest possible input. Test with real regional speech, on a real phone line rather than a laptop microphone, and score accuracy per field rather than per call, because a ninety percent successful call rate can still hide a postcode field that fails one time in three. I batch this with the Claude Code and Comet pipeline I built at Fortell, but the important part is the input, not the tooling.
One more thing that only shows up on real calls: the transfer target is usually a mobile. UK practice staff carry phones around a building rather than sitting at a desk extension, so escalations reach voicemail more often than the client expects. Set the ring window accordingly and design the failure branch, which is the handoff ladder ending in an honest callback promise rather than a dead line.
The short version
- Audit every default: voice, recognition locale, and the model's written spelling.
- Ban numeric dates outright and speak the weekday as a checksum.
- Handle "half four", and use British ordinal phrasing.
- Load the correct bank holidays, including the ones that differ by nation, and watch the three weeks a year when UK and US clock changes disagree.
- Normalise +44 and the leading zero once, in the pipeline.
- Treat the postcode as the hardest field in the build and give it a repair ladder.
- Write the knowledge base in the caller's vocabulary, surgery and MOT included.
- Do not import American SMS advice, and never ask for a reply from a sender that cannot receive one.
- Frame recording and retention under UK GDPR, and get the client their own legal advice.
- Test with real regional accents and score per field.
None of this is difficult. It is just invisible until a caller hears it, which is why it tends to get discovered in week one of a live deployment rather than in the build.
I build production voice and chat agents on Retell, wired into n8n, GoHighLevel and Twilio, for clients across the US, UK and Europe. More about my background here, or book a call.