Funcionalidade equivalente (like-for-like)
Esta página é a visão do app de documentação para a matriz de paridade mais completa em Matriz de Funcionalidades. A pergunta que ela responde é simples: O que precisa existir antes que esta plataforma possa substituir o Charles em fluxos de trabalho reais dos operadores?Padrão de substituição
A plataforma é operacionalmente equivalente (like-for-like) quando:- o tráfego de clientes de entrada chega ao nosso webhook e aparece na nossa inbox
- mensagens de saída, templates e atualizações de status pertencem à nossa plataforma
- contatos, estado de assinante e tratamento de opt-out não dependem mais do Charles
- operadores conseguem atender conversas sem precisar voltar para a ferramenta anterior
- sistemas internos podem continuar chamando endpoints de compatibilidade durante a migração
- as operações conseguem inspecionar, reproduzir (replay) e auditar falhas sem intervenção do fornecedor
Mapa de módulos
Inbox e workspace do operador
A paridade exigida inclui:- lista de conversas, busca, filtros de fila, estado de atribuição, contagens de não lidas
- detalhe da thread com cronologia de entrada e saída
- visibilidade do estado de entrega e do estado de leitura
- percepção de service-window e avisos de somente-template
- painel lateral de contato, notas, tags e ações rápidas
- pontos de entrada para envio de template e comportamento de resposta compartilhada
- auditabilidade para ações de atribuição, envio, replay e intervenção
Contatos e estado de assinante
A paridade exigida inclui:- IDs de referência externos do CRM
- normalização de telefone e correspondência de identidade
- estado de opt-in e opt-out
- tags, notas e propriedades personalizadas
- atribuição de origem e contexto comercial
- comportamento explícito de suppression para destinatários inseguros
Templates e respostas compartilhadas
A paridade exigida inclui:- espelho local dos templates do provider
- visibilidade de locale, categoria, variável e aprovação
- bloqueio de envio quando a conversa está fora da service-window
- prévia e validação antes do envio
- respostas compartilhadas de propriedade do time, distintas dos templates do provider
Campanhas
A paridade exigida inclui:- rascunho de campanha e revisão de lançamento
- seleção de audiência ou snapshot
- estado de agendamento
- visibilidade de entrega e falha por destinatário
- pausar, retomar, cancelar e trilhas de auditoria
Journeys e automações
A paridade exigida inclui:- triggers de webhook e de compatibilidade
- definições versionadas
- waits, branches e atualizações de propriedade/tag
- estado de publicação
- histórico de execuções, falhas e limites de execução seguros para replay
Integrações e compatibilidade
A paridade exigida inclui:- endpoints de compatibilidade para mutação de contatos
- endpoints de compatibilidade para trigger de journey
- modelo de integração webhook-first para o Twenty CRM
- metadados de auditoria explícitos para ações de parceiros de entrada
- inspeção de replay e falha para o tráfego de integração
Operações e governança
A paridade exigida inclui:- diagnósticos de runtime
- forense de webhook e controles de replay
- visibilidade de fila e outbox
- acesso a logs de auditoria
- feature flags e kill switches
- administração de credenciais e canais
Faixas de prioridade
Camada de continuidade P0
- núcleo da inbox
- contatos e estado de assinante
- registro de templates e bloqueio de envio
- ingestão de webhook de entrada
- fila de intenção de saída
- reconciliação de entrega e status
- endpoints de compatibilidade
- diagnósticos de runtime e auditoria
Paridade operacional P1
- campanhas
- runtime de journeys
- segmentos e gestão de audiência
- sincronização mais profunda com o Twenty CRM
- relatórios essenciais
- ergonomia de colaboração
Expansão P2
- camadas de assistência de IA
- experimentação mais rica
- suporte a canais mais amplo
- funcionalidades avançadas de analytics e recomendação
O que significa “drop-in” aqui
A substituição não precisa copiar os detalhes de implementação do Charles. Ela precisa preservar o contrato operacional:- sistemas upstream ainda conseguem disparar contatos e flows
- operadores conseguem continuar atendendo o tráfego de clientes de entrada
- templates aprovados e regras de envio permanecem aplicáveis
- o tratamento de falhas operacionais é pelo menos tão forte quanto o estado da ferramenta anterior