/src/pages/Acquisition.tsx é um shell de 3 abas (wa_button, widget, form) sobre a mesma tabela widget_configs, discriminada pela coluna acquisition_type. Cada aba lista as instâncias já criadas e oferece criação de uma nova (useCreateAcquisitionInstance), edição (redireciona para o builder dedicado) e exclusão (useDeleteAcquisitionInstance).

builder dedicado (WaButtonBuilder.tsx) grava em widget_configs (com acquisition_type = 'wa_button') o número, a mensagem inicial, o estilo do botão (wa_button_style), os campos capturados (wa_button_capture_fields, padrão ['phone']) e — opcionalmente — um disparo automático via Instant Engage: quando wa_button_auto_engage_enabled está ligado, o clique no botão não apenas abre o WhatsApp, dispara um template aprovado da Meta (wa_button_auto_engage_template_id) pelo canal escolhido, com variáveis mapeadas. Auto-save com debounce de 1.5s a cada edição.

SDK vanilla TS de ~5KB gzip (widget/src/sdk.ts) injetado via <script> IIFE, que carrega um iframe com a UI do chat (widget/src/widget.ts) e fala com o backend por widget-api (config pública, registro de visitante) e webhook-widget (mensagens entram no MESMO pipeline de contato → conversa → ai-orchestrator, resposta devolvida via Supabase Realtime broadcast). Rastreia UTMs, scrollDepth e tempo na página via uma classe PageTracker interna. Progressive profiling é configurável por field_collection_moment: before_chat (formulário antes de conversar), during_chat ou after_resolution. Gatilho proativo (proactive_enabled) dispara uma bolha de mensagem depois de N segundos (proactive_delay_seconds, padrão 30s) filtrando por página (proactive_pages). "Ponte pro WhatsApp" (wa_bridge_enabled) troca o canal sem perder o histórico. Quando o visitante do widget informa e-mail ou telefone que já batem com um contato existente (ex: já é contato de WhatsApp), a RPC widget_identify_and_merge (chamada em webhook-widget/index.ts) funde o contato do widget (cookie_id) com o contato já existente, com confiança 1.0 (telefone) ou 0.9 (e-mail) — sem isso, o mesmo visitante viraria dois contatos separados no CRM.

IntakeTemplateBuilder monta o template (/intake/new, /intake/:id), listado em IntakeTemplates.tsx. Vive na aba "Formulários" do yaAcquisition Hub junto com a conexão ao iLeadway (ILeadwayConnectionCard).

a mensagem que chega pelo WhatsApp oficial (BSP) traz um objeto referral da Meta com ctwa_clid. O webhook protegido webhook-bsp-platform (arquivo sob regra de não-alteração sem autorização expressa) extrai 10 campos: ctwa_clid, source_id, source_type (os 3 clássicos) + source_url, headline, body, media_type, image_url, video_url, thumbnail_url (a cópia e a mídia do anúncio). Cria um registro em contact_attributions com todos os 10 campos e attribution_model = 'last_touch'; em contacts.metadata grava um subconjunto de 7 (fica de fora video_url/thumbnail_url, que só vivem em contact_attributions.metadata). Em seguida faz join com ad_ads/ad_adsets/ad_campaigns pelo source_id (id do anúncio na Meta) para enriquecer o registro com nome da campanha, do conjunto de anúncios e do anúncio — rodando como tarefa de fundo (não bloqueia a resposta do webhook).

ad-lead-webhook (Meta) e google-ads-lead-webhook (Google) recebem o lead, criam o contato e o registro em contact_attributions (utm_source=meta|google, utm_medium=lead_form). Se a campanha tem metadata.instant_engage.enabled = true, resolve as variáveis do template aprovado (mapa de +20 variáveis: {{contact.name}}, {{deal.value}}, {{utm_campaign}} etc., com fallback para o formato legado {{contact_name}}) e chama send-active-message com o template configurado. Suporta canal WhatsApp ou e-mail — se for e-mail, exige contactEmail em vez de contactPhone. Ao concluir, emite o evento lead.instant_engage_sent e marca ad_leads.status = 'engaged'.

OAuth simplificado grava a conexão; ad-sync-campaigns puxa da Graph API (v21.0) campanhas, adsets e ads com upsert em lote (3 chamadas ao banco por sincronização, não uma por entidade); ad-sync-insights traz CPC, CTR, impressões e conversões; ad-sync-forms sincroniza os Lead Forms configurados; ad-token-refresh renova o token OAuth. Suporta seleção multi-conta de anúncio.

google-ads-oauth-init/google-ads-oauth-callback fazem a autenticação; google-ads-sync-campaigns e google-ads-sync-insights trazem campanhas e métricas; google-ads-lead-webhook processa Lead Form Extension do Google (payload com gcl_id, user_column_data) e dispara Instant Engage igual ao fluxo Meta; google-ads-send-conversion fecha o loop enviando conversão de volta para o Google.

CampaignIntelligenceDialog.tsx grava em ad_campaigns.metadata (JSONB, que o sync automático nunca sobrescreve) os campos intelligence.expected_ticket (ticket médio esperado), intelligence.product_context (qual produto a campanha vende), intelligence.target_audience (perfil do público), além de funnel_stage, urgency_level e sales_approach. Esse mesmo JSONB carrega a config do Instant Engage (instant_engage.*). A função SQL get_conversation_fast_context usa esses dados (via JOIN com ad_campaigns) para montar o contexto que a IA recebe assim que a conversa abre.

snippet v2 (GTM_SNIPPET, gerado em src/pages/settings/YaptTag.tsx) roda no navegador do visitante: lê variáveis de e-commerce do dataLayer (transaction_id, value, items), hasheia e-mail/telefone em SHA-256 via Web Crypto API no próprio navegador (nunca envia PII em texto claro), captura ctwa_clid, fbclid, gclid e UTMs (com fallback da query string se a variável do GTM vier vazia), e envia tudo com event_id estável (deduplicado por sessionStorage) para a Edge Function yapt-ingest via header X-Yapt-Api-Key. Dali, o evento passa por um pipeline de 3 etapas assíncronas: yapt-ingest grava em tag_events; yapt-enricher (via fila pgmq ou cron de segurança a cada 30s) resolve contato/conversa/pedido; yapt-dispatcher reenvia o evento resolvido para a Meta CAPI (e futuros destinos), com circuit breaker por tenant+destino (abre depois de 5 falhas seguidas, fecha depois de 3 sucessos em half-open, fica aberto por 60s). No painel, o admin liga quais eventos (purchase, lead, deal_won, add_to_cart) disparam para Meta CAPI e quais para Google.

resolveMatch() (supabase/functions/_shared/yapt-tag-match.ts) tenta resolver o contact_id numa ordem de prioridade fixa, parando no primeiro que bater: (1) user_id explícito → contacts.external_id; (2) anonymous_id do widget → widget_visitors.visitor_id; (3) telefone normalizado → contact_identifiers; (4) e-mail normalizado → contact_identifiers; (5) ctwa_clid → contact_attributions; (6) gclid → contact_attributions; (7) fbclid → contact_attributions. Depois de achar o contato, resolve também a conversa mais recente (janela de 30 dias, priorizando conversa já atribuída a um vendedor) e, para eventos de compra, o pedido correspondente (tenta source_external_id primeiro, depois order_number, porque o GTM manda o número visível ao cliente, não o ID interno da plataforma). Um passo extra "injeta" o ctwa_clid histórico (até 6 meses atrás) num evento de compra que não trouxe click ID — para não perder a atribuição de campanha numa venda que só aconteceu semanas depois do clique.

duas rotas complementares. (1) yapt Tag → yapt-dispatcher: eventos do site (purchase, lead, add_to_cart) resolvidos pelo enricher são reenviados à Meta Conversions API. (2) Conversion Destinations → ad-send-conversion: painel de "Destinos de Conversão" (ConversionsTab.tsx, DestinationsList.tsx, DestinationFormDialog.tsx) permite ao admin cadastrar destinos (Meta, e Google via google-ads-send-conversion) e mapear eventos de ciclo de vida do CRM (mudança de estágio, deal_won) para eventos de plataforma (event_mappings). Quando um automation-worker processa a fila capi_conversion, ad-send-conversion resolve o token OAuth (Vault), hasheia PII em SHA-256 e envia o evento à Graph API — com log de cada envio em ad_conversion_events e badge de saúde do destino (DestinationHealthBadge.tsx).

motor de sync agnóstico de plataforma (supabase/functions/_shared/commerce-sync/) com um PlatformAdapter por loja — adapter-shopify.ts, adapter-woocommerce.ts, adapter-nuvemshop.ts — cada um implementando fetchOrders, normalizeOrder, extractCustomer e mapeamento de status de pagamento para o formato comum do yapt. (adapter-registry.ts decide qual adapter usar por platform; order-processor.ts e sanitize-credentials.ts completam o motor compartilhado). commerce-catalog-sync sincroniza produtos, commerce-reconciliation concilia pedidos, shopify-customer-sync traz clientes do Shopify. Desde a última varredura, o pipeline ganhou mais três Edge Functions: commerce-order-sync, commerce-catalog-feed e commerce-knowledge-indexer (indexação do catálogo para a IA usar em conversa). O catálogo de apps nativos de 1 clique (native-apps-config.ts) também cresceu: além de Shopify, WooCommerce, Nuvemshop, Hotmart, Kiwify, Bling e Advbox, agora inclui integrações de logística, provedor e ERP — ou seja, deixou de ser só ads/e-commerce e passou a cobrir logística e ERP também. Cada app mantém mapeamento padrão de campos (ex.: buyer.email → contact.email) e triggers padrão (ex.: criar deal em compra aprovada).

pipeline por mensagem (ai-orchestrator): sanitização → checagem de blocklist → rate limit por tenant → debounce/agregação de burst → contexto rápido da conversa (cacheado, com validação de tenant a cada acerto de cache) → decisão de estado via get_handler_context → resolução do modo de operação → carregamento do agente → checagem de guardrails de handoff → execução. O agente tem à disposição 54 ferramentas (criar negócio, mover etapa do pipeline, agendar reunião, enviar template, consultar catálogo, pedir humano etc.), cada uma roteada para o handler real que a executa. Internamente, o pipeline foi reorganizado por estratégia (autônomo, sussurro, zona de IA cada um com seu próprio módulo), mas o comportamento ponta a ponta é o mesmo pipeline auditável de sempre.

