AI chatbot for business that answers from your own documents
A customer asks at 10:30 pm. An employee asks about a procedure in the middle of the day. An AI chatbot answers both from your company documents in seconds, and when the answer is not there it says so and hands the conversation to a person with the full history. The same chatbot sits on your website and in your internal channel on Slack or Microsoft Teams.
- 5 to 10 secondshow long an answer from your documents and systems takes, instead of a search through three places
- 2 to 3 weeksfrom workshop to a chatbot that answers from your knowledge base on the website
- 50 questionshow many of your real tickets go through testing before the chatbot goes anywhere near a customer
The problem
Why does a customer ask at 10:30 pm and get nothing back?
A customer opens your site in the evening to ask whether a model is in stock and whether the parcel arrives by Thursday. The old chatbot shows a menu: orders, returns, contact support. Three levels of clicking later comes the line "get in touch between 9 and 5". The tab is closed and nobody in the company knows anyone was there.
The same mechanism runs in the middle of the day and inside the company. Someone asks on Slack about the returns policy, someone else hunts for the current price list, and the answer sits in a document nobody remembers the name of. Support answers the same payment terms question for the third time this week, because there is nowhere a customer could take it from on their own.
The scale of this has been counted. In an audit of 2,241 companies published in Harvard Business Review the average response time to a web enquiry was 42 hours, and 23 percent of companies never replied at all. A question left for two days stops being a question, because by then somebody bought elsewhere.
- The 10:30 pm question waits until morning, and the customer buys elsewhere in the meantime
- Support answers the same question about terms and returns for the tenth time
- The current price list sits in a document half the team does not know about
- A new hire asks people about things that are written down, just not findable
Why now
What changed, so that a chatbot stopped guessing?
A menu chatbot ran on a rule: if the customer writes X, answer Y. Every phrasing had to be predicted and typed in by hand, and customers write the same question in dozens of ways, with typos and abbreviations. A language model reads the intent, so the scripts stopped being necessary.
The second change matters more and it is called RAG. The chatbot does not answer from the model's general knowledge, it answers from the documents you hand it: the price list, the terms of service, product documentation, procedures, the ticket history. Every answer can be checked against its source, and when the documents do not hold one, the chatbot says so and gives the conversation to a person instead of inventing something.
The third change is channels. The website widget installs with one snippet of code, the internal channel is an app for Slack or Microsoft Teams, and your own software connects over a REST API. One tidy set of documents serves the customer on the website and the employee inside the company. When questions about data from systems outnumber questions about document content, the same material feeds BOND, our company AI agent.
What changes
What do support and the rest of the team actually get?
Answers from your documents, not from the internet
The chatbot reads the price list, the terms, the documentation and the procedures you pointed it at, and answers from those alone. The model's general knowledge is switched off for questions about your offer.
Every answer traces back to the document it came from
Routine questions leave the team
Questions about pricing, lead times, terms of work, availability and order status are handled by the chatbot on its own, at any hour. Support gets the cases that need a decision instead of pasting the same reply again.
Scope set on your own tickets from recent months, not on a list of examples
It says it does not know, instead of inventing
A question outside the knowledge base does not end in a made up answer. The chatbot tells the customer and hands the conversation to a person together with the whole history, so nobody describes the case twice.
Topic boundaries and escalation points agreed before launch, not after the first mishap
The same chatbot on the website and inside the company
Customers talk to the widget on the site, the team talks to the same chatbot on Slack or in Microsoft Teams. A new person asks about a procedure instead of searching the drive and asking three colleagues in turn.
The widget is one snippet of code, the internal channel an app, your own software a REST API
Statuses and data from systems, not from memory
A question about order status, variant availability or an invoice is checked in the system and answered with a specific. No email to support for information that already sits in a database.
Read over an API from BaseLinker, Shopify, PrestaShop and Fakturownia, and from an on-premise ERP against its database inside your network
You can see what the chatbot cannot do
After 30 days you get a report: how many questions it closed alone, how many it escalated and which topics have no documents behind them. The knowledge base grows around what customers actually ask.
A report after 30 and 90 days, on metrics agreed before the start
Proof
Do you talk to a chatbot like this yourselves?
Yes, and it is the only proof we can show without asking a client for permission to publish their numbers. An AI agent inside our founders' agency has been answering the team from company data since March 2026, over chat on Slack. Below is the scale of that work, together with what the number does NOT prove.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency of around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
The agent is wired into the CRM, the task system, the data warehouse, Analytics, Search Console and the ad platforms. The team asks it in a plain sentence on Slack, with no logging into tools.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- In March 2026, the first month after launch, 4 people used it and it ran 83 operations. Everyone else asked colleagues for data or dug through dashboards themselves.
- After
- In August 2026, 23 people use it and the monthly operation count is 62,985. Questions about company data stopped bouncing around Slack between people.
From 83 operations and 4 people in March to 62,985 operations and 23 people in August 2026
And in your company
What if our documents are a mess?
Four sentences we hear most often, and how we answer them.
We had a chatbot and customers hated it.
Almost everyone did, and almost every time it was a decision tree with a menu. An AI chatbot has no script to click through: it reads a question written in plain language and answers from documents. In the workshop we show, on your own tickets, which of them the old chatbot let through and which the new one handles.
Our documentation lives in several places and part of it is out of date.
That is how it looks in most companies, which is why the first week goes on the knowledge base and not on the model. A chatbot exposes the gaps faster than an audit, because you see straight away which questions have nothing to answer them. If it turns out there are almost no current documents, we say so and we start there.
We are afraid it will tell a customer something untrue.
That is the right worry and we answer it with architecture, not with a promise. The chatbot answers only from the documents and systems it was given, it has a written list of topics it does not touch, and with no answer in hand it escalates to a person. Every conversation is stored, so any answer can be checked.
We get 20 enquiries a month, this will not pay off.
At that volume a chatbot on the website makes no sense and we will tell you so on the call. Then we look at the internal channel: how often the team asks about procedures and data, because that count is often far higher than the one on the website. If it is low there too, the matter ends with a conversation.
- Knowledge base
- Notion, Confluence, Google Workspace, Microsoft 365, Google Sheets, PDF and DOCX files
- CRM
- HubSpot, Pipedrive, Salesforce, LiveSpace
- Shop and orders
- BaseLinker, Shopify, WooCommerce, PrestaShop, Allegro
- Invoicing and finance
- Fakturownia, sevDesk, Xero, Comarch Optima
- Tickets and team channels
- Zendesk, Freshdesk, Slack, Microsoft Teams
- Technical layer
- Website widget, REST API, n8n, Make, custom API integrations
Kinds of question and where the chatbot takes the answer from
The split we lay out in the workshop. The third column matters most here, because it decides where the chatbot ends and a person begins.
| Kind of question | Where the answer comes from | Who finishes the case |
|---|---|---|
| Pricing, lead times, terms of work | documents and FAQ in the knowledge base | the chatbot, no escalation |
| Order and shipment status | the order system, BaseLinker, read live | the chatbot, data from the system |
| Product and variant availability | the shop: Shopify, WooCommerce, PrestaShop | the chatbot, data from the shop |
| Invoice, duplicate, credit note | Fakturownia, sevDesk, Xero, Comarch Optima | the chatbot gives the status, a person issues the correction |
| A technical problem with the product | product documentation and ticket history | the chatbot diagnoses, the ticket goes to Zendesk or Freshdesk |
| Internal procedure, leave, policy | Notion, Confluence, Google Workspace | the chatbot on Slack or in Microsoft Teams |
| A complaint or a disputed case | outside the knowledge base, the chatbot does not answer | a person, with the full conversation history |
The rows are a starting point. In most companies a first launch covers three or four kinds of question, and the rest is added once the report shows customers are asking about them.
How we do it
Five steps from documents in a mess to a chatbot on the website
Every step ends with something you can judge before you decide on the next one.
Workshop and the question list
We take your tickets from recent months: email, chat, phone calls written down by support, threads on Slack. Out of that comes a list of questions ranked by how often they come back and how much time an answer eats. We also agree which topics the chatbot does not touch.
Knowledge base
We tidy the documents and prepare them in the form the chatbot answers from: price list, terms, product documentation, procedures, the replies support already uses. This is where it becomes clear which questions have nothing to answer them, and that is a separate result of this step.
Integrations and escalation
We connect the systems the chatbot reads live: the shop, the order system, the CRM, invoicing, tickets. We configure the handover to a person with the full history and agree how the chatbot recognises that a case is beyond it.
Testing on 50 real questions
We test on at least 50 questions taken from your own tickets, not on examples from a deck. We correct the answers, the topic boundaries and the escalation points until the result is acceptable to the person who replies to customers by hand today.
Launch and measurement
The widget goes onto the site with one snippet of code, the internal channel through an app. After 30 days a report: how many questions the chatbot closed alone, how many it escalated, where it loses conversations and which documents are missing. After 90 days the same, on the same metrics.
Before and after
How a day in customer support changes
Before
- Twenty questions from the evening sitting in the inbox in the morning, half of them the same
- The customer describes the case a second time, because the chatbot passed nothing on
- One person knows the current price list, so every pricing question lands on them
- A new hire takes half a day off someone experienced, asking about procedures
After
- The evening questions have answers, and only the cases that need a decision are left in the morning
- The escalation arrives with the whole conversation, so support starts inside the context
- Pricing and terms answer themselves, from a document somebody tidied once
- The new person asks the chatbot on Slack and gets the procedure back in seconds
You see the first conversations on launch day. How many questions the chatbot closes alone, and where the documents run out, is judged after 30 days on real conversations.
For the person signing this off
What the head of customer support gets out of it
You stop explaining to the board why the team grows with the order count while half the questions have been the same for two years. Instead you have a number: how many questions the chatbot closed, how many went to people and which topics have no documents behind them. That is an argument in the headcount conversation that you do not have today.
The second point is about risk, so we say it plainly. A chatbot answering from the model's general knowledge can tell a customer something that is not in your offer, and you are the one who answers for it. So answers come only from your documents, the out of scope topics are written down, and every conversation is stored and open to review.
- A report after 30 and 90 days, on metrics agreed before the start
- You approve the topic boundaries and escalation points before launch
- Testing on 50 of your own real questions, before the chatbot sees a customer
- Your own people top up the knowledge base, with no ticket to us
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week and runs from 1 to 7 weeks depending on scope. For a chatbot one week is usually enough, because the process is narrow: from the customer's question to the answer. We quote the rollout after the workshop, once it is clear what state the documents are in and how many systems have to be connected for the chatbot to answer with data rather than with generalities.
You pay for models and tools directly to the provider, according to your own usage, with no margin from us. A chatbot answering a few hundred questions a month from a knowledge base is cheap on the model side, typically EUR 0.005 to 0.07 per query, and the bill grows when reads from several systems pile into one conversation.
Process workshop
EUR 3,500 net
per week, usually one week for a chatbot
A self-contained piece of work. It ends with a list of questions for support and a knowledge base plan you can execute without us.
- A list of questions from your own tickets, ranked by how often they come back
- An inventory of the documents you have and the ones you are missing
- Topic boundaries and the points where a conversation goes to a person
- The metrics to measure after 30 days
- Most popular
Workshop and chatbot rollout
Quoted after the workshop
scope follows from the number of integrations and the state of the documents
The option most companies choose. A chatbot answering from your knowledge base, on the website and in the internal channel.
- Everything in the workshop
- A knowledge base prepared for answering from documents
- Integration with the shop, the CRM, invoicing or the ticket system
- Website widget plus a channel on Slack or in Microsoft Teams
- Testing on 50 real questions and a report after 30 days
Chatbot and a company AI agent
Quoted after the workshop
for companies where questions about data outnumber questions about documents
Everything in the rollout plus BOND, the company AI agent that answers from company data, not only from the knowledge base.
- Everything in the chatbot rollout
- BOND wired into your systems, an answer in 5 to 10 seconds
- An internal channel for the team, in English and Polish
- Agent rollout counted in roughly 2 months
The workshop ends with a question list and a knowledge base plan that stands on its own without us: you can execute it yourself or with another company. If it turns out there are too few questions, or that there is nothing to answer them with, we say so and the matter ends at the workshop instead of at a rollout you do not need.
Frequently asked questions
How is an AI chatbot different from a menu chatbot?
A menu chatbot runs on rules: if the customer writes X, answer Y, and every phrasing has to be predicted by hand. An AI chatbot reads the intent of a question written in plain language, copes with typos and abbreviations and needs no scripts. Instead of a decision tree the customer gets a conversation, and asks about the thing they came for straight away.
Does an AI chatbot invent answers?
Not when it is built on RAG. Then it answers only from the documents you supplied and from data read out of your systems, rather than from the model's general knowledge. On top of that we write down the topics it does not touch and we store every conversation, so any answer can be checked against its source.
What happens when the chatbot does not know the answer?
It tells the customer and hands the conversation to a person together with the full history, so nobody describes the case twice. Escalation points are agreed before launch: the kind of question, a complaint, no match in the documents, a clear request to speak to a human. If the case needs a ticket, the chatbot opens one in Zendesk or Freshdesk.
How long does it take to roll out an AI chatbot in a company?
A chatbot answering from a knowledge base on the website: one week of workshop and 2 to 3 weeks of rollout. The version that reads data from systems, meaning order status, availability and invoices, takes 4 to 6 weeks, because integrations and testing on real data are added. Installing it on the site after launch is one snippet of code.
How much does an AI chatbot for business cost?
The process workshop costs EUR 3,500 net per week and for a chatbot one week is usually enough. The rollout is quoted after the workshop, because the cost depends on the state of the documents and the number of systems to connect. Models and tools are paid directly to the provider according to your usage, with no margin from us, typically EUR 0.005 to 0.07 per query.
Where can the chatbot be deployed?
On the website as a widget installed with one snippet of code, in the internal channel as an app for Slack or Microsoft Teams, in your own software over a REST API. The same set of documents serves every channel, so a customer and an employee get an answer from the same source. The document scope per channel is agreed separately, because not everything the team sees is meant for a customer.
Does the chatbot handle languages other than English?
Yes. The Claude and GPT models we build on handle English, Polish, German and other European languages with no separate configuration for each. The answer comes back in the language of the question, and the documents can stay in one language even when the customer writes in another.
How is the chatbot different from BOND, your company AI agent?
The chatbot answers from documents and from a few systems, in one conversation, usually on the website and in the team channel. BOND is a company AI agent: it answers from company data in 5 to 10 seconds, reaches into many systems at once and carries out tasks rather than only answering. An agent rollout is counted in roughly 2 months, a chatbot in weeks, which is why we often start with the chatbot.
Let us look at what your customers ask most often
The free consultation takes 30 minutes. You tell us how many questions you get and where they come from, even if nobody counts them, and where the documents with the answers sit. We show which questions a chatbot closes from your documents straight away, and which need the knowledge base sorted out first. At this stage you do not have to give us access to any system.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If someone at your company answered the same question about lead times or returns for the third time this week, that is exactly this problem. The answer already sits in your documents, it is just that nobody outside the team can reach it at 10:30 pm. Sorting that out is where the workshop starts.