A mudança de preços da Meta obriga os provedores a rever como usam o WhatsApp.
A reação mais imediata pode ser: “Então vou tirar o WhatsApp do omnichannel.”
Mas, para um provedor, essa decisão pode ser mais complicada do que parece.
Porque o WhatsApp tem uma característica que muitos canais alternativos não têm: o cliente pode usá-lo mesmo depois de perder a conexão com a internet.
E isso muda completamente a estratégia.
O problema dos dois tipos de queda
Imagine que um cliente fica sem serviço.
Caso 1: ele não pagou a fatura
Nesse cenário, o provedor pode usar um portal cativo. Mesmo com o serviço suspenso, é possível liberar o acesso a alguns domínios para que o cliente:
- Consulte o débito
- Baixe a fatura
- Faça o pagamento
- Peça a religação
Caso 2: o serviço caiu por uma falha de rede
Aqui tudo muda. Se existe uma falha física, não há internet para entrar no portal. O cliente não consegue usar:
- O portal do cliente
- O chat do site
- O web inbox
- O site do provedor
No caso 1, o portal cativo faz muito sentido. No caso 2, o cliente precisa usar outra conexão. Normalmente: os dados móveis.
E nesse momento o WhatsApp tem uma vantagem enorme como canal de contingência.
Por isso não existe um substituto perfeito para o WhatsApp
Os provedores estão explorando várias alternativas.
1. Web Inbox
Permite centralizar o atendimento direto no site. É uma boa alternativa para usuários que têm conectividade.
O problema: não resolve totalmente uma queda de internet.
2. Portal cativo
É excelente para suspensão por falta de pagamento. Pode transformar uma suspensão em uma oportunidade de recuperar inadimplência.
Mas também não substitui o WhatsApp numa falha física.
3. Telegram
É tecnicamente viável e pode funcionar como canal adicional.
O problema é a adoção. Para muitos provedores da América Latina a objeção é simples: “Meus clientes não usam Telegram.”
Você não resolve um problema de atendimento mandando o cliente para um canal que ele não usa.
4. Facebook Messenger e Instagram
São canais que já fazem parte do ecossistema digital de muitos provedores. Também podem ser muito úteis para vendas e atendimento.
Mas estar presente neles não significa necessariamente que substituam o papel do WhatsApp como canal principal.
5. WhatsApp Calling
Outra possibilidade é usar chamadas de WhatsApp em alguns cenários. Pode ser especialmente interessante quando a prioridade é falar por voz sem depender da conexão fixa do assinante.
Mas continua sendo mais uma peça da estratégia, não uma solução completa.
Então, o que fazer?
A resposta provavelmente não é: “Eliminar o WhatsApp.” A resposta pode ser: “Usar cada canal para o problema que ele resolve melhor.” Por exemplo:
| Canal | Para quê |
|---|---|
| Suporte, vendas inbound e atendimento quando o cliente inicia a conversa. | |
| Portal cativo | Pagamentos, religação e gestão de clientes suspensos. |
| Web | Autoatendimento, documentação, perguntas frequentes e operações que exigem conectividade. |
| Instagram / Messenger | Aquisição e canais complementares. |
| Telegram | Canal adicional para alguns segmentos de clientes. |
E onde entra a IA?
Aqui aparece uma segunda decisão.
Um provedor pode automatizar o atendimento no WhatsApp com modelos próprios ou usar soluções nativas do ecossistema da Meta. A Meta também oferece o Meta Business Agent.
Como referência de mercado, fornecedores que analisaram a documentação da Meta estimam que o Business Agent é cobrado a US$ 2 por milhão de tokens e que uma resposta típica pode representar cerca de US$ 0,04–0,05 de consumo. Essa equivalência é uma estimativa, não uma tarifa fixa por mensagem publicada pela Meta.
Em paralelo, nossos cenários atuais com GPT-4.1-mini giram em torno de:
| Conversas | Custo de LLM |
|---|---|
| 3.000 | US$ 75 |
| 5.000 | US$ 120 |
| 10.000 | US$ 220 |
Isso equivale a aproximadamente US$ 0,022–0,025 por conversa nesses cenários.
Mas a comparação importante não é só o preço do modelo.
IA genérica vs. IA feita para um provedor
Um provedor não precisa só responder perguntas. Precisa executar ações. Por exemplo:
“Estou sem internet.”
A IA deveria conseguir:
- Identificar o assinante.
- Consultar o status do serviço.
- Verificar se existe uma falha massiva.
- Checar a ONU / CPE quando for o caso.
- Abrir ou atualizar um chamado.
- Orientar o cliente.
- Escalar para a equipe humana quando necessário.
“Já paguei.”
A IA deveria conseguir:
- Identificar o cliente.
- Validar as informações do pagamento.
- Consultar a situação da conta.
- Atualizar o sistema correspondente.
- Pedir a religação quando for o caso.
- Confirmar com o cliente.
Isso exige integração com o stack operacional do provedor.
Nos provedores é comum encontrar sistemas como Wispro, Sae Plus, Infobox, MikroTik, SmartOLT, ISP Cube e outros OSS/BSS, justamente porque a automação precisa operar sobre os sistemas que o provedor já usa.
O erro é pensar em “um chatbot”
Um provedor não precisa simplesmente de um chatbot que escreva bonito. Precisa de uma camada de automação capaz de conectar:
- Cliente
- Canal
- IA
- OSS / BSS / CRM
- Ação
- Cliente
E essa arquitetura pode conviver com vários canais.
O que um provedor faria?
Uma arquitetura razoável poderia ser:
| Peça | Seu papel |
|---|---|
| O canal principal para conversas iniciadas pelos clientes. | |
| Portal cativo | O canal principal para pagamentos e religações quando existe conectividade. |
| Web | Autoatendimento e operações complementares. |
| Instagram / Messenger | Vendas e atendimento complementar. |
| IA | A camada que automatiza a resolução por trás de todos esses canais. |
O objetivo não deveria ser eliminar o WhatsApp. Também não deveria ser mandar absolutamente tudo pelo WhatsApp.
A pergunta que os provedores deveriam fazer
Depois dessa mudança da Meta, eu começaria por quatro números:
- 1Quantos assinantes eu tenho?
- 2Quantos me escrevem por mês?
- 3Quantas mensagens enviamos por conversa?
- 4Que porcentagem dessas conversas pode ser resolvida automaticamente?
Com essas quatro variáveis você já pode começar a modelar o custo real da sua operação de atendimento.
Porque o futuro do suporte de um provedor provavelmente não é: WhatsApp vs. Web vs. Telegram. Será: WhatsApp + Web + Portal + outros canais + IA + automação.
A pergunta é como desenhar essa arquitetura para que ela escale.
Compartilhe este artigo
