A chatbot is only as good as the data behind it
Most disappointing chatbots are not badly written. They are just disconnected — answering from a script instead of from the business.
The ceiling on a scripted bot
A scripted bot knows what someone typed into it months ago. It can tell a customer your opening hours and roughly what you sell, and for about four exchanges it looks impressive.
Then someone asks the question they actually came to ask. Is the blue one in stock. Where is my order. Can I get a slot on Thursday afternoon. The bot does not know, because nothing connected it to the place where that answer lives — and the customer ends up in the queue for a human anyway, now slightly more annoyed than if they had just waited.
That is the ceiling. A bot that cannot see your data can only ever handle the questions that do not matter much.
The useful part is the integration
The bots that pay for themselves do something narrower and much more valuable: they read your real data and answer from it.
- Stock and prices — pulled live from your inventory or POS, so the answer is right today rather than right in March.
- Order status — "where is order 4821" answered without anyone opening a laptop.
- Availability and bookings — real free slots from the real calendar, and the booking written back into it.
- Customer context — recognising a returning customer from your CRM instead of asking them to explain themselves again.
None of that is a conversation problem. It is a plumbing problem: getting a chat interface talking safely to systems that were never designed to be talked to that way.
We build into what you already run
The most common fear people bring to this is that "integrating a chatbot" means replacing the software they already paid for and trained everyone on. It does not, and we would push back if someone suggested it.
The bot sits alongside your CRM, ERP, POS or database and reads from it. Your team keeps using the same screens they used last week. Nothing about the internal workflow changes — what changes is that a customer can now reach that data through a message.
What we will not do is promise a specific integration before we know the system's name. Some tools have a clean, documented API and the work is straightforward. Some have nothing, and the honest answer is that we would need an intermediate step — usually a small system of our own that both sides can read. Both are workable; they are not the same size of job, and you should hear which one you are in before signing anything.
When the data does not exist yet
Sometimes the honest finding is that there is nothing to integrate with. Stock lives in a notebook. Prices live in someone's head, and vary a bit depending on the customer. Orders are a WhatsApp thread scrolled backwards.
In that situation a chatbot is the second thing to build, not the first. The first is somewhere for the answers to live — an inventory engine, a simple ERP, an admin dashboard — and then the automation on top has something true to read.
This is why we do custom software at all. Not as a separate product line, but because an automation with nothing behind it is a demo, and we would rather build the thing that keeps working.
Two questions worth answering before you brief anyone
- What are the three questions customers ask that a script could not answer? Those define the integration.
- Where does the answer to each of them currently live — which system, which file, or whose head?
Bring those two answers to any conversation about a chatbot, with us or with anyone else, and you will get a far more honest quote.