Custos na WhatsApp Cloud API: como otimizar sem degradar experiência

O WhatsApp adota conversation-based pricing. A unidade de cobrança não é a mensagem individual, mas a conversa: uma janela de 24 horas que se abre quando a primeira mensagem de uma categoria é entregue. Dentro dessa janela você pode trocar quantas mensagens quiser pelo mesmo custo da conversa. A cobrança acontece por categoria, e cada categoria tem sua própria regra de quando a conversa é tarifada.

Existem quatro categorias. Marketing cobre promoções, ofertas e reengajamento. Utility cobre transações e atualizações ligadas a uma ação do usuário (confirmação de pedido, aviso de entrega, fatura). Authentication cobre códigos de verificação e OTP. Service cobre o atendimento dentro da janela aberta pelo próprio cliente, quando ele inicia a conversa.

Os valores variam por país e por categoria e a Meta os reajusta periodicamente, então não trabalhe com números fixos de cabeça. O que se mantém estável é a estrutura: você paga por conversa, por categoria, dentro de uma janela de 24 horas. Toda decisão de otimização se apoia nessa estrutura, não em um preço congelado.

Antes de otimizar é preciso enxergar o desperdício. Na prática, o custo escapa por poucos pontos recorrentes, quase sempre ligados a abrir conversas que não precisavam existir ou que não geraram resultado.

• Templates de marketing mal segmentados: disparar para a base inteira abre uma conversa cobrada por contato, mesmo nos contatos sem qualquer intenção de compra. O custo escala com o tamanho da lista, não com a receita.
• Reabertura de janela desnecessária: enviar uma mensagem proativa para um cliente que voltaria a falar sozinho, ou fragmentar avisos em vários disparos em vez de consolidar, abre conversas extras que poderiam ser uma só.
• Falta de resolução no primeiro contato: quando o atendimento não resolve e o assunto volta dias depois, cada retorno pode reabrir conversa e multiplicar o custo da mesma jornada.
• Categoria errada no template: classificar como marketing algo que seria utility (ou vice-versa) muda a regra de cobrança e pode encarecer mensagens que deveriam ser mais baratas.
• Ignorar a service window: responder via template pago quando o cliente acabou de escrever, em vez de usar a janela de service aberta por ele, paga por algo que poderia custar menos ou nada.

Repare que nenhum desses vazamentos é sobre o preço unitário. Todos são sobre volume de conversas mal direcionadas. É aí que está a alavanca de FinOps: reduzir conversas desperdiçadas pesa muito mais do que negociar centavos por mensagem.

Com o mapa do desperdício em mãos, as estratégias seguem uma ordem lógica: primeiro evitar conversas desnecessárias, depois usar a janela mais barata disponível, depois classificar certo e, por fim, resolver de uma vez.

1. Consolide mensagens dentro da janela de 24h. Uma vez aberta a conversa, todas as mensagens daquela categoria cabem nela pelo mesmo custo. Agrupe atualizações (pedido confirmado, em separação, enviado) na mesma janela em vez de abrir uma conversa para cada evento.
2. Use a service window gratuita ou mais barata quando o cliente inicia. Se o usuário acabou de escrever, você está dentro da janela de service iniciada por ele: responda nessa janela em vez de disparar um template pago. Só recorra a template quando a janela já fechou.
3. Escolha a categoria certa do template. Uma confirmação de pedido é utility, não marketing. Classificar corretamente alinha a cobrança à regra mais favorável daquele tipo de mensagem e evita que utilidades sejam tarifadas como promoção.
4. Resolva no primeiro contato. Uma jornada resolvida de uma vez consome uma conversa; a mesma jornada arrastada por reaberturas consome várias. Invista em respostas completas, contexto preservado e handoff humano no momento certo para fechar o assunto antes que ele volte.
5. Segmente o marketing por intenção, não por tamanho de base. Disparar para quem demonstrou interesse converte mais e abre menos conversas vazias. Menos volume bem direcionado costuma render mais receita com menos custo do que envio em massa.

A lógica comum a todas elas: cada conversa aberta deve ter um propósito que justifique o custo. Quando esse propósito existe e a conversa resolve, o gasto vira investimento; quando não existe, vira vazamento.

A métrica que importa não é quanto custa uma conversa, é quanto custa resolver uma jornada do cliente. Uma jornada pode consumir mais de uma conversa (um aviso utility, depois um atendimento service, talvez um reengajamento). O custo real é a soma das conversas que aquela jornada precisou para chegar ao fim.

// Custo por jornada resolvida (estrutura, nao precos fixos).
// Os precos por categoria mudam por regiao e sao reajustados pela Meta,
// entao trate-os como variaveis de entrada, nao como constantes.

const precoConversa = {
  marketing: 0,       // preencha com o valor vigente da sua regiao
  utility: 0,
  authentication: 0,
  service: 0,         // muitas vezes a mais barata ou gratuita
};

// Conversas abertas em uma jornada tipica, por categoria.
function custoDaJornada(conversasPorCategoria) {
  return Object.entries(conversasPorCategoria).reduce(
    (total, [categoria, qtd]) => total + qtd * precoConversa[categoria],
    0,
  );
}

// Custo por RESOLUCAO = custo total das conversas / jornadas resolvidas.
// Esta e a metrica de FinOps que voce deve acompanhar ao longo do tempo.
function custoPorResolucao(custoTotalConversas, jornadasResolvidas) {
  if (jornadasResolvidas === 0) return Infinity; // gasto sem resultado
  return custoTotalConversas / jornadasResolvidas;
}

// Exemplo de leitura:
// Mais conversas por jornada => custo por resolucao sobe.
// Mais resolucao no primeiro contato => custo por resolucao cai.

Jornada do cliente (1 problema a resolver)
        |
        v
+-------------------------------+
|  Conversas abertas na jornada |
|  utility   -> 1 conversa      |
|  service   -> 1 conversa      |
|  marketing -> 0..N conversas  |
+-------------------------------+
        |
        |  soma dos custos por categoria
        v
   Custo total da jornada
        |
        |  dividido por jornadas resolvidas
        v
+-------------------------------+
|   CUSTO POR RESOLUCAO         |  <-- metrica que importa
+-------------------------------+
   menos conversas por jornada  => mais barato
   mais resolucao 1o contato    => mais barato

A fórmula deixa explícito o que melhora o número: reduzir conversas por jornada e aumentar a taxa de resolução. Cortar mensagens dentro de uma conversa já aberta não muda nada no custo, porque a conversa já foi tarifada. Por isso otimizar mensagem a mensagem é quase sempre energia desperdiçada.

O erro de FinOps mais comum nesse canal é olhar para o número de mensagens enviadas. Como a cobrança é por conversa, a contagem de mensagens não tem relação direta com o gasto. Uma conversa com 2 mensagens custa o mesmo que uma com 20. Otimizar o número de mensagens cria atrito no atendimento sem economizar nada.

A métrica certa é custo por resolução: quanto você gastou em conversas dividido pelas jornadas efetivamente resolvidas. Ela captura ao mesmo tempo o desperdício (conversas que não resolveram) e a eficiência (resolver com menos conversas). Acompanhe-a por categoria e por fluxo para descobrir onde o custo por resultado está alto.

Quando o time passa a otimizar custo por resolução, as decisões mudam de natureza: em vez de cortar mensagens e degradar a experiência, você reduz conversas inúteis e resolve mais rápido. O resultado é custo menor com atendimento melhor, que é exatamente o que FinOps aplicado deveria entregar.