Meta's pricing change forces ISPs to rethink how they use WhatsApp.
The most immediate reaction might be: “Then I'll take WhatsApp out of my omnichannel setup.”
But for an ISP that decision can be more complicated than it looks.
Because WhatsApp has one feature that many alternative channels don't: customers can use it even after losing their internet connection.
And that changes the strategy completely.
The problem of the two kinds of outage
Picture a customer who loses service.
Case 1: they didn't pay their bill
Here an ISP can use a captive portal. Even with the service suspended, access to certain domains can be allowed so the customer can:
- Check what they owe
- Download their bill
- Make the payment
- Request reconnection
Case 2: the service went down because of a network fault
Here everything changes. If there's a physical fault, there's no internet to reach the portal. The customer can't use:
- The customer portal
- The web chat
- The web inbox
- The ISP's website
In case 1, the captive portal makes a lot of sense. In case 2, the customer needs another connection. Usually: their mobile data.
And at that moment WhatsApp has a huge advantage as a backup channel.
That's why there's no perfect replacement for WhatsApp
ISPs are exploring several alternatives.
1. Web Inbox
It lets you centralize customer service right from the website. It's a good alternative for users who have connectivity.
The problem: it doesn't fully solve an internet outage.
2. Captive portal
It's excellent for suspensions due to non-payment. It can turn a suspension into an opportunity to recover overdue accounts.
But it doesn't replace WhatsApp for a physical fault either.
3. Telegram
It's technically viable and can work as an additional channel.
The problem is adoption. For many ISPs in Latin America the objection is simple: “My customers don't use Telegram.”
You can't solve a customer service problem by sending the customer to a channel they don't use.
4. Facebook Messenger and Instagram
These channels are already part of many ISPs' digital ecosystem. They can also be very useful for sales and support.
But being there doesn't necessarily mean they replace WhatsApp's role as the main channel.
5. WhatsApp Calling
Another option is to use WhatsApp calls for certain scenarios. It can be especially interesting when the priority is voice contact without depending on the subscriber's fixed connection.
But it's still one more piece of the strategy, not a complete solution.
So what should you do?
The answer probably isn't: “Get rid of WhatsApp.” The answer may be: “Use each channel for the problem it solves best.” For example:
| Channel | What for |
|---|---|
| Support, inbound sales and service when the customer starts the conversation. | |
| Captive portal | Payments, reconnection and managing suspended customers. |
| Web | Self-service, documentation, FAQs and tasks that need connectivity. |
| Instagram / Messenger | Acquisition and complementary channels. |
| Telegram | An additional channel for certain customer segments. |
And where does AI come in?
Here a second decision comes up.
An ISP can automate WhatsApp support with its own models or use native solutions from Meta's ecosystem. Meta also offers Meta Business Agent.
As a market reference, vendors who have analysed Meta's documentation estimate that Business Agent is billed at US$2 per million tokens, and that a typical reply can amount to around US$0.04–US$0.05 of usage. This equivalence is an estimate, not a fixed per-message rate published by Meta.
Meanwhile, our current scenarios with GPT-4.1-mini are around:
| Conversations | LLM cost |
|---|---|
| 3,000 | US$75 |
| 5,000 | US$120 |
| 10,000 | US$220 |
That's roughly US$0.022–US$0.025 per conversation in these scenarios.
But the comparison that matters isn't only the model's price.
Generic AI vs. AI built for an ISP
An ISP doesn't just need to answer questions. It needs to take actions. For example:
“My internet is down.”
The AI should be able to:
- Identify the subscriber.
- Check the service status.
- Determine whether there's a mass outage.
- Check the ONU / CPE when relevant.
- Create or update a ticket.
- Guide the customer.
- Escalate to the human team when needed.
“I already paid.”
The AI should be able to:
- Identify the customer.
- Validate the payment details.
- Check the account status.
- Update the relevant system.
- Request reconnection when appropriate.
- Confirm with the customer.
That requires integration with the ISP's operational stack.
At ISPs it's common to find systems like Wispro, Sae Plus, Infobox, MikroTik, SmartOLT, ISP Cube and other OSS/BSS, precisely because automation has to work on top of the systems the ISP already uses.
The mistake is thinking of “a chatbot”
An ISP doesn't simply need a chatbot that writes nicely. It needs an automation layer able to connect:
- Customer
- Channel
- AI
- OSS / BSS / CRM
- Action
- Customer
And that architecture can coexist with several channels.
What would an ISP do?
A reasonable architecture could be:
| Piece | Its role |
|---|---|
| The main channel for customer-initiated conversations. | |
| Captive portal | The main channel for payments and reconnections when there's connectivity. |
| Web | Self-service and complementary tasks. |
| Instagram / Messenger | Sales and complementary support. |
| AI | The layer that automates resolution behind all those channels. |
The goal shouldn't be to get rid of WhatsApp. Nor should it be to send absolutely everything through WhatsApp.
The question ISPs should be asking
After this change from Meta, I'd start with four numbers:
- 1How many subscribers do I have?
- 2How many of them message us each month?
- 3How many messages do we send per conversation?
- 4What share of those conversations can be resolved automatically?
With those four variables you can start modelling the real cost of your customer service operation.
Because the future of ISP support probably isn't: WhatsApp vs. Web vs. Telegram. It will be: WhatsApp + Web + Portal + other channels + AI + automation.
The question is how to design that architecture so it scales.
Share this article
