Voice notes: transcription is lossy, confident, and worth having anyway

A significant number of people would rather talk than type, and for some of them it is the difference between using your business and not. Somebody driving, somebody carrying shopping, somebody whose first language is not written easily, somebody with arthritis or dyslexia, somebody describing a noise that a machine is making. All of them send voice notes, and a system that ignores them is closed to a group of customers who have already tried to reach you.

The complication is that transcription produces text which looks exactly as reliable as text somebody typed, and is not. Everything worth saying about handling voice follows from taking that asymmetry seriously.

What we'll cover

• Who actually sends voice notes
• Transcription is lossy and sounds certain
• Where it fails most
• Never act on a transcript that costs money
• Building it with CodeWords
• What is lost even when the words are right
• The long voice note
• Replying in voice, and when not to
• Privacy, because a recording is different
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Who actually sends voice notes

Worth knowing, because it changes how seriously you take the failure cases.

People with their hands full. Driving, working, carrying a child. They will not type and they are not going to wait.

People for whom writing is harder than speaking. Dyslexia, limited literacy in the written form of a language they speak fluently, a language whose script is awkward on a phone keyboard.

People with a physical reason. Arthritis, tremor, poor eyesight, temporary injury.

People describing something audible. A rattle, a hum, a bang. Speech is not even the point; the recording is.

People who find it faster, which is a large and growing group in many markets.

The accessibility cases are the reason this is worth building properly rather than as a novelty. For those customers, a business that cannot receive a voice note is a business that has effectively asked them to find somebody else.

Transcription is lossy and sounds certain

The core problem is a mismatch in appearance. A transcript arrives as plain text, indistinguishable in form from something typed, and everything downstream treats it with the same confidence.

The dangerous failures are not gibberish. Gibberish is obvious and gets handled. The dangerous ones are plausible: a number heard wrong, a negation dropped, a name replaced with a similar word, "can't make Tuesday" becoming "can make Tuesday".

So the first design decision is to keep the transcript marked as a transcript all the way through, rather than converting it into text and forgetting where it came from. Anything acting on it should know it is acting on a guess.

Where it fails most

Predictable, and worth designing around specifically.

Numbers. Prices, quantities, dates, phone numbers, reference codes and postcodes are exactly what business conversations turn on and exactly what recognition handles least reliably.

Names, including your own product names and anything unusual.

Accents and dialects, where quality varies considerably and not in ways you can test from one office.

Background noise. A workshop, a road, a kitchen, a building site. Much of this audio comes from noisy places by definition.

Negation. Small words that reverse meaning are easy to lose and change everything.

Overlapping speech, where somebody else is talking in the room.

Very short notes, where there is not enough context to disambiguate.

The pattern is clear enough to act on: treat numbers, names and negations as low confidence by default regardless of what the transcript looks like.

Never act on a transcript that costs money

The rule that prevents almost all of the harm.

Anything with a consequence gets confirmed in writing before it happens. Booking, cancelling, changing a date, approving work, agreeing a price, changing an address, anything about payment. The confirmation is short and it is the whole safeguard.

"I have that as cancelling Thursday the 14th and rebooking for the 21st. Reply YES to confirm." One line, and the transcription error becomes a correction rather than a wasted visit.

Two supporting rules. Read numbers back explicitly, in full, because that is where the errors live. And where confidence is low or the note was hard to hear, say so plainly and ask rather than guessing: "I could not make out the reg, could you send it as text?" is a good answer and nobody minds it.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what happens when audio arrives, what is transcribed, what is confirmed before acting, and what goes to a person.
3. Authorize the connections to wherever jobs or bookings are recorded and your WhatsApp Business Platform account.
4. Describe the exceptions: a note that cannot be transcribed, one in a language you do not support, one containing anything urgent, one longer than the flow can sensibly handle.
5. Test with recordings from the environments your customers are actually in, since a clean recording from a quiet room tells you nothing useful.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What is lost even when the words are right

A perfect transcript still throws away most of what was in the recording.

Tone. Frustration, distress, anger and sarcasm are in the voice and not in the text. A transcript reading "great, so nobody's coming today" loses the entire meaning.

Hesitation and uncertainty, which frequently signal that somebody is unsure whether to raise something.

The audible thing itself, where the customer recorded a noise rather than describing it.

Who is speaking, in a household with several people.

Two consequences. Keep the original audio and link it to the conversation, because a person taking over needs to hear it, particularly where the customer is upset. And where anything suggests distress or a complaint, route the audio to a person rather than replying from the transcript, since the transcript is exactly where the emotional content has gone missing.

