AI chatbots for businessAI chatbots for business: what they can and can’t dowhat they can and can’t do

We build AI assistants for businesses, and we run one on our own website: Glint. The examples here come from it and from demos we have built. We don’t sell an off-the-shelf chatbot, so we have no reason to make it sound better than it is.

What is an AI chatbot?

An AI chatbot, or AI assistant (we use the two words for the same thing), is a chat that answers whatever a customer types, in its own words, instead of making them pick from a set of buttons. Behind it is a language model, the same kind of technology as in ChatGPT, and a set of facts about your business: prices, opening hours, the menu, your rules.

The difference from the old button bots is that people can ask however they like. “Are you open on Christmas Eve?” and “can we drop by on the 24th?” become the same question. That makes it far more useful, and also harder to keep in line. More on that below.

What it does well

Answers right away, at any hour

A lot of what a small business gets asked is the same handful of questions: when are you open, what does it cost, where are you, do I need to book, is there anything gluten free? A chatbot answers those in seconds, including at eleven on a Saturday night when nobody on staff has a hand free for the phone.

Takes requests and bookings

A good chatbot doesn’t stop at the answer. It can ask for what’s needed (how many, which day, a name and a number) and pass you a complete request, by email for example. Whether it can book straight into your booking system depends on what that system allows, and that has to be checked before anyone promises it.

Hands over to a person

When a question is too tricky, when a customer is unhappy or simply wants a human, the chatbot should say so plainly and hand over: gather what it’s about and how the customer wants to be reached, and send it to the right person. A chatbot that keeps someone in a loop of half-answers is worse than none at all.

Replies in the customer’s language

If a customer writes in Swedish, it replies in Swedish; in English, it replies in English. You don’t write every answer twice. For a business in Stockholm with tourists and customers from abroad, that’s an easy win.

What it can’t do, and where it goes wrong

This is the part worth understanding before you get one.

It only knows what you told it

A chatbot can’t know that the kitchen closes early tonight, that a dish is sold out or that you’ve changed a price, unless someone put it in. It is never better than the information behind it. So updating that information has to be easy, and someone has to own the job.

It can sound sure and still be wrong

Language models are good at phrasing things, and that is exactly the risk: a made-up answer sounds as convincing as a real one. When the answer isn’t in your information, it should say “I don’t know, I’ll ask the staff” rather than guess. That doesn’t happen by itself. It has to be built in with clear rules, then tested with real questions.

It must not make promises for you

Discounts, exceptions, guarantees, “sure, you can keep the table until midnight”: a person decides those. A chatbot needs a list of things it must never promise, and the answer to those is to pass the question on.

It doesn’t connect to your systems on its own

“It should see free tables” or “check the stock” sounds simple. It depends entirely on whether your booking system or stock system has an API (an open door that other software is allowed to use). Some do, some don’t. That’s the first thing we check, before promising anything.

It doesn’t answer the phone

The assistants we build answer in writing: on your website, in WhatsApp, in Instagram and by email. We don’t build voice bots that pick up calls. If most of your customers would rather call than write, a chatbot is not the whole answer.

It shouldn’t handle the hard conversations

A complaint, a guest who reacted to something they ate, someone angry about last night: that’s where the chatbot should hand over at once. It can take the message and make sure the right person gets it, but it shouldn’t try to solve it.

An example: a pub on a Saturday night

Here is what it can look like. The conversation below is a demo from our start page, not a real pub and not a real booking, but these are exactly the questions a pub gets before a match night.

It looks simple. To answer like that, though, the chatbot needs three things:

• The match schedule: which games the pub shows and when they start. Staff have to be able to update it themselves, every week.
• The table rules: how big a group you take, how long a table is held, what’s different on match nights.
• The menu with allergens: which dishes can be made gluten free, and how.

One more thing: in the demo the chatbot “holds” the table. For real, it can only do that if it is connected to the pub’s booking system. Without that connection the honest answer is “I’ll pass your request to the staff, and you’ll get a confirmation”. That’s a perfectly good answer, as long as it’s the true one.

How the website itself can show matches and events that staff add is in A website for a restaurant or pub.

One assistant, several channels

