The caller already emailed. The email already has the location, the service, and a photo of the problem. Then they call, and the agent asks for their name as if the business has never heard of them. That is not a voice-model failure. It is a front desk that only exists on the phone.
A production AI voice agent still has to book. The checklist for latency, barge-in, and calendar writes is in how we ship production voice agents. This article is the next buying question: what happens to the customer who does not stay on that one call.
Operators do not experience channels
Staff experience one person who emailed, called, and then typed into the website chat because nobody confirmed the slot. Three tools each store a fragment. The fragment that wins is whichever inbox a person opens first. Attribution, medical history, and the job address get retyped until one of them is wrong.
- Voice books a slot the email thread already cancelled.
- Chat promises a callback the phone agent does not know about.
- The CRM row says 'phone' because a human overwrote the campaign when they pasted the message.
What Dynaris actually runs
Dynaris is a live AI front desk KeenCraft built for multi-location operations. Inbound coverage, booking, follow-up, and alerts share one customer thread across voice, chat, and email. Gmail is connected through Composio, so a mailbox is not a side system the agent is forbidden to know about.
The execution layer is multi-agent, with session-level checkpointing, graph caching, and persistent workflow state. A long task can stop and resume without a human reconstructing what the last step wrote. That is what makes follow-up auditable: the next action is a continuation, not a new guess.
VoiceCake is the inbound phone proof for dental, healthcare, fitness, and mortgage clients: real appointments on the live schedule. Dynaris is the proof that the phone is not the whole desk. A practice that only needs nights covered should start with the after-hours receptionist. A business whose customers already cross channels should not stop at the handset.
Isolation is how multi-location stays correct
Multi-location systems fail when workspace A can call workspace B's calendar or read workspace B's mailbox. Dynaris runs voice agents and tools as separate MCP-based services so each workspace has its own tool servers. That isolation is a security and correctness requirement. A shared tool process with a location id in the prompt will eventually book the wrong site.
The same rule applies to the CRM write. Source, location, and channel are fields, not a sentence in a note. How those fields survive into HubSpot, Salesforce, Zoho, or a custom system is covered in CRM automation that writes back. The front desk's job is to put them on the thread before a person has to.
What the front desk is allowed to finish
- Answer on the channel the customer already used, with the prior channel's outcome in context.
- Book, reschedule, or cancel against the location's real calendar, not a shared spreadsheet.
- Continue a stuck call as chat or email without asking the customer to start over.
- Hand an urgent or out-of-policy case to a human with the thread attached, not a one-line voicemail.
- Refuse work that belongs to another location. Isolation is a feature the caller should feel as 'we have your site,' not as a transfer loop.
When a phone agent is still the right scope
Buy the phone agent when one number, one calendar, and one outcome (book or take a message) describe the business. Adding chat and email before that write-path works will spread a broken booking across more inboxes. Fix the appointment first. Then attach the channels customers already use.
KeenCraft prices the front desk as a fixed Statement of Work. Multi-location and multi-channel work is staged in QA-gated milestones, not implied by a voice demo. Book a call if customers already reach you on more than one channel and the record depends on who checked the inbox. A proposal typically lands in 2 to 5 business days.
Related on this site