Corporate chatbot instead of a support queue
An employee looks for the answer not where it lives. The policy is in a shared folder, the approval procedure is in a long message thread, and the current version of the instruction is in one person's personal files.
In this situation, searching for an answer in the knowledge base returns either no results or a document that diverged from reality three edits ago.
Then first-line support kicks in. It handles recurring requests: how to request access, who approves a request, where to send an invoice.
The same question arrives dozens of times, and each time it is retold from scratch — the load on first-line support grows not because tasks are complex, but because ready knowledge is not delivered directly.
An employee chatbot closes exactly this gap. The answer is assembled from connected sources — the knowledge base, internal policies, previously resolved requests — and arrives in the channel where the employee already works, without waiting in a queue.
If there is no confident match, the dialogue goes to first-line support together with context: what was asked and what the bot has already shown.
Discrepancies are eliminated at the source level: one current version of the document, one owner, a clear update date. Otherwise, internal employee support gets one more channel that confidently retells outdated information.
What changes after implementation: response time, load, data quality
The first measurable shift is response time for the employee. In email and the general chat, a question waits until an operator is free, and the wait does not depend on the complexity of the question.
The bot answers a typical scenario in seconds, and a request goes to a human only if the knowledge base has no suitable fragment or system access is required.
The second metric is the share of automated answers. We count it honestly: the dialogue is closed without an operator, without a repeat clarification, and without a subsequent "but still?".
At the start, about half of requests on HR and IT topics are closed this way, and the share grows from adding articles, not from "fine-tuning" the model.
The third is reduced load on support. Operators stop working as an information desk and handle non-standard matters: investigations, access, data conflicts. The queue shrinks not by speeding up answers but because typical requests simply do not reach it.
The fourth is a single answer base. Previously, the answer depended on whom you asked: articles from Confluence lived in several copies, and part of the knowledge was in personal notes.
Now search runs across one indexed source, each answer shows a link to the source article, and edits are made in one place. The "my colleague has a different version" class of failures goes away.
Implementation options: cloud, on-premises, and hybrid modes
The deployment mode is chosen not by team convenience but by two answers: where policy requires storing conversations and how the bot will access internal systems.
The answers are independent — the model can run in an external cloud while data and accounts remain inside the perimeter.
Below are three working options. For each — when it fits and what limitations you will have to accept consciously rather than discover during pilot operation.
| Variant | When it fits | Limitations |
|---|---|---|
| Cloud implementation option | Fast launch is needed, there is no ban on keeping dialogues outside the perimeter, internal systems are available through software interfaces | Conversations and logs reside with an external provider; access to internal systems is only through public software interfaces, and some reference data remains unavailable |
| On-premises implementation option | Policy prohibits exporting data outside, there are own compute resources and a directory service for access control | Resources, updates, and monitoring are on the internal team; external services are unavailable, and answer quality is limited by the local model |
| Hybrid mode | An external model is needed, but storage of internal data is strictly inside, with access control | Harder to maintain: two perimeters, a gateway, request routing rules, and logging on both sides |
A separate check before choosing is compatibility with the current perimeter: directory service, read rights to systems of record, export formats, attachment limits. A bot that cannot access the reference data is useless in pilot operation.
Hybrid mode covers this with a gateway: an anonymized request goes outside, while search across internal data is performed inside.
Implementation stages: from process analysis to handover of policies
Development starts not with code but with an analysis of how tasks are solved now: which systems hold the data, who is responsible for the answer, and where policy diverges from practice.
If this step is skipped, the bot will be technically correct but useless — it will confidently answer the wrong questions. That is why an audit of internal processes comes first, and only after it does an implementation plan appear with clear timelines for each department.
- Internal process audit. We go through departments and record typical requests: what is asked, how often, who answers, and in what time. The output is a scenario map with frequency and the cost of manual handling, not a general list of "wishes".
- Identification of data sources. We find the source system for each topic: reference data, ticketing system, internal knowledge base. We agree on read-only access — the bot does not change records at this stage.
- Dialogue scenario design. We describe branches, clarifying questions, and escalation rules: where the bot must hand over the dialogue to a human. We separately record topics it does not handle — an honest "I don't know" is better than a confident error.
- Assembly and integrations. We connect sources, configure document search and access control: the employee sees exactly what they see in their own systems.
- Testing on real requests. We run a blind set from the request history, compare answers with reference ones, and adjust wording, search rules, and the escalation threshold. We calculate the share of correct answers and the share of correct escalations separately.
- Pilot in one department. A limited group uses the bot in working mode, we review the dialogue log, and refine weak points before rolling out to other departments.
- Policy handover. We deliver documentation: scenario map, access matrix, operator instructions, and the procedure for updating and maintaining the knowledge base.
The outcome of each stage is an artifact that can be verified, not a report about work done. This order allows you to stop at any step and see what already works and what needs clarification.
Handover package: configurations, dialogue scenarios, access policies
The handover package is a check on whether the solution remains manageable after delivery. Anything not captured in configurations and documents lives only in conversations, and any edit turns into a separate project.
- Configurations and deployment. Service parameters, component composition, and environment variables are in version-controlled files: the environment can be brought up from scratch reproducibly, without "remember to click this" steps.
- Dialogue scenarios. Branches, replies, transition conditions, and texts remain editable — the process owner edits the answer themselves and rolls back an unsuccessful edit on the test environment.
- Data access policies. A matrix of roles and scopes: which sources the bot accesses, what is masked in the answer, what is not stored in the dialogue history, and who can access the logs.
- Employee instructions. Policies for operators and process owners: how to correct an answer, when to hand over the dialogue to a human, and what to do when a request falls outside the permitted scope.
- Support documentation. A diagram of components and connections, failure points, degradation procedures, configuration rollback, and a set of reference questions for checking after edits.
- Integration map. Which systems are connected, through which interfaces, under which accounts, how keys are updated, and what happens when an external service is unavailable.
We hand over not an archive but a working process: we show changes on a clean environment, review incidents using live examples, and work side by side with your engineer until they can make an edit from start to rollout themselves.
Case study: an internal support bot with 40 scenarios
The client is a service company with teams in several cities and a shared first-line support. Typical questions — access to internal systems, request status, vacation requests, procurement limits — went to the general work chat and were handled manually.
The bot was built directly in Microsoft Teams, where employees already spend the workday: no separate app to install or remember.
What was before and what we changed
A first-line support team of three people processed about a thousand requests per month. The average first response time was 4 hours, the queue grew by the end of the day, and 60% of questions repeated week after week.
An employee stuck waiting wrote again or went directly to an acquaintance on the specialist team — request tracking was lost.
We broke down 40 scenarios into three levels: a hint with a ready answer, a dialogue with the knowledge base, and escalation to a specialist with context transfer — what has already been asked, from which department, and which steps have been checked.
Some scenarios the bot closes itself through internal systems: it checks request status or remaining limit without switching the person to another system.
Everything that did not fall into a scenario goes to first-line support with a note — these requests become material for new scenarios.
Result
68% of requests are closed without support staff involvement, response time is 30–40 seconds at any time of day, and the load on first-line support dropped by about a third.
The freed-up time went to complex investigations and access matters that require a person with permissions.
How is a corporate chatbot different from a public assistant?
A public assistant answers an anonymous user: it knows neither the role, nor the department, nor the access level of the person it is talking to. Its corpus is publicly available materials, and an error costs irritation, not a leak. The internal perimeter works by the opposite logic.
A corporate chatbot first establishes who is asking, and only then decides what to show. Access control is built into the search across internal knowledge sources: an employee receives fragments of policies, contracts, or requests exactly within the boundaries of their role.
The same question about terms with a counterparty will produce different answers for a lawyer, an accountant, and a manager.
Internal knowledge sources are the knowledge base, file storage, ticketing system, and project correspondence.
They change daily and contain drafts and personal data, so the answer comes with a link to the document and date: without citation, an employee cannot distinguish a current policy from a revoked one.
Responsibility for the answer is different too. A public assistant gives a recommendation; the person makes the decision.
An internal bot is embedded in the workflow — its answer is referenced in an approval or in a letter to a client, so the request and the issued fragment go into the log. If there is a discrepancy, the incident is investigated using the log, not the participants' memory.
Hence the practical conclusion: the internal perimeter is a separate architecture with permission checks at every step, connection of corporate systems, and a policy that defines what the bot does not disclose even upon direct request.
Putting a password on a public assistant does not work: access is checked not at login but on every answer.
Technical concerns: access, data, scenario support
A bot embedded in the work perimeter receives rights in systems of record and works with employee data — this is the first thing checked before launch. Below are three questions most often raised by the client's engineering teams.
How does the bot get access to internal systems?
Each integration goes through a separate service account with minimally sufficient rights: read access to reference data and requests, write access only for explicitly agreed actions.
Calls are logged, rights are granted at the role level rather than for the entire database, and are revoked in one operation when a scenario is decommissioned.
How is personal data processed?
The bot operates in the client's perimeter: at input we mask identifiers, and in dialogue history we store only what is needed to investigate requests.
Retention periods and deletion rules are fixed in policy before launch — then export to the model does not drag along extra personal data fields.
What happens with unknown requests and how are scenarios changed?
If answer confidence is below the threshold, the bot does not improvise — it hands the dialogue to an operator with context and marks the request as unhandled.
Such requests form a backlog for refinement: wording and branching are described separately from code, so editing a scenario does not require a release, and we regularly check the share of requests closed without an operator.
Let's discuss the task: we'll analyze processes and come back with a plan
We start the conversation with processes, not technologies: what requests come in, who handles them, where time is lost, and what data is needed for an answer. Such an analysis shows where a corporate chatbot will genuinely reduce load and where its involvement will only hurt. As a result, you get not a generic proposal but a plan for your perimeter.
- A process map with automation points and boundaries where the decision must go to a human.
- An integration scheme: which corporate systems we connect, what data we read, and with what rights.
- A set of first-priority scenarios with escalation rules and answer templates.
- Pilot metrics: share of requests closed without an operator, response time, share of correct escalations.
- Pilot launch plan: limited perimeter, timelines, acceptance criteria, and expansion conditions.
- Requirements for access, environment, and data perimeter, including hosting the model within your infrastructure.
- Estimate and implementation plan: stage sequence, scope of work, and what the team takes on.
Describe the task: which processes you want to cover, which systems you already use, and whether there are data storage restrictions. We will come back with an estimate, an implementation plan, and a proposal for a pilot launch.
