Start with an FAQ when a small set of stable answers is simply hard to find. Consider an AI chatbot when visitors need to ask questions across a wider body of approved information. Add live chat when the conversation needs a person’s judgement and your team can reliably staff it. Keep a direct contact route available whichever option you choose.

This FAQ vs chatbot vs live chat guide helps you choose that first step. It is a channel decision, before you compare suppliers or install software.

What each channel asks of your team

An FAQ or help page lets visitors read an answer without starting a conversation. It suits clearly named questions with reasonably short, stable answers. Someone must still keep those answers current and make the page easy to reach from the point of uncertainty.

A source-based AI chatbot lets visitors use their own wording and ask follow-up questions about the material your business has supplied. Someone must review that material, test the answers and deal with gaps. A chat interface does not itself provide access to a customer’s order, subscription or private account.

Live chat puts a person into the conversation. That person can investigate and make decisions within their authority, but needs time, the right information and a clear way to take responsibility for the request. An unstaffed live-chat window is not a useful substitute for a contact form.

These channels can work together. An FAQ may be both a useful page and a chatbot source; a chatbot may offer a route to a colleague. You do not have to launch every layer at once.

Match five question types to the right first route

Classify the task behind the question before choosing a channel. A general delivery question and an individual missing-parcel enquiry may use similar words but require different information.

On smaller screens, swipe or scroll within the table. Keyboard users can focus the table and use the arrow keys.

The table is a starting framework, not a rule that every business must implement identically. Some systems support authenticated lookups or controlled actions. Ask for proof of the specific connection you need; crawling a public website does not establish that capability.

Choose an FAQ first when the answer already fits on one page

If visitors repeatedly ask for opening hours, service areas or a basic eligibility rule, check where that answer appears. A clearly labelled link beside the relevant service or purchase step may solve the problem with less operating work than a new chat channel.

An FAQ is a strong first choice when the question set is small, answers are stable and visitors can recognise the right heading. It is also the place to start when your sources disagree. Giving a chatbot two conflicting rules does not decide which one your business intends to honour.

The output of this decision should be specific: “Make the service-area answer visible from the enquiry page,” rather than “Improve self-service.” Use our website FAQ guide for the separate task of writing the answer clearly.

Consider AI chat when the difficulty is finding and combining approved information

A visitor may not know which page contains the answer. They may ask whether a package includes a particular feature, then add a condition that changes the answer. A source-based assistant is worth evaluating when these questions span several well-maintained pages or documents.

The useful test is whether the assistant can help with a defined group of questions while preserving the conditions in the source. It should also recognise when the material cannot establish an answer. A fluent response is not evidence that the information is correct.

Keep the scope narrow enough for your team to check. For example, start with published package inclusions and preparation requirements. Leave negotiated discounts, private records and exceptions with the people or systems already authorised to handle them.

Once you have decided that chat is worth testing, the website knowledge base chatbot buyer’s guide covers the next decision: evaluating a supplier using your own material.

Add live chat when a person can make progress during the conversation

Live chat is most useful when an available colleague can clarify the situation, inspect the relevant information or make an authorised decision. It is less useful when the operator has to pass every question to someone else and cannot set an honest expectation.

Before adding it, name the person covering each period and the route available when they are absent or busy. State service hours with a time zone when visitors may come from different countries. An English-language website serving the UK, Europe, North America or Australia should not leave people guessing whose “9 to 5” applies.

If the team cannot staff live chat consistently, a clear contact form or email route may be the better first step. Keep it visible on the website, so visitors can contact you without opening the assistant. Our live-agent takeover guide explains the operating decisions in more detail.

Work through a small-team example

Fictional planning example: a two-person equipment supplier receives questions about published product dimensions, delivery regions, individual order progress and special compatibility requirements. This is an illustration, not a RobiFox customer case study or measured result.

The team first makes the product specification and delivery pages easier to find. It considers a source-based chatbot for questions that span those pages. Order progress stays with the existing account or support route, because the public information cannot establish an individual shipment’s state. Compatibility exceptions go to the person who can assess them.

The first investment could therefore be a clearer help page followed by a limited chat evaluation. Adding a promise of immediate human chat would make little sense unless one of the two colleagues could cover it. The decision follows the question and the available capacity, rather than an assumption that more channels are always better.

Write your first-investment decision in six lines

Copy this short record into your planning notes and fill it in with your own evidence:

• Question group: the recurring task we want to help visitors complete.
• Source: the current page or document that establishes the answer.
• First route: FAQ, source-based chat, staffed chat or direct contact.
• Owner: the person responsible for content and any follow-up work.
• Boundary: the requests this route cannot resolve and where they go instead.
• Review evidence: what we will inspect to decide whether to continue, change or stop.

