Voicebot, IVR or chatbot: what each is, how it works, and when each is enough

A voicebot is a program that answers the phone and holds a conversation: it listens, turns the sentence it heard into text, establishes what the matter is, checks the data in the company’s systems and replies in a synthesised voice. It is also written as voice bot; in Polish it is a bot głosowy. One thing separates it from a keypad menu: the caller speaks instead of pressing keys.

Three systems compete on a phone line and they are easy to confuse: IVR, voicebot and chatbot. We settle the choice between them not with a feature list but with one question — what does each receive on input, and what may it conclude from that. Everything else, the verdict “an IVR is enough” included, follows from that single answer.

What a voicebot is, and what it actually does

Inside there are four steps, and their names are worth knowing: speech recognition, intent detection, a read from the source system, and speech synthesis. What is not on that list matters more. The bot does not know what is on offer or the status of an order “from memory” — it can state only what it read live from the system where that information lives. That is what separates it from an answering machine, which always says the same sentence, and it is that step, not the voice itself, which requires an integration.

It is built either as a cascade of three components or as a single speech-to-speech model; the differences and our default choice are set out alongside what a voicebot costs. One thing survives both architectures: a cascade hands the next step a transcript, an end-to-end model works from the audio and may never produce one at all, and in either case what reaches the business logic is a hypothesis about what was said rather than the words themselves. The walkthrough below follows the cascade, because that is where the four steps are separately visible.

IVR: what it is, and why it is not the same thing as a voicebot

An IVR is an automated voice menu in which the caller picks a branch with a key. Pirios, a Polish contact-centre vendor, defines it in its glossary (updated July 2026) as a menu that routes the call on the basis of the customer’s choice — keypad or spoken — before it reaches an agent. In its classic form there is no recognition step at all: the system does not guess what it heard, because it is not listening.

A pressed key need not be a sound that has to be recognised, and that is no accident. IETF RFC 4733, of December 2006, defines a way for telephony to carry DTMF not as a recording but as a named event code, and gives the reason: low-bit-rate codecs do not reproduce tones faithfully enough for them to be recognised automatically. That payload is negotiated between the two ends rather than guaranteed on every call, but where it is in use the set of signals is closed — the same document registers sixteen named DTMF events: ten digits, star, hash and four rarely seen letters. A seven then reaches the application as a seven, not as a hypothesis.

The middle case is a speech-enabled IVR: the caller may say “complaint” instead of pressing a key. That is still not a voicebot, because the recogniser listens only for what somebody wrote into a grammar beforehand — the W3C Speech Recognition Grammar Specification 1.0 (a Recommendation of 16 March 2004) describes it as a record of the words and patterns of words a recogniser is to listen for. The set of admissible answers is therefore declared in advance — like the list of keys, though not always as short.

That is not to say callers are fond of IVRs — the Polish Wikipedia article gives criticism of them a section of its own (revision of 22 June 2025), and everybody has met the menu where, four levels in, the right option still has not appeared. That, though, is a charge against a particular tree, not against the technology.

Chatbot versus voicebot: a chatbot gets exactly what was typed

A chatbot receives exactly the characters the person sent. There is no recognition step, so there is no place where a seven could turn into an eight. Its uncertainty begins only at the level of understanding — it does not always know what the text meant, but it always knows which text it got. A typo is visible on both sides and the person corrects it themselves, before anything happens.

And its whole job ends with an answer displayed on a screen — we described that boundary, and the test that detects it, in the difference between an agent and a chatbot, and how the text channel joins up with the telephone one on the page about customer service automation.

What each one receives on input — and what it may conclude from that

An IVR receives exact codes from a closed list of keys — one for a menu choice, ten in a row for a tax number — a chatbot exactly the characters somebody typed, and a voicebot only the most likely hypothesis of what it heard. That one difference settles the choice.

The same telephony platform treats a key and speech as two different input types: in Twilio’s documentation for the Gather verb (read on 8 September 2026) the step that collects an answer accepts the keypad, speech, or both at once. What comes back differs, though. For the keypad — a field holding the digits pressed, and no measure of confidence beside it. For speech — a transcript, plus a confidence score on a scale from 0.0 to 1.0.

