WhatsApp automation isn’t cheap. It’s cheap per message.

Show someone a price of eighty paise and watch what their mind does with it. It does not evaluate it. Eighty paise is below the level at which anybody bothers, so the number gets filed as “basically nothing” and the thinking stops there.²Then show the same person forty thousand messages a month and watch that get filed as “scale.” Two numbers, two different drawers, and the multiplication between them never happens.³

That is not stupidity. It is how fast judgement works, in everyone, including me. It is also why per-unit pricing is quoted per unit.

First, the unit moved

A lot of what people believe about WhatsApp costs is out of date, and the date is on the record.

Until the middle of 2025, WhatsApp billed by conversation: a twenty-four hour window opened, and everything inside it was covered. That model was deprecated on 1 July 2025 in favour of billing per message.¹ If your understanding of what this costs was formed before that, it is describing a product that no longer exists.

Three rules matter, and all three are Meta’s, not ours:

• You are charged when a template message is delivered. Not when it is sent into the void, and not when it is read.
• Messages that are not templates, sent while a customer service window is open, are free. Every reply your staff type back inside that window costs nothing.
• The rate depends on the category: marketing, utility, authentication or service.

Those three together decide almost everything about whether a WhatsApp build is cheap or ruinous, and none of them is about volume.

The expensive part of a WhatsApp flow is never the message. It is how many template messages you had to send to get one thing to happen.

The rate is not a constant, and India has felt that

People plan on a rate card as though it were weather. It is a price list, set by one company, and it moves.

Meta’s own pricing page records an India marketing rate increase on 1 January 2026, and further rate changes across markets on 1 April 2026 and 1 July 2026.¹ The same page records that billing for India moved to rupees from January 2026.

Read that as a business fact rather than a billing detail. If a flow only works at today’s marketing rate, you have built something whose economics belong to somebody else’s pricing committee. A flow that survives a rate rise is one where the recovered money per message is large enough that the message price is a rounding error. That is a design constraint, and it is worth applying before you build rather than after the rate moves.

The sum, with numbers we made up

I am going to pick figures now. They are ours, they are labelled, and you should replace every one of them.

Say eighty paise a delivered marketing message. Say a list of ten thousand. Say the flow sends four template messages to each person before it gets anywhere: the offer, the nudge, the reminder, the last call.

Forty thousand delivered messages at eighty paise is thirty-two thousand rupees. Now say three in a hundred do the thing you wanted. Three hundred outcomes.

Thirty-two thousand divided by three hundred is a hundred and seven rupees per outcome.

That is the number. Not eighty paise. And it is the number that decides whether this was a good idea, because the only question that matters is whether one of those outcomes is worth more than a hundred and seven rupees to you. For a jeweller, obviously. For a tea shop, obviously not. The rate card cannot tell you which one you are, and it is not trying to.

Where the money actually leaks

Once you look at cost per outcome instead of cost per message, the leaks are easy to name.

• Messages sent to people who will never act. You pay on delivery, not on interest. A list of ten thousand where two thousand are live and eight thousand are dead costs you the full ten thousand, every send, forever.
• Four templates where one would do. Each extra nudge multiplies the whole list again. The fourth message in a sequence is usually paying for the failure of the first three.
• Paying marketing rates for utility work. An order update, a reminder, a delivery notice: these have their own category and their own economics. Flows that send them as marketing are paying the wrong price for the right message.
• Not using the free window. When somebody replies, a service window opens and your ordinary replies inside it cost nothing. A build that answers with more templates instead of using that window is paying for something it was handed free.

The one that loses money

Since this paper is about arithmetic rather than enthusiasm, here is the conclusion that costs us work. This is reasoning from the sums above, not a measured result, and you should treat it as such.

Broadcasting marketing templates to a large list of people who did not ask to hear from you is the use case that loses money. It has the worst possible shape for per-message billing: the cost scales with the whole list, the response rate is set by how little those people wanted the message, and the rate for that category is the one most exposed to being raised. It is also the use case most often demonstrated in a sales meeting, because it is the one that produces an impressive screenshot.

The flows that hold up are the dull ones. A reminder that stops a no-show. A confirmation that stops a phone call. A reorder nudge to somebody who has already bought twice. Small lists, high intent, one message, real money recovered per send.

Four things to do before you sign anything

1. Ask for cost per outcome, not per message. If the person quoting cannot produce that number for a flow they have already built, they have not measured one.
2. Count the templates in the sequence. Multiply by your list. That is your bill, and you can work it out before anybody builds anything.
3. Write down what one outcome is worth to you. An actual rupee figure, from your own margin. Every decision after this is a comparison against that number.
4. Test the rate rise.Redo the sum with the message price doubled. If the flow stops working, you have built on someone else’s price list, and it has already moved twice.