Voice bot for order confirmation: where the process breaks
Voice order confirmation breaks not during the conversation but in the queue. While there are dozens of orders, an operator calls them manually and keeps up.
As soon as the flow grows — a promotion, evening peak, weekend — the shift is overwhelmed: there are fewer lines than orders, call attempts go into retry, and some customers don't answer on the first try.
Peak load on a shift exposes a second problem — order status mismatches.
While a call attempt sits in the queue, the customer may change their mind in chat, change the address, or cancel everything; in the system, the order is still "confirmed," the warehouse worker is picking it, and the courier is on the way. A return, redelivery, and sorting it out with the customer cost more than the call itself.
Two more operators won't fix this. The load is nonlinear: three hours of peak, then idle time, and keeping a shift for peak hours is unprofitable.
Plus, manual calling doesn't provide a consistent scenario — one operator will confirm the delivery time, another won't, and some orders remain unconfirmed until morning.
A voice bot for order confirmation handles this differently: automatic customer calling runs in parallel across the entire queue, call attempts are repeated on a schedule with attempts spaced out, and the customer's response — agreement, rescheduling, cancellation — immediately turns into a single status update.
The event goes to the accounting system once, so duplicate records and status bouncing don't occur; the call recording and transcript remain linked to the order.
We break down how this works in practice: which conversation scenarios cover 90% of outcomes, how the bot behaves on a failed call attempt, and how order statuses stop diverging from reality.
Automated confirmation scenarios: the effect in numbers
The effect of auto-confirmation can be seen in four metrics: share of confirmed orders, time to confirmation, operator workload, and repeat contacts. We measure them in the same week before and after launch — otherwise the comparison is skewed by demand seasonality.
- Share of confirmed orders. At peak times, manual calling can't keep up with the flow: operators close the first items in the queue, and the rest sit until timeout. The bot calls the entire list — a gain of 20–25 percentage points and no drop-off during load hours.
- Time to confirmation. The call goes out a minute after the order is placed, while the customer is still by the phone, not an hour later when an operator is free. A short pause means higher response.
- Operator workload. Typical cases — item in stock, address and time unchanged — go to automation, which is 60–70% of contacts. The operator remains for reschedules, replacements, and refusals.
- Repeat contacts. The customer doesn't call "what's happening with my order": the status is confirmed and visible in Bitrix24. The share of such calls drops severalfold and frees up the same line.
- Eliminated class of cancellations. Orders stuck without confirmation and canceled by timeout stop occurring as a phenomenon.
We record each metric in a single before-and-after report, so scenario expansion is driven by data, not gut feeling.
Calling modes: comparison of approaches and their limitations
The calling mode is chosen not by taste but by the structure of the order base and the cost of an error in the conversation.
The more uniform the scenario and the cleaner the order data, the more steps can be handed to automation; the more exceptions in orders, the earlier a human should join the dialogue. There is one fork: what the system does when the customer responds outside the prepared scenario.
The scenario's limitations are not in speech recognition quality but in dialogue branching.
Fully automatic calling handles predictable answers "yes," "no," "call back later," but there's nowhere to put a nonstandard question — and the conversation breaks off.
Connecting an operator removes this, but adds a handoff procedure and a pause on the line. Below is a comparison of modes by which order base each fits.
| Mode | When it fits | Limitations |
|---|---|---|
| Fully automatic calling | High-volume same-type orders, short scenario, "yes/no/later" answers | Doesn't handle branching: a disputed order or nonstandard question stops the dialogue |
| Automation with handoff to an operator | Mixed base — most orders are standard, the rest require clarification | Requires a handoff procedure and an operator on the line, otherwise a noticeable pause occurs |
| Operator calling with assistant prompts | Complex, expensive, and conflict-prone orders, key customers | Depends on the operator's timing and manner of speaking, but the scenario is unlimited |
| Confirmation without a call | Customers who don't answer the phone, orders where it's more convenient to reply by text | No voice contact: harder to distinguish a refusal from "didn't see the message" |
In practice, modes are combined: automation handles the bulk of orders, and on uncertain answers or disputed items it hands the dialogue to an operator.
When designing, we describe in advance which answers are considered unambiguous and which go to a human — otherwise the share of unclosed orders grows along with the base.
Implementation stages: from call audit to shift handover
Implementing a voice bot is not installing a ready-made product but configuring it for your order flow.
The implementation stages are structured so that each is closed with a verifiable artifact: a cancellation map, a scenario diagram, calling rules, and a report on a test sample of orders.
- Call audit. We label recordings and logs for a period: how many orders reach confirmation, at which line the dialogue breaks off, which wording the customer asks to repeat. The output is a cancellation map and a dictionary of real objections instead of guesses.
- Scenario diagram. Branching by response: I confirm, I don't confirm, reschedule the date, question about the contents. The branches "I didn't order this" and "call back later" lead to a handoff to an operator with the conversation context, not to a dead end.
- Calling rules. Calling window, number of attempts and intervals between them, quiet hours, behavior on a failed call attempt. Attempts exhausted — the order goes to an operator along with the call history.
- Connection to the accounting system. The status changes based on the conversation outcome, not via a separate export. A repeat call doesn't create a second status and doesn't move the order out of the picking queue.
- Test sample of orders. A run on real orders with manual labeling: where the bot misunderstood — we adjust the wording and the trigger threshold until discrepancies become isolated.
- Shift handover. A procedure for scenario edits, a metrics panel, review of disputed dialogues. After that, we make changes based on data, not feelings.
Before launch, we establish a baseline: the share of correct confirmations, time to first successful call, and the share of dialogues that went to a human. Otherwise there's no way to prove improvement, and the scenario quickly diverges from the real order flow.
Routing rules, scenarios, and documentation based on results
Documentation is assembled throughout the project, not reconstructed at handover — otherwise some decisions remain in correspondence with developers.
Everything that describes the bot's behavior is stored in configuration: a phrase, handoff condition, or recognition threshold can be changed without reworking the logic and full retesting.
- Routing rules — a "condition → action" table: which customer response confirms the order, which makes the bot ask again, and which immediately transfers the call to an operator; repeat calling and connection loss are described separately.
- Escalation scheme — handoff levels (bot → operator → shift supervisor), wait timeout and number of call attempts, failed-call criterion, and the moment when the order goes to manual calling.
- Phrase texts — a set of phrases for each dialogue step: greeting, confirmation, clarification, refusal, completion. It is marked where the wording is fixed and where variants are allowed.
- Customer response dictionary — synonyms for "yes," "I confirm," "I didn't order," "call back," as well as a list of phrases at which the bot must fall silent and call a human. It is updated based on disputed calls.
- Disputed order procedure — to whom the request is transferred if the customer denies the order, which fields are recorded, and within what timeframe.
- Exchange scheme with the accounting system — which order fields are written, what happens on a write error, and how the bot behaves if the system is unavailable.
- Review log — how to read dialogue recordings and recognized responses to find problematic phrases and update the dictionary without us.
We hand over the package with versioning: each edit is recorded, and the previous version remains available for rollback.
Case study: how automatic calling reduced shift workload
Before implementation, order confirmation relied entirely on the operator shift. During the evening peak, the queue grew, average time to confirmation reached 40 minutes, and some orders were closed as canceled simply because the customer couldn't be reached in two attempts.
The load was distributed unevenly: half the calls occurred within two hours, and the shift was idle the rest of the time.
The process was split into two routes. The voice bot for order confirmation follows a scenario with branches — confirm, reschedule delivery, change contents, refuse.
Telephony and call routing were built on Twilio, and speech recognition and synthesis were moved to a separate service so the model could be changed without rewriting the dialogue logic.
The key element is the confidence threshold: if the response isn't parsed, the customer interrupts, or there is silence, the dialogue isn't pushed to completion but is transferred to an operator along with the transcript and attempt history.
Before-and-after metrics: the share of confirmations without human involvement grew to 78%, and average time to confirmation dropped from 40 minutes to 2.
The peak queue stopped being a bottleneck — the same shift handles the evening volume and simultaneously processes escalations instead of calling everyone indiscriminately.
We separately addressed the class of cancellations. Previously, an unreachable number, erroneous input, and a deliberate refusal all fell into one "cancellation" metric, making it unclear what to fix.
Now a failed call goes to scheduled repeat calling, an erroneous number is flagged and doesn't waste attempts, and an explicit refusal is recorded with a reason.
Losses from "couldn't reach" decreased threefold, and cancellations began to be classified by reason rather than just recorded as such.
How does calling with an auto-informer differ from a dialogue scenario?
An auto-informer is a one-way recording: it reads out text, at most asks you to press a key, and ends the call.
It doesn't parse the customer's words — if the person says "I didn't order anything" or "let's do tomorrow," the system doesn't hear this and repeats the phrase in a loop.
The report shows "call connected," although the order isn't confirmed, and the list goes back to an operator for manual calling.
A dialogue scenario begins with recognizing the customer's response: the system hears speech, determines the meaning of what was said, and selects a conversation branch.
Confirmation, refusal, delivery rescheduling, a request to call back, wrong number — each intent follows its own path.
If the response is recognized with low confidence, the bot doesn't stay silent or repeat the same thing; it asks again with one clarifying phrase, and after the second attempt transfers the call to a human along with the conversation history.
The difference from a contact center is not who "speaks better" but what the bot takes on and what goes to people.
Order confirmation is a short conversation with a predictable set of responses, and it is handled entirely: dozens of parallel lines, calling in the right window, and the same set of questions on every call.
A dispute over the amount, a complaint, a change to the order contents — the scenario recognizes these cases and immediately hands them to an operator without trying to play out the phrases. The bot takes the volume; the human takes the exceptions.
Difficult cases: poor connection, dialects, refusals to take calls
A real call rarely resembles a studio recording: noise and echo on the line, a dropped connection, fast speech, a local dialect. A bot that tries to guess in such a situation confirms the order at random — and that is more expensive than honestly transferring the call to a human.
That is why the logic is built around a confidence threshold: until recognition has gathered the required signals, the bot asks again instead of filling in the gaps.
Processing runs as a stream, without waiting for the end of the phrase: noise cleanup cuts off background, and the order number and the "yes" or "no" answer are checked separately from the rest of the speech.
If there is no answer after two re-prompts, the call is marked with a reason and goes to an operator along with the transcript. Below are typical doubts that we resolve before launch.
What should be done if the connection drops in the middle?
The conversation continues from the same point: confirmed fields are already recorded, and on a repeat call the bot clarifies only what remains. The order state is not reset, and the customer doesn't retell everything from the beginning.
Will the bot understand a dialect or a strong accent?
Configuration is based on the region and the customer's dictionary, not on literary speech. Where confidence falls below the threshold, the response is not a refusal but a re-prompt with a simplified wording.
The customer refuses to talk to the bot — what then?
The first refusal is not considered final: the bot ends the call correctly, sets a flag, and transfers the order to manual calling at another time. Repeat calling is no more than once, so the conversation doesn't seem intrusive.
Where does a disputed order go?
To the operator queue with a reason — noise on the line, unintelligible response, refusal to engage in dialogue, discrepancy with system data — and a transcript of the conversation. A human makes the decision on the order; nothing is lost.
Let's discuss the task: what data is needed for an estimate
An estimate for a voice bot for order confirmation cannot be given based on the phrase "we need to call customers." The timeline and scope of work are determined by the calling volume: how many orders per day and on peak days, what share of calls connect on the first attempt, and whether there are nighttime orders.
And the order cancellation rules determine the dialogue logic — the bot must correctly process a refusal, a date reschedule, or a partial change of contents, not just hear "no."
To come back with an estimate and a stage-by-stage plan, rather than an approximate range, we need the inputs below. We clarify some of them during the recording review and a call with your delivery service.
- Calling volume: orders per day, peak days and hours, share of failed calls and repeat attempts.
- Conversation recordings: 10–20 calls with different outcomes — confirmation, refusal, rescheduling, silence on the line.
- Order cancellation rules: within what timeframe cancellation is possible, who approves it, and what is considered a partial refusal.
- Conversation scenario or procedure: what the bot must say, which customer data to confirm, and when to call an operator.
- Requirements for storing results: how long to keep recordings and transcripts, who gets access, and whether anonymization is needed.
- Integration points: where the bot writes the order status and whether there is a test environment for runs.
- Calling limitations: time zones, impermissible call times, refusals to take calls.
If something from the list is missing, it's not critical; we capture what's missing on a call. After the review, we establish a plan: the number of lines for peak load, the stages of scenario setup, a run on your recordings, and the acceptance procedure.