Algeria AgencyArtificial intelligence
The words transcription does not know
The voice agent understands the sentence and gets the name wrong. That is the opposite of what people fear, and it is what makes an appointment unusable.
A customer calls a workshop in Tlemcen for an appointment. He gives his name, the agent repeats it wrongly, he spells it out, the agent repeats it differently. The appointment is booked, the record carries a name that does not exist, and nobody will find the file when the car arrives.
The sentence had been understood perfectly. What failed was a word, and that is the commonest case: a voice artificial intelligence system rarely gets “I would like an appointment on Tuesday” wrong and regularly gets the name, the neighbourhood and the part reference wrong.
This article names the words that break, says why they break, and describes the matching layer that answers them — the one that flags instead of correcting. It does not restate the argument that transcription decides before the model, which is covered elsewhere and is the precondition of everything that follows.
What breaks is not the language, it is the vocabulary
The commonest confusion on this subject is believing the problem is accent or language. Current transcription systems cope with Algerian French, with standard Arabic, and roughly with a Darija sentence whose structure is common.
What they do not do is guess a word that was not in what they learned. Transcription chooses, at every moment, the most probable sequence of sounds according to a corpus; a word absent from that corpus cannot be chosen, and the system offers instead the known word most like it.
That is why the error has a recognisable shape and why it is deceptive: it produces a real word. It is not noise, it is not a blank, it is another name, correctly spelled, settling into the record without anything signalling a difficulty.
What follows is what we have observed on systems we have put into service and listened to, not the result of a published benchmark. We publish no error rate for it: we have no annotated audio corpus and no comparison between models, and a percentage invented on this subject would be precisely what this article reproaches the systems it describes for.
Proper nouns, and the two alphabets
An Algerian name is commonly written several ways in Latin characters, because transliteration from Arabic was never unified. The same person exists in your files under two or three spellings, written by two different employees three years ago.
For a transcription system that compounds two difficulties. The first is choosing a spelling; the second is that the chosen spelling will not necessarily be the one in your database, which makes the search fail even when the transcription is defensible.
The costliest case is the compound first name and the name with a particle, where the system cuts in the wrong place and produces two words one of which is a common first name. The result looks like a plausible name, and that is what makes it invisible in a list.
What to take away is a design consequence rather than a list of names: if your system looks for an exact match between what it transcribed and what your database holds, it will fail on a substantial share of calls without ever saying why.
Neighbourhoods and wilayas
Algerian place names are a special case of proper nouns and they are worse, because they are numerous, thinly present in training corpora, and often built from words that exist elsewhere.
A neighbourhood whose name contains a common word is regularly transcribed as the sequence of those common words, producing an address that is grammatically correct and geographically non-existent. Listening, the error cannot be heard; on a delivery note it sends a driver somewhere else.
Wilayas fare better — they are better represented — and they create a different error: the system prefers them. An uncommon commune name is frequently replaced by the wilaya name it resembles, turning a precise address into a provincial one.
The operational lesson is that the address must never be taken from the transcription alone. It is the most expensive piece of data to correct afterwards, because the error only surfaces at delivery, and it is also the easiest to have confirmed through another channel.
Your product references exist in no corpus
An internal reference is, by construction, absent from everything a model was trained on. It mixes letters and digits according to a logic that belongs to you alone, and the system has to guess both the characters and how they are grouped.
The result is almost never a blank. It respects the shape — the right length, the right prefix — and gets one or two characters wrong, producing a reference that could have existed. That is the worst possible result, because nothing in its appearance signals the error.
The confusions are predictable and they recur: letters that sound nearly alike, the zero and the letter resembling it, digits spoken in groups that are recomposed differently. A catalogue whose references differ by a single one of those characters is a catalogue designed for writing and read aloud.
This is where the solution is partly at your end rather than in the system: an engine never exceeds the quality of the catalogue it is given, and a reference that reads aloud cleanly is a catalogue decision before it is a transcription problem.
Digits, and where they break
Numbers are transcribed better than names and they break anyway, for a reason that has nothing to do with the above: how they are said. A phone number spoken in twos, in threes, or digit by digit produces three different transcriptions of the same number.
Add the switch from one language to another mid-sentence, which is the norm rather than the exception in a commercial call here. A customer gives their name in Arabic, their neighbourhood in Arabic, and their number in French or alternating, and the system has to change register in the middle of one piece of data.
The good news is that digits are the easiest data to check automatically, because they have a shape: an Algerian phone number has a known length and prefix. A format check rejects most errors while knowing nothing about the customer.
It is the only category where automatic correction is reasonable, and on one strict condition: correct towards a valid form, never towards an existing value. Completing an incomplete number by matching it to another customer’s is the kind of error that sends an appointment confirmation to the wrong person.
Why correcting inside the model does not work
The first instinct is to want to improve the transcription: teach it the names, adapt it, specialise it. That is possible up to a point, it requires data, and it addresses the problem badly for a fundamental reason.
The vocabulary you are missing is not stable. Your customers change, your catalogue changes, a new commune appears in your deliveries. An adapted model is adapted to one state of your business, and it has to be readapted at every change — which is a recurring project where you wanted a solution.
There is something more decisive: even a perfectly adapted system will sometimes be wrong, and the question is not eliminating the error but knowing when it happened. A model that is wrong less often but always silently gives you nothing more than before.
The answer is therefore not in the model but after it, in a layer comparing what it produced against what you already know. It is less impressive and it is built in days rather than months.
The matching layer: your lists, not the model
The principle fits in one sentence: the transcription’s output is not data, it is a hypothesis, and it is checked against your real lists before entering anything. Your customers, your delivery communes, your product references.
Technically it is a difference-tolerant search rather than an exact match, and tuning it is the whole job. Too strict and it finds nothing and you are back where you started; too loose and it matches two different customers, which is far worse than finding nothing.
That tuning is done on your data and not on a general principle, because it depends on the size and shape of your lists. A base of three hundred customers tolerates a great deal; one of thirty thousand where several people share a common surname tolerates almost nothing.
The matching also has to be able to answer “several candidates”. That is a legitimate result and it is the one quickly-built systems do not provide for: they take the first, which produces exactly the silent error this whole layer existed to avoid.
Flag rather than correct
This is the rule that changes the systems we see most, and it is counter-intuitive: when the match is not certain, do not correct — say so.
A silent correction turns a visible error into an invisible one. Before, an obviously wrong name in a record alerted whoever read it; after, a plausible wrong name no longer does. The system improved the statistic and degraded the detection.
What “flag” means in practice is short: the record carries the value chosen, a mark saying it is uncertain, and the raw transcribed value beside it. Somebody picking up the file sees immediately what was guessed, which takes a second and saves a wasted journey.
For a voice agent there is one extra move and it costs little: ask for a repeat, or better, ask for confirmation through another channel for the expensive fields. A confirmation message containing the address as it was understood settles the neighbourhood question for good.
In writing, the same break in another form
The problem is not specific to voice, and a business with a written assistant meets it in another form. The customer types it themselves, so there is no transcription error — there are multiple spellings, typing mistakes, and names written in two alphabets depending on the keyboard available.
The consequence is identical: an exact search fails, and the system answers that it cannot find the file while looking straight at it. The customer knows they are a customer, and “I cannot find your order” is received as incompetence rather than as a spelling question.
The matching layer is therefore the same, and that is the good news in this article: it is built once and serves both channels. It is also why it is better placed between the assistant and your data rather than inside the assistant.
One useful difference remains: in writing you can ask for a correction without it being unpleasant. Offering three candidates and letting the customer choose is natural in a written conversation, and impossible on the phone without lengthening the call.
What this changes about choosing a supplier
A voice agent demonstration is nearly always done on general sentences, and they work. So the question to ask during a demonstration is a precise one: give it twenty names and twenty addresses from your own files, live, and listen.
What distinguishes suppliers is not transcription quality — they all use similar systems — but what they do with uncertainty. A supplier with no answer to “what happens when the match hesitates” has not built the layer this article is about.
The second question is about the lists: can the system consult my files to check, and in what form. A voice agent with no access to your database is an agent that guesses, whatever its quality otherwise.
The third is about the record. The weekly listening session is what surfaces the missed words, and it assumes calls are kept and can be listened to. A system that keeps nothing does not improve, because nobody knows what it is getting wrong.
The twenty-name test
Here is the check, and it is done this week, without us and without a project. Take twenty customer names from your file — not the easy ones, taken at random — and twenty real delivery addresses.
Read them aloud to the system you are considering, or to the one you already have, as a customer would say them: without spelling, at normal speed, switching language if that is what your customers do. Note what comes back.
Count three things, separately. How many are exact. How many are wrong but plausible — another real name, another real commune. And how many the system flagged as uncertain. It is the second number that decides: those are the errors nobody will see.
Its full version — sample, human reference, normalisation rule and scoring sheet — is the measurement protocol published here, for the day a comparable figure becomes necessary.
The third number judges the supplier more than the first does. A system transcribing fifteen names out of twenty and flagging the other five is usable; one transcribing seventeen and flagging nothing produces three invisible errors every twenty calls, and that is the expensive version.
What we do, and what we refuse
We build the matching layer against your real lists and tune it on your data, with the uncertainty threshold written down and adjustable. We also put in the display of the raw value beside the chosen one, which is the least impressive part and the one that saves wasted journeys.
We run the twenty-name test on the system under consideration before it is bought, and we show you the second number. That is half a day and it has changed minds more often than it has confirmed a choice.
We publish no recognition rate, neither ours nor a supplier’s. We have no annotated audio corpus and no comparison between models, and a figure offered without those would be an invented measurement presented as a measurement — exactly what this article reproaches a system for when it guesses without saying so.
And we do not put in silent automatic correction on a name or an address, even when it is asked for and would make better statistics. It turns an error a person would have seen into one nobody will see, and it is the only setting in this field we refuse to deliver.
Frequently asked questions
Can a voice agent learn our customers’ names?
Transcription can be helped with a list of expected words, and that improves the commonest cases. It does not replace the matching layer, for two reasons: your vocabulary changes constantly, and even a well-helped system will sometimes be wrong — the question is not eliminating the error but knowing when it happened.
Should names be spelled out on the phone?
For a name, often yes, and it is acceptable to the caller if it only happens once. For an address it is long and tiresome, and confirmation by message is almost always the better option: it is written, the customer can check it, and it settles the neighbourhood for good.
Does the problem exist in Arabic too?
Yes, and differently: the difficulty is no longer the multiplicity of Latin spellings but the thin presence of local names in training corpora. The error mechanism is the same — an unknown word is replaced by the nearest known one — and the answer is the same: match against your lists rather than improve the transcription.
How long does the matching layer take?
Building it is counted in days; tuning it happens on your data and requires a second pass after a few weeks of real use. That is considerably less than adapting a model, and it has the advantage of not needing to be redone every time your catalogue or your customer base changes.
Why do you not give an error rate?
Because we have no annotated audio corpus and no comparison between models, and a rate offered without those would describe something other than what it claims to measure. The only useful figure here is yours, and the twenty-name test produces it in half an hour on your own files.
Does our catalogue have to change?
Sometimes, and it is the least expected conclusion on this subject. References distinguished only by a character that is easy to confuse aloud are designed for writing; changing them costs less than a system meant to guess them, and it also helps the calls humans handle.
Where we come in
On your twenty names, it is not the number of correct ones that decides: it is the number of wrong ones that look right, because nobody will see those go past.
- Every hypothesis the system forms is checked against your files, at a threshold you can raise or lower.
- What was heard stays visible under what was kept: the hesitation reads at a glance.
- The supplier sits the twenty-name trial in front of you, before any commitment is signed.
A silent rewrite of a surname or a neighbourhood will never leave our hands, however firmly it is asked for: it hides what a human eye would have caught.
Read next
Measuring darija transcription: the protocol, and the figure we do not publish
Nobody publishes an error rate for Algerian darija, us included. Here is the protocol that would produce one, and what to know before reading it.The cost of a call, minute by minute
Four meters run during a voice call and none of them counts the same thing. Confusing them gives an estimate wrong by a factor, not by a margin.Voice agent: the thirty-second test
A voice agent does not replace your switchboard. It takes the calls nobody takes — and only the ones that fit in thirty seconds.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.