Before the handover
The handover pack includes access details, operating notes and an open-issues register with named owners.
The project lead reviews the pack with the receiving team before responsibility transfers.
Give staff and customers answers from approved documents, with source references and access matched to each audience.
Turn manuals, procedures and product documentation into answers people can use in the middle of a task. Anteomnio connects your knowledge to a conversational interface, with references back to the original material and access shaped around the people using it.
A support agent has a customer waiting while they search three versions of a manual. A new colleague asks a senior person to explain a procedure already written down. A project lead repeats the same handover instructions every month.
The cost is more than the search itself. Experienced people become the route to every answer, new starters wait for help, and teams develop different interpretations of the same process.
A knowledge base chatbot gives people a way to ask about the task in front of them, retrieve the relevant guidance and open the supporting passage. It is most useful when the answers already exist, but reaching them consistently takes too much effort.
We start with the questions that interrupt work today. Those questions tell us which sources to connect, where the content needs attention and what a worthwhile first release should improve.
A project lead preparing a handover needs a checklist, not a tour of the shared drive. This fictional example shows the instruction they receive, the passage behind it and the point at which a project-specific question needs another source.
The handover pack includes access details, operating notes and an open-issues register with named owners.
The project lead reviews the pack with the receiving team before responsibility transfers.
Access details, operating notes and open issues with named owners. The project lead reviews these with the receiving team.
Reference: Project handbook, section 6.The handbook describes the process but does not name that project’s owner. The assistant should explain the gap and point to the agreed project contact or record.
A general procedure is not a project-specific fact.The reference should open the relevant section, with enough surrounding detail to check exceptions or follow the full procedure. During testing, we check that the response preserves the source’s meaning rather than merely linking to a related document.
An onboarding assistant, a support assistant and a technical reference tool need different sources and different answers. We shape the experience around the person using it and the task they need to finish.
Bring the handbook, tool instructions and team procedures into a place where a new colleague can ask practical questions: which account to request, how to prepare a client update or who reviews a purchase.
The answer can point to the current form, explain the steps and identify the team responsible. The aim is fewer repeated requests for links and a more consistent introduction to how work is done.
A useful first collection: one department’s onboarding and recurring operating procedures.
Help support staff find the correct setup instructions, product limitations and troubleshooting steps while a customer is waiting. Carry the product version and relevant conditions into the answer, so guidance for one release is not mistaken for another.
Start as an internal tool that helps an agent prepare a response. If customers will use it directly, we define a separate public collection, the questions it should handle and the route to support when it cannot help.
A useful first collection: one product’s help articles, release notes and approved support guidance.
Give delivery and technical teams a way to consult playbooks, implementation notes and recorded decisions before repeating a problem someone has already solved.
An engineer can locate a procedure and its exceptions; a project lead can retrieve a handover checklist. Where an answer depends on the live state of a project, we identify the system that owns that fact and assess the additional integration.
A useful first collection: a service team’s playbooks, checklists and maintained technical notes.
Your support team may need product guidance without access to engineering runbooks. A customer should see published help material without seeing internal delivery notes. We map those audiences to your sign-in and source permissions before connecting the collection.
Access checks happen before material is passed to the model. Source previews and links follow the same rules, and we test what happens when a colleague changes role or loses access. This lets the assistant fit the organisation you already run.
Illustrative boundaries. Actual permissions depend on your sources, identity system and approved scope.
We bring the content connection, answer experience and application engineering into one project. The assistant can live in a dedicated internal workspace or inside an existing portal, depending on how your users already work.
The scope sets out the sources, audience, interface and operating responsibilities. You can review each part of the delivery, rather than judging the whole investment on a handful of impressive demo answers.
Source inventory, agreed imports or connectors, document preparation and the metadata needed to distinguish products, versions and access levels. We include a defined process for publishing changes.
A question interface, follow-up conversation and source links that help readers inspect the original guidance. Feedback and unanswered-question handling give the team a practical way to report gaps.
Authentication, permissions and the agreed portal or application integration. We confirm API and identity-system capabilities before committing to a particular connection.
A reviewed set of questions and expected answers, recorded limitations, refresh instructions and operating notes. The handover includes the agreed source code, configuration and account access.
A custom build earns its place when an existing product cannot reasonably fit the sources, permissions or user experience your business needs. We review your current tools first. Better document organisation or an existing search feature may resolve the problem with less work.
| Route | Choose it when | Typical starting point |
|---|---|---|
| Improve the existing knowledge base | The main problem is missing guidance, duplicate files or unclear ownership. People can find answers once the material is organised. | Consolidate the current instructions, archive obsolete versions and make ownership visible. |
| Configure an existing product | A product supports your sources, access model and required interface, with acceptable running costs and data handling. | Test your own questions and permission changes before adopting it for the team. |
| Build a custom assistant | You need a specific portal experience, knowledge across several systems, customer-specific access or retrieval behaviour that standard settings cannot provide. | Build around one audience and the integration or workflow that makes the custom work worthwhile. |
For example, a customer portal may need answers from a common product guide and that customer’s private project documents, under the portal’s existing account permissions. That is a different application brief from a shared staff handbook.
Need fields extracted into a business system? See AI Document Processing. Need the assistant to carry out tasks? See AI Agents for Business.
We review a representative sample before asking you to reorganise years of material. The aim is to identify the preparation the first use case actually needs and make that work explicit in the proposal.
Your subject experts approve the meaning of the material. We handle the agreed preparation and engineering, and show where a content decision is needed.
Before building, we collect questions from the intended users and agree what a useful answer looks like. The pilot is then assessed against those questions and fresh examples, not just the prompts used to tune the demonstration.
Ask users to complete representative tasks. Review whether they found the relevant instruction, understood its conditions and still needed a colleague to explain it.
Check the cited passage, the version and the exceptions. Include ambiguous questions and cases where the sources disagree or contain no answer.
Test with different roles, then change a document or revoke permission. Confirm that the answer and its source links reflect the intended change.
Review usage cost alongside time spent finding answers, questions escalated to experts and effort required to keep the collection current.
The pilot gives you a basis for deciding whether to expand, improve the content or stop at a smaller release. AI responses can still be wrong, so ongoing answer review remains part of the operating plan.
We agree the audience, sources, user journeys and acceptance criteria before the build. You know what your team needs to provide, what Anteomnio will deliver and what is reserved for a later phase.
Review recurring questions, current workarounds and available tools. Identify the audience and the improvement that would make the project worth doing.
Document the content preparation, connectors, interface, permissions and test cases. Confirm dependencies and the price for the agreed scope.
Use a working preview with representative material. Your subject experts check meaning while intended users judge whether the experience helps them do their work.
Review the pilot findings, deploy the agreed release and hand over the code, configuration and operating notes. Assign responsibility for content updates and support.
A maintained handbook for one staff group is a smaller project than a customer portal with private collections, several source systems and frequent permission changes. Source quality and integration complexity can matter more than the number of files.
The implementation quote separates content preparation, source connections, the interface and evaluation. Recurring estimates cover the selected model and retrieval services, storage, refresh jobs and the agreed maintenance.
We use your expected question volume and update frequency to explain the running assumptions. You can then judge both the first release and what expansion would add.
A knowledge base chatbot answers questions using a selected collection of documents or records. It retrieves relevant material and uses it to prepare an answer, ideally with references the reader can inspect. A business implementation also needs access controls, a content-update process and evaluation of whether the answer is actually supported.
RAG stands for retrieval-augmented generation. A RAG chatbot retrieves relevant passages from a knowledge collection and supplies them to a language model as context for a response. This lets the application use selected business information without relying only on the model’s general knowledge. Retrieval and generation can both make mistakes, so the system still needs evaluation and a way to handle insufficient evidence.
Not necessarily. We first assess whether your existing tool can answer representative questions, respect permissions and keep up with content changes. Configuration or better source material may be enough. Custom development becomes useful when you need a particular portal experience, connections across systems or customer-specific access that the existing product cannot reasonably support.
No. Start with a representative sample from the team or process you want to improve. We review versions, structure, formats and missing context, then include the necessary preparation in the scope. Your subject experts decide which instructions are authoritative; Anteomnio handles the agreed document preparation and technical implementation. Scans, complex tables and image-only instructions may need additional work.
No. A source can be relevant without supporting every claim in an answer. We test whether each response is supported by the retrieved passages, whether the references point to the right material and whether the system recognises missing evidence. Important decisions still need the appropriate human review.
We design the assistant to explain the gap, ask a useful clarification or direct the question to a named owner. When documents conflict, an agreed version or authority rule may resolve the difference; otherwise the conflict should be surfaced. The assistant should not silently combine incompatible instructions into a new policy.
Yes, when the source and application permissions support the required design. We define who can retrieve each document and enforce access before material is passed to the model. References and source links must respect the same rules. Permission changes and revoked access are included in the update and evaluation process.
We agree how additions, edits, deletions and permission changes reach the assistant. The implementation may use a supported connector, a scheduled refresh or an approved publishing workflow. Content needs a responsible owner, a clear source of truth and a way to confirm that an update has actually reached retrieval. Refresh frequency is part of the scope.
We assess the authentication, interface and integration options available in your application. The assistant can be scoped for an internal workspace, a customer portal or a public help experience. Each audience needs its own approved collection and permissions; internal documents should not become public simply because the interface is shared.
Implementation depends on the source systems, document preparation, access rules, interface, integrations and evaluation work. Running costs can include retrieval infrastructure, model usage, storage, refresh jobs, monitoring and maintenance. We separate implementation from recurring estimates and state assumptions about collection size, question volume and content changes.
The agreed release includes the assistant interface, source connections, access controls and publishing process defined in the scope. Handover covers the agreed source code, configuration, account access and operating notes, together with evaluation findings and known limitations. We also identify who maintains the content and which technical support or maintenance is included, so responsibilities are clear after launch.
Bring a few real questions and the material your team uses to answer them. We’ll help you assess the fit, identify the content and integration work, and define a first release worth putting in people’s hands.
Discuss your knowledge assistant