AI chatbot for VK: why a community loses leads
A message to a community arrives at any time: in the evening, at night, on weekends, at the moment an ad campaign or viral post launches. Operators, however, respond during working hours—so a question asked at 11:00 p.m. waits for an answer until morning.
A person evaluates the speed of the first response earlier than the content: 10–15 minutes versus 8–10 hours decide whether they stay in the conversation or close the chat.
At peak load, the mechanics are different. When a single operator has a dozen conversations at once, they switch between them, lose context, and fall back on template answers.
The queue of inquiries grows not because there are more questions, but because one person's throughput is limited—some conversations end up abandoned.
Hence lost leads. A person who writes to a community and does not receive an answer rarely writes a second time—they go where someone answered first. The community collects demand but does not retain it, and the load on operators grows faster than the flow of inquiries.
An AI chatbot for VK closes not the “presence of a chat” but the gap between a question arriving and the first meaningful response.
It accepts a message the moment it is sent, answers according to the knowledge base and company rules, and hands off to an operator only those conversations where a human is truly needed. Let's break down how this works and what changes in the metrics.
What chat automation in a community provides
An AI chatbot in a VKontakte community responds at the moment of the inquiry, not when an operator becomes free. First response time stops depending on shift load and time zone: at night, on weekends, and during a promo peak, a person receives an answer immediately.
We separately calculate the share of inquiries closed without an operator—this is the indicator that automation actually works rather than simply shifting the flow.
It works like this: the bot searches for an answer in the knowledge base—regulations, instructions, the history of closed conversations—and formulates it from the retrieved fragments, not from memorized templates.
If confidence is below the threshold or the question concerns charges and personal data, the conversation goes to an operator along with the chat context. We configure the threshold by topic: in some cases it is better to answer precisely, in others—to call a human immediately.
The share of auto-replies usually stays in the 60–80% range and depends on the completeness of the knowledge base, not on the model.
Operators stop handling repetitive questions about terms, delivery, and order status and focus on complex cases—the queue during peak hours no longer grows, and a night shift is no longer needed for basic answers.
The effect is visible in reporting: first response time, share of auto-replies, number of escalations, and the reasons the bot failed. These slices make it clear which topics to add to the knowledge base and which escalation rules to adjust.
The class of failures “did not answer in time” disappears along with silence in conversations on evenings and weekends.
Automation scenarios: comparison of approaches
The choice of approach in automation is dictated not by technology but by the cost of error and the variability of questions.
If the flow is repetitive—order status, tariffs, booking—rigid dialogue scenarios with buttons and branches provide complete predictability: the bot does not go off track, the answer is the same for everyone, and behavior is reproducible in testing.
Where people ask in their own words and there are dozens of formulations, branches have to be multiplied, and maintaining such a scheme quickly becomes more expensive than the automation itself.
Answers from a knowledge base with generation reverse the logic: instead of a transition tree, there is a search for relevant fragments and assembly of an answer based on them.
You cover formulations you did not foresee, but quality rests on the source—if the base is incomplete or contradictory, the model will confidently reproduce that contradiction. Only an explicit rule helps: no support in the base—no answer, the question goes to a human.
| Option | When it fits | Limitations |
|---|---|---|
| Rigid dialogue scenarios | Repetitive inquiries, short branches, need guaranteed wording | Any question outside the branch is a dead end; growth in the number of topics multiplies support |
| Knowledge base with generation | Wide range of questions, there is a maintained source | Dependence on base completeness; risk of a plausible but incorrect answer |
| Hybrid approach | Mixed flow: standard operations and open questions | Requires configuration of routing and confidence metrics |
| Handoff to operator | Conflicts, disputed terms, sensitive topics | Does not scale with load, depends on people's schedules |
In practice, the hybrid approach proves workable: the bot closes routine cases itself, and on signs of uncertainty—no support in the base, repeated clarifications, negative tone—it hands the conversation to an operator along with the chat history.
The boundaries of automation are designed in advance: the list of topics the bot does not take on and the escalation conditions are more important than coverage. Next—how this is assembled and tested on a real flow of communities.
How we implement the bot: stages of engineering work
We start the work not with model configuration but with how the community actually communicates. The order of stages is fixed: each subsequent one relies on data from the previous one, so the bot does not “invent” answers but responds according to your regulations. Below is how it looks from audit to handover.
- Audit of inquiries. We export the chat history for several months and label it by topic: order and status, delivery, warranty, payment, complaints. We calculate the share of repetitive questions—this is what determines what makes sense to automate and what is cheaper to leave to people.
- Dialogue scheme. We build a map of scenarios: where the bot answers itself, where it clarifies, where it immediately hands off to an operator. We separately record stop topics—conflicts, returns, personal data—on these the bot stays silent and calls a human.
- Knowledge base assembly. We reduce regulations, instructions, and working answers to short fragments that are used for search. We clean up duplicates and contradictions between documents: every bot answer must rely on a specific source, not on the model's general ideas.
- Setting up integration with the community. We connect the bot to the community through standard mechanisms, configure processing of direct messages and comments, routing to an operator, and notifications about conversations it did not close.
- Testing on real conversations. We run the bot on an export of inquiries and look at the numbers: share of correct answers, share handed off to a human, answers without a confirmed source. We make edits to the base and scenarios until agreed values are reached.
- Acceptance testing and handover. We agree on a set of control conversations, show the work log, hand over access, an operator instruction, and a knowledge base update regulation—so that support does not depend on us.
What we hand over: chatbot scenarios and knowledge base
The project ends not with a bot demonstration but with the handover of documents and settings that you then use on your own. A community has a life of its own: new services appear, terms change, and the employee who handled the conversations leaves.
Therefore, everything that determines the bot's behavior is recorded as artifacts on your side—not in a chat and not in the contractor's head.
- Scenario map — a tree of topics with example formulations, clarification branches, and exit points to an operator. It shows which questions the bot closes itself and which it deliberately routes to a human.
- Labeled knowledge base — articles with required fields, broken into semantic fragments and with an up-to-date status. Editing one article changes the bot's answer without retraining the model.
- Escalation regulation — conditions for handing a conversation to a human: model uncertainty, a complaint, a question about price, a repeat inquiry. Plus rules for conducting the conversation after the handoff.
- Instructions for editors — how to add or remove an article, which fields are required, which formulations break search, and how to test a new entry before publishing to the community.
- Update regulation — frequency of base reconciliation, the person responsible on your side, the procedure for removing outdated materials, and a change log.
- Set of test conversations — several dozen questions with reference answers so that after each edit you can see that the bot has not started answering worse.
- Accesses and ownership of the environment — accounts, keys, configurations, and logs remain with you; we do not become the single entry point to the system.
Case study: a retail chain community after launch
A retail chain community on VKontakte received about 8,500 inquiries per month, and almost all of them arrived during the same hours.
Two operators managed to close part of them during the work shift; the rest waited until morning: a nighttime question about delivery time or product availability at the nearest store remained unanswered for 6–8 hours. During such a pause, the customer either called the store or went where they answer faster.
We assembled a knowledge base from regulations, product cards, and the history of past conversations, broke it into short fragments, and connected search across them: the bot answers only if it finds confirmation in the sources.
If there is no confirmation or the topic concerns a return, complaint, or order change, the conversation goes to an operator along with the accumulated context—the customer does not need to describe the problem again.
Metrics before and after
We compare comparable periods of four weeks so that seasonality and promotions do not distort the picture. The flow of inquiries increased, and this is expected: some customers moved from calls to chat because the answer comes immediately.
| Metric | Before launch | After |
|---|---|---|
| Inquiries per month | about 8,500 | about 11,000 |
| Automatic closure of inquiries | 21% | 69% |
| First response outside working hours | 6–8 hours | less than a minute |
| Conversations handed off to an operator | 79% | 31% |
Handoff to an operator stopped being the main scenario: less than a third of conversations go to people, and these are precisely returns, claims, and non-standard orders.
The queue during peak hours no longer grows, and we configure confidence thresholds and escalation rules for your assortment and regulations—they determine what the bot takes on and what it immediately gives to the shift.
How a scenario-based bot differs from a knowledge-base bot
A scenario-based bot is a state tree: buttons, branches, pre-written texts. Such a bot does not make mistakes by definition because it does not generate answers but selects them from a prepared set.
The price of this predictability is rigidity: a user who wrote a question in their own words instead of pressing a button either goes into a dead-end branch or gets “I didn't understand, choose an option.”
Answers from a knowledge base are structured differently. For each question, a relevant fragment is first found in your documents, instructions, and support conversations, and only then is the wording formed. This removes the main pain of scenarios—rephrasing questions.
“How do I return an item,” “what if it didn't fit,” and “I want to cancel the order” lead to the same fragment, although they have almost no words in common.
The flip side is the risk of an inaccurate answer. If the search pulled the wrong fragment, the bot will answer confidently and off target.
Therefore, the scheme requires a relevance threshold, an honest “didn't find it, passing to a human” instead of a guess, and a source link by which the answer can be verified.
These three constraints turn inaccuracy from a systemic problem into isolated cases that are visible in logs and fixed with document text rather than code.
Support also differs in labor intensity. A new tariff or changed condition in scenarios has to be edited in all branches where it is mentioned—a forgotten branch starts lying.
In the knowledge base, one document changes, and the answer is updated across all formulations at once, without edits to the bot's logic.
In practice, the choice is not binary. Rigid operations—order placement, delivery status, payment—are more reliably kept on scenarios, while reference questions should be given to the knowledge base, leaving the transition to an operator as an explicit exit.
Technical doubts and limitations of the solution
The bot answers strictly from the knowledge base, not “from the model's memory”: each answer is assembled from retrieved fragments of documents and support conversations. Hence the limitations—if there is no suitable fragment, there will be no invented answer.
We set the boundaries at the start: which topics the bot closes itself and which it immediately routes to an operator.
Below are the things most often clarified before work starts: behavior on an empty result, training on your own conversations, conversation handoff, and the procedure for updating data.
What happens if the bot does not find an answer?
An empty result is a normal situation, not a failure. The bot does not make things up: it reports that it does not have the data and offers to leave the question for an operator or clarify the wording.
Every miss goes into a report along with the client's original phrase—it shows which topics are missing from the base.
Can the bot be trained on our conversations?
Yes, conversation history is the most valuable source. We export the conversations, clean them of service and personal information, label them by topic, and assemble them into “question—working answer” pairs. Only formulations confirmed by employees go into the base.
How is the knowledge base updated?
Sources are tied to the regulation: edits to instructions or terms are reindexed within an hour, without rebuilding the bot. Outdated document revisions are displaced automatically, so the bot does not mix old and new.
What if the client needs a live person?
Conversation handoff happens by direct request or automatically: if the question concerns a disputed situation, a complaint, or personal data, the bot gives way to an operator. The operator receives the chat context and a brief summary, not an empty window.
Let's discuss the task: automating your community
To come back with an estimate and a plan rather than general promises, we need the context of your specific community.
Below is what to send: this is enough to understand the volume of the knowledge base, the complexity of scenarios, and to propose a scheme in which the bot closes routine work rather than creating new work.
- A link to the community and to closed chats if the bot should work there too: we will look at the frequency of questions, tone of communication, and share of repeat inquiries.
- 10–20 examples of conversations with an operator, including disputed ones and escalations—they show where the bot answers itself and where it must hand off to a human.
- A list of support topics: delivery, payment, booking, warranty, returns. We will divide them by frequency and decide what is covered by documents and what requires access to the accounting system.
- Excerpts from internal instructions, regulations, and tables—from these we assemble the index the bot uses to search for answers.
- Who currently handles the conversations, how many people, and during which hours: we will design the handoff to an operator so that context is not lost.
- A list of systems that require access: order accounting, warehouse, delivery statuses—we will note where integrations are needed.
- Stop topics: what the bot must not discuss under any circumstances.
Once we receive this, we will discuss the task specifically and come back with an estimate and a plan: the composition of the knowledge base, the handoff scheme to an operator, and answer quality metrics.
