पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 18 · Build

WhatsApp as a product surface, not just a channel

For many Indian customers the chat is already open and the app is not installed. Put the short, notification-led jobs in WhatsApp, keep the long ones in the app, and design the journeys so the messages are cheap.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

A busy street market in Bengaluru with shoppers around a fresh produce stall. — Photograph: Aditya Oberai · Pexels

An Indian founder building a consumer or small-business product faces a plain fact: the customer will not install another app for something they do twice a month, and they already have WhatsApp open. The question is not whether to use it. It is which parts of the product should live there, which should not, and how to keep the message bill from growing faster than revenue.

The [distribution lesson](/library/whatsapp-as-distribution-channel) treats WhatsApp as a way to reach customers. This one treats it as part of the product: what the Platform can now do, how to decide job by job between chat and app, the rules that shape the design, what the messages cost, a worked example, and how to build it so it does not break. The figure prices the one design decision that moves the bill most.

What the Platform can do now

The WhatsApp Business Platform is no longer only text and templates. Meta describes WhatsApp Flows as a way to build structured interactions for business messaging, and its published use cases include lead capture, loan offers where the user adjusts the terms and verifies identity, insurance quotes and personalised recommendations, with onboarding and profile completion noted as adaptations. In practice a Flow is a short form that opens inside the chat, which is exactly what most booking and sign-up steps need.

In India the Platform also takes payment. A business sends an order details message; the customer taps Review and Pay, sees the order and the total, and pays without leaving the chat. Meta lists four payment gateways for this route, BillDesk, Razorpay, PayU and Zaakpay. A second route uses a UPI intent: the customer can pay with WhatsApp’s own payment method or any UPI app installed on the phone, and the merchant can put a preferred app at the top of the list. In both, the business confirms with order status messages as the payment and the order progress.

Chat or app: deciding job by job

Go through the product’s jobs one at a time and put each where it fits. Chat suits jobs that are short, start from a notification and end in one decision: book, confirm, reschedule, pay, receive a document, reorder the usual, ask a question. They happen a few times a month, they do not need the customer to remember a password, and the result arrives where the customer will see it. App or web suits jobs that are long, exploratory or data-heavy: browsing a catalogue, comparing options, reading history across months, editing a complex record, anything that needs a chart or a table wider than a phone held upright.

A vendor and a customer at a sidewalk electronics stall in Thalassery. — Short jobs that start with a message and end in one decision belong in the chat. The long ones need a screen. Photograph: SAMANYU S KUMAR · Pexels

Three tests settle the doubtful cases. Would the customer start this job unprompted, or does it begin with your message? Prompted jobs belong in chat. Does it need more than about five inputs? Then it needs a screen, though a Flow can carry a short form. Will the customer want to find the result again in six months? Then it needs a home outside the chat thread, even if the chat delivers it first. Many products end with chat as the front door and the app as the back office, and that is a sound shape. The [activation lesson](/library/activation-first-session-that-decides) applies to both: the first result should arrive in the first session, wherever the session happens.

The rules that shape the design

Four rules decide what a WhatsApp journey can look like. The customer service window. Meta’s pricing documentation explains that when a customer messages you a 24-hour window opens; inside it any message can be sent and non-template messages are free. Once it closes only approved templates can be sent. Template categories. Templates are marketing, utility or authentication, and the category decides the price. The free entry point. When a customer arrives from a click-to-WhatsApp ad or a Facebook Page button and you reply, a 72-hour window opens in which every message is free.

Messaging limits. Meta’s limits page says a newly created business portfolio can send to 250 customers in a rolling 24 hours outside service windows, rising to 2,000 after a scaling path and further with automatic scaling if message quality holds. A product that plans to send a morning reminder to ten thousand customers on launch day will not be able to. And behind all four sits opt-in: the customer must have agreed to hear from you, which the distribution lesson covers.

The design consequence is the most useful idea in this lesson. Build journeys in which the customer writes or taps first. A reminder template with a “Confirm” and a “Reschedule” button costs one utility message; when the customer taps, a window opens and everything that follows for the next day, the confirmation, the directions, the receipt, is free.

Paying for the messages

Since 1 July 2025 the Platform has charged per message rather than per conversation. Utility templates delivered inside an open window are free; outside it they are charged, as marketing and authentication templates always are. The India rates from 1 October 2026, as reported on 30 September 2026, are ₹0.8631 for a marketing message and ₹0.115 for a utility or authentication message, before taxes and before any fee your solution provider adds. Meta’s pricing page notes local billing for eligible customers in India from January 2026. Checked on 10 October 2026; rates change, so read the current card before budgeting.

Two things stand out at most settings. Utility messages are cheap enough that sending them cold is rarely ruinous, but designing for the window still removes a meaningful part of that line. And marketing is usually most of the bill, at more than seven times the utility rate. A product surface that sends one promotion a month per customer can spend more on that promotion than on every useful message it sends. Price marketing against what it sells, as the distribution lesson’s figure does, and keep the product surface for service.

A worked example: a diagnostic lab

A diagnostic lab chain in Lucknow has 40,000 patients a month who interact on WhatsApp. A patient taps a link on the lab’s website, which opens a chat; the patient writes first, so a window opens. A Flow takes the test, the address and the slot; an order details message collects payment by UPI. Within the same 24 hours the lab confirms the booking and sends “Your technician is on the way”: both inside the window, both free. The next day come “Sample received” and “Report ready”, two utility templates sent outside the window and charged. “Report ready” carries a “Get my report” button, so the tap opens a new window and the PDF itself goes as a free service message. Add one OTP at sign-in and one health-package promotion a month.

The arithmetic: 40,000 × 2 × ₹0.115 is ₹9,200 for utility, 40,000 × ₹0.115 is ₹4,600 for authentication, 40,000 × ₹0.8631 is about ₹34,500 for marketing. About ₹48,300 a month, roughly ₹1.21 per patient. Sending all four notifications cold would add ₹9,200. The promotion is 71 per cent of the bill. What stays in the app: reports across years with trends, family profiles and the comparison of health packages, the long jobs patients do a few times a year.

Design the journey so the customer writes first. Then the useful messages are free and only the promotions cost money.

Building it properly

A WhatsApp surface is a distributed system with an unreliable user at one end. Model each journey as a state machine, booked, paid, collected, reported, stored on your server, so a message that arrives twice or out of order does not double a booking. For payments, Meta’s gateway documentation says to wait for status updates by webhook but not to rely on webhooks alone, and to use the payment lookup call to check status directly. Track every journey with server-side events, as the [instrumentation lesson](/library/instrumenting-product-twelve-events) sets out, so the funnel inside the chat is as visible as the one in the app.

Give every journey a way to a human, inside working hours and with a stated response time, because a chat that cannot reach a person feels worse than an app that never offered one. Write templates in the customer’s language and get them approved in each one before launch. Health, finance and identity documents are personal data; the [DPDP lesson](/library/dpdp-act-what-it-requires-of-your-product) covers notice, consent and retention, and the same rules apply inside a chat as on a screen.

The monthly surface review

Once a month, one hour. Read the bill by category and compute the cost per active customer. Find the share of utility messages that went out inside a window and pick one journey to redesign so the customer taps first. Check the messaging limit against next month’s largest planned send. Read twenty chat transcripts end to end and note where customers typed a question the flow did not expect. Check payment completion inside the chat against the app. And ask of each job in the product whether it is in the right place: a job customers keep starting in the chat and finishing in the app, or the other way round, is telling you where it belongs.

Rates and rules are as checked on 10 October 2026 from the sources below and change often; the Lucknow example is illustrative. Nothing here is legal advice.