We begin by studying which conversations should not stay with a bot. We read chats that went wrong and ask your team which cases they always want to handle themselves. Common ones are complaints, refund and cancellation requests, high-value quotes, medical, legal or financial questions, repeated misunderstandings, upset language, requests that need judgment and customers who simply ask for a person. We turn these into triggers: explicit requests, keywords and phrases, the bot failing to understand twice in a row, a sentiment signal where the tool supports it, certain menu choices, a high order value or a customer tagged as important in the CRM. Next we decide who receives each handoff. A single shared inbox suits small teams; larger ones need queues by topic, language, city or product, with rules for who is next and how workload is balanced; see lead routing to sales representatives. We map the team’s availability and set the handoff to behave differently when nobody is online: the bot explains the situation, collects the details needed and promises a reply at a defined time. We design the context package. When the bot hands over, the agent should see the customer’s name and number, the reason for the handoff, the full conversation, answers already collected, the customer’s language, any CRM record and previous purchases, and the time waited. We present it as a short note at the top of the chat so that the agent can start with “I see you are asking about a refund for order 4521” rather than “How can I help?”. For this we connect the bot to the inbox and CRM; see API integration with websites and CRMs. We write the customer-facing messages with care: a clear statement that a person will take over, the expected wait and what the customer can do meanwhile, such as send photos or order details. We avoid vague promises and add an update if the wait grows. We define the agent’s side: how they accept a chat, how they mark it resolved, how they hand it back to the bot for later steps like feedback and what happens if nobody accepts within a time limit, for example escalation to a manager. We include rules to avoid ping-pong, so a customer is not bounced between bot and human repeatedly, and to avoid the bot talking over an agent. We test every trigger and path, including night-time, busy queues, language mismatches and a customer who writes again after the chat is closed. We train agents on the new flow and on writing the first reply; see WhatsApp business workflow training. We track measures such as handoff rate, wait time, time to resolution, customer feedback after handoff and cases where customers asked for a human unprompted; see conversation analytics. Where many handoffs concern the same question, we improve the bot or add an answer to its knowledge. We cannot guarantee instant human replies or perfect detection of upset customers, and sentiment tools make mistakes, but a well-built handoff keeps the bot useful for easy questions and gets people involved when it matters.