The long voice note

Some people send four minutes. It usually contains one question and a lot of context, and it is a genuine design problem.

The temptation is to summarise it and act on the summary, which compounds two lossy steps. Better to extract the specific things you need, confirm them, and keep the rest available rather than discarded.

Where a long note clearly contains several requests, handle them one at a time and say so. And where it contains a story rather than a request, which is common and entirely human, the right answer is usually a person rather than a longer automated reply.

Replying in voice, and when not to

Generated speech is easy to produce and is not always the right response.

It works for the same people who sent one: a customer who is driving, or who reads with difficulty. It works badly for anything with numbers, dates, references or addresses in it, because a spoken reference cannot be copied, searched or checked, and the customer now has to write it down.

The workable default is to reply in text, and add audio only where the customer is clearly using voice by preference rather than convenience. Never send only audio for anything carrying a price, a date, a reference or an instruction. Those need to be readable and re-readable.

Privacy, because a recording is different

A voice note is more identifying than its transcript and it deserves separate treatment.

It carries the voice itself, background sounds that may reveal more than intended, and frequently other people talking in the room who never agreed to anything. It is also the category customers are least likely to think about before sending.

Practical handling: retain audio for less time than text, state in the first interaction that voice notes are transcribed and how long recordings are kept, do not pass audio to anything that does not need it, and treat a recording as media for retention purposes rather than as message content.

Where somebody asks what you hold about them, the recordings are part of the answer, which is another reason to know where they live.

Making it survive

Mark transcripts as transcripts throughout the system.

Confirm anything consequential in writing, reading numbers back in full.

Keep the original audio linked to the conversation.

Route distress and complaints to a person with the audio attached.

Set shorter retention for recordings than for text, and apply it.

Limits worth knowing about

Accuracy varies by accent and environment, and you cannot assess that from one office.

Numbers and names are the least reliable part and the most consequential.

A transcript loses tone entirely, which matters most exactly when it matters most.

Not every voice note contains a request, and some need a person by nature.

Recordings raise the privacy stakes, including for people in the room who did not send anything.

What to build first

The confirmation step. Before anything in your flow can act on a transcript, make it read the details back and wait for a yes, with numbers spelled out in full. It is one message and it neutralises the entire category of plausible transcription errors.

Two habits make the difference. Keep the original audio attached to the conversation, because the day somebody is upset is the day the transcript is least adequate and a person needs to hear what was actually said. And test with recordings made in the places your customers really are, since a clean sample from a quiet room will pass every time and tell you nothing.

Frequently asked questions

Why support voice messages at all?

Because a real group of customers use them by necessity rather than preference: people with their hands full, people for whom writing is harder than speaking, people with physical reasons, and people recording a noise. Ignoring voice closes the door on them.

How reliable is transcription?

Good enough to be useful and unreliable in exactly the places business conversations turn on. Numbers, names, negations, accents and noisy environments are the weak points.

What is the dangerous failure?

Plausible wrongness rather than gibberish. A misheard number, a dropped negation, "can't make Tuesday" becoming "can make Tuesday". Gibberish gets caught; plausible errors get acted on.

What should never happen from a transcript alone?

Anything with a consequence: booking, cancelling, changing a date, approving work, agreeing a price, or anything about payment. Confirm in writing first, reading numbers back in full.

What should happen if the audio is unclear?

Say so and ask, rather than guessing. Asking somebody to send a registration or postcode as text is a perfectly good answer and nobody objects.

What does a transcript lose even when correct?

Tone, hesitation, the audible thing itself, and who is speaking. That is why the original audio should stay linked and why distress or complaints should go to a person with the recording attached.

How should long voice notes be handled?

Extract the specific things you need and confirm them rather than summarising and acting on the summary, which stacks two lossy steps. A note containing a story rather than a request usually needs a person.

Should the bot reply with audio?

Sometimes, for customers clearly using voice by preference. Never for anything carrying a price, date, reference or instruction, since spoken details cannot be copied, searched or checked.

Are voice notes a bigger privacy concern than text?

Yes. They carry the voice itself, background sound, and often other people in the room. Retain them for less time than text, say that they are transcribed, and know where they live for access requests.

How should this be tested?

With recordings made in the environments your customers are actually in, across the accents you actually serve. A clean sample from a quiet office passes every time and proves nothing.

Related reading

• Multilingual bots and what never gets translated
• The edge cases that actually matter
• Data protection for a messaging bot