A promessa do WhatsApp Flows é boa e é real: em vez de mandar o cliente para um formulário no navegador — onde ele some —, você abre o formulário dentro da conversa. Ele preenche ali, com campos de verdade, validação e telas encadeadas, e volta para o atendimento sem nunca ter saído do aplicativo.
O que falta no conteúdo em português sobre o assunto são as duas coisas que decidem se o seu flow vai funcionar: os limites e o ciclo de vida. Sem isso, você descobre o teto depois de ter desenhado a tela inteira.
Uma observação antes: circulam estatísticas de conversão bem específicas sobre o recurso — “72% de conclusão contra 35% de formulário web” é a mais repetida. Não encontramos fonte primária para esse número. Ele pode ser real e vir de um estudo de caso de alguma plataforma, mas não é dado publicado pela Meta, e tratar como benchmark do recurso é otimismo com aparência de estatística.
O que dá para montar
As telas do flow são descritas em um formato chamado Flow JSON, e os blocos disponíveis cobrem bem mais do que “formulário”:
Texto e conteúdo: TextHeading, TextSubheading, TextBody, TextCaption, RichText (para textos longos com markdown), Image e EmbeddedLink.
Entrada de dados: TextInput — que aceita texto, número, e-mail, senha ou telefone —, TextArea para texto longo, CheckboxGroup para múltipla escolha, RadioButtonsGroup para escolha única, Dropdown para lista suspensa, DatePicker e CalendarPicker para datas, OptIn para consentimento e upload de mídia.
Lógica: If e Switch, que mostram ou escondem partes da tela conforme o que o cliente respondeu. É o que permite um flow ramificar sem virar um labirinto de telas.
O CalendarPicker merece destaque para quem trabalha com agendamento: ele suporta seleção de data única ou de intervalo, com filtro de dias da semana e datas indisponíveis. Dá para montar agenda de verdade sem site.
Os limites que você precisa saber antes de desenhar
Aqui está o que a documentação registra e que economiza retrabalho:
| Item | Limite |
|---|---|
| Componentes por tela | 50 |
| Título e subtítulo | 80 caracteres |
| Corpo de texto | 4.096 caracteres |
| Legenda | 409 caracteres |
| Rótulo de campo | 20 caracteres |
| Texto de ajuda do campo | 80 caracteres |
| Mensagem de erro | 30 caracteres |
| Opções em seleção única ou múltipla | 20 |
| Opções em lista suspensa | 1 a 200 (100 se tiverem imagem) |
| Imagens por tela | 3 |
| Caixas de consentimento por tela | 5 |
Dois desses limites derrubam projetos com frequência.
Rótulo de campo com 20 caracteres. É pouco. “Qual o seu melhor e-mail?” não cabe. O texto de ajuda tem 80 e resolve parte, mas o rótulo precisa ser curto de verdade — vale escrever os campos antes de prometer a tela para alguém.
20 opções em seleção. Catálogo de serviços com 30 itens não cabe num RadioButtonsGroup. A saída é Dropdown, que vai até 200 — mas cai para 100 quando as opções têm imagem.
Sobre imagens, um detalhe de peso literal: são no máximo 3 por tela, em JPEG ou PNG, com tamanho recomendado de até 300 KB cada, e o payload total tem limite de 1 MB. Flow com imagem pesada não é lento — ele simplesmente não passa.
O ciclo de vida, e a parte que ninguém conta
Esta é a seção que faz diferença na operação.
Você controla três estados:
- Rascunho (
draft): serve só para teste, mostra avisos ao usuário e pode ser apagado por completo. É o único estado com volta total. - Publicado (
published): vai para usuários reais. E aqui está a pegadinha: um flow publicado não pode mais ser editado. Qualquer ajuste significa uma nova versão. - Descontinuado (
deprecated): não sai mais para ninguém, mas respostas de instâncias antigas ainda podem chegar. Ou seja: descontinuar não é o mesmo que desligar o webhook.
O WhatsApp controla dois:
- Limitado (
throttled): quando o sistema detecta problemas de saúde no flow, o envio cai para 10 mensagens por hora. O flow continua funcionando — só que num filete. - Bloqueado (
blocked): se a degradação continua, você não consegue mais enviar e o cliente não consegue abrir.
Repare no risco operacional: uma campanha planejada para milhares de envios pode encontrar um teto de 10 por hora sem que ninguém tenha mexido em nada. Se o seu flow depende de um endpoint seu para responder, a saúde desse endpoint é o que mantém o flow vivo — lentidão e erro no seu servidor viram limitação do lado da Meta.
Por isso, duas recomendações práticas: monitore o endpoint do flow como você monitora um checkout, e teste tudo no rascunho, porque depois de publicado não há edição.
Vale ainda uma distinção que confunde muita gente: o flow em si não passa pelo mesmo tipo de revisão de conteúdo que um template de mensagem. As páginas de ciclo de vida que consultamos descrevem transições feitas por você ou pelo monitoramento automático — não um processo de aprovação editorial. O template usado para entregar o flow, esse sim segue as regras de sempre, que tratamos em como criar um template que a Meta aprova.
Onde o Flows realmente compensa
Nem todo atendimento merece um flow. O recurso brilha quando existem dados estruturados a coletar e o texto livre é ruim para isso:
- Agendamento, com
CalendarPickerfazendo o trabalho que uma conversa de dez mensagens faria mal. - Qualificação de lead com campos definidos, em vez do bot perguntando um dado por mensagem — o que, a partir de outubro de 2026, também passa a ter custo por mensagem.
- Cadastro e atualização de dados, com validação na hora e sem erro de digitação para corrigir depois.
- Pesquisa e pós-atendimento, onde a taxa de resposta despenca quando exige sair do aplicativo.
E vale notar a sinergia com a mudança de cobrança: um flow que coleta cinco informações em uma tela substitui cinco perguntas do bot. Antes isso era só uma experiência melhor. Depois de outubro, é também uma fatura menor.
Onde ele não compensa: conversa que precisa de negociação, explicação ou empatia. Formulário não vende o que exige convencimento — e cliente que recebe um formulário quando queria uma resposta se sente processado, não atendido.
Colocar isso de pé
Nada aqui é impossível, mas repare no que o recurso exige de verdade: montar o Flow JSON, publicar pela API, hospedar e monitorar um endpoint que responde às telas, tratar as respostas que chegam por webhook, versionar quando algo mudar e acompanhar a saúde do flow para não cair em throttled no meio de uma campanha.
É trabalho de plataforma, não de configuração.
Com o AtendeChat, você opera a API Oficial com a estrutura em volta pronta: vários atendentes no mesmo número, fila de distribuição, histórico centralizado, funil e relatórios — para que o dado que o cliente preencheu chegue em algum lugar útil, e não morre num webhook. Somos parceiros oficiais da Meta e conduzimos com você a verificação de negócio, o registro do número e a aprovação dos templates.
Se você está avaliando levar seus formulários para dentro da conversa, fale com a gente — a gente ajuda a decidir o que vale virar flow e o que é melhor continuar como conversa.