cada conversa carrega um estado (bot_active, pending_handoff, human_active, pending_return, closed, e mais recentemente human_reviewing — humano revisando antes de a IA voltar a assumir) guardado no próprio registro da conversa. A troca de estado passa por uma rotina de transição dedicada, então nunca existe uma zona cinzenta onde IA e humano respondem ao mesmo tempo sem controle.

um registro central de handlers organizado por domínio: mensagens, conversa, contato, negócio (deal), tag, agendamento, base de conhecimento, procedimentos, qualificação, escalonamento, notificação, comércio/carrinho, frete, imobiliário, fonte de dados, zona conversacional, comandos financeiros, campos customizados, e estágio/triagem de ticket de suporte — 54 habilidades ao todo, cada execução protegida por retry e circuit breaker (se uma ferramenta começa a falhar, o sistema para de tentá-la em vez de insistir cegamente). Algumas contas verticais têm habilidades adicionais específicas do próprio segmento de negócio (ex.: consulta a sistemas externos de billing/plano), plugadas no mesmo registro central.

antes de responder, o motor busca os fatos mais relevantes já guardados sobre aquele contato (busca por relevância, não histórico bruto); depois de responder, grava novos fatos aprendidos, em segundo plano, sem atrasar a resposta ao cliente. A memória pode ser isolada por agente (cada agente só enxerga o que é dele) ou compartilhada entre agentes do mesmo contato, dependendo da configuração. Todo registro é isolado por conta — nunca vaza entre clientes. Se a busca de memória falhar por qualquer motivo, o motor monta o contexto a partir do histórico recente da própria conversa e do negócio ativo — a resposta nunca trava esperando a memória. O motor de memória hoje pode rodar com o armazenamento local (dentro do próprio banco) ou externo, dependendo da conta e de forma reversível — troca de backend sem mudar o que o cliente final percebe.

duas camadas. Uma rápida e imediata, que olha padrões de texto para decidir na hora se a conversa precisa de atenção humana urgente. Uma profunda, que roda em segundo plano a cada minuto e classifica cada mensagem por sentimento, intensidade e sinais específicos (frustração, urgência, risco de perda do cliente, entusiasmo, prontidão de compra, entre outros, até 3 sinais por mensagem). Essa leitura entra no score comportamental do contato e alimenta um painel de "pulso emocional" com a tendência da conversa, visível em tempo real para quem está atendendo.

dois formatos. Um embutido: quando um agente configurado como "consultor" está ativo numa conversa conduzida por humano, o motor injeta um prompt de coaching que orienta a condução em tempo real. Outro dedicado: um chat interativo separado, onde o colaborador pode conversar diretamente com o Mentor para tirar dúvidas, revisar abordagem ou pedir sugestão — com histórico e analytics próprios.

enquanto a conversa está com um humano, o motor gera passos de sugestão transmitidos ao vivo e grava cada sugestão concreta com seu nível de confiança. Um filtro de relevância suprime sugestões triviais e reforça a sugestão quando detecta objeção do cliente ou sinal de fechamento — ou seja, o sussurro fica mais presente exatamente nos momentos de maior risco/oportunidade da venda.

o fluxo tem um tipo de nó dedicado a essa zona; enquanto ela está ativa, a automação determinística do fluxo não dispara por cima — a IA assume aquele trecho. Uma Edge Function separada do orquestrador principal processa essas mensagens. Cada passo da zona pode ter um contrato de guardrail: ferramentas que a IA é obrigada a chamar, tipos de saída permitidos, ou até supressão forçada da resposta — uma validação programática por cima do que o modelo de linguagem gera, configurável por conta.

um montador de prompt reúne seções independentes e condicionais: contexto da campanha que originou a conversa, histórico comercial do contato, histórico da conversa atual, fatos de memória relevantes, controle de anti-repetição de saudação, campos de qualificação já coletados, dados de contato e de formulário preenchido — cada seção só entra se fizer sentido para aquela conversa específica. Suporta também idioma (português, inglês, espanhol).

a pergunta do cliente é transformada em vetor e comparada contra a base de conhecimento cadastrada (busca semântica, com limite de resultados e limiar de relevância, com tempo máximo de espera); se a busca vetorial falhar ou não achar nada relevante o bastante, cai para uma busca textual por palavra-chave, e por fim para um contexto geral — nunca fica sem resposta por falha técnica. Para agentes de vendas/e-commerce, produtos fora de estoque são filtrados da resposta.

toda chamada de IA grava um evento de uso com custo unitário e total, separando tokens de entrada, saída e os que vieram de cache (mais baratos). Cada interação também fica registrada numa trilha de auditoria com hash do prompt e da resposta e a base legal de tratamento de dado (LGPD). Esses eventos são agregados diariamente.

cada versão salva um retrato completo da configuração do agente naquele momento, quem (humano, IA ou sistema) fez a mudança, e um resumo do que mudou em relação à anterior. É possível restaurar uma versão anterior. No editor, o histórico mostra o diff calculado entre versões.

um chat de teste roda a configuração em rascunho do agente com busca na base de conhecimento real e chamada de ferramentas (até 3 rodadas de uso de ferramenta por interação), simulando o comportamento real sem expor o cliente final.

interface de configuração do agente dentro do Control Tower, com um seletor de modo de construção (dois modos no código: "Rápido" e "Avançado" — isso é o quanto de detalhe você quer configurar, não como a IA age na conversa). O modo de ação da IA na conversa é um campo separado do agente ("autônoma" ou "sussurro", com possibilidade de forçar autônoma fora do horário comercial configurado). O agente configurado aqui é o que o orquestrador carrega e executa (ver "Orquestrador de IA").

em vez de deixar a IA "decidir" a ação com base em linguagem livre, um roteador de comandos reconhece a intenção, preenche os dados obrigatórios em etapas (slot-filling) e executa a ação por uma rotina fixa e auditável, com validação do resultado antes de confirmar ao cliente. É opt-in por conta — quem não liga, continua no fluxo normal via modelo de linguagem.

4 views fixas — Minha Caixa, Fila Inteligente, Abertas, Resolvidas/Aguardando — com 5 opções de ordenação (waiting_longest, next_sla, priority, last_activity, customer_waiting; o padrão em todas as views segue o semáforo vermelho→verde→IA de quem está esperando). A prioridade de exibição usa um score calculado por conversa (tempo de espera, prioridade manual urgente/alta/normal/baixa, lead score do contato, mensagens não lidas, bônus de reabertura, e sinais de emoção da IA — ver seção de roteamento por emoção). O alternador bot↔humano é uma máquina de estados real (bot_active, pending_handoff, human_active, human_reviewing, pending_return, closed), transicionada por uma rotina central — não é um campo booleano solto. Badges de alerta no card avisam handoff, prioridade, estouro de SLA e conversa adiada (snooze). Atualização em tempo real via Supabase Realtime, sem F5.

abas de contexto lado a lado com a conversa — Informações, Histórico/Timeline, Atividades, Negócios (Deals), Reuniões, Notas, Relacionamentos, Mktzap. A aba de histórico mostra a jornada completa do contato (lifecycle, negócios, propostas) e o histórico de reaberturas daquela conversa especificamente.

paleta de macros acionável durante o atendimento. Liberado para todos os planos, sem ser recurso premium.

hub com abas de radar, regras, equipe, cliente, escalonamento, auditoria e copiloto. O radar atualiza a cada 10 segundos e também em tempo real via eventos do banco (fila, status de agente, alertas e conversas). Mostra por setor: quantos esperando, quantos em atendimento, tempo médio de espera, tempo do mais antigo na fila, tamanho máximo, modelo de capacidade do setor (total ou inteligente) e status de SLA (ok / alerta / estourado — alerta dispara 30 minutos antes do prazo de primeira resposta). Mostra o mapa de agentes por status (online/ausente/ocupado/pausa/offline) com carga atual sobre carga máxima. Gera alertas classificados por severidade (informativo/alerta/crítico) quando, por exemplo, todos os fallbacks de IA falham ou a fila transborda. Permite reatribuir uma conversa, transferir em lote entre agentes, ou redistribuir a fila inteira de um setor.

um worker roda a cada minuto via cron, lê quem está esperando (fila real: estados queued e reserved do motor de roteamento — corrigido em julho/2026 depois de um incidente em que a posição informada ficava errada porque reservas de 30s não entravam na conta) e envia a mensagem de espera pelo canal oficial, com tempo estimado, respeitando janela de 24h do WhatsApp e horário de silêncio configurado. Quando o cliente é de fato atribuído a um atendente, dispara a mensagem de "chegou sua vez". Tem cooldown de 60 minutos entre avisos de espera, deduplicação por "episódio" de fila (uma mesma conversa pode reentrar na fila depois de reaberta e ser notificada de novo, sem duplicar dentro do mesmo episódio) e um kill switch global de emergência que, se falhar a leitura, aborta o envio por segurança (fail-closed) em vez de arriscar mandar errado. Fica desligado por padrão por tenant e nasce em modo dry-run (calcula mas não envia) — precisa ser ligado e tirado do dry-run explicitamente por setor.

cada setor escolhe entre dois modelos de capacidade. No modelo total, o agente fica disponível enquanto o número de conversas abertas atribuídas a ele estiver abaixo de um limite configurado. No modelo inteligente (yaRoute), o que conta é a "carga ativa" — só as conversas em que o cliente falou por último e ainda está dentro de uma janela de inatividade configurável (padrão 30 minutos, de 5 a 240) contam contra o limite de slots do agente (padrão 8 slots, de 1 a 50), com um teto de segurança à parte para o total de conversas abertas (padrão 150). Na prática, isso significa que conversas "mortas" (cliente sumiu, aguardando) não ocupam vaga de atendimento ativo. Setores no modelo inteligente também recebem auto-resolução automática de conversas ociosas (padrão 72h, configurável) e um job de reconciliação que corrige contadores de carga que desviaram do real.

três modos de distribuição configuráveis — round robin (revezamento), menor carga (least loaded) e manual (sem atribuição automática). Comportamento configurável para quando um operador fica offline: manter atribuído, redistribuir para outro agente, devolver a conversa para a IA, ou transferir para um setor de transbordo — a ação dispara apenas na transição real para offline, nunca em pausa/ausente/ocupado. Existe também um modo sticky de fidelização de cliente ao mesmo atendente (desligado, sempre, por período, ou até resolver), com regra de contingência (esperar o atendente fidelizado ou redistribuir) para quando ele não está disponível. Regra para "ninguém online" configurável por condição (zero online, fora do expediente, feriado) com ação de enviar mensagem automática, devolver para IA ou não fazer nada.

