Build notes

The day there is no free way to answer a WhatsApp customer

29 August 2026 · a pricing change, and the half of it nobody is reporting · Founder, Klaros

Status: Resolved. This postmortem is a historical log. The issue discussed below has been fully fixed.

On the morning of 1 October, an operator was going to open the Costs screen in Klaros and read the words free-form replies inside the 24h window next to a category that had started costing money the same day. Not a crash, not an error, just a screen quietly telling the person paying the bill something that had stopped being true while they slept. We found it with thirty-three days to spare, and only because we went to check somebody else's homework.

What Meta actually said

One page carries this, and it is not the pricing page. It is the upcoming pricing page for non-template messages, and it says two things a month apart in consequence but identical in date:

The same page sets the price without setting a number: "rates for service messages are the same as the rates for utility and authentication messages" for the recipient's market, and "Meta does not offer volume tiers for service messages." That second sentence is the one worth reading twice. Utility and authentication templates get volume discounts. Service replies do not, at any scale.

It is also more useful than it looks. Because service is priced against utility and authentication, and those rates are already published per country, you do not have to wait for an announcement to size your October bill. Take last month's in-window replies, multiply by your country's utility rate, and you have the number. Meta said it would publish the final rates by 1 September, but you can do the arithmetic today.

Two things stay free, and both are worth keeping: messages your customers send you, and everything inside the 72-hour free entry point window that opens when somebody arrives from a Click-to-WhatsApp ad or a Page button. That window was already the best-value entry point on the platform. It is about to be the only free one.

Why we missed it for two weeks

We looked at this on 12 August and concluded the window was still free. That was wrong, and the way it was wrong is worth publishing, because anybody checking carefully would have reached the same answer.

Meta's main pricing page, the one everybody links and the one we linked from our own roadmap page as its primary source, still says today, on 29 August:

No October note. No banner. The change lives on a different page. So the method was sound and the source disagreed with itself, which is the failure mode that survives careful people. We had cited the page that contradicts the thing we were citing it for.

The correction is not "check harder". It is a rule: Meta's pricing page is authoritative for rates and not for what is about to become billable. Those are two different questions and they now live in two different places. Our sources list says this out loud, next to both links, so the next person does not have to rediscover it.

The escape route closes the same day

Read the explainers published this month and they converge on one recommendation: your conversations are too chatty, compress them, move multi-turn data collection into WhatsApp Flows, replace back-and-forth with structured templates. It is reasonable advice about interaction design. As cost advice, on this timeline, it is close to circular.

A booking dialogue that takes six free-form replies today costs six service messages from 1 October. Turn it into a utility template plus a Flow and it costs a utility message from 1 October. The saving is five messages, which is real, but it is not the saving being advertised, because the advertised version assumes the destination is still free. It is not. It stopped being free on the same morning.

The honest version of the advice is narrower and less exciting. There is no format that is free any more. There is only fewer messages, better timed, and the only lever left is whether a conversation reaches an outcome. Which, awkwardly for us, is the thing we have been arguing for two years while it was merely a philosophical preference. It is now arithmetic.

Because it does cost us something. Klaros charges a licence and passes Meta's rates through at zero markup, so every message a customer sends is revenue we do not take. A platform with a per-message margin has a straightforward interest in you sending more messages, and this change makes each one worth more to them. We have no such interest, and this is the first month where saying so is a claim with money behind it rather than a slogan on a pricing page.

Our own screen was telling the wrong story

The Costs panel in Klaros reads Meta's own billing and shows what was spent by category. It described service replies as free in six places. The category label itself was Service (free). The blended per-message figure was explained as "replies free, Utility cheap". The footer said in-window replies "are counted here at zero".

The worst one was not a label. The panel has an advisor that tells you about avoidable spend, and one of its findings reads: N paid templates sent inside a free window. These contacts had messaged you within 24h, so a free-form reply would have cost nothing. Same message, no charge.

After 1 October that recommendation overstates itself. A free-form reply does not cost nothing; it costs the utility rate. The real saving is the gap between the template rate and that, which on most rate cards is a fraction of what the panel was claiming. A cost tool that overstates your savings is a worse failure than one that overstates your costs, because you act on it.

What we changed

The obvious fix is to rewrite the copy. We did not do that, because the copy is correct today. Telling an operator in August that their replies cost money would be exactly as wrong as telling them in October that they do not.

So the screen now knows the date:

All six sites switch on that one line. The panel says replies are free while they are free, and stops saying it on the morning it stops being true, without waiting for us to notice and without a deploy. The advisor recommendation changes shape rather than disappearing: after the date it says the saving is the gap between the two rates, not the whole amount.

This is a small piece of code carrying a specific belief: a number on a screen that somebody pays money because of should not depend on us remembering to update it.

The deadline we could not prove

This is the part we would rather not write.

Our WhatsApp roadmap page stated, in nine separate places, that Meta requires a payment method on file by 30 September or it stops delivering your service messages. One of those nine was inside the FAQPage structured data, which is the version an AI assistant quotes to somebody who asks. We described the page as primary-sourced.

