.png)
Map the customer conversation before choosing chatbot software. Define what makes an enquiry qualified, ask only the minimum questions needed to route it, show what happens after each answer, and design a clear path to a person when the bot cannot help. Then review consent, message-policy requirements, data handling, errors and measurement. A conversation map is ready when a staff member can follow every branch without guessing what the system should do.
This guide covers planning, not a promised lead-conversion result. WhatsApp’s current policy says businesses may contact people only when they have the person’s number or username and opt-in permission; its Platform rules also govern approved templates, customer-service windows and automation escalation. Read the current WhatsApp Business Messaging Policy and verify the product documentation for the implementation you plan to use. For the campaign context that should exist before qualification begins, read the WhatsApp campaign planning guide. Teams that need to connect this approved conversation map to their systems can review SMSNiti’s WhatsApp API service.
1. Define “qualified” in operational terms
Before writing a question, agree on what the business needs to know to decide the next helpful step. “Good lead” is subjective. A useful definition might be: the person has asked about a service the organisation provides, is within a supported service area, has a stated need that can be routed to an available team, and has agreed to a follow-up on the chosen channel. The exact criteria belong to the organisation; do not infer them from an automation template.
Separate qualification from purchase pressure. A bot should gather enough context to help the enquiry reach the right person, not force a prospect into a score they cannot understand. Avoid collecting sensitive or unnecessary details simply because a form can. If a field does not affect routing or a clearly explained next step, leave it out of the first conversation.
2. Set the conversation’s boundaries
Write down what the bot is allowed to do and what it must not decide. It may acknowledge an enquiry, ask a small number of routing questions, share approved general information and create a handoff. It should not promise availability, eligibility, a price or a result that depends on a person checking the details. Mark any topic that requires a trained human, a secure form or a different channel.
Choose the entry points: a customer may start by messaging the business, using a click-to-chat link, scanning a code or replying to a business-initiated message. The first response should identify the business and explain what the automated conversation can help with. If the flow is initiated by the business, confirm that the required permission and current template rules are met before sending.
Keep channel permissions separate. WhatsApp’s policy requires opt-in for business communication on WhatsApp and says the business must honour opt-out requests. If the flow also sends SMS or places voice calls, have the responsible team verify the requirements for those channels independently. A conversation that begins on WhatsApp does not automatically grant permission to contact the person through every other channel.
3. Ask only questions that change the route
Start with the least burdensome question that meaningfully separates one next step from another. A lead may need to choose a broad service area, describe the type of help sought or select a preferred callback method. Ask one thing at a time, use familiar options, and let the person correct an answer. If a question is optional, say so. If a free-text answer is needed, give a short example without suggesting that a particular answer is required to receive service.
Review each proposed question with the staff who will receive the lead:
What decision will this answer change?
Can the person answer without searching for documents or disclosing unnecessary details?
What should happen if the answer is “not sure,” “other,” or “I prefer not to say”?
Does the business have a clear reason and approved process for keeping the answer?
Could the same routing decision be made after a human follow-up instead?
Fewer questions can be better when the next step is simply a human response. The purpose is to route with enough context, not to reproduce a full sales form inside a chat.
4. Draw every branch and its ending
Use a simple map with five elements: customer message, bot response, condition, next node and owner. For every answer, show where the conversation goes and how it ends. A basic flow might begin with the reason for contact, branch to an available service team, ask one relevant context question, capture a preferred contact window if appropriate, then confirm that the enquiry has been routed. This is an illustrative pattern, not a product feature or guaranteed process.
Include branches for answers the designer did not hope to receive. If the person chooses “none of these,” the flow should offer a human route rather than looping back to the same options. If the person enters an unsupported location or an unrecognised phrase, explain the limitation and show a safe next step. If the customer stops replying, define whether the conversation simply ends or whether an approved follow-up is permissible; do not assume permission from silence.
For every end state, state what the user sees, what the business records, who owns the next action, and what acknowledgement is sent. A flow that reaches a “success” node without creating a clear operational task is not complete.
5. Make human handoff a first-class branch
Specify when the system hands off: the user asks for a person, the answer does not match known choices, the request concerns a complaint, the user repeats a failed step, or the topic is outside the bot’s authority. Give the person a clear message that explains whether a team member is available and what to expect next. Avoid saying “an agent will reply shortly” unless the organisation has defined and can meet a response window.
Name the receiving queue or role, the information passed with the enquiry, the service-hours behaviour, the escalation owner and the way the team records a completed handoff. Keep the handoff summary factual and concise. The employee should see the user’s relevant answers without receiving an unnecessary dump of the entire conversation or unrelated personal information.
WhatsApp’s policy allows automation during the customer-service window but requires prompt, clear and direct escalation paths. The exact tools and handoff features depend on the chosen Platform implementation. Test that the promised human route works in the live configuration before inviting customers into it.
6. Handle time, templates and message states
Design the flow with the messaging rules in view. WhatsApp’s current policy says business-initiated conversations on the Platform may be started only with approved message templates. It permits replies without a template within a 24-hour customer-service window that opens and resets with each user message; outside that window, approved templates are required. Check the live policy and template status at implementation time. Do not hard-code a policy assumption into a diagram and forget to review it later.
Mark whether each message is an incoming user message, a reply within an open service window, or an outbound message that needs an approved template. Include what happens if a message cannot be sent, a template is paused, the integration is unavailable or the customer replies after the flow was expected to end. Keep technical errors out of customer-facing language and provide a useful alternative contact route.
7. Protect data and make the limits clear
At the design stage, list every field the bot asks for, where it comes from, which system receives it, who can view it, why it is needed and how long it is retained under the business’s approved process. Remove fields that do not support a defined task. Avoid requesting payment credentials, identity documents, health details or other sensitive information in an ordinary lead-qualification conversation unless the organisation has reviewed the need and approved a suitable secure process.
Tell the user when a person or system is collecting information and what the next step will be. Do not disguise an automated assistant as a human. Make it easy to stop, ask for a person or correct a mistaken answer. Review the applicable privacy and channel requirements with the organisation’s responsible contact; this article is operational guidance, not legal advice.
8. Test the map before building the full flow
Walk through the map using realistic but non-sensitive scenarios: a clear-fit enquiry, an out-of-scope request, an incomplete answer, a user asking for a person, an unexpected message, an opt-out and a failed integration. Ask a staff member who did not design the map to follow each branch. If they disagree about what happens next, clarify the route before configuration.
After implementation, test on authorised accounts. Check the words on a phone screen, the order of questions, button or list labels where used, template approval, record creation, assignment, human notification, retry behaviour and what the user sees after a technical error. Confirm that the bot does not repeatedly ask a question that has already been answered. Record defects and rerun only the affected scenarios after a change.
9. Measure whether the conversation works
Decide on a small measurement set before launch. A team might track how many conversations reach each end state, how many are handed to a person, which question causes users to leave, whether the receiving team can act on the summary, and how often a technical failure interrupts the route. Define each measure and its data source. A conversation completed is not proof that a lead is qualified, and a handoff is not proof that a sale occurred.
Review representative conversations in accordance with the organisation’s access and retention rules. Use findings to simplify confusing questions, add missing branches or improve handoffs. Do not tune the flow to collect more data unless the extra data improves a defined and appropriate next step.
Conversation-map review checklist
Qualification criteria are explicit and approved by the receiving team.
Every question changes a route or supports a stated next step.
Each known answer, unknown answer, opt-out and error has a safe ending.
A human handoff has a named owner, availability message and working route.
WhatsApp permission, template and customer-service-window rules are reflected in the map.
Data fields have a documented purpose, destination, access owner and retention process.
Scenarios have been walked through before the full bot is configured.
Measures describe conversation behaviour without claiming sales outcomes.
Frequently asked questions
Should I write the bot script before drawing the flow?
Usually, map the branches first. The map helps the team agree on which question belongs where, what happens after an unusual answer and where a person must take over. Then write and review the actual words.
How many questions should a lead-qualification bot ask?
There is no universal number. Ask only what changes the routing or supports a clearly explained next step. If the team can safely handle the detail after a handoff, do not force it into the first conversation.
Can the bot continue messaging after the user stops?
Do not assume that silence authorises another message. Check the current WhatsApp policy, the conversation window and any approved template and permission requirements for the exact follow-up.
What should happen when the bot does not understand?
Explain that the answer did not match, offer a small number of clear alternatives, and provide a direct human route. Avoid repeating the same prompt indefinitely.
Connect the map to an implementation plan
Once the conversation is agreed, confirm the current implementation scope with the provider. Bring the map, handoff owner, opt-in process and integration questions to that discussion; do not begin with a feature list before the customer journey is clear. For overall campaign structure, see the WhatsApp campaign planning guide; to compare app and API operating models first, read the Business App versus Platform guide.