três tipos de carteira — carteira de contas (book of business, com dono fixo), território (sempre cai no setor de transbordo, sem dono individual) e pool (dividida entre um time, vai para o membro menos carregado). Quatro modos de distribuição: round robin, menor carga, menor número de contas, menor receita. Papéis por membro: dono (owner), colaborador e visualizador (viewer). Metas configuráveis por período (semanal, mensal, trimestral, anual) sobre métricas como receita, negócios ganhos, conversas resolvidas, tempo médio de resposta, contatos engajados, taxa de conversão, MRR e NPS. Health score calculado a partir de dados reais de engajamento (volume de conversas em 30 dias), saúde dos negócios em aberto/ganhos/perdidos, cumprimento de SLA em 90 dias e recência da última interação — não é um número decorativo.

três comportamentos configuráveis por setor — fechar imediatamente (resolvida por 1 hora de segurança, depois encerra e qualquer mensagem nova abre conversa e ticket novos); resolver e fechar depois, com janela de tempo configurável (ex.: 24h) dentro da qual o cliente reabre a mesma conversa; ou apenas resolver, que reabre indefinidamente e nunca cria conversa nova sozinha. O ticket segue o mesmo ciclo de vida da conversa (aberto, em andamento, resolvido, reaberto, fechado). Conversa nova criada após encerramento fica linkada à conversa anterior.

presença por heartbeat a cada 45 segundos; se o pulso para por 3 minutos e não há atividade recente, o sistema marca offline automaticamente — se houve atividade recente mas o pulso falhou (ex.: aba suspensa), marca apenas "ausente" em vez de offline, pra não confundir throttle de navegador com saída real. Cinco estados de presença (online, ocupado, ausente, em pausa, offline), com máquina de estados que só permite sair de offline indo para online. Motivos de pausa configuráveis por tenant (padrão: almoço, banheiro, reunião, treinamento, pessoal), cada um com duração de referência que gera alerta se estourada — sem forçar retorno. Detecção de ociosidade em três modos: rígido (marca ausente ao sair da aba), flexível (não marca se o agente tem conversas ativas — pensado para operação com sistemas paralelos) ou desligado. Wrap-up (tempo pós-atendimento) configurável por setor, de 0 a 300 segundos, com expiração automática monitorada.

calcula a necessidade de equipe a partir de 4 semanas de histórico do mesmo dia da semana, com média ponderada (semana mais recente pesa mais), e apresenta três cenários — pessimista (30% acima da base), base (a média ponderada) e otimista (30% abaixo). Roda automaticamente todo dia de madrugada. Exige um mínimo de 28 dias de dados históricos; antes disso, avisa explicitamente que ainda está "aquecendo" em vez de mostrar um número não confiável.

compara métricas do agente (tempo médio de atendimento, tempo de primeira resposta, tempo em pausa) contra a própria linha de base dos últimos 14 dias para detectar anomalia; compara a semana atual contra a anterior em múltiplos fatores para classificar risco de burnout em três níveis.

quatro visões — produtividade (tempo médio de atendimento, tempo de primeira resposta, conversas por hora, ocupação percentual), tempo não produtivo/shrinkage (detalhamento de pausas), mapa de calor de volume por hora e dia da semana (média de 4 semanas), e quadrante de performance cruzando produtividade × qualidade em quatro zonas. A métrica de ocupação soma os intervalos de trabalho do agente sem duplicar sobreposição, para nunca ultrapassar 100%.

monitora o prazo de expiração de cada conversa e, antes de fechar, dispara um lembrete (nudge) para reengajar o cliente ainda dentro da janela — com nível de antecedência configurável (2h, 4h, 6h ou 8h antes de expirar). O lembrete pode ser automático ou exigir aprovação do atendente antes de enviar. Respeita horário de silêncio configurável por fuso horário, com modo de antecipar o envio antes do silêncio começar (para não deixar a janela expirar durante a noite sem aviso). Não reabre uma janela já fechada — só antecipa o aviso antes dela fechar.

cada conversa carrega um canal de origem e o Inbox filtra e exibe por canal — WhatsApp, Instagram, webchat — sem exigir telas separadas por canal.

transferência para agente específico, para setor, ou para os dois ao mesmo tempo, com checagem de permissão tanto na origem quanto no destino. Preserva o estado do atendimento: se a IA estava conduzindo, continua conduzindo após o forward; se vai para um atendente específico, passa a atendimento humano; se vai só para um setor sem atendente definido, volta para a fila. Toda transferência fica registrada com motivo, atendente de origem e destino, setor de origem e destino. Também é possível transferir em lote — esvaziar a fila de um setor, aliviar um agente sobrecarregado ou mover todas as conversas de um agente de uma vez.

painel com visão ao vivo, saúde do motor, capacidade de equipe, fluxo de distribuição, histórico de decisões recentes e regras ativas. Cada decisão de roteamento fica registrada em log de auditoria com a regra que venceu, a ação tomada, o contexto avaliado no momento e o tempo de execução em milissegundos — inclusive quando a decisão veio do roteamento por carteira.

o score que ordena as conversas na tela do Inbox (aba "prioridade") recebe pontos extras quando a IA detecta sinal de ameaça, risco de churn ou sentimento negativo na conversa — isso muda a posição da conversa na lista que o atendente vê. Este sinal não decide para qual agente ou setor a conversa é despachada — o motor de despacho que atribui a conversa a um atendente específico não usa nenhum fator de emoção em seu cálculo.

listagem com KPIs clicáveis (que funcionam como filtro), filtros avançados (canal, setor, atendente, status, handler state, motivo de encerramento, tags, período), exportação, e a possibilidade de criar uma audiência de disparo diretamente a partir do resultado filtrado. Abre o mesmo modal de conversa (com toda a timeline) usado no Inbox.

abas de Visão Geral, Agentes, IA, SLA e Motivos de encerramento (a aba "Qualidade" existe na navegação como espaço reservado — placeholder — e uma aba de Canais foi removida nesta rodada de revisão do relatório). Cobre volume de mensagens, contenção por IA, cumprimento de SLA, performance detalhada por agente e distribuição de motivos de fechamento, com filtros de período/canal/setor.

/src/pages/Deals.tsx com /src/components/deals/kanban/ (KanbanBoard, KanbanColumn, KanbanDealCard), drag-and-drop nativo (HTML5 draggable, sem lib externa). Cada tenant pode ter mais de um pipeline ao mesmo tempo (abas em PipelineTabs.tsx, criação em PipelineCreateDialog.tsx) — tabela pipelines (is_default, settings) e pipeline_stages (position, probability 0-100, sla_days, is_won, is_lost, color), com deals.pipeline_id/deals.stage_id como FK. A RPC ensure_default_pipeline() cria automaticamente 6 estágios padrão para tenant novo.

cada estágio (pipeline_stages) carrega um probability (0-100) configurável — por exemplo, "Proposta enviada" pode valer 50% de chance de ganho. Isso mudou desde a última varredura: hoje existe um projection-worker que calcula weighted_value (valor × probabilidade efetiva do estágio / 100) e grava numa camada de projeção (_projections.deals), e tanto o Kanban (src/pages/Deals.tsx) quanto o cabeçalho de resumo (src/components/deals/DealsSummaryHeader.tsx) leem esse valor pré-calculado — o segundo, inclusive, soma tcv × (probability / 100) usando a probabilidade real de cada estágio (stage.probability ?? 50). O fallback de 50% só entra em cena se a projeção ainda não tiver populado o campo (linha de segurança, não o comportamento normal).

tabela unificada closure_reasons (entity_type cobre deal_won e deal_lost), configurável por inbox_id — ou seja, um setor pode ter motivos de perda diferentes de outro. Captura via LostReasonModal.tsx e hook useClosureReasons('deal_lost', ...); a RPC lose_deal() grava lost_reason, lost_reason_code, lost_reason_note e closure_reason_id no negócio.

tabela deal_contacts (N:N entre deals e contacts) com papel (role: champion, decision_maker, influencer, blocker, end_user, economic_buyer, technical_buyer) e is_primary. Componente DealStakeholdersSection.tsx. Regra de negócio ativa: a RPC win_deal() exige que exista pelo menos um stakeholder com papel decision_maker para o negócio poder ser marcado como ganho.

tabela deal_products ligando deals a products, com quantity, unit_price, discount_percent e total_value — este último é coluna gerada pelo próprio Postgres (quantity × unit_price × (1 - discount/100)). O valor agregado do negócio (Setup, MRR, ARR, TCV) é recalculado no front a cada leitura, tanto no Kanban quanto no drawer 360.

src/components/deals/DealDrawer360.tsx abre em cima do kanban (não é navegação por URL — é estado local) e organiza em seções colapsáveis: Resumo, Detalhes do Negócio, Categoria, Stakeholders, Produtos e Serviços, Propostas vinculadas, Atividades, Notas Internas, Carteira (quando aplicável), Conversas do WhatsApp ligadas ao negócio, e Timeline de eventos. Botões de Ganhar/Perder ficam fixos no cabeçalho.

tabela accounts (type: company ou person, cnpj, industry, total_revenue, total_deals, lifetime_value) e account_contacts (N:N com role/is_decision_maker). deals.account_id e conversations.account_id referenciam a conta diretamente. Página /accounts (AccountsPage.tsx) e drawer AccountDrawer360.tsx cruzam negócios, contatos, conversas e portfólios de uma mesma empresa.

src/components/contacts/ContactDrawer360.tsx reúne Lead Intelligence (score), Qualificação, Formulários preenchidos, Dados pessoais, Canais de contato, Origem & Atribuição, Widget Web (se veio de visitante anônimo), Jornada do lead, Empresas vinculadas, Portfólio, Conversas, Negócios, Compras, Atividades, Insights de IA, Campos personalizados e Histórico de eventos.

campo contacts.lifecycle_stage, com 9 estados possíveis e transições controladas: subscriber → lead → mql → sal → sql → opportunity → customer → churned (com disqualified como saída em qualquer ponto). Transições inválidas são bloqueadas pela regra VALID_TRANSITIONS. Cada mudança de estágio grava data (became_lead_at, became_mql_at, became_sql_at, became_opportunity_at, became_customer_at) e fica registrada em lifecycle_history (histórico com origem, destino, quem mudou e o motivo), visível na linha do tempo do drawer.