Use a manageable sample of recent questions with personal details removed. If you have no reliable sample, label the decision provisional and start collecting one. Do not invent demand to justify a tool you already want to buy.

Review whether visitors can find the answer, whether sampled replies are correct and whether requests for a person reach a usable route. Widget opens alone cannot establish that someone received useful help. If the evidence points to a clearer FAQ without a chatbot, that is a valid outcome.

Where RobiFox fits

RobiFox is an option to evaluate when the task is answering from approved website or document information, showing source references and keeping a route to human support. Its features include knowledge review, conversation inspection, contact requests and live chat. Live chat still needs appropriate project settings and real operator availability; the software does not supply your support staff.

If your recurring questions are suitable for source-based answers, see how RobiFox works. You can then try the free website preview with your own site and question sample. The preview uses up to ten website pages and requires email confirmation; it is not a test of private-account access or a complete deployment. Our preview walkthrough explains what that limited first check can show.

Cover image: AI-generated editorial illustration, not a product screenshot.

Start with a simple model: first-month cost = setup work + recurring software and operating costs. For later months, remove the one-off setup work and update the usage assumptions with actual data. The worksheet below helps you do that without inventing a return on investment or assuming that every website visitor becomes a billable conversation.

Separate the provider’s bill from your team’s work

A predictable software bill can still require regular staff time. Keep these costs separate so you can tell whether a change comes from demand, a plan upgrade or the work needed to keep answers current.

• Software: the subscription, any deliberately purchased extra capacity, and separately priced features you actually enable.
• Initial preparation: correcting source pages, resolving conflicting policies, configuring the assistant and installing the widget.
• Ongoing review: checking conversations, updating knowledge and retesting important answers after changes.
• Human follow-up: enquiries, exceptions and account-specific questions handled by your team.

RobiFox’s standard service does not include custom development, consulting or content writing unless separately agreed. If you need outside help with those tasks, add the actual quote rather than treating it as part of the subscription. The service terms describe that boundary.

Understand the billable unit before estimating usage

A visitor, a message and a billable conversation are different things. Someone can browse without opening chat. A conversation can contain several messages. The same person can return and begin another conversation.

RobiFox’s published pricing uses conversation credits rather than a charge for every message. For standard text chat, one credit covers one conversation. Refusal-only conversations do not consume that credit. If the assistant has already given a chargeable answer, a later refusal or human takeover does not refund the credit already used.

Human messages during live takeover do not consume AI conversation credits, and the pricing page lists live chat as included without a per-agent fee. Your staff’s time still belongs in your operating budget.

Before modelling voice or other optional modes, confirm their credit rules separately. Also confirm when a long or resumed exchange becomes a new conversation. Do not multiply a message count by a conversation price, or assume one customer can only consume one credit in a month.

Use current plan limits, not a generic chatbot price range

The following examples were checked against RobiFox’s pricing page on 29 October 2026. They are monthly EUR prices excluding VAT. The final tax-inclusive amount is shown at checkout and depends on the billing details. Check the current page and checkout before buying; these are dated reference figures.

On a small screen, scroll the tables sideways to see every column.

A plan must fit your sources and number of websites as well as your conversations. A low-volume site can still need a larger page allowance. The linked pricing page includes the other plans and current limits.

RobiFox’s published terms say there is no automatic overage billing: when the allowance is exhausted, the assistant becomes temporarily unavailable and offers to collect contact details. You can choose to change plan or top up. Do not budget an invented per-credit overage rate. Obtain the current top-up price and validity rules before adding that purchase to your worksheet.

Unused monthly allowance does not carry into the next period. Subscriptions renew monthly until cancelled; cancellation keeps the plan available until the end of the paid period. Those rules affect how much capacity you should buy and when to review it.

Build a demand baseline from a defined period

Use a recent period that represents the customers and pages you intend to serve. Record its dates, traffic sources and any unusual promotion. If you already have chat, use its actual conversation and credit records. If you do not, mark chat demand as unknown and measure it during a pilot.

As an initial planning estimate, you can use:

Estimated conversation starts = eligible website visits × assumed chat-start rate.

That estimates starts, not billable usage. A second estimate needs the observed billable share and the rules for repeat conversations and different modes. Validate both against the account’s credit records. An analytics visit count and a chatbot conversation count need not have the same measurement boundaries.

Do not treat all support enquiries as removable workload. Some involve account access, judgement or exceptions that a website knowledge assistant cannot resolve. Our guide to a website knowledge-base chatbot explains the source-based use case.

Copy this budget worksheet

Choose one reporting currency. Fill the blank inputs with your own time estimates, internal hourly cost or supplier quotes. An unfilled input means unknown, not zero. Keep supplier charges and staff time separate to avoid counting the same outsourced work twice.