On 29 August we went to find the primary source. It is not in Meta's pricing documentation. It is not on the page that documents the October change. It is not in the partner announcement a major vendor published about the same change. The articles asserting it cite no Meta document, and the one that describes the enforcement behaviour in most detail cites nothing at all.

It may well be true. Deadlines like this are often relayed to providers through partner channels before they reach public documentation, and the date is specific enough that somebody probably received it in writing. But "probably true and widely repeated" is the standard we criticise other people for, and a page that calls itself primary-sourced cannot carry a claim on it.

So the page now says what we know and when we checked. The practical advice has not changed, because it never depended on the deadline being real: attach a payment method before October. It costs nothing, and an account Meta cannot bill is an account with a problem the moment your replies become billable.

Going looking also turned up something documented that we had missed entirely. The Meta Terms for WhatsApp Business are updated effective 23 September 2026, a week before the billing change. If a payment obligation exists, that is the likelier home for it than a pricing page. It is now on our timeline.

The economics, and the wait that was not necessary

This section originally said the copy was fixed and the economics were not, and that four files would stay visibly unfinished until Meta published its rates on 1 September. That was wrong, and worth recording as wrong, because the mistake is a common one: waiting for a number when what you needed was a rule.

Meta had already stated the rule, on the same page as the date. "By market, rates for service messages are the same as the rates for utility and authentication messages." That is enough to price every market we have ever billed in, because we already hold each market's utility rate, derived from real Meta invoices rather than a published table. What 1 September adds is confirmation of figures we can already compute, not the structure. Two days of deliberate incompleteness would have bought nothing.

So there is now one function, serviceMessageRate(rates, at): zero before 1 October, the market's utility rate after it, falling back to the authentication rate, and null rather than zero when neither is known. That last part matters more than it looks. A null reports as unpriced and is visible; a zero contributes nothing to a total and is not. Understating a bill is not more honest than overstating one, it is just quieter.

That last row is the one worth stealing. Every other file on the list needed a date gate because it models what a message costs. The analytics module needed none because it reads what a message cost. Given the choice, read.

The advisor row deserves its own sentence, because it is the largest number on the cost screen and it was about to become the most wrong. It counts billable templates sent to contacts whose window was open, and it quoted the entire spend as avoidable, which was true only while the alternative was free. From 1 October the alternative is billed too, so what is avoidable is the difference between the two rates. On Indian rates that is the gap between about ₹0.86 and ₹0.12, not the whole ₹0.86. The figure narrows on the date by itself. If we cannot price the alternative for that account it now says so, rather than reverting to the flattering old number.

And then the same bug, in our own fix

An audit of the finished work found the defect this note is about, in the work this note describes. It is worth publishing for that reason rather than in spite of it.

isBillableCategory('SERVICE') now returns true after 1 October, and messageCostPaise prices it from the market's utility cell. Both are correct. Nothing calls them with a service message. chargeTrialCredit() has exactly one call site, in the campaign consumer, behind if (messageKind === 'template'), and a template is never a service message. So the trial ledger meters campaign templates and nothing else: not an inbox reply, not an AI answer, not a sequence step, not anything the assistant sends. The primitive is right and unreachable, which is the same shape as a dashboard that says a reply is free. Ours just says it in arithmetic instead of English.

It matters because of whose money it is. On a hosted trial the number belongs to us, so Meta bills us. Before 1 October an unmetered reply cost nothing and the gap was invisible by being genuinely free. After it, a trial that answers a thousand inbound messages spends real money against a ₹25 credit that never moves.

We are not fixing it by quietly adding a charge to the send path, because that decides something we have not decided: whether a trial that has spent its credit should be unable to answer its own customers. A campaign that stops is an inconvenience. A business that cannot reply is a different product. The charge point is also not free to choose. sendTextMessage has 47 call sites, so metering at the persisted wrapper would miss whatever calls the raw sender, and metering at 47 places would rot.

So the open decision is larger than it was, and better stated. Our free trial includes a ₹25 message credit. From 1 October the same grant buys about 192 replies in India, 166 in the United States, 71 in the United Kingdom, 62 in a market we do not recognise. Three things need deciding together: whether to raise the grant, whether replies are metered at all, and what a trial does when the credit is gone and somebody has just asked it a question.

What this is really about

Digital distance is the gap between what a person believes you remember about them and what your software actually knows. We usually write about it pointed at a customer. This one points at us.

An operator who opens a cost screen believes it is telling them what things cost. For thirty-three days that belief would have been accurate, and then one morning it would not, and nothing on the screen would have changed to say so. They would have carried on trusting a number while it drifted, and found out from an invoice. The gap between what our software knew and what it was willing to say is the same gap, just with the vendor on the wrong side of it.

The fix was nine lines. Publishing the deadline we got wrong cost more than the fix did.

Written 29 August 2026, appended 30 August when the economics closed earlier than expected. The per-country rates land on 1 September and we will check them against what we derived. Related: the platform change tracker, cost calculator, digital distance, all build notes.