existe hoje uma coexistência de dois mecanismos. O que efetivamente aparece no drawer do contato é um campo contacts.custom_fields em formato livre (chave-valor solto, tudo texto). Em paralelo, existe um sistema mais estruturado — tabelas custom_fields (com tipo: texto, número, data, booleano, seleção, seleção múltipla, URL, e-mail, telefone) e custom_field_values. O banco já foi ampliado: o enum custom_field_entity_type cobre contact, deal e conversation — ou seja, o schema já prevê campo personalizado tipado em negócio e em conversa, não só em contato. Na prática, porém, o consumo em tela (CustomFieldsBlock.tsx, usado no ContactDrawer360.tsx e no painel do inbox) hoje só cobre contatos — Deals ainda não tem tela que leia esse sistema tipado, mesmo o banco permitindo.

tabela tags (nome, cor, descrição, tipo de entidade) por tenant, ligada ao contato via contact_tags. Gerenciamento em TagsManager.tsx. Suporta marcação em massa (RPC bulk_tag_contacts) direto da Central de Leads.

aba ActivitiesTab.tsx dentro do drawer do contato, usando ActivityTimeline, ActivityModal e ActivityQuickActions (src/components/activities/), com hooks useContactActivities/useCompleteActivity.

deduplicação automática por telefone (reconhece variante com e sem o 9º dígito) já acontece na entrada da conversa, via função find_or_create_contact_v2(). Para casos não óbvios, existe merge assistido: tabela contact_merge_candidates com confidence_score calculado, RPC find_merge_candidates() para sugerir duplicatas e execute_contact_merge() para unificar (com opção de desfazer via unmerge_contact). Contato mesclado fica marcado (is_merged, merged_at, canonical_contact_id).

Edge Function scoring-processor roda em quatro modos configuráveis por tenant — behavioral (comportamento observado), questions (respostas a perguntas de qualificação), icp_description (avaliação semântica por IA contra uma descrição textual do cliente ideal) e hybrid (combina os dois: pega o maior entre a nota de IA e a nota comportamental). O modo comportamental é 100% SQL, sem IA — soma 7 fatores com peso fixo (engajamento 25, recência 20, perfil 15, emoção 15, canal 10, negócio 10, ciclo de vida 5) e recalcula em lote a cada 10 minutos via cron. O modo por IA roda via fila assíncrona quando um evento relevante acontece na conversa. Aparece no drawer do contato como badge (LeadScoreBadge.tsx) com detalhamento por fator (LeadScoreBreakdown.tsx).

duas telas: LeadsCentral.tsx (KPIs, filtros avançados, segmentos salvos, tabela paginada, ações em massa — marcar tag, mudar estágio de ciclo de vida, exportar CSV, criar audiência de campanha a partir do filtro) e LeadsPage.tsx (visão unificada de leads vindos de todas as origens — Meta, Widget, Connect, orgânico — com indicador de etapa da jornada). O filtro (_leads_filtered_contacts) suporta cerca de 30 parâmetros: score, ciclo de vida, tags, faturamento, pedidos, canal, dono (derivado da conversa mais recente), portfólio, datas, opt-out. Módulo habilitado por tenant via feature flag (module.leads_central).

não existe um motor de "distribuição de leads" dedicado a vendas. O que existe é o motor de distribuição de conversas do inbox (fila de roteamento, considerando status e capacidade do atendente). A Central de Leads deriva o "dono" do lead lendo o assigned_to da conversa mais recente do contato — é uma leitura, não uma atribuição própria de CRM.

modelo de template com seções fixas — capa, contexto, solução, escopo, investimento, cronograma, termos, próximos passos e assinatura (src/components/proposals/editor/ProposalContentEditSheet.tsx, editor de texto rico via TipTap). A lista de preços vem dos itens de proposta (ProposalItem[]), que podem ser pré-populados a partir dos produtos já anexados ao negócio. Layouts disponíveis: landing, executivo, moderno, clássico, minimal, bold. Suporta versionamento (version, parent_version_id, version_notes).

rota pública /p/:hash (ProposalPublicView), resolvida pela Edge Function get-public-proposal (com limite de 30 requisições/minuto por IP contra abuso). Registra first_viewed_at, last_viewed_at, view_count, tempo total de visualização e — por sessão — dispositivo, seções vistas e profundidade de rolagem. Cada carregamento emite um evento proposal.viewed.

cliente preenche nome, e-mail e aceite dos termos; recebe um código de verificação por e-mail (via Resend) antes de confirmar. Ao confirmar, a Edge Function accept-proposal grava status = accepted, com nome, e-mail, IP e user agent de quem aceitou, além dos itens aceitos. Re-checado no main: o gap é mais sério do que "conferido só no navegador" — o código é gerado no próprio navegador do cliente (ProposalAcceptDialog.tsx), guardado em localStorage, e a comparação de "código confere" é feita inteiramente no front (localStorage vs. o que o cliente digitou). A Edge Function send-proposal-verification só recebe o código já pronto do front e o reenvia por e-mail — não grava esse código em nenhuma tabela do servidor. E a Edge Function accept-proposal aceita verification_code como campo opcional no schema e nunca chega a lê-lo: o UPDATE proposals SET status = 'accepted' roda sem checar código nenhum. Ou seja, dá pra chamar accept-proposal direto, pulando toda a etapa de código, e a proposta é aceita do mesmo jeito.

src/pages/ProductsCatalog.tsx — CRUD completo com preço unitário, faixa de preço aberta (mínimo/máximo, para negociação), categoria, marca, imagem, disponibilidade e SKU. Sincroniza com plataformas externas (source_platform, sync_status) e com o catálogo de produtos da Meta/WhatsApp (meta_catalog_id, meta_product_id). Marca se o produto está indexado para a IA usar em conversa (ai_indexed). Não há controle de variantes nem de estoque quantitativo no catálogo interno — só disponibilidade textual.

carrinho (Cart/CartItem) com status (ativo, convertido, abandonado, expirado), origem (WhatsApp, web, manual, catálogo do WhatsApp), cupom de desconto e totais recalculados automaticamente. Ao fechar, vira um pedido (orders) — tratado como "fato de receita" separado do pipeline de negócios: status (pendente, confirmado, reembolsado, parcialmente reembolsado, cancelado), origem (Shopify, Bling, Hotmart, Kiwify, Nuvemshop, proposta, negócio, manual, API, Connect), com campos de MRR/ARR para receita recorrente. Métodos de pagamento suportados: Pix, cartão de crédito, cartão de débito, boleto, dinheiro, transferência, link de pagamento e débito em conta. Não há cálculo de frete próprio — quando o pedido vem de loja integrada, o status de envio é apenas espelhado da origem.

adaptadores dedicados para WooCommerce, Shopify e Nuvemshop (supabase/functions/_shared/commerce-sync/), cada um implementando a mesma interface de sincronização — busca e normaliza produtos, clientes e pedidos. Edge Functions commerce-catalog-sync e commerce-order-sync rodam a sincronização periódica. Desde a última varredura, o conjunto de funções cresceu: commerce-catalog-feed (feed de catálogo), commerce-reconciliation (concilia divergência entre o pedido na loja de origem e o pedido espelhado no yapt.) e commerce-knowledge-indexer (indexa catálogo/pedido pra uso da IA).

OAuth real com o Google (supabase/functions/_shared/google-calendar.ts), tokens de acesso e de renovação armazenados de forma criptografada (user_oauth_tokens), com renovação automática. Edge Function calendar-sync mantém a sincronização.

src/types/sales-playbook.ts define quatro blocos: Produto (o que vende, diferenciais, casos de sucesso), Qualificação (perguntas por categoria — dor, volume, autoridade, orçamento, tempo), Pipeline (ação recomendada por estágio) e Situações (tratamento de objeção, sinal de compra, script de recuperação). Wizard de criação em 5 passos (usePlaybookBuilder.ts), salvo na tabela sales_playbooks. Quando um agente de IA tem um playbook vinculado, o orquestrador injeta esse conteúdo direto no prompt do Mentor durante a conversa — não é um documento estático, é consultado em tempo real pela IA que está atendendo.

campo SalesMethodology no builder do agente de IA (src/types/sales-agent-config.ts), consumido pelo gerador de prompt (src/lib/prompt-generator.ts) — cada metodologia molda como a IA conduz a qualificação na conversa. É um mecanismo diferente do módulo de Playbooks (acima), embora complementar: a metodologia define o "como perguntar", o playbook define "o que perguntar e o que fazer depois".

src/pages/AnalyticsSales.tsx, em RPCs SQL diretas (não Edge Functions dedicadas): visão geral (get_vendas_overview_v1), negócios (get_negocios_detail_v1), vendas B2C (get_vendas_b2c_detail_v1), ranking de vendedores (get_vendedores_ranking_v2) e atribuição (get_atribuicao_funnel_v1) — esta última com navegação em drilldown: Campanha → Conjunto de anúncios → Anúncio, mostrando ROAS e CAC em cada nível, além de contagem de vendas sem atribuição identificada. O motor de atribuição foi reescrito desde a última varredura: mudou de cálculo linha-a-linha para uma abordagem set-based (20260609065906_atribuicao_set_based_rewrite.sql) e passou a ler de uma camada de snapshot pré-calculada em vez de recalcular a cada requisição (20260613212041_attribution_reports_read_snapshot.sql) — melhora de performance, sem mudar o conceito exposto na tela.

mudar o estágio de um negócio passa pela RPC move_deal_stage, que só emite um evento genérico (emit_event('deal.stage_changed', ...)) — não há uma tabela relacional dedicada tipo deal_stage_transitions para consultar o caminho percorrido pelo negócio. Isso é diferente do que já existe em outras partes do produto: conversas têm sua própria tabela de histórico de transição (conversation_state_transitions), tickets de suporte também (support_ticket_stage_transitions) — mas Deals ainda não. Já existe, porém, sinal de que está no radar: a tabela required_fields_rules (que hoje só cobre closure_reason na prática) já reserva deal_stage_transition como tipo de alvo para uma Fase 2 futura — a tabela em si (deal_stage_transitions) ainda não foi criada.

src/pages/Sales.tsx (identificado no próprio código como "yaRevenue"). Reúne receita de origens diferentes (comércio eletrônico, deals ganhos, propostas aceitas) numa tabela única, com filtro e seleção de linhas, exportação em CSV e criação de audiência de campanha a partir dos pedidos selecionados (useCreateAudienceFromOrders). Também traz uma aba de faturas ligadas a contrato (SalesInvoicesTab, do módulo de Contratos — ver seção seguinte).