If you report in GBP, USD, CAD, AUD or NZD, record the EUR conversion rate, its date and any actual payment fee. Do not assume a fixed exchange rate. For a cash budget, include the tax actually paid; for an expense budget, use the tax treatment your accountant confirms. Keep those two views distinct.

Test low, base and high demand without inventing savings

Copy the following table alongside the cost lines. Use measured ranges where available. If a rate is only an assumption, label it and give it a review date.

In a high-demand case, the decision may be to upgrade, authorise a top-up or accept temporary unavailability. Record the operational consequence alongside the price. A hard billing cap protects the bill; it does not guarantee uninterrupted answering after the allowance runs out.

Do not subtract a guessed number of “hours saved” to make the total look attractive. Measure workload and customer outcomes separately. Our guide to reducing support tickets without guesswork explains how to assess that question.

Close the billing questions and assign an owner

Before approving the budget, confirm the conversation boundary, optional-mode credit costs, current top-up terms, page-processing limits and the final checkout amount. Confirm any automatic top-up setting and its cap separately; “no automatic overage” does not mean a separately authorised purchase setting should be ignored.

Name one person to review usage and one to approve spending. Set a practical review trigger: before a campaign, when the expected allowance is no longer sufficient, or when source updates increase the review workload. Replace assumptions with actual conversation credits and logged staff time after the pilot.

Compare the current RobiFox plans once you know the conversation, website and page capacity you need. If the fit is unclear, ask for clarification before paying. A useful budget makes both the price and the remaining work visible.

A good preview gives you a reason to investigate further. It does not establish that every page has been read, every answer is correct, or your assistant is ready for customers. This guide explains how to run that first check and keep a clear record of what you actually tested.

Preview limits checked on 29 October 2026: up to 10 website pages, 15 questions and 30 days of access to the finished preview. Check the request form for current limits before starting.

Start with a website you own or have permission to test

Choose the public website your visitors use. For an English-language evaluation, begin with its English version and use English questions. Pick a site whose content you can check yourself; you will need to compare the assistant’s answer with the underlying page.

Before requesting the preview, write down two questions. The first should have a clear answer on a public page, such as what a service includes. The second should ask for information the site does not supply, such as a private account detail or an unpublished delivery commitment. Use invented account references, never a real customer’s details.

That small preparation makes the preview more useful than a sequence of easy questions chosen after seeing what it already knows.

Request the preview, then start it from the email

1. Open the RobiFox homepage and select Get my free website preview.
2. Enter your email address and website address. The newsletter option is separate and optional.
3. Select Send my verification e-mail. Receiving a message is a separate step from submitting the form.
4. Open the verification email and follow it to the preview start page. Start the preview there; submitting the original form alone does not complete the process.
5. When the assistant is ready, inspect the pages it read before asking your prepared questions.

No credit card or account is required for this website preview. It is created on a separate page and does not install a chat widget on your website. Keep the email confirmation link private. If you share the finished preview with a colleague, you share its question allowance rather than giving each person a new allowance.

Check the page sample before judging the answers

Up to 10 pages is a limit, not a promise that every relevant page is included. A pricing page, policy or English service description outside that sample cannot support an answer in this preview. A website with hundreds of pages needs a broader evaluation.

Look through the listed source addresses. Does the sample include the page you expected? Is it the right language? Is the answer still current on that page? If the page was not included, record a coverage gap rather than concluding that the assistant ignored information it had read.

Also check what the source itself says. If two pages publish conflicting terms, the preview cannot decide which commitment your business intends to make. Correct the underlying material and review the resulting knowledge before relying on it.

What happened in our own preview on 29 October 2026

We submitted robifox.com from its English homepage, received the verification email, opened the start page and selected Build my preview. An initial submission returned a security-check error; reloading the page and submitting the form again succeeded. We did not bypass the security check.

The finished preview reported 10 pages read. Its list contained five English addresses: /, /faq, /about, /contact and /pricing. It also contained five Hungarian addresses: /hu, /hu/arak, /hu/gyik, /hu/rolunk and /hu/kapcsolat.

This matters for the scope of the result: starting from our English homepage produced a mixed-language source sample. It did not read every English page or demonstrate coverage of the whole blog. We asked both test questions in English.

Covered question: the account trial

We asked: “How long is the free account trial, and do I need a credit card?”

The free trial lasts 14 days. You do not need to provide a credit card to start it.

The response linked to our pricing page and the homepage. We checked those two claims against the live pages: both were supported. The source badges were labelled machine draft, a reminder that this was preview material rather than a completed business review.

Uncovered question: a private subscription detail

We asked: “What is the expiry date of my private RobiFox subscription for account TEST-NOT-A-REAL-CUSTOMER?” The account reference was deliberately invented.

I can’t confirm the expiry date of a private RobiFox subscription from here. I don’t know this account-specific information.

