Skip to content

Talking to the assistant

You can speak to the assistant instead of typing, and have its replies read back. A spoken message is turned into text and then handled exactly like something you typed — so intents, parameter forms, workflows and everything else behave identically. The transcript is the message, and your audio is not kept.

Where Speaking to it Hearing replies
The app Microphone in the composer, or hands-free A speak button per reply, or automatic
An embedded widget Microphone in the widget A speak button per reply
Slack Send a voice note Not by default
Forms Answer by speaking A “Read form” control

Press the microphone and talk. Your words appear as a normal message.

Hands-free keeps listening: it notices when you start and stop speaking, sends each turn, and speaks the reply back as it arrives — so you can hold a conversation without touching anything. A few things people hit:

  • The assistant interrupts itself. Your speakers are being heard as speech. Headphones fix it completely.
  • Turns end mid-sentence. It is treating your pauses as the end of a turn.
  • Background noise starts a turn. It is too sensitive for the room. A turn that opens and retracts is never transcribed, so this costs nothing but annoyance.

The first two and the third can all be tuned; ask whoever administers your installation.

Nothing to configure — if voice is on, the microphone appears. The widget uses your visitor’s language rather than the embed creator’s.

If the microphone is missing from your site, the page is almost certainly served over plain HTTP. Browsers only grant microphone access over a secure connection, so the control is not shown at all rather than shown broken. Serve the page over HTTPS.

Send a voice note in a direct message, or in a channel where you mention the assistant. It is transcribed and answered as an ordinary message. Slack replies come back as text by default; spoken replies can be turned on.

Slack conversations are handled in English. A Slack message carries no language preference, so there is nothing better to work from.

In the app, voice follows the language you have the interface set to. In a widget it follows the visitor’s. Cantonese and Mandarin are distinguished properly, which matters for speech — the written text alone cannot tell them apart.

One thing is not translated: the field labels of a form read aloud. Those were written by whoever built the workflow, so they are read as written. The controls around them are translated.

  • Microphone access, which requires a secure connection — HTTPS.
  • A browser with audio recording support. Where it is missing, the button is not shown rather than shown failing.
  • Hands-free needs a little more, and may show two microphone indicators. That is expected.
  • Only one reply speaks at a time.
  • Automatic speaking may be blocked until you have clicked something on the page — browsers refuse audio that a person did not initiate. The per-reply speak button always works.
What you see What it is
No microphone button The page is not on HTTPS, or the browser cannot record
“Microphone access was blocked” You declined the permission — change it in site settings
The reply arrives but never speaks Autoplay was refused, or the reply had nothing sayable in it
Slack: “I couldn’t make out that voice message”, every time The Slack app needs reinstalling with permission to read files
A Slack voice note gets no reply Voice notes are off, or it was a channel message with no mention
Everything refuses The workspace has no active subscription

Speech in is metered by audio length; speech out by characters spoken. Both are separate from model tokens — see the billing units reference.

A streamed spoken reply is billed per sentence as it goes, so one reply can show several charges that add up to the whole. That is expected, not double-billing.