A voicebot is a program that answers the phone and holds a conversation: it listens, recognises the sentence it heard (usually by turning it into text), establishes what the matter is, checks the data in the company’s systems and replies in a computer-generated 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 are easy to confuse: IVR, voicebot and chatbot. We compare them by what they receive from the caller — a keypress, speech or typed text — and what they can conclude from it. Everything else follows from that, including when an IVR is enough.
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 is stored. 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.
A bot is built in one of two ways: from three separate modules (speech recognition, a language model that decides the answer — an AI engine like the one behind ChatGPT — and speech synthesis) or from one model that performs all these tasks. We set out the differences and our default choice in what a voicebot costs. The three-module version passes on a text of the conversation (a transcript). The single-model version works straight on the audio and may never write the conversation down as text. Either way, the part of the system that checks data and takes action receives not the caller’s words but a best guess at what they said. What follows describes the three-module version, because only there can the four steps be seen separately.
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, describes how to send telephone keypad signals (DTMF tones) not as audio but as a ready-made code. It also gives the reason: some audio compression methods (low-bit-rate codecs) distort keypad tones too much for them to be recognised automatically. The devices at both ends agree whether to use this format, so it is not guaranteed on every call. Where it is used, though, there are sixteen possible signals, registered in the same document: ten digits, star, hash and four rarely seen letters. A seven then reaches the application as a seven, not as a recognition result.
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 system only recognises words and word patterns described in advance in a set of rules, a so-called recognition grammar. 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 acceptable answers is therefore fixed beforehand — 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.
Keypress, speech or text: what the system receives and how far to trust it
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 its best guess at what it heard. That one difference settles the choice.
The same telephony platform treats a key and speech as two different kinds of answer. In the documentation of the Twilio telephony platform (read on 8 September 2026), the Gather step, which collects the caller’s 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 the transcript is only the most likely version of what was said, and the reliability score is not guaranteed either. This is not one provider’s quirk: in detailed mode Azure returns several alternative versions of what may have been said, each with its own confidence score, 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.
| IVR | Voicebot | Chatbot | |
|---|---|---|---|
| What the caller does | presses a key | speaks | types |
| What the system gets | the exact code of the key pressed | a transcript, plus a confidence score that may be absent | exactly the characters sent |
| What it may conclude | one of the prepared options | its best guess at what was said | exactly what was typed |
| What a mistake costs | one keypress to correct | a wrong digit reaches the system | a typo both sides can see |
| What must be confirmed | whatever the action’s own risk demands | that, plus every value the recogniser supplied | whatever the action’s own risk demands |
A speech-enabled IVR is the middle case here: answers from a closed list, as with a keypad menu, but recognition uncertainty as with a voicebot. Reading a value back is our design rule, but we did not invent it — Amazon Lex V2 (documentation read on 8 September 2026) has a ready-made confirmation step. It is not on by default: you switch it on in the definition of a given request type (an intent). It has a separate path for when the caller’s reply cannot be taken as either 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.
- 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.
- 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.
- 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.
- 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.
- The bot reads the data from the source system. This step does not distinguish between channels: a programmable IVR also passes the keyed digits to your system (in Twilio, the Gather step above does this) and checks the same thing. A chatbot does exactly the same thing, only it displays the result.
- 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.
- 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.
- 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
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.
| Assumed error per digit | All ten digits correct | At least one wrong |
|---|---|---|
| 1% | 90.4% | 9.6% |
| 2% | 81.7% | 18.3% |
| 3% | 73.7% | 26.3% |
| 5% | 59.9% | 40.1% |
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. This follows from the arithmetic: none of the weights in the algorithm 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 is simple. A checksum only says the number is correctly formed. Reading it back and asking for confirmation checks something else: whether the bot heard the number the caller gave. Neither confirms that the number belongs to the caller. A NIP is public, so anyone can confirm one they happen to know — before access to records or any change to them, identity has to be verified separately. The same NIP entered on a keypad arrives with no recognition error, and the checksum catches an ordinary slip of the finger (except for the three transpositions listed above). What remains is a question about the risk of the action, not the channel. And 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 recognition result that may be wrong.
- 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 whose cost depends on the client’s API (the interface other software uses to work with its systems), even where a vendor lists a base price for an integration. 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 another solution works better
A voicebot is one of several tools on a phone line. In these situations something other than the voice channel solves the problem:
- 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.
Which matters we start an implementation with, and how we set the limits of what the bot may say, are on the page about voicebots for business. The economics — from the number of unanswered calls to the four lines on the price list — are set out in the piece on what a voicebot costs.
What to do next
Before anybody shows you a demo, this is worth doing in the coming week:
- Pull a three-month report from your switchboard and list the matters customers call about most often.
- 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.
- 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.
- 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 — we will show which matters a well-ordered keypad menu can handle and which are worth giving to a voicebot.
Sources, as at 9 October 2026
- IETF RFC 4733 — carrying DTMF tones and their distortion by low-rate codecs; read on 9 October 2026.
- W3C Speech Recognition Grammar Specification 1.0 — speech recognition grammars; read on 9 October 2026.
- Pirios glossary: IVR (Polish); read on 9 October 2026.
- Polish Wikipedia: Interactive voice response — the criticism section; read on 9 October 2026.
- Twilio TwiML Gather — keypad and speech input, confidence for speech; read on 9 October 2026.
- Microsoft Learn: speech-to-text REST API for short audio — the NBest list with a confidence score; read on 9 October 2026.
- Google Cloud Speech-to-Text basics — the order of transcription alternatives; read on 9 October 2026.
- Amazon Lex V2 intent confirmation; read on 9 October 2026.
- M. Junczyk, “BIGOS V2 Benchmark for Polish ASR”, NeurIPS 2024 (PDF) — read versus conversational speech; read on 9 October 2026.
- Polish Wikipedia: NIP — the NIP weights and checksum; read on 9 October 2026.