Your chatbot is not dumb.It was never allowed to check anything.
Contents
“Where is order 4821?” The bot answers: “Thank you for contacting us! Delivery times are 3 to 5 working days.” You write it again, with the number. Same sentence. You ask for a person. Same sentence. That chatbot is not dumb. It was never allowed to check anything. It is a decision tree with a chat window on top, and every complaint about it (repeats itself, ignores the context, never calls a human) is a design choice. This is what a customer support chatbot with an LLM, tools and a human in the loop looks like, in three scenes, and how you know it works before you trust it.
Three complaints, three decisions
- Same answer every time. It matches a keyword to a canned reply. It never reads the thread or the customer.
- Does not get the context. It cannot open the order, the booking or the invoice. A human agent is useful because they check, not because they know sentences.
- Never calls a human. It has no notion of confidence and no way to pass a case on with the context attached.
Each one can be made differently.
What a real support chatbot does
An order. “Where is order 4821?” The chatbot looks it up, sees the carrier scan stopped two days ago, and answers with that fact and the options you allow (wait, reship, refund). Nothing invented. It read the order, not a script.
A booking. “Can I move my appointment to Thursday?” It checks the calendar, proposes the free slots, and moves the booking. Whether it moves it itself or prepares the change for you to confirm is your call, per action.
A support case. “I was charged twice.” It reads the invoices, finds the duplicate, prepares the refund and hands the case to a person with everything attached. One click to approve, or take over.
- customerI was charged twice for order 4821.
- model → toolinvoice.read(order: 4821)
- tool → model2 charges · same amount · 4 min apart · same card
- model → toolrefund.draft(invoice: 2231, reason: duplicate)
- tool → modeldraft created · not sent
- model → humanhandoff(summary: duplicate charge on 4821, refund drafted, needs approval)
- humanApproves the draft. The customer gets the reply and the refund.
When it calls a human
Escalation is a tool the chatbot can call, and a policy says when: low confidence, anger or urgency, anything irreversible, a request outside its permissions, the customer asking for a person, two failed attempts. The handoff carries a summary, what was checked, what was done and what is still open, so the person starts warm. That is what human in the loop means in practice. And the chatbot never pretends to be human.
Under the hood
channels
- Telegram
- Web chat
The model
Claude · GPT · Gemini · Llama. Interchangeable.
tools, your API
- order.read
- invoice.read
- booking.move
- refund.draft
One permission per tool. Reads are free, writes are drafts.
knowledge, files you can read
- Role.md
- Rules.md
- Memory.md
- KB.md
human in the loop
- queue
Approves drafts, takes over, corrects.
audit log: every call · eval: every change
Five parts, none exotic. The channels are adapters. The LLM reads the thread and the customer and plans the calls; it can be any of the four, and a small cheap one handles the plain cases while a capable one takes the open questions. The tools are your own API behind one identity, one permission per tool, the same tools layer I built for a client’s admin. The knowledge is a handful of files: who the bot is, the rules for handing off, what it remembers of this customer, your documents. The person has a queue. Underneath, every call goes to the audit log.
Drafts first, then automatic
The first weeks run in draft mode: the chatbot prepares every reply and every action, a person sends them, the score is visible. Categories go automatic one at a time as they earn it. Trust is granted per category, not switched on. Some clients will stop at drafts and be happy; some will automate most of the order questions within a month. Both are fine.
How you know it works
Take a hundred real conversations from the past year. For each, write the expected outcome: the right answer, the tools it should call, whether a human must be involved. Run the chatbot on all of them at every change and score four things: right outcome, right tools, right handoff, no invented facts. A change that lowers the score does not ship. The set grows every week from the cases the humans corrected. That is the whole quality system, and it is what the customer support chatbots people complain about do not have.
How it starts
An audit of your last support conversations, showing where the current chatbot fails and what a person would have done. Then the pilot in draft mode on your own API and data, as an AI and Automation engagement. Then go-live, category by category. Nothing new to maintain: your API, your documents, one service identity, every call logged.
Questions people ask
Why does my chatbot give the same answer to everything?
Because it matches keywords to canned replies and cannot read the conversation or look anything up. Give it the thread, the customer and tools against your own API, and the answer changes with the case.
When should a support chatbot hand over to a human?
On low confidence, anger or urgency, anything irreversible, a request outside its permissions, when the customer asks for a person, and after two failed attempts. The handoff should carry what was checked, what was done and what is still open.
Do I need a large language model for customer support?
Not for every message. A small model can route and answer the plain cases; a capable one handles the open questions, plans the tool calls and decides the handoff. Most conversations cost cents.