Everything I Know About Building Chatbots That Actually Work

The hard part of building a chatbot was never the technology. I learned this in 2019, building a natural-language chatbot from scratch for a large hotel group, across dozens of locations and several languages, back when "conversational AI" was a research term and not a product category. The model that understood the questions was the easy part. What made the bot actually work, or fail, was everything around it: knowing precisely which questions to handle, what to do when it was unsure, and when to get out of the way and hand off to a human.

That order of difficulty has not changed in 2026, even though the technology has transformed completely. The single most consistent finding across every serious guide today is the same lesson I learned the hard way: most chatbot failures are planning failures, not technology failures. The model is rarely the bottleneck. The thinking around it is. So this is the full version of what I know, from having built one before it was easy, structured as the things that actually decide whether a chatbot earns its place or annoys everyone who touches it.

Start with the questions, not the technology

The mistake almost everyone makes is starting with the tool. They pick a platform, get excited about what it can do, and only then ask what the bot should actually handle. That is backwards, and it produces a bot that does a hundred things adequately and nothing well.

When I built that hotel-group bot, the first real work had nothing to do with code. It was finding out what guests actually asked. Not what we assumed they asked, what they actually typed and phoned in, day after day. The pattern that emerged is the pattern that always emerges: a relatively small number of questions accounted for the overwhelming majority of all contact. Where is my booking. What time is check-in. Do you have parking. Is breakfast included. The long tail of unusual questions was real, but it was a tail. The head was small, repetitive, and entirely knowable.

This is the foundation everything else sits on, and the current best practice says exactly the same thing: go to your real contact data, find the questions that each account for a meaningful share of your volume, and build for those first. "Build a chatbot that handles customer service" is not a plan, it is a wish. "Build a chatbot that nails the eight questions making up most of our contact volume" is a plan. The discipline is resisting the urge to cover everything, and instead covering the things that matter brilliantly. A bot that perfectly handles your top ten questions and cleanly hands off the rest is a success. A bot that vaguely attempts everything is the thing people screenshot to mock.

So before any tool: pull your real questions, rank them by how often they actually occur, and draw a hard line around the set you will handle well. That set is your scope. Everything outside it is a handoff, which I will come back to, because the handoff is where most bots quietly fail.

Intent is the real engineering, and it is mostly listening

Once you know which questions to handle, the core technical task is intent design: teaching the system to recognise what a person wants, regardless of how they phrase it. "Where's my booking," "I can't find my reservation," "did my booking go through," and "haven't got a confirmation" are four sentences and one intent. The bot's job is to map all of them to the same place.

This sounds like a modelling problem, and partly it is, but the part that actually determines success is unglamorous: you have to feed the system the real ways real people phrase things, including the messy ones. Slang. Typos. Half-sentences. The phrasings that make sense to a stressed traveller at midnight and to nobody else. When I trained it, the difference between an intent that worked and one that didn't was almost always the breadth and realism of the example phrasings behind it, not anything clever in the model. A model trained on tidy, textbook phrasings falls apart on the first real human who types the way real humans actually type.

Two practical lessons from that work that still hold. First, keep your set of intents focused rather than sprawling. A current rule of thumb is to start with something like thirty to forty intents for an initial system, and that matches my experience: a tight set you have trained deeply beats a huge set you have trained thinly. Second, separate the meaningful intents (the real business questions) from the structural ones (greetings, thanks, "are you a robot"). Both need handling, but they are different jobs, and conflating them muddies the model.

And here is the thing that has genuinely changed since 2019, and changed for the better. Back then, intent recognition was the hard ceiling, you fought constantly to get the model to understand varied phrasings, and a lot of failures were simply the bot not understanding the question. Today's large language models understand varied, messy language far more naturally, which removes a huge amount of the pain I lived through. But, and this matters, it moves the difficulty rather than removing it. The hard problems are now the ones that were always hardest anyway: what does the bot do when it is unsure, and what happens when it should not be answering at all.

The two questions that separate good bots from bad ones

If I had to compress everything into the two design questions that decide a chatbot's fate, they would be these: what does it do when it is uncertain, and how cleanly does it hand off to a human?

Uncertainty first. A bad bot, faced with a question it only half-understands, guesses confidently and gives a wrong answer in a fluent, authoritative tone. This is the chatbot version of the hallucination problem, and it is corrosive, because one confident wrong answer about a refund or a check-in time destroys more trust than ten "let me check that for you" responses ever could. A good bot does the opposite: when it is unsure, it says so, or it asks a clarifying question, or it surfaces its uncertainty rather than hiding it. Designing for the bot's uncertainty, making its confidence visible before the user acts on the answer, is one of the strongest patterns in current chatbot design, and it is something I wish I had understood more fully in 2019. The instinct is to make the bot always sound confident. The right move is to make it honest about what it does not know.

