The XICBOT manual
How the application is structured, which area answers which question and in what order to proceed: from the first source through approving tools to reviewing conversations. Written for the person who actually maintains the assistant.
This manual describes working with a running assistant. If you do not have an account yet, the path there is described under Create an account; if you want to know what the assistant can do, see Features. This page is about operating it: which area answers which question, what a change does and how you can tell that it worked.
The areas of the application
The application lives at /app and is divided into areas that follow an order: first the assistant, then its knowledge, then what it is allowed to do, and finally what production creates. Each area answers a different question.
Assistants
Name, languages, tone of voice and behaviour when a question cannot be answered. This is also where the embed snippet is generated and where you list the domains on which the widget may load.
Knowledge
All sources with their state, section count and last read. Here you add website addresses, documents and your own texts, exclude pages and trigger a fresh read.
Tools
What the assistant may do beyond answering: look things up, propose appointments, take enquiries. Writing tools are approved individually and can be switched off individually.
Conversations
Every conversation with its course, the sources used and any handovers to humans. The place where gaps in the knowledge base show up before anyone reports them.
Analytics
Development over time: conversations, answered and unanswered questions, handovers, frequent topics. Numbers with a period attached, not without.
Cases
What the assistant triggered: enquiries taken, appointments proposed, requests forwarded — with state and timestamp.
Audit log
Every change to assistant, sources, tools and approvals with timestamp and the account that triggered it. Anyone looking for something that changed inexplicably looks here.
Operations
State of processing: running reads, queues, the quotas of the booked package and the most recently measured availability.
Legal and account
Data processing agreement, deletion periods, retention, access and rights per person, and deletion of the account including its data.
The first steps in your account
Create and name the assistant
The name appears in the widget. Language and tone determine how it answers; the behaviour for unanswerable questions decides whether it asks back or hands over. These settings can be changed at any time without touching the knowledge base.
Read in the first source
Usually your own website. The read runs in the background; under Knowledge you see which pages were taken in and how many sections came out of them. A source without sections is a source that could not be read — that is a finding, not an interim state.
Review the answers
Ask ten to twenty real customer questions in the test area. Every answer names its source. If an answer is missing, the source is usually missing, not the capability — add the content instead of changing the wording.
Approve tools
Only once the answers are right do you approve tools. Start with reading tools, add writing ones individually and test each in the test area before it becomes reachable on your website.
Embed the widget and set the domains
The line from the Assistants area goes into your template. Enter the permitted domains so the widget cannot be loaded on foreign sites. Then check once in a real page view that it appears and answers.
The name appears in the widget. Language and tone determine how it answers; the behaviour for unanswerable questions decides whether it asks back or hands over. These settings can be changed at any time without touching the knowledge base.
Usually your own website. The read runs in the background; under Knowledge you see which pages were taken in and how many sections came out of them. A source without sections is a source that could not be read — that is a finding, not an interim state.
Ask ten to twenty real customer questions in the test area. Every answer names its source. If an answer is missing, the source is usually missing, not the capability — add the content instead of changing the wording.
Only once the answers are right do you approve tools. Start with reading tools, add writing ones individually and test each in the test area before it becomes reachable on your website.
The line from the Assistants area goes into your template. Enter the permitted domains so the widget cannot be loaded on foreign sites. Then check once in a real page view that it appears and answers.
Keeping the knowledge base current
An assistant goes out of date exactly as fast as the content it answers from. When prices, opening hours or services change, change them at the source and have it read again — the assistant does not have to be rebuilt for that. The following habits keep the state clean.
- After every content change on the website, have the affected source read again and then check the state, not the confirmation message.
- Remove sources nobody maintains any more instead of leaving them: an outdated source keeps producing answers.
- Review the unanswered questions under Conversations regularly — they are the most reliable list of what is missing from the knowledge base.
- Maintain prices, deadlines and commitments in exactly one source. Two sources with different numbers produce two different answers.
- After larger changes, ask the same test questions that the assistant was accepted with.
Tools and approvals
Tools differ in one point that matters: reading tools fetch information, writing tools leave a trace in another system. That is why every writing tool is approved individually, can be switched off individually and is traceable in the audit log. The assistant acts only within what has been approved; what is not approved, it does not offer.
Changes take effect immediately, but not retroactively