The assistant declined to supply the private date. That was the appropriate boundary for this question. It did not complete a human handoff in this test, so we cannot describe the response as a successful escalation. The interface showed 14 questions remaining after the supported answer and still showed 14 after this refusal.

These are two observed responses from one preview of our own site. They do not establish an English accuracy rate, cross-language answer quality, customer results or production readiness. We did not complete a new account registration, upload documents or install a widget during this test.

Try one covered question and one uncovered question

A question with a known source

Ask your first question without supplying the answer in the question. Open the cited source and compare the actual claims: what is included, what is excluded, and whether any condition or exception has been lost.

A clickable citation is helpful, but the link existing does not prove the answer is supported. If the answer makes a specific promise, find that promise in the source. Record missing qualifications as well as factual mistakes.

A question the sampled content cannot answer

Now ask the deliberately uncovered question. Check whether the response acknowledges the missing information rather than inventing a business-specific answer. If it suggests contacting someone, distinguish that suggestion from a completed handoff: no person has necessarily received or accepted the conversation.

Adapt these tests to your own content; the observed responses above belong to our site. An answer that passes one question can fail another. A refusal on an uncovered question is useful evidence about that response, not proof that every unsupported question will be handled correctly.

For a deeper check of individual answers, use our guide to evaluating a chatbot with source citations.

Keep a simple preview scope card

Copy this table into your evaluation notes. Retain the actual wording of both responses, including an unhelpful answer or failure. Leave a field as “not tested” when you have not checked it.

On a small screen, scroll the table sideways to see both columns.

If you capture screenshots, hide email addresses and access links. Keep the source list and the response visible so a colleague can understand the evidence without access to your inbox.

The website preview and the account trial are different steps

The preview tests a limited sample of public website pages. It is not the place to upload PDF, Word or Excel files, approve a complete business knowledge base, or install the assistant on your live site.

The separate account trial currently runs for 14 days, with 50 conversation credits, one project and up to 100 crawlable pages. Its allowance is a one-off trial allowance. The preview’s 15-question limit and 30-day access period do not describe that account trial.

The verified owner can continue from the preview into registration and retain the knowledge already prepared for the same website. Use the owner journey from the confirmation email in the same browser session; a colleague opening only a shared preview link does not gain ownership of it. If you return later, reopen the original confirmation email link in the browser you will use for registration before continuing; owner verification is time-limited. Check that the expected project and source material are present after registration before adding more.

You still decide which knowledge is suitable for customers, which further sources to add and when to install the widget. Our guide to building a website chatbot from existing content covers the fuller launch process.

Use the preview to choose your next step

Continue to a fuller trial when the sample contains relevant material, the answers you checked are supported, and you know what still needs testing. Fix the source content first when an important policy is missing or contradictory. Investigate further if an answer invents a commitment or a source does not support it.

The useful outcome is a documented decision, with specific work left to do. Request your free RobiFox website preview, try your two prepared questions and save the scope card before deciding whether to continue.

This is an introduction to the idea and its vocabulary. The worked example below shows what grounding can and cannot establish. If you are already comparing products, move on to the website chatbot buyer’s guide; if you are checking a particular reply, use the single-answer source check.

What does “grounded” mean in a support answer?

An answer is grounded when its factual claims are supported by the relevant source information. For customer support, that may be a current service page, product guide, policy or approved document. The source provides the basis for the claim; the assistant turns it into a response to the visitor’s question.

Grounding is not the same as adding a citation label. A reference can point to a real page while the answer adds an unsupported promise. It is also not a guarantee that the source itself is accurate. A perfectly faithful summary of an outdated policy can still mislead a customer.

Five terms that are easy to confuse

You may also hear “retrieval-augmented generation” or RAG, introduced in the research by Lewis and colleagues. Broadly, this describes finding relevant information to supply when generating a response. It is different from changing a model’s training weights. The technique alone does not provide approval, accurate policies, visitor access to citations or a staffed support route; those need their own controls.

A worked example: one policy, two different questions

Fictional source: “Unused standard items can be returned within 30 days. Made-to-order items are excluded. Contact the team before sending an item back.” This is an illustration, not a statement of RobiFox’s terms or a measured customer result.

Question one: “What is the return window for an unused standard item?” A source-backed response can explain the 30-day rule and the contact step, then identify the returns policy. It should preserve the conditions that make that answer applicable.

Question two: “My made-to-order item arrived late. Can you approve its return?” The same policy does not authorise an exception or settle this individual case. The assistant can explain the published exclusion and direct the visitor to the business, while making clear that it has not approved the return.

The difference is the evidence available for each claim. Grounded support should make that boundary visible. The business also needs a process for complaints or other rights that the short policy example does not address.

Where the business still has work to do

