A few years ago we had a support chatbot. It was expensive, it was built by a specialist vendor, and on launch day it worked well. A year later, people avoided it.
Nothing had broken, technically. The bot still answered every question, quickly and politely. The problem was that more and more of the answers were wrong. Products had changed, processes had changed, the documentation had moved on. The bot hadn't.
That experience sets the bar for every chatbot we've built since. And it taught me the most important thing I know about them: a chatbot is not a technology project. It's a content maintenance problem dressed up as one.
How bots rot
Classic chatbots are built from scripted answers. Someone writes a list of questions and the matching responses, the vendor trains a model to recognise the questions, and off it goes.
From that day on, every change in your business creates a small gap. A new product version. A new return process. A price change. A feature that got renamed. Each gap is tiny. Nobody owns closing them, because the bot was a project and the project is finished.
Six months later, the bot is confidently telling customers things that were true last spring. The customers notice before you do.
What's different with LLMs, and what isn't
Modern language models change one thing fundamentally: you don't have to script answers anymore. You can point the bot at your documentation, and it answers from there. When the documentation changes, the answers change with it.
That sounds like the rot problem is solved. It's only moved.
The bot is now exactly as good as the documentation it reads. If the docs are outdated, incomplete or written in words your customers don't use, the bot will be too, just more fluently. Freshness of your knowledge base becomes the real KPI of your chatbot.
What we do differently this time
When we replaced the old vendor bot with a language-model-based assistant this year, we set a few rules.
Human first. If someone from the team is online, the customer gets a person. The bot only answers when nobody is available, for example at night or on weekends. It's a safety net, not a gatekeeper. We even deliberately launched one support channel without any AI at all, because the people using it needed a human more than an instant answer.
One bot, one job. A bot that helps people learn the product and a bot that answers pre-sales questions need different sources, different tone and different boundaries. We keep them separate and give each its own name, so customers and the team know which one they're talking to.
Decline instead of guess. Before going live, we tested the documentation bot against 200 real support questions. Most answers were partially right, a few were wrong, and one was a proper hallucination. So the bot now has a confidence gate: if the documentation doesn't clearly cover a question, it says so and hands over. I wrote more about this in Make your AI contradictable.
Reconstructed view with made-up data: the real tool looks like this, but every name and number here is invented.
Speak the customer's language. Customers describe symptoms; documentation describes features. When we added the documentation's own vocabulary to each search, the number of customer phrasings the bot could answer roughly doubled in our tests. That's not a model improvement. It's a content improvement.
Every answer can be rated. Thumbs up, thumbs down, with a reason. The ratings don't just improve the bot, they point at the articles that need work.
The failure nobody expects
One more story, because it's the kind of thing you only learn by running a bot in production.
On one of its first days, our bot suddenly made hundreds of calls to the chat system within seconds. The cause was a single configuration detail: the bot's "I can't help, let me forward you" answer was placed in a spot where the chat system treated it as a new question. The bot answered its own forwarding message, which triggered another forwarding message, and so on.
Nothing bad happened to customers, and the fix was one line. But it's a good reminder: a bot is a system that talks to other systems, and those systems have their own logic. Watch it closely in the first weeks.
Who owns the bot?
This is the question that decides whether a bot rots.
The wrong answer is "the person who built it". That person will move on to the next project, and the bot becomes an orphan.
The right answer is "the team whose knowledge it serves". In our case that's the people who write and maintain the documentation, together with support. They see the thumbs down. They see which questions the bot declined. They fix the articles, and the bot gets better without anyone touching the bot itself.
A checklist before you launch a bot
- Who keeps the knowledge current? Name a team, not a person.
- Human first or bot first? Decide deliberately, per channel.
- One job per bot. Separate bots for separate purposes.
- A confidence gate. Decline instead of guess.
- Ratings with reasons, routed to the people who own the content.
- Watch the first weeks closely. Bots talking to systems do surprising things.
A chatbot doesn't rot because the technology gets worse. It rots because nobody feels responsible for what it knows. Solve that, and the technology is the easy part.
No comments yet