Voice Input in AI Chat: Customers Speak Instead of Typing

64 percent of smartphone users have already used voice assistants (Bitkom). How voice input works in a website chat and which legal rules apply to it.

In plain language

In the chat, the visitor can speak instead of typing. They tap a microphone and say what they need. The text that was heard shows up in the input field first and can be changed before sending. The reply comes as text, as usual. Speaking helps on the go, with your hands full and for long questions. The text field stays next to it, for example in an open office. Errors often come from dialect, names, numbers and noise. Voice recordings are personal data and belong in the privacy policy.

July 27, 2026 12 min read By XICBOT

Key points

Speaking instead of typing works like this: the visitor taps a microphone icon, says what they need, and the recognised text appears in the input field first, editable before sending; the reply arrives as text, as usual.
64 percent (Bitkom) of smartphone users in Germany have already used voice assistants and 56 percent (Bitkom) use chatbots on their device; both figures come from a survey of 1,006 people (Bitkom) aged 16 and over.
Voice pays off on mobile, with hands full on a building site and for long, detailed requests; it comes in as a second input path alongside keyboard and pointer, yet it does not replace the text field, for example in an open-plan office. The WCAG 2.2 (W3C) guidelines explicitly cover limited movement as well as speech disabilities.
Voice input alone beats a full spoken dialogue as a starting point: it can be retrofitted, tolerates latency and leaves a complete text log. A mobile-only start, measured over four weeks on abort and correction rates, shows whether more is worth it.
Recognition errors come mainly from dialect, product names, order numbers and background noise; a dictionary of company-specific names, a read-back for figures and appointments, and the editable transcript before sending catch most of them.
Voice recordings are personal data; processing location, retention period and deletion deadline belong in the privacy policy. The transparency duties under Article 50 of Regulation (EU) 2024/1689 apply from 2 August 2026 (European Commission).

Why voice is a normal input method in 2026

The usage figures are no longer a niche finding. Of the 1,006 respondents (Bitkom) in the current Bitkom survey, 861 (Bitkom) used a smartphone, and within that group 64 percent (Bitkom) have already used a voice assistant. In parallel, 38 percent (Bitkom) say they use AI features on their device regularly; among those under 30 it is 54 percent (Bitkom). Anyone opening a website today therefore brings along a habit that has long been established elsewhere. Speaking to a device no longer feels like an experiment to a large share of visitors, it feels like a shortcut.

A second finding from the same survey is just as telling: 53 percent (Bitkom) do not know in detail where AI is actually at work inside their device. Applied to a website chat, this means habit and understanding have drifted apart. People talk to technology as a matter of course without knowing what happens behind it. That is precisely why transparency and clear labelling belong to a voice feature from day one. If you first want to clarify what such an assistant actually does, the overview of what an AI chat assistant is covers the basics.

On the company side, the pressure is rising in parallel. A Gartner survey of 321 customer service and support leaders (Gartner) found that 91 percent (Gartner) of them feel pressure from executive leadership to implement AI. The same survey also shows that only 20 percent (Gartner) actually reduced service headcount due to AI. The message behind that is sober: AI features are being added, not treated as a replacement. Voice input fits this pattern exactly, because it makes an existing channel more convenient instead of opening a new one.

The core in one sentence

Voice input replaces neither a channel nor a member of staff. It removes the typing effort for visitors on a smartphone, while the answer, the transcript and the handover stay exactly as they already are in the text chat.

Where voice input delivers a real advantage

Voice is not an end in itself. It pays off where typing is awkward, slow or simply impossible, and it adds little where a question is asked in three words anyway. The share of mobile visits therefore predicts the benefit better than the industry does. If the assistant sits in the right place in the layout and is easy to reach on a phone, the microphone becomes a logical extension of the input field rather than another button nobody looks for.

On the move

Someone asking on the train, as a passenger in a car or at a bus stop formulates far more quickly by speaking than with a thumb on a small keyboard.
Trades with busy hands

On a building site, hands are dirty or in gloves. A spoken request to the assistant for trades and crafts still works in that situation.
Long, detailed matters

A damage report, a custom enquiry or a complaint needs context. Spoken requests turn out longer and more complete than typed ones.
Older audiences

Small keyboards and typing errors are a real barrier. For many people, speaking is the more familiar way to describe a concern.
Motor impairments

Anyone who can only use a keyboard to a limited degree gains noticeable independence from a second input path.
Non-native speakers

People who speak a language but write it with hesitation get further by speaking. This matters especially with a multilingual assistant.

