Most conversations I have about putting a chatbot on a website start with what it should be able to do. The more useful conversation, and the one that decides whether the thing is safe to leave running unattended, is about what it should not be able to do.
A chatbot on a business website is answering strangers, in public, in your name, at three in the morning when nobody is watching. That is a different proposition from an assistant you use yourself, and I treat it as a different set of rules.
Give it one job
A bot built to do one job well is far easier to get right than a bot built to be generally helpful. "Answer questions about our services and capture enquiries" is a scope. "Help customers" is not.
The narrower scope also gives it a clean answer when something falls outside its remit. A bot that knows its job can say it does not handle that and offer to pass the question on. A bot with no defined edges will attempt anything, and attempting anything is where invented answers come from.
Before anyone builds anything, write down the three or four questions the bot exists to answer. Everything outside that list should be a polite hand-off, not an attempt.
Anything that costs money or makes a commitment goes through a person
There is a firm line I draw between a bot that tells people things and a bot that does things on your behalf.
Telling people things is low risk. Confirming a booking, quoting a price, agreeing to a deadline, promising a discount or accepting a job are commitments, and a commitment made by software in your name is still one your customer will reasonably expect you to honour.
So the pattern I build to is that the bot gathers and a person confirms. It can collect everything needed for a quote and pass it to you complete. It can take availability preferences and hand them over. What it does not do is send back a number or a confirmed slot without you in the loop.
You still get the time saving, because the tedious part is the back-and-forth of collecting details, not the ten seconds it takes you to confirm. What you avoid is being held to a figure you never approved.
Assume somebody will try to talk it into something
People will try to make a public chatbot misbehave. Some are curious, some are bored, and a few are looking for something they can screenshot.
The technique has a name, prompt injection, and in its simplest form it is just typing instructions at the bot: telling it to ignore its previous rules, to pretend it is something else, or to repeat the instructions it was given. A more awkward version happens when the bot reads content from elsewhere, a document or a web page, and that content has instructions buried in it aimed at the bot rather than at any reader. I have written that up properly here: prompt injection, explained without the jargon.
There is no single setting that switches this off. What works is layered and unexciting: keep the bot's instructions separate from anything a user typed, treat everything a user sends as data rather than as orders, limit what the bot can reach in the first place, and check the output before it goes anywhere consequential. Every bot I build starts on that footing rather than having it added later.
Ask whoever builds your bot what happens when a visitor tells it to ignore its instructions. The answer tells you a lot. The right answer is not "nobody would do that."
Be careful what it can see
A bot can only leak what it has access to. That makes access the thing to be careful about, rather than something to sort out once it is live.
Give it the information it needs for its job and nothing else. Your services, your process, your hours, your published prices if you have them. Not your customer list, not your supplier terms, and not an internal folder that happens to be convenient to point it at.
The same restraint applies to what it collects. A name and a way of getting back in touch is usually enough for an enquiry. Anything more should be there because you need it, not because the form had room. Under UK GDPR the details a visitor gives your bot are personal data like any other, so they need somewhere to live, a reason to be kept, and a point at which they are deleted.
Say that it is a bot
Tell people plainly that they are talking to an assistant, and make the route to a human obvious rather than hidden behind three unsuccessful attempts.
In my experience customers are far more forgiving of a bot that is upfront about being one and hands over cleanly than of a bot that gives the impression of being a person until it does something no person would do. The hand-off is the feature that keeps the rest of it acceptable.
A visible "talk to a person" option does not undermine the bot. It is what makes the bot safe to leave running out of hours, because the worst case becomes a slightly slower reply rather than a bad answer nobody caught.
A short version
Give it one job. Let it gather, but let a person commit. Assume it will be prodded. Give it the minimum it needs to see. Say what it is, and make the way out easy to find.
None of this makes a bot less useful. It mostly stops it being useful in ways you did not ask for. This piece sits inside my wider guide to using AI safely in a small business, and if you want to talk through what a bot could reasonably take off your hands, that is what Custom Business Bots covers. The scoping conversation is where most of the value in it sits.