página ContractsPage.tsx (carteira de contratos do gestor) e uma tela de configuração dedicada em /settings (SalesContracts.tsx, dentro de Configurações → Vendas → Contratos). Modelo de dados: contracts, contract_parties (as partes do contrato), contract_items, contract_types (tipos configuráveis), contract_invoices (faturas ligadas ao contrato) e, específico do vertical de espaços, contract_space_entitlements/contract_dedicated_spaces. Mudança de estado do contrato é registrada em contract_events. No drawer de Contas (AccountDrawer360), o contrato ativo da conta aparece via hook useAccountActiveContract.

o wizard foi reconstruído (v2) em 5 passos — Básico, Público, Como & quando, Conteúdo, Revisar — em CampaignWizardV2.tsx (BasicStep, AudienceStep, HowWhenStep, ContentStepV2, ReviewStepV2). A audiência aceita 5 modos definidos no tipo AudienceMode (src/types/campaign.ts): smart_picks (audiências prontas com contagem ao vivo, em SmartPicks.tsx), manual (seleção contato a contato via ContactPicker), filter (filtro dinâmico via SegmentBuilder), import (upload de CSV processado por campaign-import-worker, 928 linhas) e saved (audiência salva via SavedAudiencePicker) — todos ainda montados por AudienceBuilder.tsx, reaproveitado dentro do AudienceStep do wizard v2. O backend materializa os destinatários em campaign_sends via campaign-scheduler, em chunks de 100 com auto-continuação se a Edge Function estourar o timeout.

SegmentBuilder.tsx e SimpleFilterBuilder.tsx constroem uma árvore FilterRules (grupos AND/OR de FilterCondition) sobre 6 entidades — contact, conversation, deal, campaign_history, ad_campaign, tag — com 13 operadores (eq, gt, contains, in, is_empty, etc., em src/types/campaign.ts). O catálogo FILTER_ENTITY_FIELDS expõe campos prontos: estágio do ciclo de vida, lead score, status do deal, origem do contato (Meta Lead Ads, CTWA, orgânico), status de conversa anterior, UTMs de campanha. Segmentos podem ser static (snapshot fixo) ou dynamic (recalcula a cada uso), com contagem cacheada (cached_count, cached_count_at).

no passo "Como & quando" do wizard v2 (HowWhenStep.tsx), o operador escolhe entre "Envio único" (1 número) e "Broadcast" (2+ números), com um cartão por canal mostrando qualidade e templates aprovados (ChannelCard.tsx). Em modo broadcast, a divisão do público entre os números é configurável em DistributionEditor.tsx — igualitária (split automático) ou personalizada (percentual por número, com "rebalancear o resto"). Independente do modo, o envio pode ser "agora", agendado para uma data, ou em ondas (2 a 5 lotes, cada uma com seu próprio percentual e horário, WavesEditor.tsx). No submit (useCampaignWizardV2Submit.ts), o público é particionado primeiro por número (partitionWeighted) e depois por onda dentro de cada número — resultando em N números × M ondas = até N×M campanhas-filhas agrupadas sob um broadcastGroup, cada uma rodando com o throttle e a proteção de tier do seu próprio número (ver seções de ritmo/pausa por tier abaixo). Um envio que resolve para um único filho (1 número, 1 onda) não é agrupado — segue como campanha simples. O modo broadcast está atrás de uma feature flag por tenant (tenants.settings.broadcast_fleet, useBroadcastFleet.ts) — só aparece na tela quando ligado para o tenant.

no passo "Conteúdo" do wizard v2 (ContentStepV2.tsx), cada número pode ter, além do template principal, uma lista ordenada de templates "reserva" (fallback) com variáveis próprias. Alternativamente, o operador pode escolher o modo "rotação" (WizardV2ContentMode = 'rotation', RotationTemplateGrid.tsx): um pool de N templates marcados que revezam entre si desde o primeiro envio, diluindo volume por template (campaign.metadata = { template_rotation: true, template_pool: [...] }, parseado por _shared/campaign-rotation.ts). No backend, campaign-scheduler lê esse pool e distribui os destinatários entre os templates (pickPoolEntry); campaign-drain monitora falhas de envio — se detecta indício de template pausado/rejeitado pela Meta, chama rotateOutBlockedTemplate para trocar automaticamente para a próxima entrada ativa do pool (reserva ou próximo da rotação) e registra o evento campaign.template_switched na timeline da campanha; se o pool se esgota, a campanha é pausada com motivo explícito.

cada campanha (ou cada número, em modo broadcast) define sends_per_minute e budget_limit opcional no passo "Como & quando" (HowWhenStep.tsx). Durante o envio, campaign-drain respeita o menor entre o ritmo configurado pelo tenant e o teto por tier Meta (TIER_SENDS_PER_MINUTE: 400/min no tier 1K, 600 no 10K, 800 no 100K, 1000 no ilimitado). O custo real (actual_cost) é atualizado por envio via calculateSendCost, que busca a tabela de preço (get_template_rate RPC) e cai para valores fixos de fallback (Marketing R$0,4485, Utility R$0,0575, Authentication R$0,0403) se a rate card não responder. Ao atingir budget_limit, a campanha pausa sozinha (pauseCampaignIfNeeded) e emite campaign.budget_reached.

CampaignDetailPage.tsx usa useCampaignRealtime, que assina mudanças via Supabase Realtime (postgres_changes) nas tabelas campaigns_outbound e campaign_sends, com invalidação de cache throttled em 1s e fallback de polling a cada 30s caso o Realtime caia. Os contadores (total_sent, total_delivered, total_read, total_replied, total_bounced, total_failed, total_opted_out) são atualizados de duas formas: incremento atômico no envio (increment_campaign_counter RPC dentro de campaign-drain) e atualização de status de entrega/leitura via campaign-events-processor, alimentado pelos webhooks de status da Meta (webhook-bsp-platform).

dois mecanismos, os dois checados em toda tentativa de envio dentro de campaign-drain. (1) campaign_blocklist — tabela por tenant com telefone normalizado, gerida em /settings via BlocklistPage.tsx (adicionar manual, motivo, importação e exportação em massa via blocklist-import/blocklist-export); todo envio WhatsApp checa o telefone do contato contra o Set pré-carregado em memória para o lote inteiro (evita N+1). (2) Opt-out por ciclo de vida — se contacts.lifecycle_stage = 'disqualified', o envio é marcado opted_out e conta separado (total_opted_out), sem consumir tentativa. Ambos bloqueiam o envio antes de qualquer chamada à Meta.

dentro do próprio campaign-drain (não é feature exclusiva de follow-up) — antes de processar o lote, a função chama a RPC is_quiet_hours(p_tenant_id) uma única vez por ciclo; se verdadeiro, todo envio pendente daquele tenant é reagendado como pending em vez de disparado (error: "quiet_hours"). Em paralelo, batch_check_frequency_cap(p_contact_ids, p_tenant_id) retorna, para cada contato, se ele já recebeu o número máximo de mensagens permitido no período — se não, o envio é marcado skipped com last_error: "frequency_cap".

channel_meta_tiers guarda, por número, current_tier (tier_1k/tier_10k/tier_100k/tier_unlimited), tier_limit, messages_sent_today e quality_rating (GREEN/YELLOW/RED). Em cada envio, campaign-drain verifica: se quality_rating === 'RED', a campanha é pausada (pauseCampaignIfNeeded, motivo "Meta quality rating RED") e o envio reagendado; se messages_sent_today atinge 90% do tier_limit (Math.floor(tier.tier_limit * 0.9)), a campanha pausa por "Meta tier limit reached (90% threshold)". Todo canal WhatsApp novo ganha automaticamente um registro tier_1k (limite 1.000/dia) via trigger auto_create_channel_meta_tier na criação do channel_instance. Rate limit devolvido pela própria Meta também aciona cooldown por canal com backoff exponencial (até 300s) e contagem de tentativas (MAX_RATE_LIMIT_RETRIES = 10).

campaign-drain calcula uma concorrência efetiva por lote com base no tier mais restritivo presente no batch (TIER_CONCURRENCY: 5 simultâneos no tier 1K, 8 no 10K, 12 no 100K, 15 no ilimitado) — isso existe para não estourar limites de infraestrutura da própria Supabase, separado do limite da Meta. O ritmo por minuto (TIER_SENDS_PER_MINUTE) também limita o sends_per_minute configurado na campanha ao teto do tier. Entre chunks de envio, há um delay calculado ((60000/sends_per_min) * concorrência, capado em 10s) para não passar do ritmo-alvo.

CampaignSequence tem passos (CampaignSequenceStep) de 4 tipos (SequenceStepType): send (envia template), wait (aguarda N horas — wait_duration_hours), condition (avalia regra e desvia para true_next_step/false_next_step) e split (weighted branch, definido no tipo e configurável na UI, mas não implementado no runner, ver Divergências). O campaign-sequence-runner roda a cada 2 minutos via pg_cron, processa até 20 inscrições (campaign_sequence_enrollments) por ciclo cujo next_action_at já passou, e só trata step_type igual a send, condition ou wait. Para passo send, chama send-active-message e avança; para condition, hoje a única condição avaliada é replied (o contato respondeu desde a inscrição) — se exit_on_reply estiver ligado na sequência, a inscrição sai automaticamente ao detectar resposta inbound.

o wizard v1 chegou a exibir um banner prometendo "distribuição em 7 dias" — esse banner não existe mais: o wizard v1 inteiro (CampaignWizard.tsx, CampaignSetupStep.tsx) foi removido do código e substituído pelo wizard v2, cujo BasicStep.tsx registra em comentário que "warm-up banner" é conceito exclusivo do v1, descontinuado. Hoje não há, em lugar nenhum da tela de campanhas, nenhuma promessa de agendamento de envios ao longo de dias. O que existe de fato, e continua em produção, é o throttle por tier já descrito acima (400 envios/min no tier 1K, concorrência 5, pausa em 90% do limite diário de 1.000 mensagens) — proteção real, mas reativa (limita o ritmo), não uma rotina que planeja/distribui envios ao longo de uma janela de dias. A subida de tier em si continua sendo controlada pela própria Meta, não pelo yapt.

SendTimeHeatmap.tsx busca até 10.000 envios recentes do tenant (campaign_sends, sent_at/read_at/status), agrupa por dia da semana (segunda a domingo) × hora (7h–20h) e calcula a taxa de leitura por célula. É puramente descritivo — mostra o histórico agregado de todas as campanhas do tenant, não recomenda nem agenda nada automaticamente, e não é por contato individual: é uma média de toda a base.

