Why Botpress implementation stalls after a pilot launch
A demo almost always goes smoothly: a short dialogue history, preselected questions, an engineer next to the screen.
In the production environment, context retention is the first thing to fall apart — after the third or fourth clarification, the bot loses the thread, and the person describes the problem from scratch.
This is exactly where Botpress implementation stops being an experiment and runs up against how state is stored and passed between scenarios.
The second bottleneck is the knowledge base. In tests it is small and up to date; in production it is connected to regulations, tariffs, and internal instructions that live their own life and change without warning.
Answers are formally valid but lag two revisions behind, and trust in the assistant falls faster than it can be corrected.
The third is access control. An assistant with shared permissions answers an employee with what is intended for another role, and logs cannot later reconstruct who requested what.
At the same time, load on first-line support surfaces: dialogue failures do not disappear but move into the operator queue, and instead of relief the team gets a peak flow of escalations at the end of the day.
We break down how each of these areas is addressed at the project stage rather than after the first incidents: where the boundary of responsibility between bot and operator lies, what counts as a correct answer, and how to verify it before launch.
What Botpress implementation delivers: impact in measurable terms
The impact of Botpress implementation is measured by four metrics, not by the number of configured scenarios.
We take measurements on your traffic before launch and after several weeks of operation — it is clear where the assistant relieves load and where a branch needs to be rewritten.
Share of requests closed without an operator
The assistant takes a typical request through to resolution: clarifies the order contents, shows status, processes a return, changes the delivery address.
The share of dialogues closed without a human depends on how narrowly the scenarios are scoped: at the start this is usually a third to a half of requests, then it grows as dialogue logs are reviewed.
Time to first substantive response
In the operator queue, the first response is measured in minutes and grows with load.
The assistant responds in seconds and straight to the point — states the timeframe, amount, condition, or passes the dialogue to a human with context already gathered, without repeated clarifications.
Offloading operators
Recurring questions are removed from people: statuses, standard terms, scheduling, reference data. The operator handles cases that require authority and decision-making. A side effect is fewer switches between dialogues and a lower error rate from manual data copying.
Resilience to peak load
A peak in requests no longer turns into abandoned dialogues: the queue does not grow, response time is not missed, requests are processed in parallel.
The failure class “did not wait for a response and left” disappears — previously it ate into campaign results precisely at the moment of highest demand.
Deployment modes: cloud environment, own server, hybrid
Deployment mode determines where the agent's scenarios, connected models, and conversation logs physically reside.
We separate three schemes — cloud deployment, own server, and hybrid — because each addresses its own class of requirements: speed of launch, perimeter control, or a balance between them.
The choice is fixed before scenario development; otherwise, changing the environment rewrites integrations and storage logic.
| Option | When it fits | What limits it |
|---|---|---|
| Cloud deployment | fast start, no in-house capacity for peak load | conversations reside on the platform provider's side, less control over the network and update schedule |
| Own server | data must not leave the perimeter, there is in-house capacity and on-call staff | operation, backup, and updates fall to the customer or to us under contract |
| Hybrid scheme | scenarios and data inside the perimeter, only model calls go outside | more complex routing and synchronization of configurations between environments |
Dialogue history storage
We define the storage policy right away: which conversation fields are written, how long a record lives, what goes to analytics, and what is deleted on schedule.
In a cloud environment, the term is limited by platform rules; on our own server, we set it — up to storage in our own database with encryption and segmentation by client.
Environment isolation
We separate test and production environments by databases, access keys, and network rules so that experiments do not see real conversations. This way, a scenario update does not affect production, and engineer access to logs is limited by a separate role.
Implementation stages: from dialogue analysis to handover to support
A scenario drawn before an inventory of requests almost always diverges from how people actually phrase questions. That is why the order of work is strict: first, the facts from real dialogues, then the branching scheme, and only then data and integrations.
The platform here is a tool; the sequence is dictated not by its capabilities but by the content of the conversations.
- Dialogue audit. We export conversations from support and messengers, count topic frequency, and tag where the operator answers with a template and where a decision is required.
- Scenario design. We assemble the branching scheme: what the bot closes on its own, what it passes to a human, at which step escalation triggers, and how the dialogue returns.
- Connecting knowledge sources. Regulations, service catalog, instructions, and closed request history — with source prioritization so answers do not contradict each other.
- Setting up integrations. A request goes to the accounting system, request status is pulled into the dialogue, and the conversation is saved in the customer card.
- Testing on real requests. First a test set of questions, then enabling on part of the traffic with comparison: bot answer versus an experienced operator's answer.
- Handover to operation. Accesses, support instructions, dialogue log review, and the procedure for editing a scenario without a developer.
Readiness criterion
A ready scenario is not one that answers everything, but one whose share of correct answers stays above the agreed threshold and has a predictable handover route to an operator.
We fix the threshold and the list of critical topics before launch — otherwise the dispute about the result starts after go-live.
Test question set
We assemble the set from the same requests: typical phrasings, typos, colloquial abbreviations, off-topic questions, and attempts to lead the bot out of the scenario.
Each topic has its own minimum number of phrasings so that editing one answer does not break neighboring branches.
What remains in the project: scenarios, schemes, policies, regulations
The project ends not with a working bot but with a set of artifacts by which your team develops the solution without us. Everything we design lives in a repository and is handed over along with accesses — descriptions, not screenshots of settings. Below is what exactly you receive.
- Scenario schemes — dialogue tree with operator handover points, transition conditions, and context reset rules when the topic changes.
- Access policies — which systems the agent reads, which it changes, under which account, and with what limits on data volume.
- Update regulations — the procedure for releasing a new version: run on the test environment, check key branches, publish, roll back to the previous build.
- Operator instructions — how to accept a dialogue, what to see in the request card, which bot answers to consider erroneous, and where to report them.
- Change log — who, when, and why changed a scenario or policy, linked to the version.
- Integration map — the list of connected systems, the exchange method, and the person responsible for access on the customer side.
- Test dialogue set — reference requests for acceptance and re-checking after edits.
How agent access policies are described
The policy answers three questions for each system: what the agent reads, what it changes, and when it stops. Access is granted through a separate service account with the minimum required permissions — not as an administrator and not through employees' personal accounts.
Dangerous actions (refund, write-off, order change) are moved outside the autonomy boundary: the agent prepares the action, and an operator or external business logic confirms it.
How the scenario change log is organized
Each scenario edit is a separate version with author, date, reason, and a link to the request that caused it. We keep it in the same repository where the scenarios are stored, so there are no discrepancies between the description and the working configuration.
Before publication, the version undergoes regression on reference dialogues, and the previous one remains available for quick rollback.
Case study: how we reduced the failure rate and time to first response
Initial picture
Support for a SaaS service: six operators, peak load in the evening hours. The first response in the queue reached 40 minutes, and every third conversation went to the second line — to engineers who dealt with accesses and settings instead of product development.
More than half of the requests were typical: request status, plan limits, password reset, data export.
Worse than the flow, the variance scaled: operators answered differently, and in review it was impossible to understand exactly where time was lost and why the share of escalations was growing.
What we changed and what the result was
Typical scenarios were moved to an agent on Botpress: knowledge base search, intent routing, and handover of the dialogue to an operator when answer confidence falls below the threshold or the client directly asks for a human.
At first the agent worked in shadow mode — it answered, but the answer was not sent; instead, it was compared with the operator's answer. Discrepancies were reviewed and phrasings corrected, so we went into production launch without surprises in dialogues.
Measurements after a month: share of requests closed without an operator, 34% → 72%; time to first response at peak, 40 minutes → less than a minute; escalations to the second line, 31% → 11%.
The freed-up shift time went to complex requests, and the queue stopped growing with the same headcount.
How does a custom agent differ from an off-the-shelf bot builder?
A builder like Botpress provides a fast start: a scenario is assembled from ready-made blocks, channels are connected in a couple of hours, and the dialogue is working in the first week.
The limit comes where the logic no longer fits into blocks — when calls to your systems, custom routing rules, and different permissions for different employee groups are needed.
Limitations of template bots show up in three places. Branching runs into the platform's set of blocks, and a complex scenario has to be split into workaround chains.
Knowledge sources are limited to what the platform can accept, so tables, internal registries, and closed databases do not make it into answers. Access rights live at the level of the whole bot: delineating which employees see which data is not possible with standard tools.
A custom agent removes these limits. Branching is described by rules and code, knowledge is pulled from your storages with scheduled updates, and access is checked on every request by user role.
At the same time, data remains in your environment: you decide what goes to an external model and what is processed locally.
Transferring scenarios from a builder is separate work, and it is more honest to consider it a rewrite than a migration. The text of replies and the dialogue structure carry over, while bindings to blocks, integrations, and storages are assembled anew.
Therefore, the choice of “custom agent or builder” is a choice between speed of launch and ownership of logic and data.
Common technical doubts before starting a project
Before starting, almost every team asks the same set of questions: what the agent will be able to do in internal systems, how it will behave with incomplete data, and what will remain with us after handover.
Below are short answers to the point; we record all agreements in project documents before work begins.
How does the agent get access to internal systems, and how secure is it?
Through separate service accounts with the minimum required permissions: reference data, knowledge bases, and accounting systems — read-only; writes (create a request, update status) — only in agreed operations.
Every request goes to the log with a dialogue identifier, and personal data is masked before being sent to the language model. Access is revoked by changing the key, and scenarios are not rewritten.
What happens if the knowledge base is incomplete?
This is a normal starting state. The agent answers only with sufficient confidence, and on gaps it honestly acknowledges the limitation and passes the dialogue to an operator — with the conversation history and a note about which knowledge was missing.
These notes become a list of improvements: texts are expanded, the base is reindexed, and the share of independent answers grows from week to week.
Can already-built scenarios be transferred?
Yes. Dialogue logic, branching, and texts are transferred if they are described explicitly — by a scheme, table, or working prototype.
The most expensive part is not the transfer but reconciling what duplicates and contradicts each other: we do this stage first so as not to drag old errors into the new system.
Who is responsible for operation after handover?
We hand over not a “black box” but an assembled system: configurations, scenario descriptions, access rules, and instructions for typical changes. Our engineers support it after launch — correct phrasings, add knowledge, and review uncovered requests. The customer's team can maintain this themselves, and we join in on complex issues.
Let's discuss the task: what we need from you and how we will start
To start, you do not need a ready-made hundred-page document — input data that shows the real load and dialogue logic is enough.
The more specifically the request flow is described, the more accurate the timeline estimate: a vague “we need a smart bot” produces an eyeballed plan, and it almost always diverges from reality. The minimum set for analyzing the task looks like this.
- Description of the request flow: channels (website, messengers, email), approximate number of dialogues per day, peak hours, and the share of questions that repeat time after time.
- Scenarios the bot must close on its own, and operator handover points — what counts as an escalation and by what criterion.
- List of systems for integration: accounting system, knowledge base, product or service catalog, booking calendar.
- Access for analysis: a test environment and an anonymized sample of real conversations for a period — they show customers' living language, not just invented questions.
- The person responsible on your side who makes decisions on answer logic and approves scenarios.
- Restrictions: topics the bot does not answer, and mandatory phrasings that cannot be changed.
- Examples of unsuccessful dialogues from current support — they quickly show exactly where requests are lost.
Next, we analyze the material, assemble a scenario map, and come back with a work plan and timeline estimate broken down by stages: knowledge base preparation, logic assembly, integrations, test run on real dialogues, launch, and observation period.
We separately mark stages whose timeline depends on your answers and accesses — you can see in advance what shifts the launch and by how much.