Somebody must decide which information is authoritative, resolve contradictions and review changes to prices, service limits or policies. The assistant cannot make two conflicting business instructions agree simply by quoting them. Our knowledge-base governance guide explains ownership; the approval workflow follows a specific content change.

A second responsibility is checking actual answers. Did the response use the right passage, retain the necessary condition and explain what remains unknown? For the failure patterns and repairs, see reducing unsupported chatbot claims. Grounding is a useful design goal, not a substitute for testing.

Where this approach is useful

It is a practical fit for recurring questions about documented services, product details, onboarding steps and published policies. A visitor can find an answer in context and inspect its basis without searching the whole site. Whether this reduces staff work or improves sales needs to be measured in the business’s own operation.

Account balances, order changes, personalised decisions and exceptional commitments need separately verified access or human authority. Being able to explain a process does not mean an assistant can complete it. Multilingual replies also need checks: finding a source in one language does not prove that every translated answer preserves its meaning.

See the workflow in RobiFox

RobiFox combines approved website and supported document knowledge, source references, conversation review and human support routes. Explore how the workflow operates and the current features, then try the free website preview with questions about your own published information. It covers up to 10 website pages and uses email confirmation; document uploads belong to the separate account workflow.

Start with a question you can inspect: “Can I understand why this answer is supported, and what still needs a person?”

Cover image: AI-generated editorial illustration, not a product screenshot or a real customer case.

This guide shows how to verify chatbot sources for one answer, using three worked examples and a small check record. It is for a visitor checking a reply or a colleague reviewing a specific conversation. For choosing a provider, use our cited-answer buying guide; for a repeatable team testing programme, use the citation-audit guide.

For the underlying concept and vocabulary, start with our introduction to grounded customer support.

1. Name the claim you need to check

Separate the answer into the statement that affects your decision and the conditions attached to it. “You can return this item within 30 days” contains more than a deadline: it also claims that this particular item is eligible. A genuine link does not prove both parts.

Write down the question and copy the relevant answer before opening the reference. If the reply combines several claims, check them separately. Do not pass the whole answer because its first sentence is correct.

2. Open the reference and find the supporting passage

Follow the citation from the same visitor view in which the answer appeared. Can you open the material, identify its owner and find the passage supporting the claim? A help-centre homepage or an unexplained “knowledge base” label leaves that work unfinished.

An internal file reference may be useful to the business without being publicly accessible. If you cannot inspect it, ask the team to confirm the applicable information or provide a suitable public source. A source you cannot open is unverified from your perspective; it is not automatically false.

3. Compare the important conditions

Look for the product or plan, destination, eligibility, date and exceptions that matter to your question. Check whether the cited page is the current policy rather than an expired promotion or an older document. A recent page date alone does not establish that its contents govern your case.

These are invented teaching examples, not RobiFox test results or statements of any business’s actual terms. Their purpose is to show how an apparently relevant reference can still fail to support an answer.

4. Record a verdict that matches the evidence

Use a short record: question → exact claim → source URL or document/version → relevant passage → verdict → next step. Useful verdicts are supported, partly supported, unsupported, and unable to verify. Add a note explaining the missing condition instead of giving an unexplained pass or fail.

For the first example, a completed note could read: “Claim: any item is eligible. Evidence: current returns page excludes clearance items. Verdict: partly supported answer, unsupported eligibility claim. Next step: confirm whether this item is clearance.” This preserves the evidence without pretending that the checker can approve a return.

5. Decide whether you can act on the answer

If the current source supports the relevant claim and its conditions, you have a clearer basis for your decision. If the source is missing, inaccessible or contradictory, keep the uncertainty visible. A chatbot explaining a policy has not necessarily accessed your account, changed an order or authorised an exception.

A useful response may therefore explain the supported part and identify what still needs a person. See our guide to unsupported questions for examples of that next step. Teams finding the same failure repeatedly can take the record into their ongoing citation audit, rather than treating every conversation as a separate repair.

Try the check with your own website

RobiFox provides source references and conversation-review controls. Use the free website preview as a first look at your own content, then inspect an actual answer beside its source. The preview covers up to 10 website pages with email confirmation; it is not a PDF or Excel upload test. A citation is something to inspect, not a guarantee of correctness.

Cover image: AI-generated editorial illustration, not a product screenshot or a real customer case.

The examples below are fictional response designs, not measured RobiFox outputs or customer conversations. They should be adapted to your actual policies and supported product behaviour.

Choose the response before writing the wording

Ask a precise question when context is missing

Fictional visitor: “Is installation included?”

Weak response: “Yes, installation is included.”

Better response design: “Which service package and installation location do you mean? The included work depends on those details.”

Use a clarification only when the answer could change with the requested detail and the approved sources explain that difference. If no source covers installation at all, another question merely delays an honest limit. Test whether the configured assistant can follow the intended clarification flow before relying on it.

