
A concrete two-week plan to ship a WhatsApp chatbot for your SaaS: approvals, template messages, LLM wiring, and the trade-offs that make or break the launch.
WhatsApp is the dominant messaging channel for most SaaS customers outside the United States and rapidly catching up inside it. For B2B products serving India, Brazil, Southeast Asia, or the Middle East, WhatsApp support is now the difference between a customer replying and a customer churning. The good news is that shipping a working WhatsApp chatbot for a SaaS product no longer takes months. Two weeks is realistic if you scope well, understand the approvals process, and pick a tool stack that handles the messy parts for you. This piece is the practical two-week plan I hand to founders in our 45-day SaaS development program when WhatsApp is part of the launch. It walks through what to build, what to skip, and where founders lose the most time. If you follow it end to end you will have a chatbot handling real customer conversations before day fifteen.
There are two products from Meta that both get called WhatsApp for business, and confusing them is the first mistake most founders make. WhatsApp Business App is the free mobile app for small businesses. It is not what you want. WhatsApp Business Platform, previously called the Cloud API, is the messaging API you need. It supports programmatic sending and receiving, template messages, media, and interactive components like buttons and lists.
Access to the Business Platform requires a Meta Business account, a verified business, and either direct integration with Meta or a Business Solution Provider. In 2026 most founders go through a BSP like Twilio, Gupshup, Interakt, or Wati because the BSPs handle template approvals, phone number setup, and quality rating monitoring for you. Direct integration saves money at scale but adds real engineering time. For a two-week launch, use a BSP.
The single most underestimated part of a WhatsApp chatbot project is the approval timeline. You cannot start sending outbound messages until you have a verified business, a phone number provisioned on the Business Platform, and at least one approved message template. Each of these can take a day or two, and they run partly in parallel and partly in sequence.
On day one, register with the BSP of your choice, submit business verification, and provision a phone number. If you can, use a number that is not already on personal WhatsApp because migration takes an extra day. On day two, submit your first message templates for approval. You will need at least a welcome template and an OTP or notification template. Keep them plain and stick to the categories Meta approves easily. Marketing templates take longer and get rejected more. On day three, complete the webhook configuration so incoming messages hit your server, and do a round-trip test with your own phone number.
By day four you have a webhook receiving messages and a way to send them. Now build the basic interaction loop. Start simple. When a user sends a message, log it, decide whether to reply, generate the reply, and send it. Do not put an LLM in the loop yet. Use scripted responses for the top three intents that make up most of your inbound volume. Pricing questions. Account help. Order status. Whatever your product's top three are.
The reason to start scripted is that you learn the WhatsApp quirks without model behavior noise on top. WhatsApp has session windows, template rules, message ordering issues, delivery status callbacks, and quirks around media handling. Discover these with a bot that always gives predictable output. Add the LLM once the plumbing is boring and reliable. Founders who invert this order spend the second week debugging whether a bug is in their code or in the model's output, which is a bad place to be with a launch deadline.
Here is a specific thing that catches everyone. WhatsApp has a 24-hour customer service window that opens when a user sends you a message. Inside that window you can send anything. Outside it, you can only send approved template messages. Founders often build a bot that works flawlessly in testing because they are always inside the window, then launch and discover that half the traffic is outside the window and their bot goes silent. Design for the window explicitly. Use templates for anything that could arrive after 24 hours.
Now add the model. The pattern I recommend is a hybrid: a lightweight intent classifier picks between scripted replies, LLM-generated replies, and human handoff. Do not send every incoming message to the model. Send the ones that need generative reasoning, which is usually a minority. This keeps cost bounded and latency low for the common intents.
For the LLM path, wrap your product docs and support KB in a RAG pipeline. Retrieve the top few relevant chunks, pass them to the model, and generate a reply constrained by system prompt to stay on topic and mention when it is uncertain. Cap the response length. WhatsApp users expect short answers, not paragraphs. Two or three sentences plus a call to action is the target. Include a way to escalate to a human at any point by typing a specific keyword or tapping a button.
The last few days are guardrails and go-live. Add rate limiting per user so a single conversation cannot burn hundreds of tokens. Add PII scrubbing on the way into the model so passwords, card numbers, and identification numbers never enter your logs. Add a fallback that hands off to a human if the model is uncertain twice in a row or if the user explicitly asks for a human.
Launch quietly at first. Route a small percentage of inbound traffic through the bot and keep the rest on your existing support workflow. Watch every conversation for the first two days. Fix the confusions you see, then ramp up the traffic percentage. A staged launch on WhatsApp is much safer than a full cutover, because WhatsApp's quality rating system will throttle your number if too many users report bad experiences early on.
Founders often forget the WhatsApp-specific costs when they budget the project. Here is the actual breakdown you should model.
The Meta conversation fee is the item founders miss. If you plan to send outbound marketing at scale, model it explicitly. A campaign to ten thousand users at three cents per conversation is three hundred dollars, and repeat sends can quickly stack. Founders working on growth and marketing campaigns need to build the WhatsApp cost into the CAC calculation from day one.
WhatsApp assigns your phone number a quality rating based on how users react to your messages. Getting reported, blocked, or ignored drops your rating. A low quality rating throttles how many messages you can send per day and can eventually get your number banned. Protecting the rating is a first-class concern, not an afterthought.
Two practices matter most. Do not send unsolicited outbound messages to users who have not opted in. And keep your response quality high on the inbound side, because a bot that gives bad answers gets reported by frustrated users. Both of these are more important than any feature you might build. A launched bot with a healthy quality rating outperforms a fancier bot with a throttled number by orders of magnitude in the long run.
No bot handles everything. The handoff to a human agent is where most WhatsApp bots quietly fail. The user asks for a human, the bot promises to connect them, and either nothing happens or the human agent starts from zero with no context. Both experiences push users to competitor channels.
Build the handoff as a first-class flow. When a user asks for a human, notify your support team in Slack or your ticketing tool with the full conversation history, the user's account details, and any relevant metadata. Route the human's reply back through the same WhatsApp channel so the user does not have to switch. Keep the bot silent during the human conversation and reactivate it only when the human explicitly closes the ticket. This pattern lets one human handle five to ten times the WhatsApp volume they could handle in a raw chat interface.
Founders often want to ship a fully polished bot with multi-language support, voice notes, deep product integrations, and a beautiful conversation designer for their team. Skip all of it for the first launch. Multi-language can wait until you know which languages your users actually use. Voice notes are complex and useful for a minority of use cases, defer them to month two. Deep integrations are worth building once you know which product actions users request most often over WhatsApp.
The two-week goal is to have a bot that responds accurately to inbound English messages for your top three intents, escalates cleanly to a human, and does not embarrass you. That is enough to prove the channel and start collecting data on what to build next. Anything beyond that is over-engineering for a first launch.
WhatsApp supports buttons, lists, and quick reply options that render natively in the app. Founders often skip these because plain text is easier to ship. That is a mistake. A single conversation with three interactive buttons resolves faster and produces cleaner data than a text-only equivalent, because users tap instead of typing free text that your model has to parse. Use interactive components anywhere the conversation has a small set of expected responses.
The two components that matter most are list messages for menus of up to ten options and reply buttons for up to three quick choices. Use them for onboarding steps, order status queries, and any decision that has a bounded set of outcomes. Save free-text handling for the truly open-ended parts of the conversation. The mix of structured and free-text turns usually produces the highest resolution rate at the lowest cost.
Inside the 45-day framework, we usually slot the WhatsApp bot into weeks four through five if it is part of the launch scope. That leaves week six for the guardrails and quality tuning. Founders sometimes ask whether they should build the bot in parallel with the rest of the product from day one. The answer is usually no. Focus on the core product first, get a couple of beta users on the web app, then add WhatsApp once you know which intents matter. Building the bot without user data first is guessing at the wrong problem.
The exception is products where WhatsApp is the primary interface, not a support layer. Delivery tracking, appointment booking, and lightweight commerce products often live entirely inside WhatsApp. In those cases the bot is the product, not an accessory, and the sequence changes. If that is your situation, the two-week plan above absorbs the whole first half of the 45 days, and the rest of the timeline is spent on the operational and payment surfaces around the conversations.
A successful two-week WhatsApp launch looks like this. Your number has an approved business profile, a healthy quality rating, and templates covering your critical outbound flows. Your bot answers inbound messages for the top intents accurately, escalates cleanly when uncertain, and produces logs you can audit. Real users are having real conversations with it every day, and your support team is spending noticeably less time on the intents the bot handles.
The bot will not be perfect. It will occasionally give a wrong answer, mishandle an edge case, or route a conversation poorly. That is fine. The goal at day fifteen is not perfection, it is a live channel with a feedback loop that lets you improve steadily. Founders who ship this version and iterate weekly usually have a strong bot by month two. Founders who wait for perfection often never ship at all. For a walk-through of how we structure the WhatsApp piece for your specific product, take a look at some of our recent projects or get in touch and we can scope it on a call.
Content Writer at Qwikly Launch
Dharmendra Singh Yadav is an experienced writer covering SaaS, technology, and product development trends.
More articles coming soon...
Want to build or scale your SaaS product? Book a free consultation with our expert team and let's turn your idea into reality.
Book a Free Consultation