AI Chatbot for Website Enquiries: what it should handle, and where it must hand over to a person

An AI chatbot for website enquiries should handle the questions your site already answers: what you do, where, when, how to book, and what happens next. It must hand over to a person the moment a visitor asks for one, the question needs a decision, the visitor is upset, or it has failed twice. The handover carries the transcript.

Most guides to putting a chatbot on a website are about which tool to install. The harder question is the one the tool cannot answer for you: which conversations the bot owns, and at exactly which point a person takes over. Get that boundary wrong in one direction and the bot answers nothing useful. Get it wrong in the other and it makes promises, takes card numbers, or argues with a customer who wanted a refund. This post draws the boundary from three documents that already exist: Meta's WhatsApp Business Messaging Policy, which is the only written list of what "hand over" is allowed to mean; the Protection of Personal Information Act; and the Electronic Communications and Transactions Act, which decides what your website has to say on its own regardless of what the bot says. The question of what a bot may legally conclude on your behalf is covered in how to automate customer service; this post is about the website widget specifically, and the mechanics of the handover.

What should an AI chatbot for a website handle?

The test is simple: if the answer is already on your website, or already in a record the bot is allowed to read, the bot handles it. If the answer requires a judgement, a concession, or information you would not print on a public page, a person handles it. Applied to the questions a small business website actually gets:

The visitor asks	Who handles it	Why
"What do you do, and do you work in my area?"	The bot	The answer is your services page and your service area. One source, no judgement.
"Are you open now, and where are you?"	The bot	Hours and address are published facts. If they are not on the site, that is the first thing to fix.
"How much does it cost?"	The bot, only for published prices	If the price is on the site, the bot quotes the page. If the price depends on scope, the bot captures the scope and a person writes the quotation. A bot must never invent a number.
"Can I book, or can someone call me?"	The bot	Name, number, preferred time, what it is about. Captured once, straight into the CRM, confirmed back to the visitor.
"Where is my order, or my job?"	The bot, only if it can read the record	A bot that reads the live status is useful. A bot that guesses is worse than no bot. If it cannot read the record, it hands over.
"I want to cancel, return this, or get a refund."	A person	The bot may quote the returns policy the site publishes. It may not decide the case.
"This is the third time I am asking."	A person, immediately	A frustrated visitor who is still typing is a customer you can keep. The bot's job is to stop talking.
"Here is my ID number and card number."	Nobody, in chat	Sensitive identifiers do not belong in a chat window. The bot declines and points to the secure form or the payment page.
"Can I speak to a person?"	A person	Always, and without a fight. See the first rule below.

Where must an AI chatbot hand over to a person?

Five triggers. The first two are written into documents you are already bound by. The other three are operating rules that come from running automation for a living.

1. The visitor asks for a person

Meta's WhatsApp Business Messaging Policy, read on 17 September 2026, permits automation and then sets the condition on it in one sentence: "You may use automation when responding during the 24-hour window, but must also have available prompt, clear, and direct escalation paths." It then lists what counts as an escalation path: "In-Chat Human Agent transfer", "Phone number", "Email", "Web support (on the business website)", "In-store visits", or a "Support form". That policy binds you on WhatsApp, and it is the only published list of what a handover is allowed to look like, so it is the right standard for the website widget too. The words that matter are "prompt, clear, and direct". A menu option four levels deep is none of those.

2. The answer would be a decision about the person

POPIA section 71 provides that a data subject "may not be subject to a decision which results in legal consequences for him, her or it, or which affects him, her or it to a substantial degree, which is based solely on the basis of the automated processing of personal information". Approving credit, declining a booking on the strength of a profile, deciding a refund claim: those are decisions, and a bot may not make them alone. The full reading of section 71, and the ECTA rule on what a bot can conclude on your behalf, is in how to automate customer service. For the widget, the rule is short: the bot collects, a person decides.

3. It has failed twice

This is the operating rule we run our own automation on, and it was set by a human who got tired of waiting. When an automated process fails at the same step two or three times, it stops retrying variations and hands the person an exact instruction: what to open, what to click, what to type. The reason is arithmetic. Every retry costs the person on the other side a minute of waiting, and the thing they wanted usually takes them thirty seconds by hand. A website chatbot is the same shape. Two failed attempts to understand a question is the signal that the question is outside the bot's map, and the third attempt is the one that loses the customer. Hand over on the second miss, with the transcript.

4. Money or a grievance is on the table

Refunds, cancellations, complaints, a dispute over what was delivered. The bot can quote the policy, and if you sell online the policy has to be on the site anyway (see the ECTA section below). What the bot cannot do is negotiate, concede, or apologise in a way that binds you. A person does that, and the bot's only task is to get the person there with the whole conversation in front of them.

5. The visitor offers sensitive information

The same Meta policy says: "Don't share or ask people to share full length individual payment card numbers, financial account numbers, personal ID card numbers, or other sensitive identifiers." A chat window is not a secure form, a transcript is stored, and the transcript is read by more people than the visitor thinks. The bot declines the number, says why in one line, and gives the secure route. That is a handover to a system, not to a person, and it is the one case where the bot should refuse rather than escalate.

What does a good handover actually look like?

"Hand over to a person" is not a feature setting. It is four things that either exist or do not.

