Companies that implemented a chatbot a year ago and are dissatisfied with it usually share the same problem: the window exists, but it responds uncertainly, invents prices, refers to pages that no longer exist, and doesn’t know when to transfer the conversation to a human. Result: customers click "close" instead of engaging.
This isn’t a technology problem. It’s an architecture problem: a bad chatbot lacks a knowledge base, boundaries, and a plan for handling exceptions. A good AI chatbot for a company website works differently from the first customer message.
What’s the difference between a good and a bad chatbot
#A bad chatbot is a language model with a single system prompt and internet access. It knows a little about everything and nothing concrete about your company. When a customer asks about a package price, it invents a number. When asked about delivery time, it describes industry averages. Every such response erodes trust.
A good chatbot is built on RAG: the model receives a question, searches for relevant fragments in your knowledge base (offer, FAQ, procedures, policies), and formulates a response based on those fragments. It doesn’t invent. When it can’t find an answer, it says so directly and suggests contacting a consultant. This isn’t a limitation—it’s a feature customers expect.
Which questions does a chatbot handle well
#Before choosing an architecture, answer concretely: what should the chatbot do on your website? Not all use cases deliver the same return.
| Question type | Suitable for chatbot | Notes |
|---|---|---|
| Product and pricing FAQs (ranges) | Yes | Requires an up-to-date knowledge base, prices as ranges |
| Lead qualification (industry, need, scale) | Yes | Collects structured data, passes to CRM |
| Scheduling a demo / call | Yes (with agent) | Needs access to calendar or form |
| Negotiations, custom quotes | No | Immediate human-handoff |
| Complaints and escalated issues | No | Chatbot acknowledges receipt, human responds |
| Knowledge / documentation navigation | Yes | Classic RAG, high precision with a good base |
The rule is simple: a chatbot works where questions are repetitive and answers can be extracted from existing documents. Where conversation requires judgment, negotiation, or empathy, the chatbot should recognize it and transfer.
Architecture: RAG as the foundation
#Classic RAG works in three steps. The customer’s question is converted into an embedding (a numerical vector), then compared with vectors of all documents in the vector database. The most similar fragments go into the model’s context as "source material." The model formulates a response based on these fragments, not its general knowledge.
Which documents to index as the first version of the base:
- Website FAQ (all questions and answers)
- Product and service descriptions with detailed parameters
- Price list with ranges (not fixed prices)
- Policies (complaints, deadlines, terms)
- Service procedures (step-by-step for typical situations)
The base should be updated every time the offer changes. Hybrid search (vector + full-text) improves precision for questions about proper names, numbers, and symbols.
Guardrails: what the chatbot can and cannot do
#Guardrails are a set of rules defining the chatbot’s scope and limits. Without them, the language model will answer anything the customer asks—including questions it shouldn’t: about competitors, internal procedures, or unrelated topics.
Minimum guardrails for a company chatbot:
- Thematic scope — the chatbot only answers questions about your company and offer; outside the scope, it refers to a human or remains silent.
- No fixed prices — if the price depends on scope, the chatbot provides ranges and directs to a quote; never gives a number not in the base.
- Manipulation detection — attempts to bypass instructions (prompt injection) should be caught before reaching the model.
- PII masking — personal data entered in the chat window shouldn’t go to external models in plain form; mask before inference.
- Human-handoff — frustration, profanity, escalation questions, no answer after two attempts = automatic transfer to a human with conversation history.
A chatbot that says, "I don’t know, I’ll connect you with a consultant," builds more trust than one that invents answers.
Personal data and legal requirements
#A chatbot on a company website processes data. Even a name entered in the chat window is personal data under RODO. A few obligations you can’t skip:
- Processing information — before the conversation starts, the customer must know who processes the data, for what purpose, and for how long.
- Marketing consent — if the chatbot collects leads, consent must be voluntary and explicit, not forced as a conversation condition.
- Data retention — don’t store conversation history longer than necessary; define the retention period clearly.
- AI nature disclosure — under AI Act, the customer has the right to know they’re talking to an automated system, not a human. The chatbot should introduce itself.
- Data residency — if the company operates in regulated sectors, check whether data goes to the cloud or stays local.
Details on AI Act and RODO are covered in the article on company obligations in 2026.
Integration with CRM and company systems
#A chatbot that only answers questions is a concierge. A chatbot that classifies leads, saves data to CRM, and sends notifications to sales is already a light agentic layer. The second version delivers measurable results in the sales funnel.
Typical valuable integrations to start with:
- Saving leads to CRM with filled fields (industry, need, email, phone)
- Notification to Slack or email for hot leads
- Proposing a call time with calendar integration
- Escalation to a ticketing system for service issues
Every integration should have a human approval point for irreversible operations (data deletion, document sending, order status changes). We design this exactly in Cashcrown.
Cost and implementation time
#The cost of an AI chatbot for a company website depends on scope. The simplest version (ready window, your FAQ base, guardrails) is a different project than a chatbot integrated with CRM, calendar, and service system, with its own analytics panel.
Approximate ranges (detailed quote from the ROI calculator):
- Starter version (RAG on FAQ, window on site, guardrails) — weeks, not months; pilot cost well below a full-time salary.
- Integrated version (CRM, calendar, analytics panel, multilingual) — several months depending on the number of systems to integrate.
- Self-hosting version (self-hosting) (data stays local, own infrastructure) — higher implementation cost, zero per-query cost after launch.
We never give fixed prices because scope determines everything. Start with a pilot on one process (e.g., FAQ + qualification), measure results, then decide on expansion.
Try it live
#The example below runs the model through our secure sandbox—the same as in the playground: PII masked, zero retention, same guardrails. Paste your company description, and the model will generate a sample set of FAQ questions for the chatbot and assess which require human-handoff.
FAQ
#Will an AI chatbot replace a consultant or service department?
#No, but it will change the proportions. The chatbot handles repetitive questions, qualifies leads, and works 24/7. The consultant gets fewer FAQ-type inquiries and more conversations ready for decision-making. The key is designing a clear boundary: the chatbot knows when a topic exceeds its scope and transfers the conversation to a human with full context.
Won’t the chatbot invent answers?
#With a properly built RAG, the model responds from your knowledge base, not its imagination. When an answer fragment isn’t covered in documents, the chatbot flags uncertainty and suggests contact. Guardrails and response quality monitoring (human or automated evaluation) catch and fix issues before they become habitual.
How long does it take to implement a chatbot on a website?
#A simpler version (RAG on existing FAQ, window on site, guardrails) launches in weeks. A version with CRM integrations and an analytics panel usually takes several months, depending on the number of systems. We start with a pilot on a narrow scope, verify results, then expand.
Is customer data secure?
#Personal data entered in the chat window is masked before being sent to the model. Conversation history retention is configured according to company policy and RODO. For regulated sectors or data residency requirements, we offer self-hosting—the entire stack runs locally, without external cloud.
Where to start if I don’t have knowledge collected yet?
#Start with an audit: what questions do customers ask most often by phone, email, or contact form? That’s a ready FAQ skeleton. A document with 30-50 questions and answers is enough for a solid pilot. The base grows iteratively and doesn’t need to be complete from day one. Also check the automation finder, which helps identify which questions are best suited for a chatbot.