People judge a front desk in the first few seconds of a call. They don't see the systems behind the voice, and they shouldn't have to. Business owners, though, want to know exactly what happens when Clodia picks up, because their customers' requests and their own reputation now go through it.
This article follows one inbound call from start to finish. It describes how Clodia is built today. Where something isn't built yet, we say so.
1. The phone rings
By default, a business's number is a phone number provided through Twilio, either a new number or one that the business's existing line forwards to. When someone dials it, Twilio sends a signed web request to Clodia asking what to do with the call. Clodia checks the signature first, so a request that did not come from Twilio is refused. It then replies with instructions to open a media stream: a two-way WebSocket that carries the caller's audio to Clodia and Clodia's audio back to the caller.
Phone audio on this path is narrowband G.711 at 8 kHz, the same quality as an ordinary landline call. That matters for the speech model, and it is one reason we test with real phone calls rather than relying only on studio-quality browser tests.
2. The right business, from the number dialled
Clodia serves many businesses from one platform. Each has its own playbook: its name, opening hours, services, rules about what to promise, and which requests need a person. The first thing Clodia does is work out which business was called. It does this from the number that was dialled, never from anything the caller says. A caller cannot talk their way into another company's records by naming it.
If the caller's number is already known to that business, the greeting can use their name. Otherwise Clodia greets them the way the business has chosen.
3. One model listens and speaks
The conversation itself runs on a speech-to-speech model from OpenAI. Rather than turning speech into text, text into a reply and the reply back into speech in three separate steps, one model hears the audio and answers in audio, full duplex. That keeps the conversation quick, lets the caller interrupt naturally, and keeps tone of voice in the loop. Our article on speech-to-speech versus cascaded pipelines covers the trade-offs.
The voice speaks first. Its instructions keep answers short enough for the phone, ask one useful question at a time, and follow the caller between English and Arabic, using a natural Emirati register in Arabic rather than formal newsreader Arabic.
4. The voice runs no tools
This is the most important design decision in Clodia. The model that talks to the caller cannot take actions. It cannot look up a booking, log a repair, send a message or spend money. When it needs a fact or an action, it delegates the request to a separate backend model that holds the business's full playbook and a short list of tools.
Those tools run on Clodia's own servers, against that business's data only. They include identifying the caller, checking details, logging a request and ending the call. A voice that could call tools directly would be a voice that could be talked into using them. Separating the two means a persuasive caller can only ever get a conversation, not an action the playbook does not allow.
5. Facts come from the business, not the model
Large language models are fluent, and fluency is not the same as knowing your prices or your cancellation policy. Clodia answers business questions from information the business has approved: its playbook and what it has taught Clodia through the workspace. When the answer is not there, the right behaviour is to say so and take a message, not to improvise. We would rather a caller hear "I'll get the team to confirm that" than a confident guess.
6. Anything consequential waits for a person
Many calls end with something that needs doing: a repair to arrange, a refund to consider, a contractor to book. Clodia records these as proposed actions. Anything that spends money or dispatches someone goes through an approval gate, where a person on the team approves or rejects it. A rejection needs a reason, and that reason becomes a correction Clodia can learn from.
When an action is approved, it runs immediately and the result is recorded. If a message could not actually be delivered, for example because a messaging provider is not configured, the record says so in plain words. Nothing in Clodia claims a delivery that did not happen.
7. Ending the call properly
Hanging up sounds trivial. It isn't. If the line drops the moment the model decides the call is over, the caller can lose the end of the goodbye, and the system can lose the last part of the transcript. Clodia asks the voice session to close after its final words, keeps the audio up until the session confirms it has closed, and only then ends the call. If that confirmation does not arrive within a few seconds, the call is recorded as not properly finalised rather than silently treated as complete.
8. The call lands on the desk
As soon as the call ends, the transcript is graded into a ticket with a priority, a category, a short title and any proposed actions. The team sees it straight away, with what the caller asked, what Clodia said and what is waiting for approval. There is no overnight sync and no inbox to trawl.
What this means for your business
- Your rules, one source. The same playbook writes what Clodia says and what the desk does, so a promise on the phone and a rule in the back office do not drift apart.
- A human where it counts. Routine questions are answered; consequential decisions stay with your team.
- A record you can check. Every call has a transcript, an outcome and a clear status.
If you want to connect your own carrier line instead of a Twilio number, read the ways a call can reach Clodia. For the regulatory side of putting any AI on your phone line in the UAE, start with our SIP trunking guide.
Sources and further reading
Hear Clodia for yourself.
Try a live conversation in your browser, or tell us about your front desk.