What Is a Chatbot, and When Does It Pay Off

Why this matters

• To know which share of incoming requests the bot will close on its own, and which will still land on a person
• To tell a scripted button bot apart from a language-model bot — they cost very different amounts
• To ask a vendor for the share of automatic answers rather than a list of features

What is a chatbot, in plain language

Clinics used to put a receptionist behind a window at the entrance. Half the questions were identical: how to book, where the room is, what the opening hours are. The other half were hard: rescheduling an appointment, sorting out a referral, finding a file.

A chatbot is the window for the first half. The program exchanges messages with a person: it reads the message, grasps what it is about, and responds with text or an action. The human employee stays for the second half.

This is exactly where the line between bot generations falls. A scripted bot knows only the phrases built into it: one step away from the buttons and the conversation falls apart. A bot built on a language model understands a question asked in the customer's own words, typos included.

How it works

1. A message arrives from a channel. Website, messenger, app, email — the entry point differs, the path after that is shared.
2. The topic is identified. A scripted bot looks for keywords; a model-based bot looks for meaning. This step filters out spam and detects the language.
3. The facts are retrieved. An answer about pricing comes not from the model's memory but from company documents: the mechanics of that search are described in RAG. Without this step the bot answers in generalities and invents the details.
4. The answer is assembled. The model writes text based on the documents found and the rules of tone. This is also where the stop list applies: the topics the bot does not discuss at all.
5. The handoff decision is made. If confidence is low, the question falls outside the covered area, or the customer is getting angry, the conversation moves to an operator along with the full message history.

Step five decides more than the rest. A bot without an honest handoff to a human irritates people more than no bot at all: the customer spends four exchanges just getting through to a live employee.

A case from practice

A field service company takes requests through a messenger: work schedules, request status, repeat visits, invoices. Half the questions repeat word for word, and they consume a dispatcher's entire working day.

The first step is usually the same: take the three or four most frequent request types, not the whole stream. For each one, a reference answer is written and the source document is named. After that the bot answers only those types; everything else goes straight to a person.

The measurement is set up before launch. Count how many requests of each type arrive per month, how many minutes an answer takes, and what share of questions can be handled from a template at all. The rough size of that figure is estimated with the manual process cost calculator — it shows whether the math is worth carrying further.

After launch the same quantities are compared over two or three weeks on the same volume. Three numbers: the share closed without a human, the share of answers an operator rewrote, time to first response. One of them almost always disappoints — and that is precisely the one pointing at what to fix.

What the business gets out of it

• The first response stops depending on the shift. Night, weekend, lunch break — the request gets an answer immediately. For some customers, speed of the first response matters more than its completeness.
• Repetitive questions leave the queue. The dispatcher stays on the hard requests. Savings appear only where it has been decided in advance where the freed-up hours will go: to a new stream of requests, to overdue tasks, to cutting overtime.
• The flow becomes visible. Bot logs show what people ask about most. That is a ready-made list of what needs fixing in the product, the instructions, or the website.
• Load grows without hiring. A peak day stops being a problem: the bot answers the same number of questions at any volume, and the tail is what reaches a person.

When it can be skipped

At low volume a bot is unnecessary. A handful of requests a day is handled by one person, while maintaining the bot, updating the knowledge base, and working through complaints eat more time than they save.

It is also unnecessary wherever every request is unique: project sales, complex equipment selection, legal advice. Here it pays better to connect the model to the employee's workstation — it drafts, a person sends.

A separate case is a process that has no rules yet. As long as the answers live in the heads of three experienced employees and come out differently each time, there is nothing to automate. Getting the rules out of those heads and writing them down solves half the problem with no bot involved. Process readiness is checked with a checklist.

What is worth checking

First: ask for the share of requests the bot will close in full, and on what volume that share was measured. A promise to "automate support" with no number and no period is unverifiable. A pilot on a hundred hand-picked questions and a live stream produce different figures — the second is always lower.

Second: a confident wrong answer costs more than a refusal to answer. A model is capable of inventing details that appear in no document — this is called a hallucination. Before launch, decide what the bot does not discuss at all, and build a stop list of topics where mistakes are expensive: deadlines, money, warranties, medicine.

Third: look at how the handoff to a human is built. Does the operator see the whole conversation, how many exchanges does the switch take, what happens at night. That scenario shapes the customer's impression more than the quality of the answers themselves.