Insights · 5 min read
AI chatbot development usually fails on scope, not on the model. Why narrow bots win, where they pay off, and how to build one customers actually use.
By GGP Editorial
Most chatbots fail, and they fail the same way. A company bolts a generic model onto their website, points it at the FAQ page, and calls it done. Customers ask one question the bot cannot answer, the bot makes something up, and the whole project gets cancelled within a month. The problem was never the model. It was the scope.
I have shipped enough of these to say it plainly: a chatbot that does one thing well beats a chatbot that pretends to do everything. The best ones are boring. They look up an order, change an address, answer "where is my refund", and hand off to a human the moment the conversation leaves their lane.
The projects that succeed share a pattern. There is a clear, repeatable question type, a source of truth to answer from, and a human team ready to take over. Here is how that maps to different jobs:
| Use case | What the bot handles | What it should not touch |
|---|---|---|
| Order status | Tracking lookups, ETA, delivery changes | Disputes, refunds, damaged goods |
| Account help | Password resets, plan changes, billing dates | Fraud review, chargebacks |
| Booking | Availability, rescheduling, reminders | Complaints, special requests |
| Lead intake | Qualifying questions, routing, scheduling | Pricing negotiation, custom quotes |
The "what it should not touch" column matters more than the first one. The fastest way to kill trust is a bot that confidently answers a question it was never meant to answer.
A client of ours runs a refund-status bot inside a WeChat mini-program. The bot reads from the order system and tells a customer where their refund is, in plain language. That is it. It does not process the refund, and it does not argue about policy. Containment runs around 70%, which is high for a bot that narrow. The customers who still reach a human are the ones who actually need one, and that is the point.
Under the hood there are only a few pieces that matter. Retrieval over your own data, a system prompt that sets hard boundaries, and an escalation path that works. Everything else is window dressing.
Retrieval is where most builds go wrong. If you let the bot talk to a raw model without your data, it will improvise. If you feed it your data badly, it will cite the wrong thing with total confidence. The fix is to keep the knowledge base small, current, and owned by the team that answers the same questions today. If your support team keeps a sloppy Notion, do not expect the bot to be smarter than the Notion.
Escalation is the other half. A good bot hands off to a human with the full conversation attached, so the customer does not repeat themselves. That handoff is a feature, not a failure. I would rather a bot escalate after two messages than burn five minutes confusing someone.
Channels matter too, and they are not interchangeable. A bot on WhatsApp, one inside WeChat, and one on your website behave differently because the users expect different things. In Brazil, WhatsApp is often the whole support channel. In much of Asia, WeChat is. Build for the channel your customers actually use, and tune the tone for it.
A scoped bot for one use case, with retrieval over your data and a clean handoff, is usually a four to six week build. You are not training a model from scratch. You are wiring a model to your systems and setting boundaries. That is where the value is, and it is also where most of the work sits.
Start with the question your team answers most often. Pull the top 50 tickets, find the one type that repeats daily, and build only that. Ship it. Watch deflection and containment numbers for a month. Then add the next case. Nobody needs a 40-scenario bot on day one, and nobody succeeds with one. The metrics that matter are simple: what share of conversations the bot closes without a human, and whether customer satisfaction holds steady. If deflection goes up but satisfaction drops, the bot is hiding problems, not solving them.
We are a China-based team with delivery experience across Brazil, South Africa, Singapore, and the US, and we run overlapping hours with a dedicated channel in English and Portuguese. That matters for chatbot work more than people expect, because a support bot has to match how customers in each market actually ask questions. A refund query in Brazil is worded differently from one in Singapore, and the bot needs tuning against real tickets, not a template.
On our own scope: we take on almost any industry. Nothing illegal, everything else is on the table. Support bots, sales bots, booking bots, mini-program bots, WhatsApp bots. If it involves software, we will have a look.
Tell us what you are building and where you are today. We typically reply within 24 hours.