The counter-check matters just as much. In a shop where the most common question concerns the whereabouts of an order, voice saves hardly any time, because two buttons are faster. And in settings where people cannot or do not want to speak out loud, in an open-plan office or a crowded train, the text field stays the preferred route. A voice feature should therefore be offered, not enforced: the microphone sits next to the input field, and the text field remains the default. That order sounds trivial, but it decides whether a voice feature is experienced as help or as an imposition.

How voice input works technically in the browser

The sequence is simpler than it sounds, and it differs from a phone assistant in one decisive respect: there is no open channel. The browser only records once someone actively taps the microphone icon, and it stops as soon as the recording ends. Everything technical happens between those two taps, and afterwards the sensor is silent again.

Permission and start: the browser asks for microphone access. Nothing happens without an active user action and without consent, and a visible recording indicator shows the state throughout.
Recording: what is spoken is captured as a short audio segment, usually a few seconds up to roughly two minutes. A visible level meter helps, because it proves that something is actually arriving.
Transcription: the audio is transferred to the server and converted into text there. At XICBOT this step is not part of standard operation; where it runs is set in the project for the extra function.
Review: the recognised text appears in the input field instead of being sent immediately. Anyone who wants to correct a name or a number does so before sending.
Answer: the assistant replies as usual, as text in the chat history. Optionally the answer can also be read aloud, for example when the screen is out of sight.

Technically this is an add-on to the existing chat rather than a second system. The knowledge base, the tool connections and the handover to a human stay unchanged, because the end of the chain is text again. That is why voice input can also be added later, once the assistant is already running. How embedding into a website and shop works in principle is described elsewhere, and the technical integration with existing systems does not change because of a voice feature.

Voice input only or a full voice dialogue

Two very different things are often lumped together in enquiries and tenders. Voice input only means speaking instead of typing, with the answer as text. A full voice dialogue means speaking and hearing a spoken answer, ideally with interruptions and a natural rhythm. The difference in effort is substantial, and it often decides whether a project goes live in a few weeks or only after months.

Criterion	Voice input only	Full voice dialogue
Sequence	Speak, review the text, send	Continuous conversation with a spoken answer
Effort to introduce	Low, can be added as an extra function	Considerably higher, needs its own concept
Latency	Uncritical, the user reviews the text anyway	Critical, every delay feels like a dropout
Drop-off behaviour	Harmless, the text stays in the input field	Breaking off mid-sentence must be handled
Error correction	Visible and possible before sending	Only through follow-up questions in the conversation
Traceability	Complete text transcript by default	Transcript only through additional transcription
Typical use	Website and shop chat on a smartphone	Hands-free scenarios, workshop and telephony

For most mid-sized websites, voice input only is the better first step. It delivers most of the benefit, costs a fraction of the effort and can be measured before bigger decisions are made. A full voice dialogue pays off where hands and eyes are genuinely occupied, for example in a workshop, a warehouse or field service, and where the effort is justified by repeating routines. Introducing both at once noticeably extends the project without increasing the benefit to the same degree.

Quality pitfalls: dialect, jargon, order numbers

Speech technology is good today, but it is not neutral. It is trained on standard language and starts slipping exactly where things get interesting for a company: proper names, article designations and numbers. A dialect, a swallowed word ending or a noisy environment shift the result further. Ignore this and you receive enquiries that look formally clean but miss the point, and you notice only when a quote is based on the wrong article number.

Dialect and speaking pace: regional colouring, high speed and clipped word endings create gaps. Short sentences are recognised more reliably than long nested ones.
Jargon and product names: material designations, type codes and proper names are rarely part of general vocabulary and otherwise end up in the transcript as a similar-sounding everyday word.
Numbers, measurements and order numbers: combinations of letters and digits are the most common source of error, because they cannot be inferred from the context of the sentence.
Ambient noise: building sites, workshops, traffic and hands-free car kits noticeably reduce recognition quality, regardless of how clearly someone speaks.
Multiple speakers: when people talk in the background, fragments mix into the transcript and produce sentences nobody actually said.

There is a concrete remedy for each of these pitfalls, and none of them is expensive. A dictionary containing the proper names, product lines and abbreviations used in the business improves recognition exactly where it counts. A read-back check for numbers, order references and appointments makes the assistant repeat what it understood before acting on it. And because the recognised text sits in the field before sending, the human corrects it if in doubt. Together, these three measures catch a large share of the typical errors. How solid content is built behind the scenes is described in the article on building a knowledge base; the point that an assistant should ask rather than guess when uncertain is covered in the piece on preventing hallucinations.

