What an AI chatbot for a website actually does
An AI chatbot for a website answers the questions your customers already ask by email and phone, at the hour they ask them, in the language they wrote in. That is the whole job. It reads what you have written about your own business and turns it into a reply that sounds like a sentence instead of a search result.
The useful version is narrow. It knows your services, your service areas, your opening hours, your booking process and your delivery terms, and it says so plainly. The useless version is a general chat model dropped into the corner of the page, happy to discuss the weather and to improvise the rest.
The difference between the two is not the model. It is what you feed it, and what you forbid it to do.
The questions that keep coming back
Open your inbox and read the last two weeks of enquiries. In most small Finnish companies the same five or six questions come back again and again. Do you come out to Espoo. How soon can you start. Do you invoice companies. Is there parking. Do you speak English.
Those are worth answering automatically, because the answer never changes and the person asking is close to buying. An assistant that handles only those and stays quiet about everything else already earns its keep.
The questions that do not repeat are the ones a human should see. A well set up assistant makes that split instead of pretending it can do the whole job.
What it can answer and what it cannot
It can answer anything that is written down and stable. Opening hours, service descriptions, what a quote includes, how long a repair usually takes, which payment methods you accept, how to cancel a booking, where to park, what documents to bring.
It cannot answer anything that depends on your calendar, your stock or your judgement, unless it is wired into the system holding that information. Asked whether you are free on Thursday, an assistant with no link to your booking system will either say it does not know or guess. You want the first behaviour, and you have to ask for it explicitly.
It will also get things wrong. Language models produce confident text, and a confident wrong answer about a price or a legal deadline costs more than no answer at all. Anyone who tells you their assistant never makes a mistake is selling. The honest question is what happens when it does, and the answer is a tight knowledge base, a narrow brief and a visible route to a person.
Feeding it your real information
The knowledge base is the product. Everything else is plumbing. In practice it is a set of short factual notes written by you about your own business, dated, containing nothing you would not put in writing to a customer.
A plumbing firm in Vantaa might have twenty of those notes. One per service, one on how the call-out charge is calculated, one on the areas covered, one on what counts as an emergency, one on preparing the flat before the plumber arrives. Four or five sentences each.
Write each note as an answer rather than as marketing copy, because the assistant will copy your tone. Keep one source per fact, so that when the call-out charge changes you edit one note instead of hunting through a website, a PDF and an old email. If your site runs on a light CMS, those notes can sit beside the page content and feed both, which removes the usual drift where the site says one thing and the bot says another.
Two languages, one set of facts
Write the facts once and let the assistant reply in the language the visitor used. This is the part that genuinely works well. A model that receives a Finnish question and an English knowledge base answers in Finnish, and the answer reads naturally as long as the underlying note is clear.
What does not survive the crossing is vocabulary you invented. If your quote form calls something a huoltosopimus and your English pages call it a service plan, say so in the notes, or the assistant will coin a third name.
Where the two languages change the answer, write two notes. Delivery outside Finland, invoicing foreign companies and VAT handling usually differ, and one note translated on the fly will be wrong in one language. A genuinely multilingual site works the same way, with real content per language rather than a translate button.
Handing over to a human
Build the handover before you build anything else. The assistant should offer a person the moment the visitor asks for one, the moment it does not know, and the moment the conversation turns into a complaint. Those three triggers cover nearly every situation where an automated reply does damage.
In a small company the handover is rarely a live agent waiting in a console. Collect the name, the phone number and the question, drop it into your inbox or your CRM, and tell the visitor when someone will call. A promised callback before noon tomorrow, kept, beats a spinning cursor.
Tell the visitor what they are talking to. One line saying this is an automated assistant and a person is available on request removes most of the irritation, and it decides whether a customer forgives a wrong answer.
What it costs to run
Three things drive the running cost, and none of them is the chat window. The model provider bills for every message processed, so the bill rises with traffic and with how much of your knowledge base travels along with each question. The small service between your site and the model needs somewhere to live, usually the server your site already uses. Your own time keeping the notes current is the third.
The first two are usage based, so a quiet B2B site with thirty conversations a month is in a different world from a shop with three thousand. Ask any supplier to model the cost on your real traffic figures rather than on a plan name.
The cost that hides is the knowledge base going stale. An assistant quoting last winter's opening hours is worse than none, so budget an hour a month for someone to read transcripts and fix what is wrong.
Writing the rules it has to follow
Give the assistant a written brief, stored beside the knowledge base, that says what it must never do. The list is short and nearly identical for every business.
- Never quote a price that is not in the notes, and never estimate one.
- Never give a delivery date, a legal deadline or a tax figure from memory.
- Never agree to a discount, a refund or a change of terms.
- Never continue a conversation that has turned into a complaint. Offer a person.
- Say plainly that it does not know, rather than producing something plausible.
That last line is the one people skip and the one that keeps you out of trouble. A model will fill a gap unless you tell it that leaving the gap visible is the preferred outcome.
Data protection and the chat log
Chat transcripts become personal data the moment someone types a name, a phone number or an address into them, which happens in the first week. They then carry the same obligations as the rest of your customer data, and the Finnish Data Protection Ombudsman sets those out at tietosuoja.fi, including the mechanisms that have to be in place before personal data leaves the EEA.
Three decisions belong before launch. How long transcripts are kept and what deletes them. Where the processing happens, because sending conversations to a model provider outside the EEA needs one of those recognised mechanisms rather than a shrug. And what your privacy notice says about all of it.
Tell visitors not to type personal identity codes or card numbers into the chat, because some of them will try. Our note on GDPR and cookies on a Finnish website covers how this fits with everything else on the site.
Measuring whether it is working
Four numbers tell you almost everything and take ten minutes a month to read. How many conversations happened. How many ended with the visitor getting a real answer. How many were handed to a person. How many bookings or contact forms started inside the chat.
The transcripts matter more than the counts. Read twenty at random. You will find the questions your website fails to answer, phrased in your customers' own words, which is the cheapest content research a small company can get.
Watch for conversations that stop dead after a vague reply. Those are not neutral. Each one is somebody who came looking for something specific and left without it.
When a chatbot is the wrong answer
Skip it when your enquiries are few and valuable. A consultancy that wins six clients a year gains nothing by automating a conversation it wants to have in person.
Skip it when the real problem is that your site does not say what you do or what it costs. An assistant bolted onto a vague site becomes a workaround for missing pages, and the visitor has to interrogate you to learn what should have been on the screen.
Skip it when nobody owns it. With no named person responsible for the notes and the transcripts, it drifts out of date within a quarter and starts doing quiet damage.
The first month after it goes live
Launch it narrow and widen later. Start with the five questions you already answer daily, refuse everything else politely, and put the handover in front of the visitor on the first refusal. A short assistant that is right beats a broad one that improvises.
Read every transcript for the first two weeks. It is tedious and it is where the value sits. You will add notes you never thought of, and catch the phrasings that trip it up before they become a pattern.
Then set a rhythm. Once a month, read a sample, update the notes, check nothing has expired. Twenty minutes, in the calendar, with a name against it.
What to ask before you buy one
Ask where the knowledge base lives and whether you can edit it yourself without calling anyone. If the answer involves a support ticket, the notes will go stale.
Ask what the assistant does when it does not know, then ask to see that happen in a demo with a question it cannot answer. Ask where conversations are processed and stored, and ask for that in writing. Ask how the running cost moves if traffic triples, using numbers from your own analytics rather than a generic plan.
Then ask the question that decides it. If this thing gives one wrong answer to one customer, who finds out, and how fast. A supplier with a clear answer has built one before. We describe how ours is put together on the AI chat page, and the same questions are worth putting to anyone else you talk to.