TemplateBuilder.tsx monta os componentes do template (header, body com variáveis {{1}}/nomeadas, footer, botões) e valida antes de enviar para a Meta (validateTemplate). As 3 categorias Meta são de fato as usadas no código ('AUTHENTICATION' | 'MARKETING' | 'UTILITY', em template-sync/index.ts), com preço por categoria vindo da rate card (get_template_rate) ou do fallback fixo. template-sync envia o template tanto pela credencial WAENT quanto pela BSP Platform e grava resultado; template-status-sync mantém o status (approved/rejected/pending) sincronizado com a Meta.

tabela dedicada template_versions (template_id, version_number, components, status, waent_response, change_reason, changed_by), populada a cada edição relevante do template, com isolamento por tenant via RLS.

TemplateAnalytics.tsx + hook useTemplateAnalytics.ts agregam template_analytics/template_send_logs por período, calculando taxa de conversão e custo por conversão (totalCost / totalConversions).

WAFlowBuilder.tsx monta as telas do Flow (WAFlowScreenCard, WAFlowComponentEditor, WAFlowComponentPalette) com preview simulando o celular (WAFlowPhonePreview.tsx) e mapeamento de resposta (WAFlowResponseMapping.tsx). A Edge Function wa-flow-manager tem uma ação dedicada publish que envia o Flow para a API da Meta. Existe galeria de templates prontos de Flow (WAFlowTemplateGallery.tsx, hook useWAFlowTemplates) para começar de um modelo em vez do zero, e teste do Flow antes de publicar (WAFlowTestDialog.tsx).

MetaConnections.tsx cuida do OAuth com a Meta e vínculo da WhatsApp Business Account; Channels.tsx lista canais, permite ativar/desativar e definir prioridade entre eles; MetaWebhooks.tsx cuida da configuração de webhook. Cada canal WhatsApp criado ganha automaticamente um registro de tier (channel_meta_tiers, tier inicial tier_1k), que é a base para todo o throttle e pausa automática descritos acima. O indicador de qualidade do número (quality_rating) aparece tanto no wizard de campanha quanto no painel yapt. Play (YaHomeWhatsAppWorld.tsx).

AIOptimizerPage.tsx renderiza 6 cards, todos marcados explicitamente no código como status: 'planned' — inclusive "Melhor Horário de Envio" ("IA analisa quando seus contatos estão mais ativos e sugere o horário ideal para cada segmento"). Não há nenhuma lógica de IA rodando por trás — é uma tela de visão de produto ("Como vai funcionar"), sem coleta, sem modelo, sem sugestão real aplicada a uma campanha. Inalterado desde a última varredura.

cada tenant configura um ou mais support_pipelines, com estágios (support_pipeline_stages) tipados como novo, em andamento, aguardando cliente, monitoramento, resolvido, encerrado ou automático. Cada estágio pode ter SLA em horas, opção de pausar a contagem do SLA (por exemplo enquanto espera resposta do cliente), exigir nota obrigatória para avançar, e ser marcado como estágio terminal. Um trigger de banco cria o ticket automaticamente a partir do inbound — o atendimento não nasce "solto" numa caixa de entrada, nasce já dentro de um pipeline.

cada ticket recebe um número de protocolo sequencial por empresa (ticket_number), prioridade (crítica, alta, normal, baixa), status (aberto, resolvido, encerrado, reaberto), marca de primeira resposta (first_response_at) e cálculo de SLA estourado (sla_breached) com tempo decorrido e pausas registradas. Um semáforo visual (verde / amarelo a partir de 75% do prazo / vermelho) mostra o risco de estouro de cabeça, sem precisar abrir o ticket. O motivo de encerramento é obrigatório desde que essa regra entrou em vigor — o atendente não fecha um ticket sem categorizar por quê.

cada setor (inbox) escolhe seu modo de criação de ticket; conversas sem ticket entram numa fila de triagem, com sugestões de vínculo; a reabertura de conversa também passa a considerar o modo de triagem configurado, com janela de regras própria (v2). A IA tem ferramentas dedicadas de triagem de ticket para uso interno.

o atendente busca a empresa por CNPJ (ou cria contato novo), escolhe canal, etapa, nota e categoria, e o sistema cria uma conversa vazia junto com o ticket, já nascendo em fluxo humano. Serve para registrar atendimento que começou por telefone, e-mail ou presencialmente, mas precisa entrar no mesmo pipeline de suporte.

cada ticket guarda parent_ticket_id e profundidade (depth); a árvore é exibida de forma recursiva num painel dedicado, permitindo criar sub-ticket a partir de qualquer nó.

tabela dedicada (ticket_conversations) marca cada conversa vinculada com um papel — principal ou vinculada — e a busca de conversa para vincular usa uma função de busca real no lugar de colar identificador manualmente.

o modo espelho mantém o atendente original visível/presente enquanto o nível superior atua junto; o modo transferência passa o ticket adiante. Cada escalação tem status (pendente, aceita, resolvida, devolvida, cancelada), nível, e pode ser disparada automaticamente por regra de SLA (escalation_rules). Existe SLA dedicado para o segundo nível (n2_sla_minutes, n2_sla_breached) e uma timeline visual da escalação.

cada reabertura grava a origem (lista da caixa de entrada, modal da conversa, histórico do contato, quadro de tickets, busca, API ou reabertura automática pelo próprio inbound), o motivo, quem reabriu, o status anterior e o estado de atendimento anterior.

motivos de encerramento (closure_reasons) são definidos por setor/caixa de entrada; a IA também classifica automaticamente o motivo, e há uma aba de relatório que cruza a classificação da IA com o motivo escolhido pelo humano para medir a acurácia dessa classificação automática.

é uma configuração de comportamento do agente de IA (behaviors.closing), com mensagem de confirmação customizável, opção de confirmar depois de usar ferramentas e encerramento automático na resolução. Nasce desligada por padrão — cada agente precisa ativar explicitamente.

cinco abas dedicadas — Visão Geral, Operações, Pipeline (reaproveita o componente de pipeline usado em outros relatórios do produto), Escalações e Motivos — cada uma consultando as tabelas de tickets, SLA e escalação diretamente.

a IA tem ferramentas específicas para mover o ticket de estágio no pipeline, encerrar a conversa com motivo de resolução (resolvido, não qualificado, sem resposta, spam), pedir humano com motivo e prioridade, transferir para outra fila, e disparar formulários de WhatsApp (inclusive de pesquisa de satisfação).

os documentos e trechos indexados (knowledge_documents, knowledge_chunks) ficam organizados por fonte (knowledge_sources) e coleção (knowledge_collections), permitindo escopar conteúdo por persona ou contexto. Procedimentos (knowledge_procedures) modelam passo a passo com pré-requisito e caminho alternativo (fallback) em caso de exceção. Já existe volume real de conteúdo em produção, em dezenas de contas de cliente diferentes.

os documentos são divididos em trechos e transformados em vetor (embedding OpenAI text-embedding-3-small), armazenados com pgvector; no momento da conversa, a IA busca os trechos mais relevantes semanticamente para montar a resposta (pipeline de RAG dedicado no orquestrador).

o painel calcula, entre outros fatores, a "frescor" do conteúdo olhando a data de atualização dos documentos nos últimos 90 dias, além de cobertura, precisão e desempenho — cálculo feito em tempo real sobre a própria tabela de documentos, não um número fixo.

tem três camadas. A primeira — detecção de lacuna — é um trigger de banco (yalearner_detect_gap()) que escuta eventos de handoff/escalação, emoção negativa, baixa confiança da IA e resposta humana longa (proxy de lacuna), e grava um sinal (kb_gap_signals) a cada ocorrência; essa camada está de fato rodando em produção, com 215.803 sinais acumulados desde abril de 2026, em ritmo contínuo até a data desta varredura, em múltiplas contas de cliente. A segunda camada (yalearner_clusterer, agrupar sinais em kb_gap_clusters) e a terceira (yalearner_draft_generator, gerar rascunho em kb_drafts a partir do cluster) rodam via pg_cron (03h e 04h, diariamente) — mas, conferido diretamente no histórico de execução do cron em produção nos dias 29, 30 e 31/07, todas as execuções recentes falharam com o mesmo erro: unrecognized configuration parameter "app.settings.service_url". Só existem 2 rascunhos no banco até hoje, ambos de abril/maio (antes desse erro se instalar) — nenhum novo desde então. Ou seja: o funil está com a torneira de entrada aberta e o cano de saída entupido por um erro de configuração pontual, não por falta de sinal ou de demanda.

o Prompt Lab é um changelog: lista as últimas versões de prompt de qualquer agente, com autor identificado (humano, yaCreator ou sistema), diff entre versões e filtro por autor — reaproveita o mesmo dado de versionamento (agent_prompt_versions) usado no builder de agentes, não é uma tela nova de teste de prompt isolada. O Coaching é um painel de feedback de qualidade: lista conversas avaliadas, com filtro, estatísticas agregadas e um painel de detalhe por conversa; tem 513 registros reais de feedback de coaching já gravados em produção (agent_coaching_feedback).

cada pesquisa (surveys) pode ser configurada para disparar automaticamente ao finalizar o ticket/conversa (trigger_on_finalize), com atraso de envio configurável em minutos, cooldown configurável em dias (por contato, vale para qualquer pesquisa — evita cansar o mesmo cliente), janela de resposta configurável em horas, kill switch em dois níveis (global e por tenant) e um serviço único de despacho que garante, por constraint de banco, no máximo um envio por conversa fechada — mesmo se o gatilho nativo e um nó do yaFlows disparassem ao mesmo tempo. O envio usa a infraestrutura de WhatsApp Flow já existente (formulário nativo da Meta): se a janela de 24h está aberta, manda o Flow direto; se está fechada, manda um template de utilidade com botão para abrir o Flow. A parte mais delicada do mecanismo é a interceptação da resposta: uma função isolada (checkSurveyInterception) decide, antes de qualquer outra coisa, se a mensagem recebida é a resposta de um Flow de pesquisa válido (token, prazo, tenant e identidade do respondente todos batendo); se for, ela grava a nota na timeline sem reabrir o card — só texto livre (um desabafo do cliente, por exemplo) reabre a conversa normalmente. Qualquer falha na checagem cai para o comportamento padrão (abre o card), nunca perde mensagem. Há também um worker de análise de sentimento sobre o comentário livre da pesquisa, e um nó dedicado ("Enviar pesquisa") para disparar pesquisa também a partir do yaFlows, além da própria régua nativa pós-atendimento. Em produção, o volume acumulado de envios já passa de 9.600 (a maior fatia expirada, seguida de falha de envio, depois respondida, cancelada e pulada por cooldown).