The documentation goes further and says something we found on none of the twelve Polish pages about voicebots that we read: it warns against treating the confidence score as a required field, because the provider guarantees neither its accuracy nor even its presence in the response. So not only is the transcript a hypothesis — the measure of its reliability is not a contract either. This is not one provider’s quirk: Azure returns, in its detailed mode, a list of competing transcripts with separate confidence scores, and Google states that the first alternative is always the most likely one (both sets of documentation read on 8 September 2026). The simple mode hides that uncertainty without removing it.

A speech-enabled IVR is the middle case here: the conclusions closed as in a keypad menu, the uncertainty as in a voicebot. Reading a value back is our design rule, but we did not invent it — the Amazon Lex V2 documentation (read on 8 September 2026) carries a ready-made confirmation step in the intent definition, one to switch on rather than a default, with a separate branch for when the caller’s answer cannot be resolved as a “yes” or a “no”. Because that “yes” is recognised speech too.

How a voicebot works: one call, step by step

An illustrative call: the customer asks about the status of an order and gives a NIP — the Polish ten-digit tax identification number. At each step we note what an IVR does at that point, and what a chatbot does.

One word about sequence: a full, unattended conversation is the shape of a mature deployment, not of a first pilot. We start with one matter, and with the cases where being misheard costs nothing.

1. The bot says that it is a machine. It always does — with us more bluntly than the EU AI Act has required since 2 August 2026; how we word that sentence is set out alongside a voicebot deployment. An IVR starts with a recorded greeting and a list of options; a chatbot says the same thing in its first message.
2. The utterance travels from the line to the recogniser. An IVR records nothing here — it waits for a key code; a chatbot has no such step at all.
3. Recognition turns sound into text. Back comes a transcript, usually with a confidence score beside it — the field the documentation above says is not guaranteed. This is the one place where a word turns into a different word without either side knowing.
4. The bot establishes the intent. An IVR has it settled the moment the key goes down; a chatbot derives it from text it knows it received in full.
5. The bot reads the data from the source system. This step is not what divides the channels: the Gather step cited above hands the keyed digits to your own application, so a programmable IVR can look the same thing up. A chatbot does exactly the same thing, only it displays the result.
6. The bot repeats the NIP and asks for confirmation. We give the reason below. An IVR and a chatbot have no recognition error to catch here — the first got the digits as they were pressed, the second as they were typed — so what they confirm is decided by the cost of acting on a wrong value, not by the channel.
7. The synthesiser speaks the answer. A menu assembled from recordings says only what was recorded in advance; a programmable IVR reaches the same synthesiser this step uses. A chatbot writes the text out.
8. The case goes back to a person, with the transcript. An IVR hands over the call itself and a branch number, a chatbot the chat history. A handover with no record of what the bot heard means the customer tells the whole story again.

Ten digits given by voice

We have no measurements of our own for digit recognition on a Polish telephone line. The table below is not a measurement — it is a worked example, showing only how the arithmetic compounds under different assumptions. It also assumes that the ten digits go wrong independently of one another — an assumption one speaker on one poor line will not honour — so read the rows as an illustration of how a ten-digit field degrades, not as a forecast. The per-digit error rate is one you pick yourselves.

The arithmetic is trivial — accuracy on a single digit, that is one minus the assumed error rate, raised to the tenth power — and that is the point. A ten-digit field degrades far faster than a single-item one, so a bot that flawlessly recognises the choice “sales enquiry” out of four options is not thereby good at taking a NIP.

Why the bot reads the number back before it uses it

We constructed the number 5270000001 for this example: it satisfies the check-digit rule, but it comes from no register and we assign it to no company. The properties below are the arithmetic of the publicly documented NIP check-digit algorithm, not a measurement.

• Every single mangled digit is caught. Provably: none of the weights is divisible by eleven, and the difference between two digits never exceeds nine.
• Every swap of two neighbouring digits is caught. The same arithmetic, the same certainty.
• An invented string of ten digits passes roughly one time in eleven, that is in 9.1% of attempts. The checksum on its own cannot do better than that, and there is no way of raising it without asking the caller.
• Swaps between positions 1 and 8, 2 and 7, and 3 and 9 are invisible to the checksum. Those pairs carry the same weight, so transposing the digits does not change the result. We found that caveat on none of the vendor pages we read.

