The split between what a support chatbot can and can’t do is cleaner than most vendor pages admit, and it lands in a predictable place. The bot owns the transaction; a human owns the judgement. Deployments that disappoint are rarely model failures. They are boundary failures: one widget asked to be both a lookup desk and a complaints handler, and therefore confident about things it should never have been asked.
What a small team can safely hand to a chatbot
Three jobs fit comfortably inside a support chatbot’s competence, and all three share a property: the correct answer already exists in writing.
- Routine product and policy questions. The ones your inbox answers every week in almost identical words — delivery windows, warranty terms, how to reset a password, what a plan actually includes.
- Order status. A lookup, not a conversation. If the bot can read the order record and say where the parcel is, it removes an entire category of status-chasing email.
- After-hours triage. When nobody is on duty, the bot can capture what is wrong, who the customer is and what they have already tried, then set a realistic expectation for the morning. That is worth considerably more than silence.
The Customer Support Chatbot (Claude AI) on sakal.shop is scoped to exactly this: it is trained on your FAQ, product documentation and knowledge base, and it deploys as a website chat widget with optional WhatsApp integration. Training on your own documents is the part that matters. A general model knows what a refund policy usually looks like; only your documentation knows what yours says.
Where the chatbot should stop and hand over
Three categories should never be left to a language model in production, no matter how good the prompt is.
Nuanced complaints. A customer with three overlapping problems and a reason to be angry is not asking for information — they are asking to be heard and made whole. A bot that resolves this confidently makes things worse. Its job here is to recognise the temperature, apologise once, and route.
Sensitive PDPA matters. Anything touching a personal data access or correction request, a consent withdrawal, or a suspected data incident belongs to a named human who can be accountable for the response. Do not let a model improvise on obligations that carry legal weight.
Escalation judgement. You can script escalation triggers, and you should. What you cannot script is the weighing — the customer’s history, a legal threat, a partner account, a review already posted in public. Those decisions need a person with context and authority.
And sometimes the answer is not to deploy at all: if your support is bespoke advisory work, if you have no written documentation for the bot to be trained on, or if nobody is free to receive handoffs. A triage bot with no human to triage to is an answering machine with better grammar.
Designing the handoff before you switch it on
Imagine a four-person team selling to other businesses who deploy a widget in a week and then spend the next month repairing transfers. The fix is usually structural rather than technical. Treat the handoff as a product feature and specify it first.
- Write the bot’s three jobs down in the customer’s own words, and give it those and nothing else.
- Define refusal triggers explicitly: complaint, dispute, refund refusal, manager, legal, PDPA, or any message containing more than one distinct problem.
- Make the bot collect a handoff packet — name, order or account reference, what has been tried, what outcome the customer wants — so the human starts from context instead of from scratch.
- Decide channel expectations. A website widget and WhatsApp are different promises, particularly about response time after hours.
- Log every conversation and review a sample weekly. The transcripts show you which documentation gaps are generating tickets.
Measure outcomes, not containment
Containment is the easiest number to report and the least honest one. A bot that ends conversations by exhausting the customer scores well on containment and badly on everything that matters. Track these instead:
- Confirmed resolution — the customer said it was solved, not merely that the chat window closed.
- Escalation quality — how many handoffs arrive with a usable packet, and how often the human has to re-ask what the bot already asked.
- Repeat contact — the same customer, the same issue, shortly afterwards. That is the signature of a confident wrong answer.
- Honest gaps — how often it says it does not know. A bot that never admits a gap is either guessing or being asked nothing.
Review these weekly for a month before widening scope. Scaling a bot that mishandles complaints simply produces more mishandled complaints, faster.
The useful mental model stays narrow: a support chatbot is a competent first responder for questions that already have written answers, and a poor substitute for judgement. Give it your FAQ, product documentation and knowledge base, define the boundaries in writing, staff the handoff, and judge it on resolved conversations rather than closed ones. The Customer Support Chatbot (Claude AI) on sakal.shop is a concrete starting point for the scoped version.
Disclosure: Code n Rob is written by the founder of Sakal Network, which runs sakal.shop.