A voice feature is not judged by how good it sounds in a showroom, but by how it handles an order number while a compressor is running.

Project experience

Law and trust: microphone, audio, labelling

The microphone is a sensitive sensor, and visitors react cautiously to it. The basic technical rule is therefore simple: record only after an active user action, show the state visibly during recording, allow cancelling at any time and avoid continuous recording in the background. The browser asks for permission anyway, but the design decides whether that permission is actually granted. A microphone icon without an explanatory note is tapped far less often than one with a short sentence beside it.

Under data protection law, voice recordings are personal data, because a voice can make a person identifiable. Three points follow from that and should be settled before going live: where processing happens, how long the audio is kept and who gets to see it. At XICBOT, voice input is an extra function outside standard operation; these three points are set in the project for it. The basics are set out on the page about data protection and hosting, and the data protection classification of a chat assistant in the article on GDPR in an AI chat. A deletion deadline belongs in the record of processing activities, not in a verbal agreement.

On top of that comes the labelling obligation. Under Article 50 of Regulation (EU) 2024/1689, AI systems that interact directly with people must be designed so that those concerned can tell they are dealing with an AI; these transparency obligations become applicable from 2 August 2026 (European Commission). If the answer is also read aloud, artificially generated audio is created, which tends to tighten rather than relax the transparency requirements. Infringements of Article 50 can be sanctioned under Article 99 with fines of up to 15 million euros (Regulation (EU) 2024/1689) or 3 percent (Regulation (EU) 2024/1689) of worldwide annual turnover. What this means in detail is set out in the article on labelling duties under the AI Act.

Accessibility as a welcome side effect

A second input path is more than convenience. The Web Content Accessibility Guidelines of the W3C, currently in the WCAG 2.2 (W3C) version, assume that people use different input methods and switch between them. Success Criterion 2.5.6 on concurrent input mechanisms requires at level AAA that content does not restrict the input methods available on a platform without a compelling reason (W3C). Offering voice alongside keyboard and pointer works in exactly that direction.

Another criterion matters too, one you would not immediately associate with voice: 2.5.3 Label in Name (W3C) at level A requires the accessible name of a control to contain the text that is presented visually. People who operate their computer by voice command depend on precisely that, because they say what they see. A microphone button whose visible label differs from its technical name cannot be addressed by that group. The WCAG 2.2 version adds nine (W3C) further success criteria compared with its predecessor and has been a W3C Recommendation since October 2023.

One point remains central: voice does not replace keyboard operation, it complements it. A chat that could only be operated by microphone would create new barriers, for example for deaf people or for anyone who cannot or does not want to speak. The requirements for an accessible AI assistant under the accessibility act continue to apply unchanged, and voice input is added as an additional path rather than in their place.

What to measure after launch

Whether a voice feature is worthwhile can be answered within a few weeks, provided the right metrics run from the start. The important part is to count not only usage but also quality. A high number of voice messages combined with many corrections is a warning sign rather than a success, because it shows that recognition is lagging behind the company's vocabulary.

Share of messages created via the microphone rather than the keyboard, split by mobile and desktop.
Drop-off rate of the recording: how often is it started and discarded again without sending?
Average length of requests compared with typed messages, measured in words.
Correction rate: share of transcripts that are still edited in the field before sending.
Recognition errors per 100 voice messages, evaluated on a sample of real conversations.
Resolution rate and handover rate to a member of staff, each compared between spoken and typed requests.

These values accumulate in the chat history anyway and can be evaluated in the conversation analytics. A manual sample stays important: two hours in which someone reads fifty conversations reveal more about recognition quality than any aggregated metric, because error types only become visible in the wording. How to derive systematic improvements from chat histories is described in the article on analysing and optimising chats.

Effort and rollout for mid-sized companies

For an existing assistant, voice input is a manageable undertaking, because it sits at the start of the chain and leaves everything behind it untouched. The effort typically falls into four blocks, some of which can run in parallel, and only one of which really requires domain knowledge from the business.

Technical integration: microphone button, recording, permission dialogue, state indicator and passing the transcript into the input field.
Domain adaptation: a dictionary of proper names, product designations, abbreviations and place names used in the business, plus rules for read-back checks on numbers.
Law and wording: extending the privacy policy, a note inside the chat, defining the deletion deadline for audio and an entry in the record of processing activities.
Testing and refinement: recordings from realistic environments, meaning building site, workshop, car and office, rather than only a quiet desk.