The conclusion fits into two sentences. The checksum says only that the number is correctly constructed; reading it back and asking for confirmation closes a different gap — whether the bot heard the number the caller actually gave. Neither says the number belongs to the caller: a NIP is public, so anyone can confirm one they happen to know, and access to records or any change to them needs a separate identity check. The same NIP entered on a keypad arrives without the recognition error, and the checksum catches the ordinary slip of a finger — everything but the three transpositions listed above — so what is left to confirm there is a question about the action, not about the channel. That is exactly where the answer “an IVR is enough” begins.

Why a phone line is a harder case than a demo

On spontaneous speech — and a telephone conversation is precisely that — systems recognising Polish do markedly worse than on read speech. In the peer-reviewed paper on the BIGOS V2 dataset (Michał Junczyk, Adam Mickiewicz University and Allegro, the Polish e-commerce company; NeurIPS 2024), commercial systems did better on read speech than on conversational speech by about 17 percentage points, and free ones by about 19. The figure comes with a caveat: only some of the recordings in that dataset come from a telephone line, so it marks a direction rather than a result for your own switchboard. What follows from that for the bill, and what vendors do not say about the Polish language, we set out alongside the voicebot bill.

When an IVR is enough

A plain keypad menu is enough more often than vendors’ pages would suggest — ours included. It is the right answer when everything the caller has to convey can be declared in advance, and in particular when:

• The task ends with routing the call. A voicebot then adds nothing beyond cost and a new place where something can be misheard.
• Nobody has to give a value that is not on the list. A number chosen on a keypad arrives as it was entered; the same number given by voice has to be read back, because it arrived as a hypothesis.
• Nothing has to be checked live — or the lookup runs on keyed digits. Opening hours and a bank account number can be recorded; a read from a system that changes during the day requires an integration, and integration is covered by no published price list — it is quoted separately. That cost falls the same way whichever channel asks for it, so it is a reason to price the work carefully, not a reason to reach for speech.
• The branches are stable. A menu that regular callers learn by heart has an advantage a voicebot will not reproduce: repeatability. That is our judgement, not a measurement.

We will not give a threshold number of branches past which a menu becomes too large; figures of that kind circulate online with no stated method. What matters more in any case is that the choice is not exclusive: a tidy IVR is often the foundation on which a voicebot is added later, one matter at a time, with the keypad left as the fallback path — the Gather step cited above accepts both input types at once. The conditions a process has to meet before it is a candidate for AI automation in a company are the same whatever the channel: repeatability, data that can be read, and a person who approves what the bot has prepared.

When a voicebot is not the answer

There are situations in which we advise against one whatever the budget.

• Traffic is already routed correctly. If the IVR in the call centre works and the complaints are about waiting time, that is a staffing problem, not a channel problem — a voicebot will not solve it, only move it.
• The answer calls for judgement, not a lookup. A bot will state the status of a case. It will not settle whether to make an exception.
• Company policy says a person is to do the talking. That is the company’s decision, not a technical one, and we treat it as overriding.

We keep the full list of matters we do not hand to a voicebot on the page about voicebots for business, and we settled the purely economic cases — a small volume of unanswered calls, and a plain answering service — in the piece on when a voicebot is not worth buying.

What to do next

Before anybody shows you a demo, this is worth doing in the coming week:

1. Pull a three-month report from your switchboard and list the matters customers call about most often.
2. For each one, answer a single question: does the caller have to give a value that cannot be picked from a list? If not, it is a matter for a keypad menu.
3. Of the rest, mark the ones where that value cannot be keyed in digit by digit either — a description of a fault, a name, a street. Only those are candidates for a voicebot; a live lookup on its own is not, because a keypad menu can trigger the same lookup.
4. Check whether today’s menu leads to them at all. Fixing the tree needs no new system, and it is worth doing before pricing anything else.

If you would like to work through this on your own numbers, get in touch — including when the answer turns out to be “stay with the IVR”.