Voice agents on Synthflow: where a live dialogue breaks
In a demo, a voice AI agent for calls sounds smooth: greeting, clarifying question, confirmation. On a real line, the dialogue breaks at four recurring points, and each break is a lost inquiry.
That is why we begin Synthflow implementation not with the scenario but with configuring the agent's behavior at exactly these points.
The first point is interruption. The agent must go silent the moment the customer starts speaking; otherwise it finishes over them and sounds like an answering machine.
We tune the trigger threshold so that a short "uh-huh" and background noise do not disrupt the line, while a real attempt to interrupt does.
The second is an unrecognized request. When speech recognition quality drops on a noisy channel or a narrow term, repeating the same question in the same words is pointless.
The agent switches to clarifying wording and, after the second failure rather than the third, transfers the conversation to a human.
The third is the pause after a question: a short one reads as pressure, a long one as a dropped connection, and the customer starts asking again.
The fourth, and most costly, is a break during transfer: if there is a gap between the agent's final line and the operator's response, the whole meaning of the conversation already started is lost.
None of these points is cured by beautiful scenario text—only by precise tuning of thresholds, clarification logic, and transfer rules. Inbound call automation and an outbound calling robot rest on the same dialogue discipline. We break down how this is handled in Synthflow without code.
What a voice agent delivers: response speed, call completion, load
The first effect is visible at the entrance: the agent picks up on the first or second ring, whereas a human at peak load answers after 30-40 seconds or does not answer at all.
Time to first response stops depending on shift load—it is the same during the morning flow, the evening flow, and a mass outreach campaign.
The share of missed inquiries falls not by speeding up operators but through parallel lines: the agent handles dozens of conversations at once and does not take breaks.
The line becomes round-the-clock without a night shift—night and weekend inquiries no longer settle in the missed log.
The main relief for operators comes from handling typical questions: application status, terms and rates, appointment, address, visit confirmation.
The agent closes these scenarios itself, and transfers the dialogue to an operator only where access to exceptions or a decision on a non-standard situation is needed—together with the conversation history and recognized customer data.
In Synthflow, such scenarios are assembled without code: branching logic, lookups to reference data, and transfer-to-human rules are configured visually, so edits to the script do not wait for a separate build cycle.
In total, an entire class of failures goes away—busy line, queue wait, mid-conversation drop-off, and contact lost after office hours.
Ways to build a scenario: Synthflow builder or custom development
The fork is simple: where the dialogue logic lives and how often it will have to be changed. A no-code dialogue builder covers typical scenarios—qualification, confirmation, reminder—and an operator makes edits in them without waiting for a release.
Custom development is needed where the conversation is inseparable from internal systems: calculations, inventory balances, application status.
| Option | When it fits | Limitations |
|---|---|---|
| No-code Synthflow builder | Typical voice scenarios, frequent editing of lines by the business | Non-standard logic is expressed through workaround branches, calculations go to an external call |
| Custom development | Dialogue is embedded in accounting systems, full control over processing is needed | Telephony, speech recognition and synthesis, monitoring—entirely with the team |
| Hybrid agent scheme | Lines and branches in the builder, checks and CRM writes in your own service | Two contours: the call contract is versioned, the response fits within the conversation pause |
Integration with telephony and data transfer to CRM are solved at the level of the bundle, not the scenario: number and routing, transfer to a live operator, call recording, writing the outcome to the customer card after the call.
The only difference is who owns this bundle—the platform or your team. In practice, the hybrid scheme more often wins: the scenario is edited in minutes, while sensitive logic remains under control and covered by checks.
Stages of voice agent implementation: from audit to handover
Voice agent implementation is not configuring one screen but an engineering cycle: each step relies on data from the previous one. First we analyze how the line works now, then build, and only then release to live customers—stages below.
-
Call recording audit. We tag a sample of real dialogues: which inquiries repeat, how many are closed with one question, where the caller hangs up. The result is the shares of typical scenarios and the boundaries the agent does not cross.
-
Dialogue scenario map. We assemble branches, conditions for transfer to an operator, mandatory clarifications, and wording. We separately specify where the agent stops and transfers the call rather than trying to guess.
-
Agent assembly in Synthflow. Voice, lines, handling of interruptions and pauses, correct pronunciation of numbers and names. We run it by text while telephony is not connected: edits at this step take minutes.
-
Telephony connection. Number or extension, routing, transfer to an operator together with dialogue history. We verify that the recording and transcript land in your system as before.
-
Testing on real calls. First internal test calls against a checklist, then a share of production traffic, not the whole flow. We look for where the agent asks again or incorrectly determines intent, and fix it in a targeted way.
-
Voice robot acceptance. We check the agreed metrics: share of recognized intents, share transferred to an operator, drops caused by the agent. If a metric does not match, we return to the scenario map rather than tweaking the lines.
-
Handover. Accesses, branch scheme, edit policy, and instructions for your specialists. After that, you add new scenarios yourself.
Deliverable composition: scenarios, escalation rules, policies
After launch, the customer has not only a working agent but also a set of artifacts by which its behavior can be changed without us.
A scenario in the Synthflow editor without a description of the logic reads as a black box—it is unclear why a branch exists and where the call result goes. Therefore the deliverable includes:
- Documentation on the voice agent—a map of branches with the purpose of each, a list of collected data, and the point where the conversation outcome goes.
- Transfer-to-operator rules—escalation conditions: direct request, repeated clarification, out-of-scope topic, irritation signal; what the agent says before transfer and how long it waits for connection.
- Access levels to settings—who edits lines and logic, who sees only transcripts, who releases changes to the production number.
- Scenario update policy—how an edit is formulated, on which test number it is checked, who approves it, and how it is rolled back.
- Operator instructions—what dialogue context arrives with the call, what the operator sees on screen, and how they mark the conversation outcome.
- Set of test calls—typical and awkward phrases that every edit is run against before deployment.
All of this is handed over in your environment rather than remaining in our correspondence. You can edit the scenario on your own, pass access audits without a contractor, and change teams without losing context.
Case study: voice agent in support—metrics before and after
A service network's support line received about two thousand inquiries per month, and almost all of them went to operators.
During peak hours the queue reached eight minutes, and typical questions—application status, visit rescheduling, address clarification—consumed up to a third of the shift. The share of successful dialogues before launch held at 61%, and some calls were abandoned before an answer.
| Metric | Before launch | After |
|---|---|---|
| Share of successful dialogues | 61% | 89% |
| Average response time | 45 seconds | 6 seconds |
| Inquiries closed without an operator | 0% | 46% |
| Peak wait on the line | up to 8 minutes | up to 40 seconds |
What was changed
The agent was assembled in Synthflow without code: the scenario closes five frequent types of inquiries, recognizes the customer by number, and pulls application status from the accounting system.
Anything beyond the scenario or requiring a human decision is transferred by the agent to an operator together with the history—the caller does not have to repeat the question.
Conversations are recorded and transcribed, so disputed inquiries are reviewed by text rather than from memory.
The load on the support line was redistributed: operators handle complex cases, while typical ones are closed automatically, including at night, when previously only an auto-informer answered.
If the scenario behaves differently than expected, routing returns to the previous scheme with one switch—rollback takes minutes and does not affect the production line.
A month after launch, the share of inquiries resolved without an operator reached 46% and remains at that level.
What to do if Synthflow is already deployed and the dialogue breaks
A breaking dialogue in Synthflow is almost never related to recognition quality as such. In most cases the cause lies in three places: deep scenario branching, incorrectly set pauses, and the absence of a fallback transfer to an operator.
Therefore, improving a launched agent begins not with rewriting the text but with analyzing call logs.
In the logs we look at which step the scenario leaves into a non-target branch and how often the agent asks the same thing again.
Separately, we note lines where the caller was interrupted or where the answer was recognized differently in meaning and the agent continued out of context. The list of edits is assembled from these points—usually several branches, not the entire dialogue.
We rewrite branches on the principle of "one intent—one branch": explicit transition conditions, short lines, repeating the question instead of a chain of clarifications.
We flatten deep nesting into a flat structure so that a new objection is handled by a separate rule rather than leading the conversation into a dead end.
Pauses and interruption are configured separately from the text: silence threshold, response wait window, reaction to interruption.
The agent must not finish a phrase over the caller or cut them off mid-breath—otherwise the dialogue sounds like an answering machine and the caller hangs up.
The fallback transfer to an operator covers the remaining failures. Triggers: the third unclear phrase in a row, a request to call a human, an abrupt topic change.
During transfer, the operator receives the conversation transcript and the number—and picks up from the essence, not from "tell me again."
Technical doubts before launch: voice, telephony, permissions
Before launching a voice agent, an engineer checks not the beautiful scenario but behavior on a live line.
Below are four doubts that most often surface during acceptance: what the agent hears in noise, where conversation recordings are stored, how consent is recorded, and where telephony hits a limit.
We assemble the agent in Synthflow: dialogue and branching logic is configured in a visual no-code builder, while the engineering part—telephony, storage, and access rights—remains with our team.
How does the agent recognize speech in noise and poor connection?
The stream from the line undergoes noise suppression and echo cancellation, and only then is recognized. On a broken connection, the agent asks again, and critical data—order number, amount, address—is confirmed digit by digit. Before launch, we measure the share of correctly recognized lines on real calls.
Where are conversation recordings stored and who has access to them?
Recording is enabled by a separate policy: encryption in transit and at rest, retention period by rule, auto-deletion upon expiration. Access is role-based, listening is logged in the audit log, and export is restricted.
How is consent for data processing formalized?
At the beginning of the conversation, the agent informs about recording and requests confirmation; refusal is a separate scenario branch with transfer to an operator.
The consent mark, time, and text version go to the CRM and log—during an audit this closes the question immediately.
What are the telephony limitations and what about line load?
The number of simultaneous calls is determined by the telecom operator, not the agent. We agree on the limit, set a queue at peaks and a backup route to a live operator—if the connection is lost or the agent fails, the call is not lost.
Let's discuss the task: what data is needed to estimate the scenario
To discuss the implementation task concretely rather than in general terms, we need a short set of inputs. The estimate of the voice agent and the work plan depend on exactly these: without these points, any estimate becomes a guess.
- Goal and metric: what we consider the result—share of inquiries closed without an operator, time to first response, recognition accuracy of key entities (order number, date, address).
- Real dialogues: recordings or transcripts of several dozen calls from a typical week, including those where the operator failed.
- Integration points: telephony, CRM, calendar, knowledge base—where the agent writes the conversation outcome and where it takes data from.
- Escalation rules: by which phrases and conditions a conversation goes to a human and what the agent manages to record before transfer.
- Data restrictions: what information cannot be stored and transferred, whether consent for recording and anonymization is needed.
- Load: languages and line schedule, peak periods, and how many conversations it must handle simultaneously.
- Accesses: test telephony and CRM environment to assemble and check the first line without risk to the production number.
With this set, we come back with a work plan for the agents: scenario scheme, list of integrations, stages, and timeline for line launch. Synthflow implementation is then built from your dialogues, not from a demo example. Describe the task—we will clarify what is missing and send an estimate.