Viber AI bot development: where leads and inquiries get lost
Inquiries in Viber arrive in a single stream but follow different scenarios. One customer asks about price and availability, another about order status, a third asks to book a consultation.
They all land in a shared chat, and from there everything depends on whether an operator managed to free up in that same minute.
The first bottleneck is the first response to the customer. If several minutes pass between the message and the reaction, some people simply close the chat and go where they got a faster answer.
Such lost inquiries in a messenger are almost invisible in reports: no lead was created, no dialogue was started, yet the customer was already there.
The second is operator workload. Routine questions about terms, timelines, and status account for the bulk of the chats, while a person handles several dialogues at once and loses the thread. There is no time left for complex customers, and evening and night messages wait until morning.
Viber AI bot development closes both loss points. The bot responds first at any time, clarifies the request step by step, pulls customer data from the accounting system, and hands the operator a dialogue with context already gathered.
Chat automation in Viber takes on routine scenarios, while a human gets involved where they are truly needed — on non-standard questions and deals.
Next we break down what such a bot consists of and how it fits into the existing flow of inquiries.
What changes after launching the assistant in chat
The first response no longer depends on whether an operator is available. The assistant in Viber picks up the message the moment it is sent and responds within seconds — including at night and on weekends, when previously a request waited until morning.
The inbound queue stops being a bottleneck: first response time becomes the same on a quiet Tuesday and at the hour of a peak broadcast.
The share of inquiries closed without a human is determined not by the "intelligence" of the model, but by how the scenarios are assembled.
Order confirmation, delivery status, repeat purchase, routine warranty questions — these are branches with a known outcome, and they go to automation.
Anything where the model is unsure or the customer directly asks for an operator is transferred together with the dialogue history: the human does not ask again what has already been said.
Peak load stops being a staffing problem. The assistant handles simultaneous dialogues without quality degradation and does not "get tired" by evening — operators deal with complex cases, not a stream of identical ones. Labor costs per inquiry fall because the routine part is cut off before it enters the line.
The shifts are visible in numbers: first response time, share of dialogues without operator involvement, distribution of inquiries by hour, average number of replies until resolution. Acceptance is built on them — otherwise automation remains a matter of faith.
Implementation options: scenarios, hybrid, language model
Dialogue logic determines what the bot can and cannot do. A rigid scenario, a hybrid scheme, and a language model solve the same task with different means, and choosing between them is a choice between predictability and response flexibility.
| Option | When it fits | Limitations |
|---|---|---|
| Scenario bot | Standard funnels: request, booking, order status. Branching is described in advance, responses are fixed | A wording outside the scenario leads to a dead end; a new branch must be rechecked in full |
| Hybrid scheme | Sales and support where there are both routine actions and open-ended questions | Requires intent labeling and routing rules — the model does not decide by itself what to show |
| Language model | Open-ended questions against a knowledge base, context-based clarifications, chat summarization | Responses are not repeated verbatim: a fact-checking layer and topic restrictions are needed |
What works in a messenger
In practice, we deploy a hybrid: intent recognition classifies the message, routine requests go into the scenario, and open-ended ones go to the model with a knowledge base.
When recognition confidence is low or the customer asks for a human, handoff to an operator triggers — with the dialogue history and request context so the conversation does not start from scratch.
We select the scheme based on your inquiries: we look at what share of messages fits the scenario and build routing around it.
How we run the project: engineering stages
AI bot development for Viber starts not with code but with analysis of live inquiries: where questions come from, which repeat most often, and at which step leads get lost.
This order reduces the risk that the assistant confidently answers the questions convenient for us rather than those that drive sales.
- Dialogue audit. We export the chat history, calculate the share of routine inquiries, first response time, and losses at transitions — we get a list of topics that are genuinely worth automating.
- Scenario design. We build a map of topics and branches: what the assistant closes on its own, where it clarifies, and at what point it hands the dialogue to an operator. We describe escalation rules in advance — by keywords and number of failed attempts.
- Example labeling. We collect a corpus of real phrases and label inquiry types and entities: product, city, order number. Separately, we add typos, jargon, and messages where several questions appear at once.
- Assembly and integration with systems. We connect the catalog, stock, order statuses, and customer history so responses are built on live data rather than a static hint.
- Assistant testing. We run scenario sets and review the share of correct responses for each inquiry type separately, not an average figure. We catch looping, silence, and topic switching.
- Launch and handover. First we enable the bot on part of the traffic and compare it with operators by response time and share of resolved questions, then roll it out to the entire flow. The client's team receives access, instructions, and a procedure for editing scenarios — further training proceeds without us.
What you keep: scenarios, labeling, documentation
We hand over not a closed service but a working system that your team runs further on its own.
The artifacts are formatted so that a new engineer or support manager can understand the logic without our explanations: step descriptions, transition conditions, comments on contentious branches.
- Dialogue scenarios — a branch tree with transition conditions and handling of unrecognized phrases: you can see where the assistant clarifies and where it hands the dialogue onward.
- Knowledge base — answers tied to scenarios, with the source of each fact indicated; edits are made without rebuilding the bot.
- Escalation rules — repeated question, negative wording, topic outside the knowledge base; thresholds are changed via configuration.
- Operator instructions — how to read the dialogue history and pick up the conversation without losing context.
- Further training procedure — labeling new wordings from accumulated dialogues, validation on a test set, rollout with rollback capability.
- Integration scheme and access — where requests go and where order data comes from, and which roles are needed for this.
- Acceptance checklist — a set of test dialogues that shows nothing broke after edits.
Then you develop the assistant at your own pace: the share of inquiries closed without an operator grows as the knowledge base expands, and we get involved for complex enhancements.
Case study: the bot removed routine inquiries from operators
The client is a chain of service centers with a flow of similar inquiries in the messenger Viber: order status, timelines, booking, warranty.
Before implementation, everything rested on operators: peak came in the evening, night messages waited until morning, and a queue accumulated by Monday.
According to an export from the dialogue history over two weeks of observations, the first response during peak hours took over 40 minutes, and every fifth request remained unanswered the same day.
Baseline
- Autoresponse share — near zero: any inquiry opened an operator card.
- First response — 15–40 minutes at peak, at night a pause until morning.
- Missed inquiries — 18–22% per week, plus repeat questions from the same customers.
We labeled the chat history by intent, assembled a set of scenario branches, and moved into the bot everything that can be resolved without a human.
Uncertain parses and contentious cases are handed by the bot to an operator together with the recognized topic and dialogue context — the employee does not start the conversation from scratch. A separate branch covers night and weekends, so the queue no longer accumulates by morning.
Result
The autoresponse share reached 62–68% per month, first response time — seconds at any time of day, missed inquiries — isolated cases at peak. Operators shifted to complex inquiries and upsells: shift workload fell by about half with the same inbound volume.
Scenario logic or language model: what to choose?
Scenario logic guides the dialogue along a predefined tree: a reply is recognized as one of the known branches, and the response is taken from a template.
This provides predictability — to an order status question the bot answers the same way and will not invent a condition that is not in the rules.
| Dialogue architecture | When it fits | Limitations |
|---|---|---|
| Scenario only | A short list of topics where accuracy matters: requests, statuses, booking | Does not understand paraphrases and typos; each new question needs a branch |
| Language model only | Open-ended consultations, analysis of long task descriptions | Responses are not repeated each time; fact-checking and a ban on some topics are needed |
| Mixed scheme | Sales and support with routine steps and live wordings | Harder to configure: requires intent labeling and tests for false triggers |
The choice is determined by two numbers: the share of inquiries that did not fit the scenario and the cost of an incorrect response.
The language model parses wordings that were not in the tree, but its responses need to be checked — without restrictions it will promise the customer too much.
The working scheme is more often mixed: the model determines intent and formulates the response, while the bot takes order, tariff, and terms data from the reference book according to the scenario. This way, flexibility of wording does not break predictability where an error is costly.
In Viber the logic is the same as in other channels: text goes in, and out comes either a response or handoff of the dialogue to an operator if recognition confidence is below the threshold.
Doubts before launch: data, reliability, escalation
Before work starts, the technical questions are usually the same — we answer them in order.
We store dialogue history in a separate database, not in the messenger chat: we set a retention period, mask phone numbers and addresses before recording, and delete a branch together with derived data upon request. Personal data does not enter the training set — configuration is done on anonymized fragments.
We integrate with the accounting system through event exchange: the bot creates a request and reads customer status, but does not edit records directly.
If the system is unavailable, the dialogue is not lost — it goes into a queue, and the customer receives a response via a fallback scenario.
Escalation to an operator triggers on customer request, repeated question, low model confidence, and contentious topic. The operator receives the full dialogue context, not a fragment — there is no need to ask the customer again.
We check response quality with a reference set of questions: we run it after every scenario edit. Labeling of unsuccessful dialogues shows where the model is confidently wrong and where it lacks data.
What happens if the bot answers incorrectly?
A contentious response is recorded in the log, the scenario is corrected, the control set is rerun — the error does not repeat. On topics outside the regulations, the bot yields the dialogue to an operator.
Can the model be changed without rewriting the bot?
Yes. Dialogue logic, integrations, and escalation rules are separated from the model, so updating it to the current version does not require rebuilding the scenarios.
Who can see the chat?
Access is role-based: an operator sees only their own dialogues; export and deletion are logged.
Let's discuss the task: what to prepare for the conversation
To make the estimate concrete rather than "by eye," a few inputs are enough: they show the scope of scenarios, the state of the data, and the number of integrations.
Below is what to prepare for the conversation; if something is missing, that is also an input — we will suggest what to replace it with.
- Goals and boundaries: which inquiries the bot closes on its own and which it must hand to an operator, and by what criterion it makes that decision.
- Dialogue examples — several dozen real chats or an export of inquiries for a period: from them we calculate routine scenarios and find places where customers abandoned the conversation.
- Project source data: where products, prices, and order statuses come from, where customer history is stored, and how complete and current it is.
- Integration points: catalog and warehouse, payment acceptance, delivery service, CRM or ticketing system, operator work schedule.
- Tone and mandatory wordings: what the bot has no right to promise, which responses require approval, and who approves them.
- Access: owner of the public Viber account, a separate test number for the sandbox, rights for integrations with your systems.
- Acceptance metrics: share of dialogues closed without an operator, first response time, intent recognition accuracy on your wordings.
With this set, we will come back with an estimate and work plan: team composition, stages, launch procedure on a test number, acceptance conditions, and further training procedure on new dialogues.
