A free FAQ chatbot that answers the questions your FAQ page misses

1. Point it at what you already wrote. Give it your existing FAQ page URL, your help centre, or a document. It reads the questions and answers you have already written rather than asking you to retype them into a builder.
2. Check the answers it will give. Every answer is editable before the bot goes live. The ones you never wrote down - the questions support actually gets - are the ones worth adding here, and they are usually a short list.
3. Paste one line into your site. A single script tag on your site, or a click for WordPress, Shopify, Wix and Squarespace. The same bot answers on WhatsApp, Messenger, Instagram and Telegram without being rebuilt.

The whole thing takes about the length of a coffee break, and the free plan means you can have it answering real questions before deciding whether it is worth paying for. Start free - no card, no expiry.

These are usually presented as alternatives. They are not - they fail in different places, and most sites end up wanting two of the three.

Keep the FAQ page: it is what search engines index, and the chatbot reads from it. Add the bot for the visitors who would never have scrolled to find the answer. We wrote the longer version of this argument in chatbot vs FAQ page.

Being specific is more useful than a feature list, so here is where this actually earns its place, and where it does not.

It works well on the narrow band of questions that make up most of your support volume - delivery times, returns, opening hours, pricing qualifiers, eligibility, whether you serve someone's country. These have settled answers, they are asked constantly, and they are the reason people email you instead of buying.

It works badly where the answer depends on the individual account, where the question is really a complaint, or where the customer needs reassurance rather than information. Those need a person, and the right design is to route them to one quickly rather than have a bot circle. The single most common complaint about FAQ bots is not being able to reach a human, so the handoff matters more than the answer coverage.

The most under-rated output is the log of questions it could not answer. Read it weekly for a month and it becomes an accurate, unflattering list of what your FAQ page is missing.

If you would rather not start from an empty flow, these are complete FAQ bots you can open and edit.

The instinct is to load in the whole FAQ page. That is the wrong starting point, because an FAQ page is written for browsing and a bot is answering one question at a time. The better method takes an afternoon.

1. Export your last 100-200 support conversations. Email, chat, the contact form, whatever you have. This is the only honest source for what people ask, and it will not match your FAQ page.
2. Group them by the answer, not the wording. “When will it arrive?”, “has it shipped?” and “where is my order?” are one entry, not three. Most businesses find their volume collapses into 10-20 distinct answers.
3. Sort by frequency and stop at the point of diminishing returns. The top handful usually covers over half your volume. Building the long tail first is the most common way to spend a week and deflect nothing.
4. Mark which ones are safe to automate. A question with one correct answer for everyone is safe. A question whose answer depends on the account, the order, or the contract is not - route those to a person from day one.

If you have no support history yet - a new site, a new product - start from your industry template and treat the first month as the research. The unanswered-question log will build the list for you.

The same answer that reads well on a help page often fails in a chat bubble. Three differences matter more than any others.

Lead with the answer, not the context. A help article can open with background because the reader is already committed to reading. In chat, the first line is the whole message for most people. “Standard delivery is 3-5 working days” then the caveats - never the reverse.

Keep it to roughly forty words. Anything longer arrives as a wall in a 380px-wide window and gets skimmed. If the honest answer needs more, give the short version and offer the detail as a follow-up the visitor can choose - which also tells you how many actually wanted it.

Write one answer per question, not one answer per topic. Bots that reply to “do you ship to Ireland?” with the full shipping policy are technically correct and practically useless. The visitor asked a yes-or-no question.

A useful test before you publish: read each answer aloud. If it sounds like a document rather than a reply, rewrite it. The conversational window design only helps if what fills it reads like a conversation.

Most FAQ bot reporting measures the bot rather than the outcome. Three numbers are worth watching, and only one of them is about the bot.

Deliberately absent from that list: conversation count, engagement rate and satisfaction score. They move for reasons unrelated to whether the bot saved anyone any work. If you want the arithmetic on what deflection is worth in money, the ticket deflection calculator shows the formula rather than hiding it behind an email form.

These are the failure modes worth designing against before launch, because each one is cheaper to avoid than to diagnose later.

1. The bot that will not let go. A visitor asks something outside its knowledge, the bot rephrases the same non-answer twice, and there is no visible way to reach a person. This is the most-reported complaint about FAQ bots and it is a design decision, not a technology limit. Offer the handoff on the first miss, not the third.

2. Answers that were true last quarter. An FAQ bot fails quietly when your prices, hours or policies change and nobody updates it. Point it at a source you already maintain, and re-read the answers whenever the underlying thing changes.

3. Confident answers to account questions. “Where is my order?” has no general answer. A bot that produces one is worse than a bot that says it needs to pass you to someone who can look it up.

4. The interruption. A proactive pop-up on a page that was converting fine costs you more than the answers gain. Trigger on intent - a pricing page, a long dwell, an exit - rather than on a timer.

There are three ways to give an FAQ bot its knowledge, and they behave differently enough that the choice matters more than the platform.

Written answers. You type the question and the answer. Completely predictable, never invents anything, and the maintenance is yours. Right for regulated answers, pricing, and anything where a wrong reply is expensive.

Trained on your content. Point it at your site or help centre and it answers from what it reads. Far less setup, covers questions you never anticipated, and the trade is that you review a sample rather than every answer. Right for broad product and policy questions.

Connected to a system. Order status, booking availability, account balance - the answer is fetched live rather than stored. This is where a bot stops being an FAQ and starts being useful for logged-in customers, and it is also where the integration work actually lives.

Most working deployments use the first two together: written answers for the dozen questions that must be exactly right, trained content for the long tail behind them.

Answer the same twelve questions once

Free plan, 600 conversations a month, no card. Import your FAQ and have it answering today.