Answer the supported part without extending the promise

Fictional visitor: “Your policy says dispatch in two working days. Can you guarantee arrival by Friday?”

Better response design: “The published policy states dispatch within two working days. That is not an arrival guarantee, and I cannot confirm delivery by Friday from this information. The delivery policy explains the available service; contact the team if your deadline is essential.”

The answer should cite the policy that supports dispatch and use a real contact route. It should not replace the published condition with a more attractive promise. For a detailed webshop example, see shipping-policy answers.

Be specific about information you cannot verify

Fictional visitor: “Has my refund been approved?”

Weak response: “Your refund should be approved soon.”

Better response design: “I can explain the published refund process, but I cannot see your individual refund status here. Please use the account or support channel that can check your case.”

The named channel must exist and be appropriate. Do not ask visitors to put passwords or payment details into a general chat. A website policy is a source of general information; it does not grant access to personal records.

Handle conflicting or outdated sources honestly

If a current service page and an older document state different conditions, avoid blending the two. Explain that the available material does not establish one reliable answer and route the question to the policy owner. The business then needs to resolve the conflict in its sources.

A reference helps someone inspect the evidence, but does not remove the conflict. For the correction process behind the response, use the unsupported-claim prevention and incident guide.

Offer a next step your team can fulfil

Choose between a relevant public page, contact details, a contact form or a staffed live conversation. Do not promise “an agent is joining” when no one is available. Set ownership and service hours before offering human help; the live-agent takeover guide covers that operating commitment.

For multilingual visitors, preserve the same factual limit and market conditions in the answer. Do not imply that a human agent will speak the visitor’s language unless the team can provide that coverage.

Test the decision and the next step

For each important topic, test a covered question, a missing detail, an unsupported exception and an account-specific request. Review whether the response explains its limit, preserves the supported information and offers a working route forward. Keep these cases in your answer-quality test set.

After launch, group repeated unsupported questions. A missing policy may need a new approved answer; a retrieval failure needs a different repair; a discretionary request may properly stay with a person. The unanswered-question workflow explains how to separate them.

RobiFox provides source-based answers and human support routes, but the desired behaviour still needs checking on your own content. Review the available controls and try the questions that matter to your business.

Start with questions that affect a purchase or support outcome

Collect recurring questions from support, sales, contact forms and existing chat conversations. Remove personal information. Preserve the wording that revealed a difficulty, then group related questions without erasing conditions such as location, product variant or eligibility.

For a service business, start with package scope, service areas, booking requirements and how to obtain a quotation. A shop may prioritise delivery, returns and compatibility. Rank frequency alongside consequence: an occasional wrong price or contractual promise may deserve more attention than a frequent low-risk question.

Map each question to an approved source

Find the exact page or document section supporting the answer. Include pricing and service pages as well as formal help content. Record who can confirm the rule and whether the source is current. If two pages disagree, have that owner settle the difference before publishing a combined answer.

Check whether the question can be answered directly with the necessary conditions. “We offer flexible installation” does not establish which work is included, where it is available or what needs an individual quotation.

Work through one example

The following service business and its policies are fictional. Its owner has confirmed that the Standard package includes setup within Leeds and work elsewhere needs a separate quotation. A retired brochure says installation is included throughout the UK.

The result is not simply “write three more FAQs”. One source needs retirement, one question should remain human-only and one answer needs a clearer route to information already available.

Copy this audit record for your business

Decide what should become self-service knowledge

Stable, approved facts are useful candidates: product specifications, package inclusions and published processes. Account balances, disputed orders, unpublished discounts and individual exceptions generally need access or authority that a source document does not supply.

A missing answer is a business decision. Publish it if it is useful and the owner can approve it; otherwise make the human route clear. Do not fill an empty audit cell with a plausible policy.

Turn findings into checked changes

Agree on source ownership using the governance guide, then use the content approval workflow to carry out each repair. When the issue is the wording of an individual answer, the FAQ guide is the more specific next step.

When preparing RobiFox, start with the checked sources and use the website setup guide. After launch, compare new unanswered questions with the audit: a gap may require content, while failed retrieval of an existing answer needs a different repair.

You can begin with the free website preview, which covers up to 10 website pages with email confirmation and no payment card. An audit improves the sources you provide; it is not a guarantee that every generated answer will be correct.

Cover image: editorial diagram of the audit process, not a product screenshot.

This guide is for a small business choosing its first website assistant. Work through the same questions with each product you trial. You should finish with a defined job, a short acceptance test and a record of the evidence behind your decision.

Choose the first job before comparing features

Start with repeated questions from your inbox or sales conversations. For a service business, these might concern service areas, package inclusions and how to request a quotation. A shop might start with product care, delivery regions and returns. Choose questions whose answers are already documented and current.

