WhatsApp Business Platform
October 31, 2026
•
6 min read

Conversation pricing vs per-message: which model your volume suits

Meta stopped charging per conversation in July 2025, but most budgets still assume it. Here is what a conversation charge used to cover, where the two models diverge on a real thread, and the arithmetic that turns an old conversation forecast into a message forecast you can defend.

Manikandan S
Founder & Technical Lead at Ziync
#WhatsApp Business Platform#pricing#BNex
A conversation thread on a phone beside a line-by-line cost table
A conversation thread on a phone beside a line-by-line cost table
Executive Summary & Key Takeaways

Meta stopped charging per conversation in July 2025, but most budgets still assume it. Here is what a conversation charge used to cover, where the two models diverge on a real thread, and the arithmetic that turns an old conversation forecast into a message forecast you can defend. In this deep dive, we explore actionable strategies, real-world engineering blueprints, and future-proof patterns to elevate your digital operations.

I still get cost models from prospects that are built on conversations. Someone has written "we do about 900 conversations a month, so at roughly X per conversation we should be at Y" into a spreadsheet, and the number under it does not match what they were invoiced last quarter.

The model is out of date. Since 1 July 2025 Meta charges per delivered message, not per 24-hour conversation window. That single change rewrote the shape of a WhatsApp bill, and the businesses that got caught out were not the ones sending the most messages. They were the ones whose flow sends several messages per thread.

Here is the difference in plain terms, and how to rebuild a conversation forecast into something the invoice will recognise.

Two models, and only one of them still exists

Under conversation-based pricing, a business paid once per 24-hour window, per category. A customer messaged you, a window opened, and everything you sent inside that window of that category rode on one charge. Three replies or one, the price was the same. That is why a support team could be genuinely chatty without it showing up in the bill.

Under per-message pricing, each delivered template is charged on its own, priced by its category and by the recipient's country calling code. The window still governs what you are allowed to send, but it no longer bundles the cost. Ten charged messages in a thread are ten charges.

Worth naming the second change, because it is the one that lands in October 2026 invoices: service messages, the free-form replies you send inside the customer service window, stopped being free on 1 October 2026. Each business phone number gets 1,000 free service messages per calendar month, the allowance does not roll over, and after it every delivered reply is billed at the market's utility rate. Utility templates sent inside an open window became chargeable on the same date.

What the two models do to a real thread

Take a support conversation that takes four replies to resolve: an acknowledgement, a question back, the answer, and a confirmation.

Under the old model, that was one conversation charge. Under per-message pricing it is four service messages, four units against the monthly allowance, and four charges once the allowance is used.

Now scale it. Four hundred conversations a month at four replies each is 1,600 service messages. On a single phone number, 1,000 are free and 600 are billable. At an India utility rate of roughly ₹0.115 per delivered message, that is about ₹69 for the month. Cheap, but it is not zero, and the same desk with a chattier bot that answers in eight short messages would have been at 3,200 messages and a bill four times larger for identical customer outcomes.

That is the whole argument in one line: the conversation was never the unit of cost after July 2025, and the number of replies now is. I walked through the wider rate card, including how the categories differ, in what WhatsApp Business Platform messaging actually costs in India.

The arithmetic that tells you which model you are still budgeting for

You do not need a new spreadsheet. You need one column you probably do not have.

  1. Count last month's conversations, honestly, from the inbox rather than from memory.
  2. Count the average number of messages your team or automation sent per conversation. Pull it from the message log; the number is usually higher than the team believes.
  3. Multiply. That is your monthly message volume, before templates.
  4. Subtract 1,000 free service messages per business phone number.
  5. Price the remainder at your market's utility rate, then add marketing and authentication templates separately, since neither shares that allowance.
  6. Add your provider's markup and tax on top.

If your current forecast was built as conversations multiplied by a per-conversation rate, step 2 is the number that explains the gap. A team that assumes one message per conversation is out by a factor of three or four on a support desk, and by far more on any flow that narrates its progress.

Where conversation thinking is still the right thinking

This is not an argument for deleting the concept. Three places where the window still decides real money:

  • The 24-hour service window decides whether you can send free-form text at all. Outside it, only approved templates go out, and those are charged.
  • The free entry point window is still the cheapest traffic you can buy. A conversation that starts from a click-to-WhatsApp ad or a click-to-chat button opens a window where every message type, templates included, is free while it lasts, and since 28 September 2026 that window can stay open up to seven days rather than 72 hours.
  • Category discipline. A utility template reclassified as marketing changes the rate on every send of it. That is not a billing question, it is a wording question, and it is decided at template submission.

Volume tiers are the other place the old instinct misleads. Tiers reduce utility and authentication rates as monthly volume grows, aggregated at the business portfolio level. Marketing templates get no tiers at all, so campaign cost scales linearly with audience size no matter how large you are. A conversation-era forecast that assumed "bigger volume, better rate" only holds for two of the four categories.

Three habits that keep a message-based bill predictable

Consolidate replies. Once the monthly allowance is gone, one longer reply costs a fraction of six short ones. Bots that announce "let me check", then "checking now", then the answer are the expensive pattern, and customers do not enjoy them either.

Let the customer open the window. Acquisition spend that lands people in a free entry point window buys up to seven free days including templates. Designing the first conversation to live inside that window is worth more than any rate negotiation.

Keep a payment method on the account. Without one, Meta delivers the first 1,000 service messages of the month and then stops delivering rather than queueing them. That failure looks like an outage in the inbox and gets debugged as one.

What to do with the old forecast

Rewrite it this month rather than at the next budget cycle, because the October 2026 change is already in the numbers you are looking at. Then keep the per-message count as a standing metric next to the bill, so the next pricing change is something you notice in a chart instead of an invoice.

If you would rather not maintain that plumbing yourself, BNex runs the shared inbox, campaigns and automation on one verified WhatsApp number, so every reply in a conversation is visible in one place and the count that decides your bill is the count you can actually see. The pricing guide covers the current model, the free allowance and the windows in more depth.

If you have a conversation-based forecast sitting in a spreadsheet and you want a second pair of eyes on it, send it to me on WhatsApp with your monthly conversation count and average replies per thread. I will tell you where it will be wrong before the invoice does.

Get more insights like this

Join our list for practical automation, web engineering, and growth strategy — written by builders, for builders.

Manikandan S

Manikandan S

Founder & Technical Lead at Ziync

Founder and technical lead at Ziync. I build high-performance websites and web applications for startups and mid-market teams: React, Next.js, Firebase. Based in Chennai, working with clients worldwide.