Then the handoff. Every chatbot will hit questions outside its scope. That is not failure, that is design, you scoped it deliberately. The failure is handling that moment badly: trapping the user in a loop, pretending it can help when it cannot, or dumping them to a dead end. The bots people actually like are the ones that recognise "this is beyond me" quickly and pass the person to a human smoothly, with the context already attached so the customer does not have to repeat everything. The handoff is not the bot admitting defeat. It is the bot knowing its limits, which is exactly the same principle I apply to automation: the skill is knowing what should stay human. A chatbot that escalates well is more trusted than one that tries to handle everything, in precisely the way a colleague who says "let me get the right person" is more trusted than one who bluffs.

Get these two right, graceful uncertainty and clean escalation, and you have a bot people trust even when it cannot answer. Get them wrong, and no amount of model sophistication saves you.

Multilingual is not translation

One lesson from that project deserves its own warning, because it is the one people most underestimate. The bot operated across several languages, and the naive assumption, the one I started with, is that multilingual means "build it once, then translate." It does not. People do not just speak different languages; they ask different questions, phrase them differently, and carry different assumptions about what the service even offers. A direct translation of an English intent set into another language gives you grammatically correct coverage of the wrong questions. The phrasings real speakers use, the things they worry about, the cultural defaults, all of it shifts. Building genuinely multilingual conversational systems means designing for each language's real usage, not translating one master version. This is its own deep topic and I have written about the multilingual chatbot problem separately, but the headline lesson belongs here: if you serve multiple languages, budget for multiple designs, not one design and a translator.

What it actually delivered, and why

So did it work? Yes, and it is worth being precise about how, because the how is the transferable part. The bot took over the large, repetitive head of incoming questions, the bookings, the check-in times, the parking, around the clock and across languages, which cut the handling cost of that volume dramatically and freed the human team to spend their time on the genuinely complex cases that actually needed a person. That is the real return, and it is the same shape as every automation success I have seen since: the value was not the bot answering questions, it was what the humans got to stop doing and start doing instead.

Notice what I am not claiming. I am not claiming the bot was clever, or that the technology was the achievement. The achievement was the scoping, the realistic intent design, the honest handling of uncertainty, and the clean handoff, the unglamorous discipline around the model. The model was the easy part. It was the easy part in 2019 in the sense that it was the part most people focused on, and it is even easier now that LLMs handle language so well. Which means the lesson is more true today, not less: the technology has stopped being the hard part, so the planning around it is now almost the entire game.

The 2026 picture: bots, agents, and what is genuinely new

I cannot write this in 2026 without addressing how the ground has shifted. The thing I built in 2019 was, in today's terms, a fairly classic intent-based chatbot: it recognised a question and returned a good answer. What is genuinely new is the move toward agents, systems that do not just answer but take action, and toward grounding bots in your real, current information through retrieval so they answer from your actual policies and data rather than from a fixed script or hazy training.

These are real upgrades. A modern system can understand language more flexibly, pull a grounded answer from your live knowledge base, and actually execute a task like checking a booking or starting a return, not just describe how. But every one of those capabilities sits on top of the same foundation, not instead of it. A more powerful model does not save a bot with no clear scope. Grounding does not save a bot that never hands off. Agentic action makes the uncertainty question more important, not less, because now a confident mistake can do something, not just say something. The new capabilities raise the ceiling. They do not move the floor, and the floor is still scope, intent realism, honest uncertainty, and clean escalation.

That is the whole of what I know about building chatbots that work. Start with the real questions, not the tool. Design intents around how people actually talk. Make the bot honest about what it does not know. Hand off cleanly, and treat that as a feature. Respect each language as its own design. And remember, through every wave of new capability, that the model was always the easy part. The thinking around it is the work, and it is the work that still decides whether the thing you build earns its place.

A few common questions

What makes a chatbot actually work? Not the model. The planning around it: scoping it to the handful of questions that make up most of your real contact volume, designing intents around how people genuinely phrase things, handling uncertainty honestly instead of guessing, and handing off to a human cleanly when a question is out of scope. Most chatbot failures are planning failures, not technology failures.

How do I decide what my chatbot should handle? Start with your real contact data, not assumptions. Find the questions that each account for a meaningful share of your volume, rank them, and scope the bot to handle that "head" brilliantly while cleanly handing off the long tail. A bot that nails your top questions and escalates the rest beats one that vaguely attempts everything.

What is intent design in a chatbot? Teaching the system to recognise what a user wants regardless of phrasing, so "where's my booking," "I can't find my reservation," and "no confirmation yet" all map to the same intent. The key to doing it well is training on realistic phrasings (including slang and typos), keeping the intent set focused, and separating real business questions from conversational filler.

Do modern AI chatbots still need careful design? More than ever. Today's language models handle messy language far better than older systems, which removes one old pain point. But that just moves the difficulty to the parts that were always hardest: knowing the bot's scope, handling uncertainty honestly, and escalating cleanly. New capabilities like agents and retrieval raise the ceiling but don't replace that foundation.