A customer types "where's my order" into a website chat window at half past nine on a Tuesday night. The bot asks which product category they mean. They type it again, more slowly, as if the machine is hard of hearing rather than badly built. Three exchanges later they are offered a link to the FAQ page and, underneath it, a phone number staffed nine to five. The chat log gets filed as a resolved conversation. Nothing was resolved.
Conversational AI is any system that lets someone ask a question or make a request in ordinary language and get a useful answer back, usually through text, sometimes through voice. That covers a lot of ground: a rigid menu-driven bot that only understands a fixed list of phrases, and a large language model that can read a policy document and explain it in plain English, are both "conversational AI" by that definition. They behave nothing alike, which is exactly where most of the confusion in this space comes from.
We build data and AI systems at Shipshape Data, and conversational interfaces are one of the most requested and most misunderstood pieces of work we see. Clients arrive wanting a chatbot. What they actually need, most of the time, is a system that can answer honestly from their own data and knows when to stop and get a person involved. This guide covers what conversational AI is, how the older intent-based bots differ from the LLM-based assistants that have mostly replaced them, what it takes to ground answers in a company's real data and processes, how handover to a human should work, how you evaluate whether any of it is actually working, and why the interface was never the hard part.
Why the chatbot on your site still annoys everyone
Most people's mental model of a chatbot was set years ago by tools that could only do one thing: match a typed sentence against a list of expected phrases and fire the matching response. Ask something slightly outside that list and the bot either guesses wrong or asks you to rephrase. Ask it something outside the list twice and you get the FAQ link and the phone number, which is a polite way of the bot admitting defeat.
That experience trained a generation of customers to distrust chat windows on sight, which is a genuine problem now that the underlying technology has moved on. A modern LLM-based assistant can, in principle, understand a badly typed question, hold context across several turns, and actually retrieve the right answer from company data. None of that helps if the person on the other end has already decided the bot is a wall and starts typing "AGENT" in capitals the moment the window opens.
The bar was set by the worst version of this
This matters for anyone commissioning one of these projects. A worse system spent years training customers to distrust chat windows, and a perfectly competent assistant that fumbles the first exchange will get abandoned just as fast, because nobody was expecting much from it anyway. The work here is rebuilding trust, which is a slower job than building a good bot from a blank slate.
What conversational AI actually means
Strip away the marketing and a conversational AI system has three jobs. Understand what the person is asking, however they phrase it. Work out what to do about it, which usually means finding the right information or triggering the right action. Reply in a way that answers the actual question, not the nearest template to it.
Text, voice, and the systems behind them
The channel varies. A support widget on a website, an internal Slack bot for staff, a voice assistant on a phone line, an SMS system for logistics updates: all of these are conversational AI if the interaction is driven by natural language rather than menus and buttons. The channel is the least interesting part of the design. What sits behind it, the model, the data it can see, and the rules about what it is and is not allowed to do, is where nearly all the engineering work actually goes.
Worth saying plainly: a conversational interface is not automatically the right answer to a business problem. If the underlying task is a five-field form that takes thirty seconds to fill in, wrapping it in a chat window usually makes it slower, not friendlier. Conversational AI earns its place when the question is genuinely open-ended, when the answer depends on retrieving something specific from a large body of information, or when the person asking does not know the right vocabulary to search for it themselves.
Intent-based bots vs LLM-based assistants
These are two different pieces of engineering that both happen to render as a chat window, and treating them as points on the same spectrum causes most of the disappointment we see in this space.
The old model: match and route
An intent-based bot works from a fixed set of intents, defined in advance by whoever built it. "Track my order." "Reset my password." "Talk to a person." Each phrase a customer might type gets matched, usually by a classifier trained on example sentences, to one of those intents, and each intent fires a fixed response or a fixed workflow. This is quick to build, cheap to run, and entirely predictable, which for a narrow, high-volume, low-variation task is a genuine strength rather than a limitation. A bank confirming a card is blocked, or an airline giving a flight status, does not need creativity. It needs the same correct answer every time.
The weakness shows up the moment a real customer phrases something the designer did not anticipate, which happens constantly, because people do not talk in the tidy sentences a bot's training set was built from. Anything outside the defined intents falls through to a fallback message, and the bot cannot reason its way to an answer it was never given.
The newer model: understand and generate
An LLM-based assistant does not match against a fixed list. It reads the question, works out what is actually being asked even when the phrasing is unusual or the request spans several things at once, and generates a response rather than selecting one from a menu. This is a genuine leap in flexibility. It is also, on its own, a genuine leap in risk, because a model that can generate any response can generate a wrong one just as fluently as a right one, and say it with exactly the same confident tone either way.
Most real deployments end up somewhere between the two: an LLM doing the understanding and the drafting, sitting on top of a narrower layer of defined actions and guardrails for the things that genuinely must never vary, like a refund amount or a legal disclaimer.
Grounding: the model needs your data, not its training alone
A general-purpose language model is fluent about almost everything and certain about nothing that happened inside your organisation. It has never seen your returns policy, your current stock levels, or the ticket a customer raised last week. Ask it a question that depends on any of that and it will either say it does not know, which is the honest answer, or it will produce something plausible-sounding that is not true, which is the answer nobody wants.
Retrieval, not memorisation
The fix in most production systems is retrieval: rather than expecting the model to know your business from training, you fetch the relevant documents, records or policy text at the moment of the question and hand them to the model as context, so it answers from what it has just been given rather than from what it vaguely recalls. That fetching step usually runs on embeddings, a way of representing meaning numerically so the system can pull back the passages that actually relate to the question rather than just the ones sharing a keyword. The short version for this guide is that grounding turns the model from a confident generalist into something closer to a well-briefed assistant who was handed the right file before walking into the room.
This sounds like a purely technical problem and is not. It is a data problem wearing a technical disguise. Retrieval only works if the underlying documents are current, findable and not contradicting each other, and most organisations' internal knowledge fails at least one of those three tests. A policy page updated in one place and not another. A product catalogue split across three systems that do not agree. Ask the assistant a question that touches any of that and it inherits the mess, fluently, and hands it straight to the customer. Anyone building one of these seriously ends up doing basic data quality work first, whether or not that was the project anyone signed up for.
From answering to acting
Grounding increasingly stretches beyond retrieving text. The assistant can also do something: check an order status from a live system, update a delivery address, raise a ticket. That moves the conversation from an assistant that answers into something closer to an agent that acts, and it raises the stakes, because a wrong answer is an embarrassment while a wrong action against a live system is a mess somebody has to clean up. The guardrails around what the system is allowed to touch, and what it must always confirm before doing, matter as much as what it can understand. Get that backwards and you end up with a chat window that can politely cancel the wrong order.
Knowing when to hand off to a person
Every conversational AI system eventually meets a question it should not answer. A distressed customer. A genuinely ambiguous case. A request that touches money, legal risk, or a complaint that is about to become a formal one. The systems worth deploying are the ones that recognise this and get out of the way, rather than the ones that keep trying because trying is all they know how to do.
Designing the exit, not bolting it on
Handover works best when it is designed in from the start rather than patched on afterwards as an escape hatch. That means deciding, deliberately, what triggers it: repeated failed attempts to answer, certain keywords or sentiment signals, any request above a defined value or risk threshold, or simply a direct ask from the person for a human. It also means the handover carries context with it. Nothing frustrates a customer faster than explaining the whole problem to a bot and then explaining it again from scratch to the person who picks it up next. The transcript, the account details, and whatever the bot had already worked out should travel with the handoff, not get left behind at the door.
The confidence problem
An intent-based bot fails loudly, by saying it does not understand. An LLM-based assistant can fail silently, by answering fluently and wrongly, which is the harder failure to catch and the one that does more damage.
This is the crux of why handover matters more with LLM-based systems than it ever did with the older intent bots. A rules-based bot that hits its limit tells you plainly, because it has nothing left to try. A language model rarely runs out of things to say. It will produce a fluent, well-structured answer even when the honest answer was "I don't actually know", and unless the system is explicitly built to recognise low confidence and route to a person, nobody notices until the customer does.
Evaluation: how you know it is working before customers find out it isn't
Traditional software gets tested against fixed inputs with fixed correct outputs. A conversational AI system does not have that luxury, because the input is whatever a person happens to type and the output is a stretch of generated prose, not a single value you can check against an answer key.
Building a real test set
The starting point is a set of realistic questions, drawn from actual support logs where they exist, covering the easy cases and the awkward edge cases in roughly the proportion they occur in real life. Run the system against that set and score it, ideally with a mix of automated checks and human review, because some failures (a wrong number, a broken link) are catchable by a script and some (a tone that reads as dismissive, an answer that is technically correct but unhelpful) genuinely need a person to notice. Part of that review is judging whether the assistant can actually say what it does not know, which is really a question about explainability rather than raw accuracy. The discipline that matters most here is simple: measure before launch, not after complaints start arriving.
Watching it in production
Evaluation does not stop at launch. Log conversations, sample them regularly, and watch specifically for the pattern where the assistant is answering confidently but wrongly, since that is the failure mode a satisfaction score will not reliably catch on its own. A customer who got a wrong answer delivered politely often still rates the interaction as fine, because politeness reads as competence even when the content underneath is not there.
None of this is exotic. It is the same discipline any serious software team applies to anything customer-facing. The difference is that the space of possible inputs is effectively unbounded, so the test set can never be complete, only representative, and it needs revisiting as the questions people ask keep shifting.
The interface was never the hard part
Every conversational AI project we have been near has, at some point, spent real money on the wrong problem. Teams argue over which model to use, how the widget should look, whether the avatar should have a name. All of that is visible and arguable in a meeting, and none of it is where the project actually succeeds or fails.
It fails or succeeds on whether the answers are right, whether the system knows the edges of what it knows, and whether it hands off cleanly when it hits them. That is a data and process problem dressed up as an interface problem. A beautifully designed chat window sitting on stale product data, contradictory policy documents, and no handover logic produces the same bad afternoon for a customer as the clunky intent-based bot it replaced, just with better typography.
We have seen this play out often enough that it stopped surprising us: the build takes a fraction of the time everyone expects, and the argument about what the assistant is allowed to say, and on what evidence, eats the rest of the schedule. That argument is worth having early. It is cheaper before launch than after a customer has screenshotted a confident, wrong answer and posted it somewhere public.
Where to start
Start with the questions people already ask, not the ones you imagine they might ask. Pull real transcripts or support tickets if you have them, and look honestly at how many of those questions could be answered from data you actually hold in a form clean enough to retrieve reliably. That number is usually smaller than expected, and it tells you where the real work sits before a single model gets chosen.
Decide the handover rules before you decide the model. Know what the assistant must never attempt on its own, and build that boundary in from day one rather than discovering it from an incident report. Then pick the simplest architecture that answers the questions you actually collected, test it against real cases before anyone outside the project sees it, and keep testing after launch, because the questions people ask will keep moving even after the system stops.
If you are weighing up a conversational AI project, or you already have one that is technically live but nobody quite trusts, talk to us. We would rather help you fix the data and the handover logic underneath than help you pick a nicer font for the chat window.