Customers don’t only ask on your website. They message you on Instagram, in WhatsApp and by email, and often with the same questions. If every channel has its own bot, or none, the answers drift apart and you end up changing the same thing in several places.

What we build is one assistant with one set of knowledge, answering where your customers already write:

• Your website: a chat that looks like the rest of the site, not a stock widget.
• WhatsApp and Instagram: replies to messages sent to your business account.
• Email: replies to the common questions that come in that way.

Change your opening hours once and every channel knows, and the requests can land in one place wherever the customer wrote. WhatsApp and Instagram have their own rules for how businesses may reply through them, so we go through those before anything is built.

GDPR: where does what customers write end up?

What people type into a chat is often personal data: a name, a phone number, sometimes more. Whichever chatbot you choose, you should be able to answer these questions:

• Where does the language model run, inside the EU or outside it?
• Are the conversations used to train the model?
• Where are conversations stored, and for how long?
• Who can read them?
• How do you delete a customer’s data if they ask?
• Is there a data processing agreement, a contract on how the provider may handle the data?

Here is how we do it with Glint on our own website. The model runs on Google Cloud (Vertex AI) inside the EU, and Google doesn’t use the messages to train its models. Conversations are stored in a database in Stockholm, without the visitor’s IP address. A conversation where the visitor didn’t leave their details is deleted automatically after 90 days. It is all on our privacy page.

Two more things. Ask customers in the chat not to share sensitive details, such as anything about their health. And mention the chatbot in your own privacy policy. This isn’t legal advice, but these are questions you should have answers to before the chatbot goes live.

A ready-made service or your own?

There are ready-made chatbot services where you add your questions and answers and have a chat on your site the same day. Sometimes that is exactly the right call.

A ready-made service is enough when

• you mostly get the same simple questions, and the answers rarely change
• you only need a chat on your website
• your booking system already has a booking button that does the job
• you first want to see whether customers use a chat at all

Your own is worth it when

• answers have to come from your own systems or documents: a changing menu, stock, bookings
• you want the same assistant on your website, in WhatsApp, in Instagram and in email
• you want to decide exactly when it hands over, and to whom
• you want to know exactly where conversations are kept, and own them
• it should look and sound like your business

Two examples of assistants that answer from their own information. VitaBox is a demo store we built, where the assistant has a knowledge base on every product and answers questions about them. Lucra is an AI economist that answers questions about a company’s books; there we did the redesign and frontend, the chat included, together with Frostlight Solutions. Read more about Lucra, or see all projects.

How to get started

Most of the work in a good chatbot isn’t the technology, it’s the content. This is worth having ready before you talk to anyone about building one, us or anyone else:

1. The questions you get most. Go through your email, your DMs and what staff answer on the phone. Write them down in your own words.
2. Prices, menu or range. The current version, and who keeps it up to date.
3. Opening hours and exceptions. Holidays, summer hours, a kitchen that closes early.
4. Your rules. Bookings, groups, cancellations, allergies, children or dogs.
5. What it must never answer or promise. Discounts, exceptions, health questions.
6. Who takes over. Who gets the requests, and how quickly do you reply?
7. Which channels. Website, WhatsApp, Instagram, email, or some of them.

Then test it with real questions before it goes live, ideally the ones your staff know are tricky. And read the conversations for the first few weeks. That’s where you see straight away what it gets wrong and what customers actually want to know.

What we learned from Glint

Glint is the assistant on our own website. It greets whoever gets in touch, asks a few short questions about their business, shows a project close to what they describe and writes us a short brief. Here’s what we learned along the way:

• One question at a time. Two questions in one message easily get half an answer.
• Tap instead of type. Where it can, the visitor picks from a few ready answers. It’s easier to reply, especially on a phone.
• Say what it doesn’t know. Glint never guesses a price or a timeline. It says the team answers that, and offers to pass the question on.
• Contact details in a form, not in the chat. When a visitor wants us to get back to them, Glint shows a small form instead of asking for an email address in the text. It’s clear what gets sent, and to whom.
• Read the conversations. We read every enquiry ourselves. That’s how we see what needs to get better.

To see how it feels, talk to Glint on our start page. And if you want an assistant of your own, there’s more on how we build them under AI assistants.