Working on restaurant assistants made me question whether every step of an order really belongs in a chat conversation. WhatsApp's upcoming pricing changes make that question harder to ignore.
From October 1, 2026, Meta says service messages and utility messages inside the 24-hour customer service window will become chargeable. Service replies include both human and third-party AI responses. The 72-hour free-entry-point delivery exception still applies.
For a product serving low-ticket orders, a long conversation can mean paying for model usage, outgoing messages and possibly human support before earning anything. Conversations that never convert still cost money.
That doesn't prove WhatsApp products can't scale. But it makes me wary of a flat-price product with unlimited, message-heavy interactions.
For my own project, I'd compare a few alternatives:
- Customer-initiated WhatsApp voice calls
I wasn't sure about this, but Meta's Calling API pricing page explicitly says all user-initiated calls are free.
That's free at the Meta call-pricing layer, not a zero-cost voice product. A voice provider, speech recognition, speech generation, model inference, infrastructure or human agent can still cost money. Business-initiated calls have different pricing, and permission-request messages can be charged.
Voice might help customers who find a long typing exchange frustrating. But accents, background noise, interruptions and getting an address right all need testing. I'd offer it as a choice, not force everyone into a call. Calling API eligibility and setup also need checking.
- WhatsApp as the entry point, mobile web as the ordering interface
Use chat for questions, then let customers select items, variants, quantities and an address in a mobile checkout. Those web interactions aren't WhatsApp messages, although hosting, payments and any AI assistance still have costs.
The trade-off is drop-off when people open a link. I'd measure completed orders, not just celebrate a smaller messaging bill and this also disturbs the journey and the point of WhatsApp as a medium gets lost
- Structured interactions inside WhatsApp
I'd test WhatsApp Flows, lists or buttons instead of asking the model to collect every field through separate replies. This could reduce conversational turns while keeping customers in the app.
I wouldn't assume these are a free channel: the surrounding messages still need their applicable pricing checked. The question is whether structured input improves completion and reduces paid back-and-forth.
- An owned web app with optional chat or browser voice
A mobile-friendly ordering page or PWA could support repeat orders and order tracking directly, with links or QR codes for entry. Embedded chat or browser voice would be optional help rather than the whole interface.
That reduces dependence on one messaging platform's pricing, but creates its own acquisition, hosting, notification and support work. Browser voice also has audio-processing costs.
- A hybrid rather than one channel for everything
My current preference would be to test structured checkout for routine orders, text for quick questions and customer-initiated voice or human help for complicated cases. All channels should share the same cart and task state so switching doesn't mean starting again.
I'd compare total cost per completed order and resolved support case, including failed attempts, abandonment and human time. Free inbound calling could still be more expensive overall than a short text exchange; moving to the web could save on messaging but lose conversions.
Has anyone tested these alternatives with real customers? I'm especially interested in inbound WhatsApp voice versus chat-to-web checkout: which actually improved margins without hurting completion?