Plan a WhatsApp chatbot for business service

Clear finish. Useful tasks have a clear finish: giving current opening hours, collecting an enquiry, explaining an authorised order status or preparing a callback. “Answer everything” is difficult to assess. General delivery information and the status of a particular order require different data and permissions.

Initial scope. For the initial scope, write down three enquiries the bot may complete, the information each requires and the conditions for staff involvement. Fixed choices and approved answers may be enough for a structured process. A language model helps interpret different wording, but does not replace current sources or confirmed responses from business systems.

Business Platform. Meta describes the Business Platform as an API offering that supports uses including automated flows and connections to business systems. This does not establish compatibility with your CRM or calendar. The particular product connection and required action still need evidence.

Three layers. Distinguish three layers in a proposal: the WhatsApp channel, the automation and the workspace used by the service team. A supplier may package these together, but their responsibilities remain different. “WhatsApp is connected” does not establish whether staff can see the conversation or repair an unsuccessful action.

Existing setup. Begin with the existing setup. Who controls the business profile and number? Which provider is involved? Who holds administrative access? Which features are already used? Select a supported platform connection and service interface after answering these questions.

Existing number. If the existing number must remain in use, obtain confirmation of the specific migration or coexistence arrangement. Do not assume that history, device access, availability or a return path will be preserved. “Your number stays the same” does not answer these operational questions. Document and test the migration route in a suitable test setup before changing the public number.

Service window and templates. The current WhatsApp Business Messaging Policy distinguishes messages within the customer service window from approved templates outside that window. A user message opens or resets the 24-hour window. Later contact requires checking the applicable template route and conditions.

Permission. The policy also requires supplied contact details and permission for subsequent messages or calls. A CRM contact is therefore insufficient evidence for unrestricted WhatsApp contact. Record the purpose, permission, time and opt-out route; assess the legal basis for the particular communication separately.

Charges. Technical permission to send does not establish a price. Charges depend on the confirmed tariff rules, recipient market, message type and provider. For proposals spanning September and October 2026, obtain written confirmation of the applicable version. The WhatsApp chatbot cost guide explains the conflicting public information and a budgeting model.

A useful flow includes receipt, decision, action and closure. An approved callback process might follow these steps:

1. Explain that this is an automated assistant and identify its limited purpose.
2. Collect the enquiry and preferred language without requesting unnecessary personal details.
3. Check only the identity or authority required for this particular task.
4. Identify the responsible team and its realistic availability.
5. Confirm the requested callback number if it differs from the messaging contact.
6. Create the request in the destination system with a stable case reference.
7. Evaluate the destination system’s confirmed response.
8. State the actual outcome and provide the next contact route.

Confirmed outcome only. The bot must not announce a successful callback request after step five. That claim requires confirmation that the request was saved. A promise such as “today” must come from an approved capacity rule or confirmed appointment. Friendly wording cannot create an available team or time slot.

Friday. A fictional customer writes at 17:30 on Friday about a damaged delivery. The bot identifies the affected items, offers a secure route for necessary supporting material and creates a request. The team will next be available on Monday. The reply explains this limit and confirms only the saved case.

Monday. On Monday, a staff member wants to ask a follow-up question. Before sending, the system must check whether another customer message has reopened the service window. If it is closed, the workflow cannot simply retry the same free-form message. It needs a permitted template route or another agreed contact channel.

Unavailable template. If the required template is unavailable, the case remains visibly open. It must not be recorded as answered or disappear into repeated send attempts. Assign an owner to this exception: who checks template availability and contact permission, who selects the alternative route, and where is the eventual response recorded?

A number is not identity. The source of a message does not automatically authorise every disclosure. A number might be shared; the enquiry might refer to another account. Define the required check for each action. General opening hours need no login, while personal order details or contract changes may require stronger verification.

Secure process. Use an appropriate secure customer process for sensitive steps. The bot should not expose the protected information in the message that directs the customer there. The relationship between a conversation and an authorised case must be checked on the server; a name supplied in the chat does not replace that check.

