AI customer support that does not invent answers

The failure everyone has already seen

A customer asks about a refund window. The bot invents thirty days because thirty days is what most companies do. Your policy is fourteen. Now you either honour a promise you did not make or start the conversation by telling a paying customer they were misinformed by your own website.

That is not a model problem. It is a grounding problem. A support agent that answers from general knowledge will eventually answer for a company that is not yours.

• Answers come from your documented policies, not from what the model already believed
• Every answer can be traced back to the source it came from
• Questions outside the documented set go to a person instead of being improvised
• The handoff carries the full conversation, so the customer never repeats themselves

What gets automated, and what does not

Most of what arrives in a support inbox is the same small set of questions, asked over and over. Where is my order. What are your hours. How do I change my booking. Do you deliver to my area. Those are worth automating on day one because the answer is identical every time and the customer wants it in seconds, not hours.

The remaining messages are the ones that decide whether someone stays a customer. A complaint, a refund dispute, a technical fault with money attached. Those go to a person, quickly, with context attached. Automating them is how a business saves twelve minutes and loses an account.

Where the conversation actually happens

Support does not arrive through one door. It arrives on WhatsApp, on Instagram, through the website, and by email, and the customer expects the business to remember the conversation regardless of which one they used last.

In much of South Asia and the Gulf, WhatsApp is the default rather than an extra channel. People send voice notes, photographs of an order, and payment screenshots, and they expect a reply the same way they would from a person. A support system that only reads typed English text will miss most of what it is sent.

• WhatsApp, including voice notes and images rather than text alone
• Instagram and Facebook messages, which frequently arrive out of hours
• Website chat, with the same answers as every other channel
• Email, for anything that needs a written record

How it is measured

A support automation that nobody measures is a support automation that nobody can defend at renewal. Four numbers are enough to know whether it is working.

First response time, because that is what the customer actually feels. Containment rate, the share of conversations resolved without a person. Escalation accuracy, whether the things that should have reached a human did. And repeat contact rate, which catches the failure where a bot closes a conversation without solving anything.

What this costs, and what changes the number

Support automation is two purchases rather than one. There is a build with a defined end: the knowledge base assembled, the channels connected, the escalation rules written and tested. Then there is running it, which is monthly, because policies change and the answers have to change with them. A business that buys only the first half owns a system that is accurate on the day it ships and quietly less accurate every month afterwards.

Three things move the number more than anything else. How much of your policy already exists in writing, since undocumented policy has to be written before it can be automated and that is the largest hidden cost on this kind of project. How many channels have to give the same answer. And how much of the monthly figure is platform usage rather than work, because messaging channels bill for their own traffic and that line moves with volume rather than with effort. Ask which is which before you sign.

Nobody can quote this responsibly without reading a month of your actual conversations. That is where the ratio of repeated questions to genuinely new ones shows up, and that ratio is the entire business case. A figure offered before anyone has seen it is a sales number rather than a scope.

• How much of your refund, delivery and booking policy is already written down
• How many channels have to give the same answer, and whether voice notes and images are among them
• Conversation volume, since the messaging platform charges separately from the build
• Whether an existing helpdesk stays in place, or the conversation history has to move

When you should not automate support yet

If your policies are not written down anywhere, automation is premature. The system can only be as accurate as the documentation behind it, and building that documentation is the actual first project. Wobble will say so rather than sell around it.

If your support volume is under roughly twenty conversations a day, a shared inbox and a saved-replies list will do the same job for nothing. Automation earns its cost at volume, and pretending otherwise is how businesses end up paying a subscription to solve a problem they did not have.

What it costs, how quickly it runs, and where it hands over

No price is published on this site, and support is the clearest illustration of why. The same assistant costs very different amounts depending on whether your answers already exist. A business with a written returns policy, current delivery times and a price list matching the till is buying a short build. A business where four people each answer the refund question differently is buying the work of deciding which answer is correct, and that is a decision only the business can make.

What it costs also turns on how many channels the same brain has to speak through, and whether any of them carry their own messaging rules and per-conversation charges.

The handover rule is fixed. Anything angry, anything about money already paid, anything the knowledge base does not cover, and any second attempt at the same question: it hands it to a human with the conversation attached rather than trying again in different words. A customer who has repeated themselves once will not repeat themselves twice.

The audit takes the first week and is mostly spent writing down what is true, and the assistant answers a narrow band of real questions inside a fortnight. Haad, the co-founder who owns client solutions, does that first pass with your support team, because they are the people who know which questions actually arrive. Doing it in-house is sensible when volume is low and the team is small enough to stay consistent by talking to each other. Either way the knowledge base is a document set you own, in your own accounts, and it stays useful even if the assistant is switched off.

Common questions

How do you stop an AI support agent from giving wrong answers?

By grounding it. The agent answers from your own documented policies and product information rather than from general knowledge, every answer is traceable to the source it came from, and anything outside the documented set is escalated to a person instead of improvised. The failure mode to design against is confident invention, not ignorance.

Can AI handle customer support on WhatsApp?

Yes, through the WhatsApp Business API, and it needs to handle more than typed text. Customers send voice notes, photographs of products and screenshots of payments. A support system that only reads text will miss a large share of what it is sent in markets where WhatsApp is the default channel.

What percentage of support tickets can be automated?

It depends entirely on how repetitive your inbound volume is, and any provider quoting a fixed percentage before looking at your data is guessing. The honest way to find out is to read a month of real conversations and count how many are the same question. That count is the ceiling.

Will customers know they are talking to AI?

They should. Disclosure costs nothing and removes the worst outcome, which is a customer discovering it mid-complaint and feeling deceived. It also sets expectations that make the handoff to a person feel like a feature rather than a failure.

What happens when the AI cannot answer?

It hands the conversation to a person, with the full history attached so the customer does not repeat themselves. Escalation rules are defined during the build rather than left to the model's judgement, and the accuracy of those escalations is measured as a first-class metric.

Do we own the support system Wobble builds?

Yes. The workflows, the knowledge base and the conversation data live on infrastructure the client controls, and the system is documented so an internal team can take it over. Wobble builds capability rather than renting access to a process.