quatro abas dedicadas de analytics (AnalyticsSurveys.tsx) — Visão Geral (score e tendência), Por Caixa, Por Agente e Respostas — cruzando o resultado (nota/comentário) com quem atendeu (agent_id), o setor (inbox_id) e se a resolução foi por IA, humano ou híbrida, tirado de um retrato do estado do atendimento no momento do fechamento. Também alimenta contact.metadata.csat_score no perfil do contato, para consulta rápida sem abrir relatório.

o motor de follow-up roda em ciclo curto e permite regras com contexto support, filtráveis por pipeline, estágio e tempo de inatividade — a capacidade técnica existe e está pronta para uso, mas, até o momento desta varredura, nenhuma regra configurada na base de clientes usava o contexto de suporte.

o JournWay é dono do dado de empresa/conta; o yapt. é dono do dado de atendimento (conversa, ticket, IA). A sincronização acontece via fila de saída (outbox) com upsert idempotente por identificador externo e uma regra de estado que nunca reabre no destino algo que já foi fechado por um evento mais recente. Hoje o escopo está restrito à própria operação interna da New Way, habilitado por uma configuração específica de tenant.

roda em dois processos separados por cron. O detector (yafollowup-engine, a cada 2 minutos) varre as réguas ativas por tenant, chama get_idle_conversations para achar conversas paradas e agenda o passo 1. O disparador (yafollowup-sender, a cada 1 minuto) reivindica execuções agendadas (FOR UPDATE SKIP LOCKED, sem risco de dois ciclos disparando a mesma), gera a mensagem, envia e agenda o próximo passo.

Detecção de inatividade: o relógio de inatividade agora é resetado tanto por mensagem do cliente quanto por mensagem manual de um atendente humano (direction = 'outbound' AND sender_type = 'user') — antes só contava a última mensagem do cliente, o que fazia a régua disparar em cima de uma conversa que um humano acabara de responder. O filtro pode ser restrito por setor, canal (WhatsApp, Instagram ou Messenger — ver "Multi-canal" abaixo), funil, estágio do pipeline, se a conversa está com IA/humano/ambos, e por tags do contato (incluir ou excluir).

Sequência e prioridade: cada régua tem uma sequência de passos com atraso próprio (delay_minutes) e modo de mensagem — fixa, sorteio entre variações, template aprovado de WhatsApp (janela de 24h fechada) ou instrução para a IA gerar o texto lendo o histórico real. Quando duas ou mais réguas ativas poderiam capturar a mesma conversa no mesmo ciclo, vale prioridade explícita (slider 1-10 configurável por régua, editor FollowUpPriorityField) e, em empate, a régua mais específica (com filtro de estágio) vence; a conversa fica "reivindicada" pela régua de prioridade mais alta no ciclo mesmo que essa régua não chegue a agendar (por rate limit ou cooldown), então uma régua de prioridade menor não pega a sobra.

Travas antes do disparo: limite de envios por contato/mês (padrão 5, configurável de 1 a 30) e horário de silêncio — ver seção dedicada abaixo. No instante do disparo há um novo gate consolidado (should_send_followup, chamado antes de qualquer geração de mensagem) que revalida: conversa ainda aberta, conversa não "adiada" (snooze), régua ainda ativa, o responsável atual (IA/humano) ainda bate com o filtro da régua, e — quando o tenant tem tabela de consentimento — o contato não optou por sair. Qualquer falha nesse gate é tratada como decisão definitiva (cancela); erro de rede/banco é tratado como transitório (tenta de novo, nunca cancela por instabilidade).

Cancelamento automático — não é só supressão pontual. Existe uma camada de 4 gatilhos independentes no banco que cancelam TODOS os passos futuros ainda agendados de uma régua, não apenas o disparo do instante:

1. Cliente responde (trigger em messages, qualquer mensagem inbound do contato) — cancela tudo que estava scheduled/retry para aquela conversa, e ainda marca as execuções já enviadas como "respondida", registrando a latência da resposta.

2. Negócio é ganho ou perdido (trigger em deals.stage_id) — cancela a régua daquele deal, condicionado ao toggle stop_conditions.on_deal_won (ligado por padrão).

3. Conversa é transferida (trigger em conversations.inbox_id) — cancela, condicionado a stop_conditions.on_transfer (ligado por padrão).

4. Um passo falha (cascata) — se um passo intermediário falha definitivamente, os passos seguintes da mesma régua/conversa são cancelados em vez de continuar tentando uma sequência quebrada.

Além disso, no instante exato do disparo ainda existe a checagem pontual: se a resposta chegou entre o agendamento e o envio efetivo, o envio é suprimido e registrado como "suprimido — lead respondeu durante o disparo".

Réguas com filtro de pipeline/estágio também têm uma trava própria: se o negócio muda de estágio, muda de funil, é fechado ou é apagado, a sequência para (o cancelamento por deal won/lost acima cobre só ganho/perdido; este cobre qualquer saída do escopo configurado).

O ciclo da régua só reabre depois que a conversa é marcada como resolvida; sem essa resolução, o mesmo ciclo não reaciona a régua. Ao final da sequência sem resposta, a régua pode executar uma ação com atraso configurável (padrão 24h): nada, encerrar a conversa (pelo caminho oficial de encerramento, com motivo registrado), marcar deal como perdido (só em vendas), tag "frio" ou transferir para uma fila/operador específico (com cooldown próprio para não repetir a transferência).

Falhas e novas tentativas: execuções que falham (erro transiente, LLM incompleto, canal indisponível) entram em retentativa com backoff (1min, 5min, 15min) até 3 tentativas antes de ir para "falhou" definitivamente, e cada tentativa fica registrada. Um checador de saúde roda a cada ciclo do detector e alerta a equipe internamente quando a taxa de terminações anormais (falha, canal não entregável, template só-WhatsApp) de um canal passa de 20 casos e mais de 50% do volume na última hora — pensado para nunca mais deixar um travamento de régua passar despercebido por dias.

Multi-canal: a régua não é mais exclusiva de WhatsApp. O escopo de canais é configurável na tela (WhatsApp, Instagram, Messenger — pelo menos um precisa ficar marcado) e o disparo resolve o destino certo (WhatsApp via telefone, Instagram via ID do Instagram, Messenger via PSID) e o identificador correto do contato para cada canal. Quando a régua inclui um canal sem janela de 24h/template (Instagram, Messenger), a tela avisa se algum passo da sequência ultrapassa a janela de resposta gratuita.

quando uma régua respeita o silêncio e o horário calculado do próximo passo cai dentro da janela, a execução não é descartada — é reagendada para o instante em que o silêncio abre (mais um espalhamento aleatório de até 15 minutos, para não sincronizar todas as execuções represadas no mesmo segundo). Isso vale tanto para o passo 1 (checado pelo detector) quanto para os passos seguintes (checado pelo disparador antes de gerar/enviar cada passo) — a régua não perde o passo por ele ter caído na madrugada.

editor com dezenas de tipos de nó disponíveis no código (mensagem, template, espera, espera por resposta, condição/branch, IA, tag, webhook, saída, inscrever/remover de outro fluxo, ação de CRM, WhatsApp Flow, botões e listas interativas, e-mail, notificação, Instagram, envio de pesquisa, espera por evento, agendar em data, espera por horário comercial, switch, teste A/B, decisão por IA, checagem de meta, conectar/desconectar IA, qualificar por IA, enriquecer por IA, zona de cobertura de IA, atualizar contato, criar atividade, mover estágio de deal, requisição HTTP, gatilho Zapier, ir para nó, sub-fluxo, execução paralela) — a paleta simplificada oferecida ao usuário no momento de montar o fluxo é um subconjunto mais enxuto desses. Os gatilhos confirmados são: conversa aberta (primeira mensagem sem conversa ativa), mensagem recebida (qualquer inbound) e correspondência de palavra-chave (com modo "qualquer" ou "exato"). Cada fluxo tem um modo de reentrada configurável — nunca mais, uma vez por conversa, com cooldown (em horas) ou sempre — e pode ser configurado para pausar automaticamente quando um humano assume a conversa. Existe uma tela de dry run para simular a execução do fluxo antes de ativá-lo. Handoff para humano é modelado como saída de nó dedicada (tipo ai_handoff), com condições configuráveis de quando disparar a passagem.

arquitetura em 3 camadas, toda a lógica de correspondência de gatilho roda dentro do banco (sem função externa no caminho crítico). Na chegada da mensagem, uma função no banco decide em menos de 1 milissegundo: se a mensagem veio da própria automação, ignora; se o contato está numa etapa "esperando resposta" de um fluxo, absorve a mensagem ali e não deixa disparar outro gatilho; se a conversa está com atendimento humano, não aciona automação; só então, se nada bateu, registra a mensagem numa fila leve para processamento em lote a cada 5 a 10 segundos. Esse processamento em lote casa a mensagem com o gatilho certo por ordem de prioridade (palavra-chave > conversa aberta > mensagem recebida), aplicando trava de inscrição única (o contato não entra duas vezes no mesmo fluxo sem querer), cooldown e limite de reentradas por período. Gatilhos suportados: conversa aberta, mensagem recebida, palavra-chave, resposta a botão de template, lead vindo de anúncio Meta, evento de integração (yapt. Connect), contato criado, mudança de estágio de deal, tag adicionada a contato.

um nó de zona de cobertura de IA pode ser inserido em qualquer ponto do fluxo, com saídas mapeadas para sucesso, tempo esgotado, resultado negativo ou passagem para humano — cada uma dessas saídas direciona o contato para um próximo passo diferente do fluxo.

monitora conversas com janela prestes a expirar e envia (ou sugere, dependendo da configuração) um lembrete ("nudge") antes do fechamento. Tem 4 níveis de proteção, cada um definindo com quantas horas de antecedência agir antes da janela fechar: conservador (2h), equilibrado (4h, padrão), agressivo (6h) e ultra (8h). O tipo de mensagem do lembrete segue a mesma lógica do yaFollowUp: template fixo, gerado por IA a partir do contexto, ou lista de variações. O modo de envio pode ser automático ou exigir aprovação humana antes de sair (padrão: exige aprovação). Respeita horário de silêncio do tenant (padrão próprio deste motor: 20h-7h) e tem lógica de antecipação: se a janela vai expirar durante o período de silêncio, o sistema antecipa o aviso para antes do silêncio começar, em vez de deixar a janela fechar sem aviso.