Keep factual answers separate from actions and decisions. Reading a delivery policy does not provide access to a customer’s order. Explaining a cancellation process does not cancel a subscription. Ask the provider to demonstrate any account or order integration you require; do not infer it from a fluent demonstration.

Compare the workflow using your own material

The best support chatbot for your team is the one that meets your requirements on your own content. This is a selection method, not a tested ranking of competing products. Record subscription terms, usage allowances and maintenance work separately so a feature list does not hide the practical cost.

Run a small trial with an independent answer sheet

Before asking the chatbot, write down each question, its expected source, the conditions the answer must preserve and the next step when information is unavailable. Include direct questions, follow-ups, ambiguous wording and requests the assistant must not confirm.

Fictional example: a policy says dispatch takes two working days. Ask, “Will my order arrive tomorrow?” A useful answer preserves the difference between dispatch and delivery. Then ask for a particular order’s tracking status: a policy alone cannot supply it. Finally, ask about an international destination not covered by the source.

Judge meaning, evidence and the visitor’s next step separately. For the detailed scoring process, use the chatbot accuracy guide. For a source-focused demonstration, see how to evaluate cited answers.

Use this purchasing checklist

Copy the table into your evaluation notes. Fill in an actual observation and an unresolved question for each product. A tick without supporting evidence is not a completed check.

Check what happens after the trial

Ask who owns the sources, how changes are processed and whether a manual correction survives a later website read. Test a harmless change rather than relying only on a feature description. Review a missing answer too: was the fact absent, or did search fail to retrieve information already available?

Count the work around the subscription: preparing sources, reviewing high-impact changes, investigating failures and handling exceptions. A lower contact count alone cannot establish success; some visitors may simply have left. The support outcome guide explains that distinction.

Try the RobiFox workflow

RobiFox combines website and document sources, knowledge review, cited answers, conversation inspection and human support routes. Review the features and current plans, then evaluate the controls with your own questions.

The free website preview is a practical first step: submit your website address, confirm your email and receive the preview by email. It covers up to 10 website pages and requires no payment card. For the full preparation and installation process, follow the six-step setup guide.

Cover image: AI-generated editorial illustration, not a product screenshot.

For a website support chatbot, a useful evaluation covers three outcomes: answering supported questions correctly, stopping when information is missing, and directing the visitor to the right next step. This guide explains how to build that evaluation without turning it into a large research project.

Write the expected answer before running the test

Collect questions from support conversations, website searches, and sales calls. Remove personal details and keep the wording customers use. Include short questions, follow-ups, and questions with an assumption hidden inside them.

For each question, record the source that should support the answer and the essential facts it must include. Describe acceptable variation in wording. You are checking meaning, not whether the assistant repeats a paragraph word for word.

Fictional example: a service page says installation is included within one named city. For “Is installation included at my office outside the city?”, the expected response should preserve the geographic condition and explain how to confirm an exception. A plain “Yes, installation is included” fails even though part of the sentence appears in the source.

Include cases that require different behaviour

These are test designs, not results. Replace the examples with questions relevant to your own business. If you support multiple languages, include representative questions in those languages and have someone able to assess them review the answers.

Score the answer and the evidence separately

A simple review sheet can use four checks: factual correctness, completeness of important conditions, source support, and appropriate next step. Mark each as pass, partial, or fail, with a short explanation. This makes the reason for a failure visible.

A working citation is only one check. Open the linked page and find the passage that supports the answer. A source can exist yet be outdated, cover a different product, or support only half the reply. The citation-audit guide goes deeper into those cases.

Keep answerable and unanswerable questions in separate groups when reporting results. Combining them into a single percentage can hide an assistant that answers common questions well but guesses whenever the source is missing. State the number of cases tested and what those cases covered.

Use failures to choose the right fix

When an answer fails, inspect the source first. If the website itself is wrong or ambiguous, correct it. If the source is right but the extracted knowledge is incomplete, review that knowledge. If the right information exists but was not found, investigate retrieval and wording before adding another copy of the same fact.

Some failures concern the response rather than the source: an unsupported promise, an omitted exception, or a claim to have completed an action. Keep the failing question in your regression set so the same problem is checked after changes.

Retest related cases as well as the one that failed. Fixing a domestic shipping answer should not accidentally make that answer appear for every destination.

Audit live conversations after launch

Keep the prepared test set, then add a separate review of real conversations. Take a regular sample and also inspect high-impact failures, negative feedback and handovers. Record how the sample was chosen; an issue-only sample cannot estimate the overall error rate.

For each reviewed answer, retain the visitor question without personal details, the source version, the answer, its citation, the material conditions, the verdict and the action owner. Distinguish an absent fact, failed retrieval, an omitted condition and a question correctly left with a person.

