The essentials

For a simple service website, we would improve the contact form first. A limited chatbot trial suits recurring questions with maintained answers. Individual projects still need a person to clarify the details.

The website needs a specific job for its chatbot

An AI chatbot needs a job. On a small business website, that might mean explaining spare parts, answering maintenance questions or finding the right contact route. An extra window alone does not justify running it.

Our recommendation follows three website types: a simple service site gets a good contact form first. A site with recurring questions and maintained answers is a candidate for a limited chatbot trial. Individual projects start with a structured enquiry and a conversation.

The key is the question left unanswered before someone gets in touch. If you only need a location, a preferred date and a description, ask for those directly. If someone needs to choose between documented services, a dialogue may help. If they need a commitment on an unusual case, involve a person. The examples below show where we would draw that line.

A simple service site needs a short form first

A short form keeps contact straightforward. Consider a cleaning business with three services and a defined service area. Someone requesting a quote should be able to state the service, location and preferred contact method without first having a conversation with a bot.

The W3C forms tutorial recommends asking only for necessary information, labelling fields clearly and providing success or error feedback. That gives you a practical starting point: use visible labels as the default, identify required fields and connect error messages to the relevant input.

We would begin with four details: requested service, location, a short description and a phone number or email field. Mark optional information. After submission, make it clear whether the enquiry arrived and what happens next. Include a response deadline only if your team can meet it.

A bot can come later if, for example, choosing a service still needs explanation. It should then complement the form rather than guard the only route to it.

Recurring questions give the bot a limited role

Recurring questions suit a limited trial. At a spare-parts supplier, a bot could explain where customers can find a model number and which details the service team needs to identify the part. It should identify the part itself only when it has a verified basis for doing so.

Google Cloud documents how answers can draw on website content, documents and frequently asked questions. These capabilities describe Google's product; with another provider, make the knowledge base, source display and handoff explicit parts of the demonstration.

We would start with a maintained list of common questions. Give each answer an owner and a review date. Remove outdated material. When an answer is missing, the bot should direct people to a contact route and never guess availability or a delivery date.

Connecting sources does not guarantee accuracy: Google's grounding documentation describes checking whether sources support an answer and using thresholds to withhold answers. That does not automatically bring an outdated manual up to date.

Individual projects need a person to clarify the details

A project enquiry needs room for specifics. For a custom-made product or technical retrofit, we would use a form asking for the project goal, existing system and desired timeframe. A designated person then reviews feasibility.

A bot can explain terminology and suggest relevant documents beforehand. It should not invent commitments on price, timing or scope. If it merely asks the same three questions as the form, one after another, we would keep the form. A flashing chat invitation is no substitute for a quote.

Also decide where follow-up questions go and who handles them. The handoff-intent detection described by Google does not staff a service desk. Outside opening hours, customers need a clear callback route. If you only need routing by enquiry type or postcode, our comparison of AI and rule-based automation helps identify the simpler option.

60 chats can deliver less than 20 forms

Qualified enquiries decide the comparison. This worked example uses assumptions, not customer results or measurements from this website: each version receives 400 visits; the form version produces 20 enquiries, 14 of them qualified, while the bot version produces 60 chat starts and 18 enquiries, 13 of them qualified.

Define a qualified enquiry beforehand: the requested service is offered, the location is covered, the request is understandable and the person can be contacted. The form calculation is then 14 ÷ 400 × 100 = 3.5 percent. The version with the bot gives 13 ÷ 400 × 100 = 3.25 percent. Those 60 chat starts are not 60 sales opportunities.

Google Analytics distinguishes an enquiry from its later qualification. Our recommendation is to keep that distinction even in a simple tally sheet. Count all contact routes together for each version, and count each enquiry only once. Moving from chat to form must not create an extra success.

The small example does not establish a statistically reliable difference. It shows why chat starts alone are the wrong decision criterion.

Seven checks make the decision concrete

The checklist records the requirements. Copy these lines into your brief and add an answer to each. If a required task remains unresolved, keep the existing contact route accessible.

  • 1. Job: which specific customer question does the bot answer better than the existing page or form? Example: finding the right model number.
  • 2. Evidence: where is the approved answer, who maintains it and when was it reviewed? An unorganised folder of documents is not enough for us.
  • 3. Limits: which questions trigger a referral? Include missing evidence, individual commitments and an explicit request to speak to a person.
  • 4. Handoff: which inbox receives the enquiry, who reads it and what message does the customer see outside opening hours?
  • 5. Usability: can people close the window, use the keyboard and reach the form and phone number without chatting? Check on a phone too.
  • 6. Data minimisation: which details does this task actually need? Do not use internal customer documents or confidential information as improvised test inputs.
  • 7. Outcome: what qualifies as a suitable enquiry, how are duplicate contacts identified and how much rework does each enquiry create?

The trial compares two complete contact routes

The trial needs identical standards for both versions. Compare the improved page with a form against the same page with an additional bot. Where possible, assign visitors randomly and keep each visitor on the same version. Keep the services, contact options and qualification criteria unchanged; otherwise you change several things at once.

Beforehand, test an answerable standard question, an unanswerable question, a request for a special commitment and a request to speak to a person. A false promise or lost handoff stops launch. A correct referral counts as a successful handoff, not an automatically resolved enquiry.

Start with a four-week plan and record rework and maintenance time alongside qualified enquiries. With few visits, that period may reveal usability problems but still be insufficient to compare enquiry rates. In that case, the effect remains unknown. You can then assess the financial side using our business chatbot pricing comparison.

Three answers help you get started

Getting started needs a clear owner. We would settle these three questions before approaching a provider.

Does every website need an AI chatbot? No. For a straightforward service and a short enquiry, we would improve the information and form first.

Can the bot replace the form? We would offer both routes initially. People who want to write directly, or cannot use the chat, need an accessible way to get in touch.

How do we prevent outdated answers? Assign an owner to the knowledge base and link changes in services to a review of the affected answers. An additional weekly review of unresolved questions helps identify gaps.

Next step: match your website to one of the three types and fill in the seven checks. For help putting the result into practice, see our chatbot and automation services.

Sources and status

Sources last checked: 1 October 2026. Vendor statements and our own reading of them are kept apart in the text.

  1. W3C WAI: Forms Tutorial
  2. Google Cloud: Data store tools
  3. Google Cloud: Data store settings, Grounding
  4. Google Analytics: Empfohlene Ereignisse

Corrections: [email protected].

What does this mean for your business?

We go through one concrete workflow with you and check whether AI can help.

Book a free first call →