Interaflow

Produto

Grupos de WhatsApp

Grupos coletivos de WhatsApp são suportados via WhatsMyPhone — descoberta automática, sincronização de metadados e ingestão de mensagens em fase 1.

Atualizado em

Para que serve

Operações em vendas consultivas, suporte premium e relacionamento B2B costumam atender clientes não em conversas 1:1, mas em grupos coletivos de WhatsApp — múltiplas pessoas do lado do cliente, várias do lado da empresa, conversando no mesmo grupo durante meses ou anos.

Tradicionalmente, isso é feito com números pessoais de Atendentes participando dos grupos individualmente. O Interaflow oferece o caminho para trazer essa operação para dentro do dashboard via WhatsMyPhone — atendimento em grupo passa a ser visível, auditável e operável dentro da plataforma, sem depender de números individuais espalhados pelas equipes.

Casos típicos:

  • Suporte premium — grupo “Cliente A — Suporte” com SLA dedicado.
  • Atendimento técnico recorrente — grupos por carteira (vendas de maquininhas, integrações específicas).
  • Broadcast assistido — coordenar comunicação com vários contatos ao mesmo tempo, mantendo histórico no canal.

Como funciona em alto nível

A peça que torna o atendimento em grupo possível é a integração com o WhatsApp pessoal/business comum (não a Cloud API oficial), feita pela bridge Baileys — o microsserviço Node.js que mantém a sessão WhatsApp ativa e troca eventos com o Interaflow.

WhatsApp (grupo) ◄──► Baileys bridge ◄──► Interaflow (Canal MyPhone)

A conexão acontece em três etapas:

  1. Pareamento do número via QR Code, igual ao WhatsApp Web. O número permanece pareado enquanto a sessão estiver válida.
  2. Descoberta dos grupos em que o número participa — feita automaticamente quando a sessão abre (backfill) e em tempo real quando o WhatsApp emite eventos de criação ou atualização de grupo.
  3. Ingestão de mensagens trocadas no grupo, alimentadas no Interaflow via webhook do bridge.

Internamente, o Canal WhatsApp tem uma flag supports_groups que diferencia provedores capazes de operar grupos (MyPhone via Baileys = sim) de provedores que não suportam gestão nativa de grupos (Meta Cloud API clássica = não).

O que existe hoje (fase 1)

A primeira fase do suporte a grupos cobre descoberta e ingestão. Funcionalidades em produção:

  • Backfill de grupos quando a sessão MyPhone abre — o bridge consulta a lista de grupos em que o número participa e emite um evento de metadado por grupo descoberto.
  • Sincronização incremental de metadados (nome, descrição, participantes) via eventos groups.upsert e groups.update emitidos pelo WhatsApp em tempo real.
  • Throttling defensivo: cada grupo tem um intervalo mínimo de 5 minutos entre re-fetches; um cooldown global protege a sessão de rate-limit do WhatsApp em operações com muitos grupos ativos.
  • Ingestão de mensagens de grupo no Canal MyPhone configurado.

O que ainda está em definição

A camada de modelagem de produto para grupos coletivos — roteamento explícito por Fila/Fluxo, painel dedicado de gestão de grupos no dashboard, atendimento colaborativo com múltiplos Atendentes no mesmo grupo, métricas próprias de grupo — está em decisão arquitetural ainda não promovida. O caminho proposto introduz um primitivo novo (peer de Conversa, com modelo, lifecycle e métricas próprios), mas a decisão final sobre escopo, UI e SLA dessa camada não foi ratificada.

Por que grupo não é uma “Conversa múltipla”

Vale registrar a diferença para entender por que esse caso de uso pede um caminho próprio em vez de ser empilhado em Conversa:

  • Conversa é 1:1, bounded (abre, atende, encerra), tem dono, e mede TMA / SLA / NPS.
  • Grupo é N:N, persistente (dura meses/anos), colaborativo (vários Atendentes participam), e métricas de atendimento 1:1 distorcem quando aplicadas (TMA num grupo de 50 pessoas é fantasia).

A analogia mais próxima é “canal compartilhado” (como um canal de Slack), não “conversa coletiva”. O modelo do produto reflete esse entendimento — daí a escolha por uma camada própria em vez de forçar encaixe em Conversa.

Limitações conhecidas

  • MyPhone usa WhatsApp pessoal/business comum — sem SLA oficial da Meta. A sessão depende do número pareado continuar válido (QR pode precisar ser refeito se o WhatsApp invalidar a sessão).
  • Throttling rígido: 5 min entre re-fetches do mesmo grupo evita flood. Operações que mudam metadado de grupo com altíssima frequência podem ver o reflexo no Interaflow com latência.
  • Sem broadcast oficial via Cloud API. Para disparos em massa oficiais use templates HSM em Cloud API; MyPhone é para grupos permanentes, não para listas de transmissão volumosas.

Ver também