An AI Chatbot for Business Websites That Never Makes Things Up

Most of the enquiries that come through a business website in Belize are the same twenty questions, asked over and over. What time do you open. Do you deliver to Dangriga. Do I need a deposit. Is the hotel pet friendly. An AI chatbot for a business website can answer those questions at two in the morning, in the visitor's own words, without a staff member sitting at a keyboard. The risk, and it is a real one, is that the thing invents an answer. I build these assistants so that they cannot.

I have put chat assistants on my own site, on a resort site and inside a hotel platform. In every case the rule is the same. The assistant answers from a curated facts base, which is simply a file of approved statements about your organisation, plus the text already published on your own pages. If the answer is not in there, it says so and offers to pass the question to a person.

What is an AI chatbot for a business website, in plain terms?

It is a small chat window in the corner of your site. A visitor types a question. The question is sent to a language model, which is software that predicts text, along with the relevant parts of your facts base and a set of instructions telling it how to behave. The model writes a reply using that material.

The important part is not the model. It is the material you give it and the rules you set. A general-purpose model knows a great deal about the world and nothing at all about your opening hours, your room types or your tuition policy. Left on its own it will guess, politely and confidently, and the guess will sometimes be wrong.

Why do chatbots make things up, and how do you stop it?

Language models are built to produce plausible text, not to be certain. When they have no source for an answer they fill the gap. In the trade this is called hallucination. It is not a bug you can patch away, it is the nature of the tool, so the engineering is in constraining it.

Here is how I constrain mine.

• One curated facts base. A single document of approved statements, written in short lines, that your staff can edit without touching code. Prices, policies, hours, locations, what you do and do not offer.
• Your own site text. The assistant can also draw on the pages you have already published, so it stays consistent with what a visitor can read for themselves.
• Explicit prohibitions. It is instructed never to quote a price that is not in the facts base, never to invent availability, and never to reveal private contact details such as a direct mobile number or a staff member's personal email.
• An honest fallback. When the answer is not there, it says it does not know and offers to take a message. That is a better outcome than a confident mistake.
• A logged record. Every conversation is written to an inbox the owner can read, so nothing happens in the dark.

That last point matters more than people expect. You cannot improve what you cannot see, and the first month of logs will tell you more about your customers than a year of guessing.

What happens when it cannot answer?

It hands off. The assistant collects the question and a way to reach the visitor, and the conversation lands in the inbox. I also send the owner an email when a new conversation starts, so a live visitor with a serious question is not left waiting until someone remembers to check.

A handoff is not a failure. A chat that ends with "a member of staff will reply to you today" is still a captured enquiry that would otherwise have bounced off the site. The alternative, an assistant that answers everything, is the one that will eventually quote a rate you withdrew in 2023.

Should it run on Claude or on a local model?

I can run the assistant two ways, and the right choice depends on the organisation.

Official API, such as Claude. An API is simply a way for my software to send your question to someone else's model and get an answer back. The quality of the writing is high and there is nothing for you to maintain. Your visitors' questions leave the country and go to a third party, and you pay per use, so a busy site costs more than a quiet one.

A local model on my own server. I run a self-hosted AI service called colibrì, which puts an OpenAI-compatible interface in front of models running on hardware I operate. Questions stay on infrastructure I control. Costs are predictable rather than per-message. The writing from smaller local models is plainer, which for a factual assistant is often fine and sometimes better.

A school, a public body or a lender with sensitive enquiries usually prefers the local option. A hotel chasing direct bookings often prefers the hosted one. The assistant itself is the same either way, and I can switch the back end later without rebuilding the widget.

What you get, and what it costs you in effort

A short checklist of what is delivered:

1. The chat widget on your site, styled to match it.
2. The facts base, in one place, editable by a named member of staff.
3. The conversation inbox, with email alerts on new conversations.
4. The handoff path to a real person, by email or your existing enquiry form.
5. Source code, documentation and in-app help. You own it. If you stop working with me, it keeps running.

What it costs you is attention, mostly at the start. Someone in your organisation has to write down the true answers to the twenty questions customers really ask, and someone has to read the inbox once a week for the first while. That weekly review is where the real gains are. You will find questions you never thought to answer on your website, and adding them to the facts base takes minutes.

How long does it take to build?

The widget itself is not the slow part. Wiring a chat assistant into an existing site, connecting it to a model and logging conversations is a few days of work. The facts base is what takes time, and it takes your time more than mine. Gathering accurate, agreed answers from the people who actually know them usually takes most of a week in a small organisation, longer where several departments disagree about policy.

That is normal, and it is useful work regardless. Several clients have found that writing the facts base forced a decision they had been avoiding for a year. If you want to see the other things I build and operate from my own servers in Belmopan, that is on my services page.

Where to start

1. Write down the twenty questions your staff answer most often. Not the ones you wish customers asked, the real ones.
2. Write the true answer to each, in one or two sentences, and get them agreed by whoever has authority to agree them.
3. Decide who owns the facts base. One named person who can edit it when a price or a policy changes.
4. Decide who reads the inbox each week, and put it in their calendar.
5. Decide whether your enquiries can leave the country. That settles the hosted or local question.

If you have those five things, the build is straightforward. If you would like to talk through whether this fits your organisation, you are welcome to get in touch.