What a chat on your website should actually be able to answer
Most chat widgets on small business websites are a disappointment for a specific reason: they were given a page of frequently asked questions and then asked to behave as if they worked there.
A visitor asks whether the walnut table is in stock, or whether there is a slot on Thursday morning, or how much a boiler service costs for their model. The widget does not know, because it was never connected to anything that does. It offers to take a message. The visitor closes it, and now you have a worse outcome than if there had been no chat at all, because you spent the visitor's goodwill and got nothing.
The three tiers of website chat
A message box. It collects a name and a question and emails you. Honest, and no worse than a contact form, but calling it chat oversells it.
A widget with a document. It has been given your FAQ or your about page and answers from that text. It handles the general questions and falls apart on anything specific, which is most of what people ask. This is where the majority of small business chat sits.
Chat that reads the live business. It knows the actual catalogue, the actual prices including whatever is on sale today, the actual calendar. It can answer a specific question with a specific answer, because it is reading the same data the site runs on.
Only the third one changes anything, and the difference is not the quality of the language model. It is whether the thing is connected.
The questions worth being able to answer
Look at your last fifty enquiries. Nearly all of them will be one of these:
- Do you have this, and how much is it today?
- Do you have a slot on Thursday?
- Do you cover my area?
- Are you open on the bank holiday?
- Do you do this specific job?
- Where is my order?
Every one of those has a factual answer that already exists somewhere in your business. A chat that cannot reach that data will get all six wrong, no matter how well it writes.
What it should refuse to do
Equally important, and less often discussed.
It should never invent a price. It should never guess at stock. It should never state an order status it cannot see. A confident wrong answer about availability is worse than no chat, because the customer acts on it and then finds out at the counter.
The correct behaviour when it does not know is to say so and hand over to a person, carrying the conversation with it so the customer does not have to start again.
Where it should stop
Be suspicious of anything claiming a chat can run the whole business. Ours will check live stock, check real booking availability, create an appointment, place an order and hand back a checkout link, and escalate to the owner by email, text, or WhatsApp with the full conversation attached.
It does not take card details itself, it sends the customer to a proper checkout. It reads live stock for the native store only. It does not process refunds or cancellations. We would rather write that down here than have you find it out in front of a customer.
The question to ask any chat vendor
One question sorts the three tiers apart.
"If I change a price right now, what does the chat say in thirty seconds?"
If the answer involves re-uploading a document, retraining, or syncing, then the chat holds a copy of your business rather than a view of it, and copies drift. If the answer is that it simply reads the new price, the thing is actually connected.
That is the whole distinction, and it is worth more than any feature list.
The Instinctor team
