AI chatbots that answer from your content.

• Choose a chatbot integration when questions arrive outside office hours.

  When the same questions arrive at all hours and written answers already exist, a chatbot can answer them from that content and pass the rest to a person.

• Choose a contact form and a fast reply when every question needs a person.

  If most inquiries depend on a quote, a judgment or a conversation, a chatbot only adds a step in front of the person who has to answer anyway.

• Choose support AI when the need is helping staff, not a public chatbot.

  Triage, suggested replies and conversation summaries help a support team without putting a model in front of customers. That work is covered on the AI solutions pillar.

A website chatbot can answer questions the approved content answers: services, opening hours, policies, published prices, how to book and what happens next. It should decline advice it is not qualified to give, promises about outcomes, and anything about a specific customer unless that customer is signed in and the chatbot is permitted to see their records.

The scope is written before the build and tested after it. A chatbot that can say it does not know is safer than one that fills a gap with a plausible guess, so declining is designed in rather than left to chance. Where the model supports it, answers carry citations: some providers offer a citations feature that lets the model cite the passages of supplied documents behind an answer, so the sources can be tracked and verified.

What visitors type is screened too. Moderation models from some providers detect harmful content in text and images, with results an application can use to filter content or route a request for review. Limiting how much text a user can enter also helps avoid prompt injection.

A chatbot hands a conversation to a person when the visitor asks for one, when the question is outside its scope, when it cannot find an answer in approved content, or when a rule flags the topic as sensitive. The handoff opens a chat, a ticket or an email and tells the visitor what happens next.

A handoff is only useful if someone receives it. Each route has a named team or inbox, hours when a live reply is possible, and a fallback outside those hours, such as a ticket with a response time the business sets. The chatbot never pretends that a person has joined when none has.

A chatbot qualifies a lead by asking the few questions sales would ask first, such as the service needed, the timing and the budget range, then creating the inquiry in the CRM with the answers and the conversation attached. The qualifying questions and what counts as qualified are written by the business, not decided by the model.

The CRM record is created the way a website form creates one: matched against existing contacts, routed to an owner and followed up by the rules the business sets. How that record is matched, deduplicated and kept in sync is covered under CRM and ERP integrations.

Qualifying questions are asked once a visitor shows intent, such as asking about a quote, and never before a visitor has had an answer. A visitor can skip them and still reach a person.

A chatbot is tested with a set of real questions collected from past emails, calls and forms, each paired with the answer the business considers correct. The set runs before launch and after every change to the content, the prompt or the model, and each failure is traced to missing content, retrieval or the model before it is fixed.

Red-teaming an application helps make sure it is robust to adversarial input, so the test set also includes deliberately hostile and off-topic questions. The questions below are the kinds every set contains, whatever the business.

• Common questions with a clear answer in the approved content.
• The same questions worded differently, or with spelling mistakes.
• Questions the content does not answer, where the right response is to say so.
• Requests the chatbot must decline, such as advice it is not qualified to give.
• Attempts to make it ignore its instructions or reveal them.
• Requests that should trigger a handoff to a person.

Chatbot conversations can be seen by the people the business names, such as the team that reviews them, and are processed by the model provider under its terms. How long they are kept, and whether personal details are stored at all, is decided by the business with its legal adviser, then configured in the logging and the provider settings.

Stored conversations need clear policies about data retention, usage and deletion, and the build follows the policy the business sets: logs keep what review needs, personal details are masked or left out where they are not needed, and access to the logs is limited to named roles.

What each model provider does with the data it receives depends on the provider and the plan, which is covered under LLM and AI API integrations. The settings are checked before launch and recorded with the rest of the documentation.

• AI chatbot integration
• Scoped knowledge and retrieval grounding
• Handoff to a person
• Conversation logging and review
• Response guardrails and refusal handling

Each answer follows the same path, and the last stage decides whether the conversation stays with the chatbot or moves to a person.

• Answers outside office hours

  Common questions get an answer at any hour, from the same approved content a member of staff would use.

• Staff time for harder conversations

  When routine questions are answered from approved content, staff can spend their time on the conversations that need a person.

• Inquiries that arrive complete

  Qualifying questions collect what sales or support needs, and the conversation travels with the inquiry.

• A record of what people ask

  Logged conversations show which questions come up most and which answers are missing from the content.

• A service business website

  The chatbot answers questions about services, locations and booking from the site content, then collects details for a callback.

• Qualifying a project inquiry

  A visitor asking about a project answers a few qualifying questions, and the inquiry is created in the CRM with the conversation attached.

• Inside a customer portal

  A signed-in customer asks about an order or a booking, and the chatbot answers from the records of that account, within the permissions granted to it.

• The chatbot is labeled as an AI assistant in its interface and is never given a human name or photo.
• Answers are grounded in approved content through retrieval, and sources are shown where the content supports them.
• Scope rules decide what it declines, and it says plainly when a question is outside what it knows.
• A handoff to a person is always available, and the person receives the conversation so far.
• Moderation and input limits screen what visitors type before it reaches the model.
• Conversations are logged for review, and personal data is kept out of logs where the review does not need it.
• API keys and prompts stay on the server, and the provider data settings are checked and recorded before launch.