AI assistant or chatbot: whichStart a projectone you actually need

Both get called the same thing in a sales deck, and the distinction only becomes obvious after launch — usually when the resolution rate settles at eleven per cent and customers learn to type "agent" straight away.

The useful line between them is not the model underneath. It is what the system is permitted to read and permitted to do.

What a chatbot is

A chatbot answers. It is given a body of text — your documentation, an FAQ, a set of scripted branches — and it matches an incoming question against that text. Everything it says is a rearrangement of what it was given.

This is genuinely useful for a narrow class of question: opening hours, delivery terms, where to find a form. It is cheap, it is quick to build, and it never touches anything that matters.

It fails the moment a customer asks something about their situation. "Where is my order" is unanswerable from documentation, and the honest chatbot has to hand over. The dishonest one improvises, which is worse.

What an assistant is

An assistant reads your actual data and takes actual actions. It can look up an order, check availability against a real calendar, issue a refund inside your billing system, update a record in the CRM.

That changes the economics. A chatbot deflects a percentage of questions; an assistant resolves them. In the deployments we have measured, that is the difference between deflecting ten per cent of conversations and closing thirty to sixty per cent of them without a person.

It also changes the risk. A system that can act can act wrongly, which is why every action gets an explicit permission: what it may do unattended, what needs a person to confirm, and a log of the reasoning behind each one.

How to tell which you need

Take a week of real conversations and sort them into three piles.

Answerable from public information. Hours, prices, policies, how something works. If this pile is most of your volume, a chatbot is the honest answer and anything more is overspending.

Answerable only from customer-specific data. Order status, account state, what was agreed last time. If this pile is large, a chatbot will not move your numbers no matter how good the writing is — the information it needs is not in the documents.

Requires judgement. Exceptions, complaints, anything where the right answer depends on context a system cannot see. This pile stays with people in either case, and the useful question is whether the system hands it over well.

The second pile is the whole decision. If it is thin, build a chatbot. If it is thick, a chatbot is a way to spend three months proving what the sorting exercise would have told you in an afternoon.

What both need and neither usually gets

Whichever you build, two things decide whether it survives contact with customers.

Retrieval you have measured separately from generation. Most disappointing deployments fail at retrieval: the right document was never in the top five results, and no amount of prompt work rescues an answer built on the wrong source. Measure whether the correct source was retrieved before you measure whether the answer was good.

An escalation path designed with the same care as the answering path. When the system gives up, the customer should land in front of a person who already has the transcript, the account context and what was already tried. Done badly, one such experience teaches someone to skip the system forever.

The number to watch

Not deflection. Not satisfaction with the bot. Track the share of conversations that ended without a person and did not come back within a week. That single number is hard to game and it tells you whether you built something that resolves or something that delays.