In this guide 6 sections
A general chatbot only talks. A support assistant is wired to your knowledge base, your order system and a list of permitted actions, so it can check a customer’s order instead of discussing orders. Fluency is not the difference. The gap is access.
Two tools with one name
People use both terms interchangeably. A general chatbot can discuss your headphones when given a product sheet, yet it has no live connection to your order database, your CRM or any customer’s serial number.
Connection is its purpose. Wired into specific systems with specific permissions, it can read an order status, open an account record or pull the exact paragraph of a returns policy. Lookups are the hard part.
Comparing knowledge access, tools and human handoff
A chatbot can answer “what is your return policy” only if the policy text is pasted into the conversation, and it cannot answer “where is my order” at all. Tools close that gap. A support assistant adds a limited set of actions, such as querying the carrier’s tracking number, plus a handoff path to a human for everything the tools cannot reach.
Take an online electronics seller. A chatbot can recite warranty terms all day, but only an assistant connected to the order system can tell one customer whether that headphone serial number is still covered.
Permissions, actions and the audit trail
Write access raises the stakes. If it can cancel an order, issue a refund or edit an address, decide what it may do without approval and make sure each one is logged.
A wrong chatbot answer is embarrassing. A support assistant with unreviewed write access to customer records, acting on a misread request, creates a different category of problem that the permission boundary exists to prevent. Keep that boundary narrow.
Setting the accuracy and escalation bar upfront
Decide the rules before launch. Define how confident the assistant must be before answering each question type alone, and what it says below that line, such as offering a colleague. The handoff must carry the full conversation history to the human agent, so the customer never repeats the order number, the fault description or the earlier apology.
Draw the line like this. Product and policy questions are answered, order-status lookups wait for identity confirmation, and any damaged-item claim or refund always goes to a person, however confident the assistant sounds.
Starting with a bounded use case
Narrow beats broad here. Pick one well-defined scenario, such as order-status lookup or policy questions, get it working reliably with a clear escalation path, and expand only after handoffs run cleanly.
Broad launches usually stumble. A narrow assistant that reliably handles one task and hands everything else over cleanly earns more customer trust than a broad one that occasionally gets something important wrong.
Support capability comparison matrix
A table setting a general chatbot against a purpose-built support assistant across five rows: knowledge source, system access, available actions, permission requirements and human-handoff behaviour. Gaps become visible at once.
Open a blank worksheet to printQuestions owners ask
Can an assistant change customer records?
Only with explicit permission. A general chatbot has no such tool, and even a connected assistant should have record changes approved by a person, especially refunds.
When should a person take over?
When confidence is low. Hand over also when the request is out of scope or involves a complaint, a refund or an upset customer, because a scripted reply frustrates more than it resolves.
What should the audit log record?
Every action the assistant takes. Each entry should show the customer, the record changed, the old and new values, the time and the conversation that triggered it, like a human agent’s edits.