AI chatbots that finish the task

Almost everyone has suffered one: the bot that circles its script, misses the second question and hides the path to a human. And when the human finally arrives, you tell the whole story again. That experience was not caused by artificial intelligence. It was caused by a way of measuring. Many bots are asked to hold on to as many conversations as possible without passing them to the human team, instead of resolving as many as possible.

We measure it the other way round. A conversation counts when the task got done or when it reached the right person with full context. So the way out to a person is never hidden, and the handover carries the whole history, so nobody repeats what they already wrote. A customer who asked for a person and got one fast comes back. One who fought a script for ten minutes does not, and does not recommend you either.

The chatbots of a few years ago were menus of buttons. They worked until the customer wrote the way people write, giving context, packing two questions into one or asking for the option the menu never had. The current generation does not follow a script. The model understands the intent and picks from a closed set of actions we define with you: book, check, change, escalate. The code executes the chosen action and validates the result before replying.

That division has a consequence you notice early. Adding a new transaction is not rewriting a whole tree, it is adding one action with its tests. And removing one is just removing it, with no leftovers of an old menu in the way.

The classic mistake of this market is the bot that knows about everything and closes nothing. We prefer the opposite, an agent that handles a few transactions and finishes them, with every category measured on its own. If eighty percent of your conversations are three procedures, the agent that does those three perfectly is worth more than the one that answers a hundred questions poorly.

In practice every transaction is a named category with its test cases and its number. “Change an appointment” is measured separately, so if its accuracy drops it shows up in its own row instead of being hidden inside a general average. Categories grow when the numbers ask for it, not when the demo suggests it.

Customer service is where a conversational agent pays for itself first. It answers the routine, qualifies the rest and escalates what needs judgment, so waiting queues turn into immediate replies. Our real-estate client saves more than three hours a day on incoming requests. The team now just books viewings.

Half the value sits in what time you reply. Inquiries do not arrive during office hours, they arrive when the customer has the phone in hand, and the longer the reply takes the less interested they are. An agent that replies within the minute turns that overnight trickle into next-morning appointments.

This is what the transaction we get asked for most looks like from inside, a booking.

An agent that only chats is not worth much. The value sits in the connections: the calendar it checks before offering a slot, the CRM where it writes, the database it pulls answers from. And connections bring their duty, because any external system can go down on a Tuesday at eleven.

When that happens, the agent neither pretends nor breaks. It says that this particular transaction is unavailable right now, carries on with the rest, and your team learns from an alarm, not from the complaints. How that is built, with a mechanism that automatically sets aside whichever piece is failing, is on the blog in detail.

The reasonable fear of any manager is a bot improvising in front of a customer. That is not avoided with promises, it is avoided by the way the thing is built. Knowledge answers come from your data and your documentation, with the source next to them. The delicate lines, a refund policy, a legal condition, a price, are not written by the model. They are texts you approved, delivered verbatim. You can edit them without touching code.

And when there is no data to answer with, the agent says so and offers the way to a person. An honest “I don’t know” keeps customers. An invented answer loses them without you ever finding out, which is the worst way to lose them.

We run our own product in production, Wazzy, a WhatsApp assistant that manages appointment bookings, changes and cancellations for clinics and service businesses. It checks real-time availability, updates calendar and records, and escalates urgencies to the team. Operating our own product keeps us sharp, and every lesson lands back in client projects.

That discipline can be counted in numbers. Wazzy watches 91 conditions that must always hold, each one with its own name, through 103 control points spread across the system. When we talk about production engineering, this is what we mean. And the full circuit gets rehearsed regularly with a real booking that is cleaned up afterwards, because a test that never touches the real world does not test the real world.

Wazzy handles health data, one of the special categories under the GDPR, the ones that get reinforced protection alongside political views, biometrics and sexual orientation. That means field-by-field encryption, retention periods agreed in writing and deletion on request of anything not held by a legal retention duty. Field-by-field encryption means each sensitive value is encrypted on its own inside the database rather than in one block with everything else. If your sector carries compliance requirements, the discipline is already built and proven where it hurts most.

Conversational systems degrade quietly. A model update or a new document can change answers with no visible error. Every change runs against a test suite before it ships and every conversation leaves a record that can be reconstructed.

Operations have their numbers too: what share ends in a task done, what share escalates and for which reasons, what each conversation costs. Those decide which category to tune and which to add. And each alarm carries its own cap on how often it can fire, because an alarm that goes off constantly drowns the rest and ends up being worse than having none.

A conversational agent does not launch to the whole world on day one. It debuts bounded, on one channel, one time window or one group of customers, with its categories measured from the first conversation. The delicate texts go out approved by you before anyone reads them, and your team knows how an escalation arrives and what to do with it.

A few weeks in, the numbers tell the truth: what gets finished inside the conversation, what escalates with which reasons and what people ask that we had not foreseen. That decides the growth, category by category. It is how the agent grows without ever putting anything in front of a customer that has not been tested first.

Saying so is also the service. If a handful of conversations reach you per day, a well-written FAQ page and a person who answers fast are cheaper and more human. If the answers you need live in no system, the real first job is organizing that knowledge, not mounting the bot. And if your customers need to talk to a person because of what the matter is, the right move is getting them there sooner, not putting a machine in between.

A conversational agent pays off when there is volume, when the information exists and when a real share of the transactions can be finished inside the conversation. If your case misses any of the three, we tell you on the first call.

The ranges we publish for any agent of ours apply here, and the factor specific to conversation is volume, because every conversation spends its model calls. In Wazzy we have the cost of each conversation measured, and we apply that same measurement in client projects. You will know what answering costs before commissioning it, not after. The full breakdown is in the cost guide.