The broken process behind the request

"We want a chatbot like ChatGPT that answers customers instead of our staff, and works twenty-four hours a day."

That is the request I hear more than any other, in close to those words.

What the client has in mind is not really a chatbot. It is a complete member of staff who never sleeps, understands any question, knows every detail of the company, sells, resolves complaints, follows up orders, and never gets anything wrong.

The idea usually arrives from somewhere specific: an impressive demo video, a competitor who has announced they are adding AI, or a good run with ChatGPT that made moving the same experience into the company look like a small technical step.

The request names an interface

None of that is unreasonable. It is just not a description of a system.

A chatbot is an interface, not a project. It is a way of talking to something, and the client names it because it is the part of the work they can picture. Everything that would make it useful sits behind it, and none of that appears in the request.

So the first thing I do is stop discussing the interface. Not argue against it — set it aside long enough to ask what broken process we are being asked to hide behind it.

The messages were not about conversation

A retailer asked me for a chatbot that would answer every customer enquiry.

Before building anything I asked to read the messages customers had actually sent. Not a summary of them, and not a description of the common cases. The messages. That is the whole method and it is not clever.

Three things came out of them, and none was a conversation problem. Product information was scattered. The returns policy was not clear. And there was no easy way for a customer to find out where their order had got to.

A chatbot placed on top of those three would have had to invent its way through all of them, and it would have done it fluently.

So what I built was an organised knowledge base, a clear search over it, a route for a customer to follow their own order, and a handover to a person for the complicated cases. The handover was in the plan from the start, not added later.

That is a less impressive thing to demonstrate than an open bot that will attempt anything. It is what the messages asked for.

Underneath, it is one of three things

One retailer is one retailer, and I would not draw a pattern from it if the shape did not keep coming back. It does. When a chatbot request is standing in for something else, what it is standing in for has usually been one of three things.

Information that cannot be reached. It exists, somebody in the company can answer the question, and the person asking has no route to either.

An internal process runs on someone moving the same things by hand from one place to another.

Support load produced by the same problem happening over and over, because nothing has been done about the cause. A system that answers the same complaint more quickly makes the complaint cheaper to live with, and the reason it keeps arriving stays where it was.

The retailer's scattered product information was the first of the three. A chatbot can be laid over any of them. It removes none of them.

The first meeting is six questions

I do not reach the real problem by being perceptive. I reach it by asking the same questions, in whatever order the conversation allows.

What task do you want the user to finish? What is the thing that repeats most every day? Where will the answer come from?

What happens if the answer is wrong? When does a person have to step in? And who will update this after it launches?

None of those questions is about the chatbot. That is the point of them.

"Answer every enquiry" is not a task. Finding out where an order has got to is a task, and a task is something the finished system can be judged against. And if nothing repeats, there is nothing worth building.

An answer has a source, or it is invented

If there is no source, the system will produce one. That is not a defect in the model. It is what you have asked it to do.

What happens when it is wrong is the other half of that question, and the answer to it decides how much freedom the system gets.

A wrong answer that is written badly gets checked. A wrong answer that is written well gets believed and acted on.

I want a name

"Who will update this after it launches" has one acceptable answer, and it is a name. Not a department, not an assurance that it will be sorted out nearer the time — a person who owns the content. If no name comes back, the answer is nobody, and I already know that whatever we ship is the most accurate that system will ever be.

It looked like the less intelligent solution

A different client wanted an intelligent sales assistant to recommend products and answer questions about price and availability. The data underneath it was not up to date.

I told them what building the assistant first would get them: a system that answers confidently with wrong information. Fixing the product catalogue and the search mattered more than putting a conversation layer on top of the mess.

Their first reaction was that the solution had become less intelligent. That is a fair thing to think. What they came round to later is the part worth keeping: the real intelligence is that the system works, not that it dazzles in the demo.

That conversation is not free to have. I am the person proposing the smaller, duller version, and for a while I am the one who has made the solution look less clever.

Work I turn down

There are two requests I do not take.

The first is a guarantee of complete accuracy out of incomplete data. Not better accuracy — a guarantee. The data does not contain what that requires.

The second is a system that makes sensitive decisions with no human review.

What either of those produces is not an AI product. It is a faster and more convincing way of producing mistakes.

It passes the demo and fails the user

Sometimes none of this lands and the client wants what they came for. That is theirs to decide.

The project usually succeeds in the demo, and demos are run on tidy questions, chosen by people who already know what the system can do. In front of a real user the questions are less orderly, the data is older, and there are more exceptions than the plan allowed for. So after launch the team narrows the scope, adds the rules and builds the handover to a person — work that could have been specified at the start, now done at speed on a live system.

The work gets done either way. Doing it first is the cheap version.

What is present when it goes right

When one of these projects goes right, the reason is not the technology.

There is one clear goal, and a source of data somebody is willing to stand behind. One named person is responsible for the content. The system has known limits on what it is allowed to do, and a defined path for when it does not know the answer.

That is a definition of success, and it is not the one in the original request. Success is not the bot answering everything. It is the bot knowing when to answer and when to stop.

So I insist on things now that I did not at the beginning. There is a discovery phase before development, run on a real sample of the actual data and conversations rather than a description of them. The cases the system is forbidden to answer get written down, which makes them a design decision instead of an incident found later. And somebody is named as responsible for updating it after launch, because a project with no maintenance plan starts degrading on its first day.

Launch is when the information starts ageing

Clients tend to treat launch as the end of the project. It is closer to the start of the part that decides whether the project was worth doing. The information underneath keeps moving, and unless somebody moves with it, the system goes on answering from where it was left.

AI does not fix the mess inside a company. It reads it, repeats it, and hands it to more people.