Tests. Explicitly test another customer’s order reference and a message claiming “I am an administrator”. Persuasive wording must not expand access or reveal sensitive information about whether a record exists. Enforce permissions in the data-access layer, rather than relying only on instructions to a language model.

Distinct states. Operations need distinct states: an incoming message was received, a case was saved, a reply was submitted for sending and an available delivery status was recorded. None automatically proves the others. In particular, successfully generating a reply does not establish that the underlying business action succeeded.

Stable reference. Give each business request a stable reference that survives retries. Receiving an event again must not create another callback request. If an acknowledgement is lost after a successful save, the integration must look for the existing case or send it to controlled reconciliation instead of blindly creating another one.

Customer and internal view. Customer-facing wording can remain simple: “Confirmation is temporarily unavailable. We are checking your request.” Internally, staff need the known state, attempted action, timestamps and next permitted step. Separating these views prevents both unsupported promises and unnecessary technical error messages in the conversation.

Handover contents. An accessible contact route needs a workable service process behind it. Handover should include the enquiry, information already established, the unresolved question and the relevant reference. Asking customers to repeat everything increases effort and mistakes. Equally, avoid copying complete documents or sensitive details into every connected system without a need.

Pausing automation. Define when automation pauses. Once a person takes ownership, bot and staff should not send independent, contradictory replies. Returning the case to automation also needs an explicit rule: a new case, a new enquiry or deliberate release by the team.

Three states. Check “handover requested”, “received by the destination” and “accepted by staff” separately. When nobody is available, explain the real next step. A waiting message without a monitored destination does not complete the practical task. The guide to human chatbot handover develops these states further.

Language is not market. A German-speaking customer may have placed a Swiss order. Language alone must not determine delivery conditions, currency or return rules. Knowledge sources should therefore identify at least their topic, market, validity period and responsible owner.

Several languages. For multiple languages, the underlying rule must remain consistent. Check amounts, dates and deadlines separately. If no approved answer exists, a focused clarification or handover is preferable to a plausible translation of outdated information.

Source updates. Publishing a new website page does not necessarily update the bot. Document how sources are imported and old versions removed. After a change, test the answer in the actual channel, including wording variations and existing conversation context. A successful import report alone does not demonstrate a correct customer answer.

Create a short data-flow inventory for the WhatsApp chatbot covering these stages:

• the WhatsApp connection
• platform supplier
• AI processing
• knowledge sources
• service interface
• logs
• backups

For each stage, record its purpose, access rights, retention and responsible contracting party. Consider the relevant European requirements for Austria and Germany and applicable Swiss data protection law for Switzerland; a supplier’s name does not settle this assessment.

Purposes. A service conversation and later advertising are different purposes. Training, quality review and lasting storage also need explicit treatment. The chatbot privacy guide explains the distinctions and practical checks.

Owners. Assign an owner for approved answers, a technical owner for failures and a service owner for outstanding cases. One person may hold several roles, but accountability must survive holidays and supplier changes. Include a way to review access when staff leave or their responsibilities change.

Successful greetings are insufficient for acceptance. Include these cases in the acceptance test for a WhatsApp chatbot:

• a completed standard enquiry
• an unknown request
• another customer’s reference
• an expired messaging window
• an unavailable template
• a repeated incoming event
• a failure after a successful save

Decide in advance. For each case, decide in advance what the customer may be told, which records may be created and who owns an unresolved state. Also assess the experience on a phone. Long paragraphs, several questions at once and ambiguous links can make a technically correct process difficult to use.

Shutdown and supplier change. Before launch, establish shutdown and supplier-change procedures: who holds administrative access, how open cases remain available and which contact route works without automation. A WhatsApp chatbot is ready for release when normal enquiries, exceptions and ongoing operation have been assessed together.

These pages cover the service overview and the related decisions for a WhatsApp chatbot in business service:

• AI chatbots for customer service
• Calculate WhatsApp chatbot platform and operating costs
• Review chatbot data, suppliers and deletion
• Customer-service AI chatbots: plan the human handover

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.