1. The path is visible before the visitor needs it. A "talk to a person" option in the widget from the first message, plus a phone number and an email address on the same screen. That is Meta's "prompt, clear, and direct" list, applied to the site.
2. The transcript travels. The person who picks up sees everything the visitor typed and everything the bot answered. The visitor never repeats themselves. If your tool cannot do this, the handover is a restart, and a restart is what the visitor was trying to avoid.
3. A time promise you can keep, with a reminder behind it. "Someone will reply within the hour" is only true if the CRM creates a task, assigns it to a named person, and nudges them when the hour is nearly up. The evidence on how fast the reply has to be is in speed to lead, with every circulating statistic traced to its source.
4. The bot says it is a bot, and the privacy policy says the widget exists. Meta's policy requires "maintaining a published privacy policy". Our own site runs a chat widget; our privacy policy states the purpose for website visitors as "To understand website usage and respond to enquiries" with the lawful basis "Legitimate interest", and names the CRM that receives those enquiries as a processor. Whatever basis you rely on, write it down, and name the widget and the tool behind it; a chat window the privacy policy does not account for is a POPIA gap, not a convenience.

What your website must still say on its own

A chatbot does not replace the disclosures the law puts on the page. If you sell goods or services through the site, ECTA section 43(1) requires the supplier to "make the following information available to consumers on the web site where such goods or services are offered", and the list includes "Its full name and legal status", "its physical address and telephone number", "the full price of the goods or services, including transport costs, taxes and any other fees or costs", "the return, exchange and refund policy of that supplier", and "the security procedures and privacy policy of that supplier in respect of payment, payment information and personal information". Section 43(3) gives the consequence: where the supplier fails to comply, "the consumer may cancel the transaction within 14 days of receiving the goods or services under the transaction".

The practical reading: the bot can point to those pages, quote them, and link them. It cannot be the only place they live. If a visitor has to ask the bot for your physical address, the page is missing, and section 43 is not satisfied by a chat log.

How the work gets reduced

A chatbot that only answers questions saves a few minutes a day. The saving comes from what happens around the conversation, and each step has a concrete mechanism.

• Captured once. The visitor's name, number, question and the page they were on are written into the CRM as a contact and a conversation the moment the bot collects them. Nobody re-types a WhatsApp message into a spreadsheet.
• One source of answers. The bot answers from the same pages the site publishes: services, area, hours, prices where published, returns policy. Update the page, and the bot's answer updates. There is no second copy of your prices living inside a bot script.
• Routed with the transcript. A handover creates a task, assigned to a named person, with the whole conversation attached. The person opens one screen and replies.
• Reminded from the promise. The time you promised the visitor is the timer on the task. If it is not answered, the CRM nudges the owner, not the customer.
• Reported by what it could not answer. The list of questions the bot handed over is the list of pages your website is missing. Read it monthly and write the pages.

The same conversation works on WhatsApp as on the site, and the cost side of running it is not our rate card but Meta's per-message fees, the platform fee and the AI layer, which are broken down in what a WhatsApp chatbot costs. What one looks like in practice, with a South African tax bot as the example, is in WhatsApp business AI in South Africa. The CRM that receives the contact, the task and the reminder is NexCRM, and where the chatbot sits in the order of things to automate is in the business process automation map.

Frequently Asked Questions

Do I have to give visitors a way to reach a person if I use a chatbot?

On WhatsApp, yes: Meta's Business Messaging Policy allows automation only if "prompt, clear, and direct escalation paths" are available. On your own website the same list is the practical standard, and POPIA section 71 means a bot may not make a decision about a person on its own.

What should a website chatbot never ask for?

Card numbers, bank account numbers, ID numbers or other sensitive identifiers. Meta's policy prohibits asking for them in chat, and a stored transcript is not a secure form. The bot declines, explains in one line, and points the visitor to the secure form or payment page.

How many attempts should a chatbot make before handing over?

Two. A question the bot has misread twice is outside its map, and the third attempt is the one that loses the visitor. Hand over on the second miss, with the full transcript, so the person picks up without asking the visitor to start again.

Does a chatbot replace the information ECTA requires on my website?

No. ECTA section 43 requires a supplier selling online to make its full name, physical address, telephone number, full price including taxes, and returns policy available on the website itself. The bot can link to those pages; it cannot be the only place they exist.

Should the chatbot tell visitors it is a bot?

Yes, in its first message, and the privacy policy should disclose that the widget exists and on what lawful basis it processes what the visitor types. Meta's policy requires a published privacy policy; POPIA requires a lawful basis for the processing either way.

The short version

An AI chatbot for website enquiries handles what the site already says: services, area, hours, published prices, bookings, and order status where it can read the record. It hands over to a person when the visitor asks, when the answer is a decision about them, on the second failed attempt, when money or a grievance is on the table, and it refuses sensitive identifiers outright. The handover is real only if the path is visible, the transcript travels, the time promise has a reminder behind it, and the privacy policy admits the widget exists. If you want to know which of your inbound questions a bot could own and which a person is still answering by hand at nine at night, that is what a Business Autopsy maps, and a discovery call is where it starts.

Sources, read directly on 17 September 2026: Meta, WhatsApp Business Messaging Policy, sections 1 to 3 (automation and escalation paths, sensitive identifiers, published privacy policy); Protection of Personal Information Act 4 of 2013, section 71, from the Government Gazette copy; Electronic Communications and Transactions Act 25 of 2002, section 43, from the Government Gazette copy published on gov.za. Every quoted phrase is the authority's own wording. The two-attempt rule is our own operating rule, stated as such. No figure in this post is a price.