uma função no banco recalcula, por contato, um resumo comercial completo a partir da tabela de eventos de compra: LTV (soma de tudo que já foi comprado), total de compras, reembolsos e chargebacks, receita líquida (compras menos reembolsos e chargebacks), ticket médio e ticket máximo, velocidade de compra (média de dias entre uma compra e outra, só calculada a partir da segunda compra), método de pagamento preferido e detalhamento por método (pix, cartão de crédito, boleto, débito), boletos gerados e não pagos, média de parcelas, assinaturas ativas e canceladas com status geral de assinatura (ativo/cancelado/nenhum), MRR corrente (soma do valor mais recente de cada assinatura ativa), produtos comprados e plataformas de origem. O risco de churn exibido na tela é uma regra simples calculada na tela, não um score estatístico: chargeback registrado ou assinatura cancelada = risco alto; mais de um reembolso = risco médio; um reembolso com mais de 3 compras = risco baixo. Esses mesmos dados (LTV, total de compras, ticket médio, última compra, método preferido, produtos) também alimentam o contexto que a IA lê ao conversar com o contato, então o agente de IA "sabe" o histórico de compra na hora de atender.

o resumo comercial (LTV, total de compras, ticket médio, última compra, método de pagamento preferido, produtos e quantidade) é incluído no contexto rápido da conversa que alimenta o modelo de IA. Isso é distinto da timeline visual do contato — compras não aparecem hoje como eventos na timeline geral do contato, aparecem exclusivamente na aba comercial dedicada.

o contato passa por estágios definidos (assinante, lead, desqualificado, MQL, SAL, SQL, oportunidade, cliente, perdido). Quando um estágio muda diretamente (por exemplo, de lead para cliente, pulando etapas intermediárias), o sistema registra automaticamente no histórico as etapas intermediárias que teoricamente foram percorridas, mantendo o rastro completo sem exigir que cada etapa seja marcada manualmente uma a uma.

cada carteira pode ter metas definidas por métrica — receita, deals ganhos, conversas resolvidas, tempo médio de resposta, contatos engajados, taxa de conversão, MRR ou NPS — com período semanal, mensal, trimestral ou anual.

o operador cadastra mensagens reutilizáveis, agrupadas em pastas, com busca e marcação de favoritos, e pode importar várias de uma vez em lote em vez de cadastrar uma a uma.

um webhook genérico de integração ("yapt. Connect") identifica automaticamente a plataforma de origem pelo cabeçalho da requisição ou pelo formato do corpo — reconhece Shopify, Bling, Hotmart e Kiwify sem configuração manual de cada evento. Um sincronizador de pedidos multi-plataforma, construído em padrão de adaptador, atende hoje Nuvemshop e Shopify de forma oficial, com execução incremental agendada em lote. Funções complementares tratam catálogo de produtos, reconciliação de dados comerciais e indexação de conhecimento comercial para uso da IA.

toda tabela do banco carrega uma coluna tenant_id e uma política de Row Level Security que resolve o tenant do usuário autenticado antes de liberar qualquer leitura ou escrita — não é um filtro aplicado na tela, é uma trava no próprio banco, que vale mesmo se alguém tentar consultar por fora da aplicação. A plataforma tem centenas de tabelas e centenas de políticas RLS ativas, cobrindo do histórico de conversa ao billing. Tenants podem ter hierarquia (parent_tenant_id), o que permite um parceiro enxergar os clientes que administra sem misturar dados entre eles.

a conexão do número de WhatsApp do cliente é provisionada pela edge function de provisionamento de BSP, que recebe e armazena diretamente da Meta o quality_rating (classificação de qualidade do número) e o messaging_limit_tier (teto de mensagens que aquele número pode enviar em 24h) — esses dados não são digitados manualmente, vêm da própria Meta e ficam disponíveis para a operação acompanhar. A sincronização de templates de mensagem também roda por conta própria (sincronização e status de aprovação).

dois caminhos. Um, API pública de leitura autenticada por chave, que expõe contatos, conversas, negócios, mensagens, eventos e atribuição de campanha em formato paginado. Outro, o yapt. Connect propriamente dito: webhooks de entrada e saída com uma camada de mapeamento de campos configurável por evento — a plataforma resolve o mapeamento em cadeia (regra específica do evento → configuração da ação → padrão), com retentativa automática com backoff, log de cada chamada e limite de taxa. Sobre essa base, existe um catálogo de integrações prontas que já passa de dez plataformas de e-commerce, pagamento e gestão (a exemplo de Shopify, Nuvem Shop, WooCommerce, Bling e plataformas de venda de infoproduto), cada uma já configurada com ações padrão como criar contato ou criar negócio.

funções dedicadas cuidam do feed de catálogo (commerce-catalog-feed, commerce-catalog-sync), da sincronização de pedidos (commerce-order-sync) e da reconciliação de dados entre as duas pontas (commerce-reconciliation), com conectores específicos para Shopify e Nuvem Shop já publicados.

o gerenciador de Flows da plataforma classifica automaticamente um template como pesquisa quando a categoria declarada é de satisfação, e a galeria de templates já entrega modelos prontos de pesquisa de satisfação, de NPS e de pesquisa de onboarding para o cliente publicar sem montar do zero.

além dos papéis básicos (dono, administrador, agente, membro), a plataforma tem perfis operacionais customizáveis por tenant, com cerca de setenta permissões booleanas independentes — coisas como ver todas as conversas, supervisionar, treinar a IA ou gerenciar cobrança podem ser ligadas ou desligadas uma a uma por perfil. Cada tenant pode clonar um perfil padrão do sistema e ajustar as permissões para a própria estrutura de equipe, em vez de ficar preso a um papel genérico.

existe uma função de verificação que reconhece a equipe da própria plataforma e libera acesso administrativo aos tenants; parceiros com tenants-filho herdam acesso aos clientes que administram através da mesma hierarquia usada no isolamento multi-tenant. A interface dedicada de parceiro reúne painel, lista de clientes, detalhe de cada cliente, gestão de equipe e configurações — tudo dentro da mesma aplicação, sem precisar de acesso direto ao banco.

setores são configurados com fila FIFO ou round-robin, capacidade por operador, distribuição por habilidade e um motor de regras condicionais que decide para onde a conversa vai, processado por funções dedicadas de roteamento e automação.

cada funcionalidade é um item cadastrado que pode ser vinculado a um plano, a um complemento avulso (addon) contratado à parte, ou receber uma liberação/bloqueio específico para um único tenant, independente do plano — com log de auditoria de cada mudança de liberação.

os planos vivem em uma tabela dedicada de billing, montados por um construtor de planos interno de várias etapas usado pela equipe da New Way; o tenant enxerga o próprio plano e cobrança na área de configurações de billing.

cada evento de uso relevante (mensagem de IA, envio de template, execução de Flow, uso de skill, proposta gerada, enriquecimento de dado) é registrado num módulo de metrificação compartilhado, de forma assíncrona, sem atrasar a resposta ao cliente final. O custo de mensagem cobrado pela Meta é reconciliado contra o consumo real através de funções dedicadas de reconciliação. Esses eventos alimentam o cálculo de custo por tenant.

clientes no modelo de cartão são cobrados via integração de pagamento com checkout, portal de autoatendimento e webhook de confirmação; clientes no modelo faturado (boleto/nota fiscal) têm o fluxo automatizado ponta a ponta com o sistema de gestão financeira da New Way — a fatura gera a ordem de serviço, fatura a ordem e já sai com boleto e nota fiscal de serviço (NFS-e) emitidos automaticamente, com retentativa, baixa de pagamento e conciliação dedicadas. Existe também modalidade de cortesia, em que o uso é rastreado normalmente mas não gera cobrança.

os dados de conversa são replicados para um banco analítico especializado (arquitetura orientada a colunas), com funções dedicadas de ingestão, backfill histórico e captura contínua de mudança de dado (CDC). Um recorte de dados analíticos também permanece no banco principal, organizado em modelo de fatos e dimensões (mensagens, contatos, agentes, canais, campanhas, tempo). Sobre essa base já existe uma família ampla de relatórios publicados — painel geral, disparos, escalonamento, pesquisas, uso de IA, follow-up, desempenho de agente, exportação de dado, campanhas, conversas, vendas e operação — cada um como tela própria dentro do produto.

um módulo de auditoria compartilhado grava, para conformidade, cada ação relevante com identificação de quem agiu, tipo de recurso afetado, o que mudou, endereço de origem e aplicativo usado — de forma assíncrona, sem atrasar a ação em si. Módulos específicos têm o próprio rastro dedicado: distribuição de conversa entre operadores e mudança de liberação de funcionalidade por tenant, por exemplo, cada um com a própria tabela de auditoria.

processamento roda sobre funções de borda (edge functions) acionadas por evento, com o próprio banco de dados funcionando como fila de trabalho — bloqueio seletivo de linha garante que cada tarefa seja pega por um único processo, sem duplicar trabalho. Automações disparadas por mensagem recebida rodam como gatilho dentro do próprio banco, com uma fila de retentativa processada em lote a cada poucos segundos por tarefas agendadas (cron interno do banco), desenhada para não travar o caminho de resposta em tempo real. Tabelas de alto volume (mensagens, eventos brutos, eventos de billing) são particionadas por período, com tempo de retenção definido e limpeza automática.

funções dedicadas processam exclusão e exportação de dado de contato sob demanda; um sistema de lista de bloqueio permite importar, exportar e aplicar bloqueio de contato de forma rastreável.

cadastro de locais e espaços com regras próprias de reserva, um funil de status de reserva (negociando → pré-reserva → aprovação, quando o espaço exige → confirmada → encerrada/no-show/cancelada), agenda e mapa visual dos espaços, painel do dia para check-in manual, e um módulo de contrato e cobrança integrado: tipos de contrato configuráveis, carteira/saldo por conta (franquia de uso), consumo lançado como venda, faturas geradas e sincronizadas com o sistema de gestão financeira da New Way (Omie) — incluindo emissão automática de nota fiscal e boleto. Tudo isolado por tenant e com permissões dedicadas (quem pode aprovar reserva, quem gerencia contrato).

a equipe da New Way abre um incidente com severidade (informativo, atenção, crítico) e status (investigando, identificado, monitorando, resolvido), publica atualizações de linha do tempo à medida que a situação evolui, e o incidente ativo fica visível para todo usuário autenticado até ser marcado como resolvido.