The biggest mistake in this sequence is a fourth block that is too short. A voice feature tested only in the office performs noticeably worse in daily use than it did during acceptance. A limited start is therefore sensible: offer voice on mobile first, measure for four weeks, then decide whether to roll it out on all devices. What a structured acceptance process with test cases looks like is shown in the article on the go-live of an AI assistant.

At XICBOT, voice input is not a standard button but an individual extra function of the existing assistant. It is trained on the terms used in the business and can be added later without rebuilding the running chat. The same principle applies to related extensions: how an assistant handles uploaded photos is described in the article on image upload in an AI chat, and how the same approach can be turned inwards in the piece on an internal AI assistant for employees. Internally in particular, voice plays to its strengths, because in a warehouse or workshop few people want to type. Whether voice input makes sense on your website and what it needs in your case, we are happy to clarify via the contact page.

A realistic expectation

Voice input does not increase the number of enquiries by itself. It lowers the barrier for people who wanted to ask anyway, and it makes their requests more detailed. Whether that turns into more deals still depends on the quality of the answers and on handing over to a human at the right moment.

NoteSources and studies

This article is based on data from: Bitkom (press release on smartphone AI from February 2026, a representative survey of 1,006 people aged 16 and over, 861 of them smartphone users: use of voice assistants and chatbots on the device, regular AI use, awareness of AI inside the device), Gartner (survey of 321 customer service and support leaders, published in February 2026: pressure to implement AI and the development of service headcount), the W3C (Web Content Accessibility Guidelines 2.2, in particular Success Criteria 2.5.3 Label in Name and 2.5.6 Concurrent Input Mechanisms) as well as Regulation (EU) 2024/1689 on artificial intelligence (transparency obligations under Article 50, penalties under Article 99) and information from the European Commission on the date of application. The figures quoted may change and can differ depending on the source and the point in time. This article gives a technical overview and does not replace individual legal advice.

Frequent questions

What exactly is voice input in a chat assistant?

Voice input means a visitor speaks their request instead of typing it. They tap a microphone icon next to the input field, speak their sentence, and the recognised text appears in the field. Only then is it sent. The answer arrives as usual as text in the chat history, and can optionally be read aloud. This is deliberately different from a continuous voice dialogue in which both sides speak: voice input only is faster to introduce, cheaper and easier to review, because a complete text transcript remains available throughout.

Is what I say sent automatically?

In a properly built implementation, no. The recognised text lands in the input field first and stays editable there, so that names, measurements or order numbers can be corrected before sending. This is the single most effective measure against recognition errors, because it makes the human the final checkpoint. Automatic sending saves a few seconds but produces requests nobody has reviewed, and it shifts the correction into the conversation that follows.

Where is the voice recording processed and how long is it stored?

That depends on the provider and should be settled in writing before going live. At XICBOT, voice input is not part of standard operation; where the audio is processed and when it is deleted is set in the project for this extra function. Because voice recordings are personal data, the purpose, legal basis, place of processing and retention period belong in the privacy policy and in the record of processing activities. A short note right at the microphone button additionally increases willingness to use the feature at all.

How does recognition cope with dialect, jargon and order numbers?

Standard language is recognised reliably, company-specific terms noticeably less so. Three things help: a dictionary of the proper names, product lines and abbreviations used in the business, a read-back check as soon as numbers, references or appointments are involved, and editable text before sending. Ambient noise remains a factor that no software fully compensates for, which is why test recordings from the workshop, the building site and the car belong in every acceptance round.

Does a voice feature have to be labelled under the AI Act?

For the chat itself, Article 50 of Regulation (EU) 2024/1689 applies: anyone interacting directly with an AI system must be able to recognise that. These transparency obligations become applicable from 2 August 2026. If the answer is also read aloud, artificially generated audio is created, which tends to raise the transparency requirements. In practice that means a visible notice before the first contact, a clear route to a human handover and documentation you can present if asked. None of this replaces individual legal advice.

How much effort is it to add voice input later?

Manageable, if the assistant is already running, because voice input sits at the start of the chain and leaves the knowledge base, tool connections and handover untouched. Four blocks need work: technical integration, the domain dictionary, the legal wording and a test in realistic environments. A limited start makes sense, for example mobile only at first, with measurement over four weeks. Whether the effort pays off in your own use case can be assessed in an initial conversation.

Ask it yourself, Assistant of this website

Automated assistant

Settings