Voice control for CRM tasks: dictate, listen, confirm
A CRM is usually operated with two hands: one on the mouse, one on the keyboard. Voice changes which of the three steps of a task you still do by hand. In Firmspace there are three separate voice paths, and they have different requirements — knowing which is which saves a lot of frustration.
Path one: dictation in the assistant window. The microphone button next to the input turns speech into text in the input field. Nothing is executed by dictation itself — the text lands in the field, you can correct it, and only the send button hands it to the assistant.
Dictation has two engines, and the assistant picks the cheaper one. In Chrome, Edge and Android the browser itself recognises speech, so no recording leaves the device and the server is not involved at all. The button only appears where one of the two engines is really available.
For browsers without that ability — Firefox and Safari, for example — the window records your voice and sends the file to the server, which transcribes it. This second route needs an OpenAI-compatible key configured on the server; without it the button warns that server dictation is not configured instead of failing silently.
One honest detail about cost: the daily AI quota counts conversations, not dictation. Transcription does not eat a request of the plan — the request is spent when the question is actually sent to the assistant.
Path two: the answer speaks. Next to each answer in the assistant window there is a speaker button; the same engine can read every new answer automatically if the auto-speak toggle is on. It is one engine for the whole page, so two answers never talk at the same time.
The voice is a proper neural voice from the server, not only the robotic browser synthesis. The server speaks through a chain of providers: first a neural voice service, and if it does not answer, a lighter offline voice as a fallback. If neither replies, the API returns a 503 and the browser takes over for a while — the answer is still heard, just not as naturally.
To keep speech fluent, a long answer is cut into sentences: the first is requested immediately, the next ones are fetched while the previous one is still playing. That is why the answer starts speaking quickly instead of waiting for the whole text to be prepared.
Path three: voice in a conversation. When the assistant is asked a question out loud, it answers out loud — but under different rules. Answers become one to three short spoken sentences: no lists, no ids, no links, no markdown, and sums are said the way a person says them. If there are many results, it names the count, the total and the two or three most important items and offers to continue.
The spoken mode also answers in the language you just spoke, not in the language of the interface, and it may use a separate voice model if the server has one configured. So a German interface does not force a German answer to a Ukrainian question.
What does not change: the confirmation rule. Voice does not skip the confirmation cards for changes. When the assistant has prepared a change, it says in a short line what it prepared and stops — it does not ask “shall I confirm?” itself, because the app asks you. Deletion still asks for a yes even in a spoken conversation.
There is one more useful behaviour for spoken work: when asked to open a page, the assistant opens it and answers with a few words plus the key fact from that page, instead of reading a whole table out loud.
Voice from the phone: the Iris bot in Telegram. There is a separate bot for talking to the assistant — not the one that sends work notifications. Send it a voice message and the bot first shows the recognised text, then does the work. If the recording cannot be understood, it says so and asks to repeat or write instead of guessing.
The Telegram path has its own practical rules that shape voice use. The bot listens to the one chat it was connected to, so it does nothing for strangers. It polls for messages from the server side, which is why it works even where the server has no public address. Messages older than ten minutes are not executed after a restart — a queue of stale voice commands from yesterday will not suddenly run.
In Telegram there are no buttons to confirm, so the rules are tighter: changes run straight away, but deletion and anything proposed after reading somebody else's text still stop and ask. One short “yes” confirms everything that is waiting.
Voice plus the queue. A long voice message with several instructions goes into the task queue, and each result comes back as its own message. Telegram also accepts a link to a page of the CRM and adds a PDF of a document where it can, so a spoken “send me the invoice” ends with the invoice file in the chat.
What we cannot promise. Speech recognition has an error rate that depends on the microphone, the noise and the language; the platform publishes no accuracy figures, so treat dictation as a draft you can correct, and this article claims nothing more. Cost of the voice features is a matter of the server configuration and provider tariffs, and we have no billing data to quote.
Also outside the scope of this article: call recording and telephone audio. Firmspace telephony is about calls from the browser and the channel list, and voice control of the assistant is a separate feature. We do not describe call transcription here because we have not verified it in the code.
Where this saves the most: in the field, in the car, in a warehouse aisle with your hands full, and in any moment when opening a laptop is the slow part. Dictate the instruction, let the answer be spoken, and keep the confirmations as the only thing you do by hand.