A customer asks whether an item suits their needs, where an order is, and whether a return is possible. Those questions may arrive in the same WhatsApp conversation, but they require different information and authority. A useful AI customer service chatbot must know which answers it can give, which records it can read, and when a person needs to take over.
For an Indonesian SME or mid-size company, the goal should be a completed service task with a clear next step. A fast answer that invents a policy or traps a customer in a loop creates more work. Plan the service boundary before choosing a chatbot for WhatsApp or your website, and keep the customer experience central to the decision.
Separate the kinds of customer questions
Public information with an approved answer
Opening hours, service areas, product specifications, and published return procedures are possible starting points. Each needs a maintained source and a named owner. A chatbot should answer from that source and admit when it cannot find the information. An old brochure and a current website should not compete silently as equally valid instructions for the same customer question.
If most questions have a small set of fixed answers, saved replies, a menu, or a clearer website may be enough. AI becomes worth comparing when customers describe the same need in many ways or need help locating information across a larger collection. Test whether that added flexibility justifies the checking and maintenance it introduces for your team.
Questions about a customer's own records
Order status and account details require controlled access to business records. Recognizing a name in a message does not prove that someone may see the associated information. Define how identity and permission will be checked before exposing details. The chatbot should receive only the fields needed for the task, rather than a complete customer history that it might accidentally repeat.
Connect status questions to the trusted order system. If that system is unavailable, say that the status cannot currently be checked and offer a human route. Do not let the model produce a plausible delivery update from earlier conversation. The wording of a reply can be generated, while the underlying status must remain tied to an actual record.
Requests that need a decision or action
A refund, changed delivery address, special discount, or complaint resolution goes beyond answering a question. Decide which actions require staff approval and which are suitable for a separate controlled process. Early chatbot scope can stop at collecting the necessary information and opening a request. Receiving a request is different from approving it, and the customer should understand that distinction.
For sensitive actions, a model's interpretation should never be the only control. The business application needs to check permissions, permitted status changes, and any required approval before doing anything. A message saying that a supervisor approved a refund is not proof of approval. Treat customer text as a request to assess, including when it contains instructions addressed to the bot.
Compare three service models before buying
The simplest model uses a menu and fixed replies. It fits a narrow set of predictable questions and can be easier to maintain. The second model uses AI to prepare suggested answers for staff. It gives the team a chance to check source use and tone before customers receive anything. That can be a practical first use when policy questions vary.
The third model lets a chatbot answer customers within a defined scope. It needs stronger source controls, escalation, monitoring, and operational ownership. These models can coexist: public questions may receive an automatic answer, while account issues reach a person with a prepared summary. Ask vendors to demonstrate the boundaries rather than assuming every conversation should stay inside one automatic channel.
Design WhatsApp and website experiences separately
Use supported WhatsApp Business Platform connections for a system integration and check the current messaging rules before launch. The WhatsApp Business Messaging Policy requires clear escalation routes when automation is used and sets conditions for messaging. Review the rules that apply to your proposed flow rather than treating a support conversation as unrestricted permission for later promotional messages.
A website chatbot needs its own practical design. Visitors should still be able to find contact details, read service information, and submit a request without using chat. On mobile, the chat control should not cover important buttons or trap keyboard focus. If no human is available, the handoff should become a visible request with an honest explanation of what happens next.
Conversation history also behaves differently across channels. A website visitor may return without the earlier session, while a shared WhatsApp number may be used by different people. Do not assume continuity proves identity. Ask only for information needed to locate and handle the request, and avoid making the customer repeat details your authorized staff can already access.
Make human handoff part of the main flow
- Let the customer ask for a person in plain language, without completing a long menu first.
- Escalate when sources are missing, contradictory, outdated, or insufficient for the requested answer.
- Route complaints, payment disputes, sensitive information, and requests outside policy to the appropriate team.
- Stop repeated failed attempts and offer another route instead of asking the same question indefinitely.
- Show whether a person is available now or whether a request is being queued for later attention.
A handoff needs an owner, not just a notification. Send the original conversation, the relevant request, information already supplied, and any source used by the bot. Label an AI summary as a summary so staff know it may omit details. The person should be able to inspect the source conversation before making a commitment or deciding that the case is resolved.
Once staff take over, prevent the bot from continuing to answer in parallel. Agree how the conversation returns to automation, if it should return at all. A customer should not receive conflicting messages from a person and a model. Test shift changes, absent staff, and unclaimed requests, because those conditions reveal whether handoff works beyond a demonstration.
Build answers around approved information
Prepare a manageable knowledge collection with a named owner for each section. Separate public policy from internal notes. Record when a policy becomes valid and which products or branches it covers. If a temporary promotion ends, the chatbot must stop using its terms. Removing a page from the website may not automatically remove a copied version from the assistant's source collection.
Ask for answers that can be traced to the relevant source. A link is helpful only if the linked material actually supports the claim. Staff should test contradictory documents and questions whose answer is absent. An assistant that politely says it cannot confirm a detail can provide a better service than one that confidently fills the gap with a familiar-sounding rule.
Documents and incoming messages can also contain instructions intended to redirect the model. Keep them separate from the business rules that control the service. Restrict tool access and verify every permitted action outside generated text. A request to ignore prior rules or reveal another customer's record should fail even when phrased as an urgent message from a supposed manager.
Two generic scenarios to test
A product question becomes a delivery promise
Imagine a wholesaler receiving a website question about a product's dimensions. The chatbot can find the approved specification and answer with a source. The customer then asks whether a large quantity can arrive before an event. That question needs current stock, delivery capacity, and commercial approval. The bot should collect the request and hand it over, without converting published delivery guidance into a promise.
A status question becomes a disputed payment
Imagine a customer asking through WhatsApp why an order has not moved. After the agreed account checks, the system shows payment awaiting verification. The customer says payment was made and attaches evidence. The chatbot may create a case for the finance or support team, but should not mark the order paid solely from the message or image. Staff review the relevant payment record.
These are illustrative scenarios rather than client results. Their purpose is to expose the point where the required authority changes. Include similar transitions in vendor demonstrations: a public question moving to private data, a neutral request becoming a complaint, or a simple answer requiring an exception. A bot that handles opening questions well may still fail at these boundaries.
Measure completed service rather than chat activity
Track whether the original question was resolved, whether the answer was supported, and whether the customer needed to contact you again about the same issue. Review a mix of apparently successful conversations and escalations. Looking only at escalated cases can hide wrong answers that customers accepted, while counting every conversation without handoff as a success rewards silence rather than good service.
Include staff correction time, abandoned requests, handoff delay, and time spent updating sources. Compare similar question types with the existing service process. Agree what would pause automatic answers, such as exposing restricted data or repeatedly misstating a return policy. Keep a simple way to switch to fixed information and human handling while the issue is investigated.
Common mistakes that make service worse
A common mistake is hiding the human contact route to make automation numbers look better. Another is uploading every document without resolving policy conflicts. Teams also forget to assign ownership after setup, so new products and changed conditions never reach the bot. These are service management failures that a more capable model alone will not solve.
A chatbot is the wrong tool when customers mostly need negotiation, specialist advice, or help with unusual disputes and the business cannot staff the handoff. In that situation, clearer contact forms and staff support may serve customers better. AI can still be considered for drafting internal summaries, but it should not become a barrier between customers and the people able to help them.
How to begin with a reviewable service scope
- Review representative customer questions and group them by public information, private records, and decisions.
- Choose one group with maintained sources and identify the questions it must pass to staff.
- Decide between fixed replies, staff-assisted drafts, and limited automatic answers.
- Test identity checks, incorrect sources, unavailable systems, and human takeover alongside normal conversations.
- Assign source maintenance, case ownership, monitoring, and the authority to pause the bot before expanding.
Discuss AI integration around those service boundaries, including how it connects to existing records. For the surrounding routing and approval steps, review workflow automation. Talk to Loomora about a customer journey your team needs to handle more clearly.