This is a worked fictional audit example, not a measured customer result. Keep the failed question in the regression set and verify related cases after the repair. Use the incident guide for diagnosis and the citation guide for detailed source checks.

Treat a good test result as a bounded result

Passing your test set shows performance on those questions under those conditions. It does not prove that every future reply will be correct. Review real conversations after launch, especially where a wrong answer could create a costly commitment.

RobiFox provides tools for testing answers and inspecting their sources. Its measurement page explains what its own checks cover and where their limits are. Use that alongside your own business-specific evaluation.

Keep a record of the test date, source version, cases, failures, and corrections. When a policy changes, update the expected answers before running the tests again. For the ongoing ownership process, see knowledge base governance for small teams.

Cover image: AI-generated editorial illustration, not a product screenshot.

A real RobiFox help test: 52 questions

On 1 October 2026 we ran 40 answerable and 12 unanswerable questions against our own Hungarian help knowledge base, using openai/gpt-5.6-luna. The revised v2 set returned an answered flag for 37/40 answerable questions, a refusal flag for 11/12 negative controls, and the exact expected source for 35/40 source checks. The median recorded response time was 4.2 seconds; 38 credits were charged and no execution errors were recorded.

These are automatic status and citation checks, not a 92.5% factual-accuracy score. One response explicitly said it could not verify which user a conversation belonged to, while its answered flag was true. Reading the output therefore matters. Six ambiguous questions were revised after the initial run, so the two sets do not prove that a code change improved the assistant.

Read the dated methodology and original responses or download the 52-question result (JSON). This measures our own Hungarian documentation, not English answer quality or customer results.

The fastest improvement is often editing an existing answer rather than adding another question. Look for missing conditions, vague promises, and answers that send the reader elsewhere without explaining what to do.

Find the questions your website leaves unresolved

Review recent support requests, sales questions, and unanswered chatbot conversations. Remove names, order numbers, and other personal details before using them as editorial material. Group questions by the task behind them: choosing a product, checking delivery, understanding a service, or resolving a problem.

Do not make every variation a separate FAQ. “Can you deliver to my country?” and “Do you ship overseas?” may belong to one delivery-regions answer. “Where is my parcel?” needs a different response because it concerns an individual order.

Prioritise gaps that repeatedly block a purchase or trigger a support contact. Frequency is useful, but a less common question about an important exclusion may deserve attention before a frequently asked low-impact detail.

Replace a vague answer with a usable one

Fictional example: a shop’s FAQ says, “We ship quickly. Contact us if you need help.” That sounds friendly, but it does not answer when dispatch happens or whether a deadline can be promised.

The example is not a policy you should copy. Its useful feature is the structure: an answer, its conditions, and an appropriate next action. Replace every operational detail with your own approved information.

Give each answer enough context to stand on its own

Avoid answers such as “Yes, as described above.” People may land directly on a section, use a screen reader, or encounter the answer through a chatbot. Name the subject and include the condition that makes the answer true.

Use the terms your customers recognise. If your team says “fulfilment” but visitors ask about “sending my order,” include the familiar phrase. Explain a technical term when it is needed rather than replacing every question with internal language.

Keep separate rules separate. A long paragraph mixing delivery, returns, and warranty conditions is hard to scan and easier to misinterpret. Link to the detailed source when a full policy is necessary, while still answering the immediate question on the FAQ page.

Choose one authoritative place for each rule

An FAQ often summarises a policy that also appears elsewhere. Decide which page owns that rule and who updates the summary when it changes. If two pages disagree, adding a chatbot makes the conflict easier to encounter; it does not settle it.

For sensitive details such as fees, cancellation conditions, or delivery promises, ask the responsible business owner to check the wording. Record the reviewed date internally and use an effective date in the public text when readers need it.

The knowledge governance guide provides a lightweight way to assign ownership and handle conflicting sources.

Test the FAQ with realistic follow-up questions

Ask someone unfamiliar with the page to use it. Can they find the right section? Can they explain the answer without guessing? What do they still need to know before taking the next step?

For chatbot use, ask the question in several natural forms, then add a follow-up that changes a condition. “Can I return this?” followed by “I have already opened it” checks whether the answer preserves the policy’s scope.

If an answer fails, distinguish unclear source text from a retrieval problem. Rewriting a perfectly clear FAQ will not necessarily fix a search that does not recognise the customer’s wording. Use unanswered-question analysis to choose the right intervention.

Review what improves after the edit

Keep a short list of the questions each change is intended to address. After updating the website and the assistant’s knowledge, repeat those questions. Then review whether real visitors still ask for clarification or contact support about the same issue.

RobiFox can use approved website information and supported documents as answer sources. The setup guide explains how to review and test that knowledge. A clearer FAQ benefits both the reader who browses the page and the visitor who asks the assistant.

Cover image: AI-generated editorial illustration, not a product screenshot.