DRS, ModularCRM

Estágio: Rascunho para validação Tipo de documento: DRS (Documento de Requisitos de Software, padrão MDS) Sistema: ModularCRM (produto próprio Modulareasy)

Família de documentos. Este DRS anda acompanhado de quatro documentos companheiros, todos sob /mds: Roadmap de Implementação (em que ordem construir e como verificar) · Inventário de Artefatos (o que precisa existir e como deve ser) · Jornadas dos Atores (como cada papel opera) · Plano de Testes (o que validar antes de entregar).

1. Visão Geral

1.1 O que é

O ModularCRM é uma plataforma de relacionamento e vendas (CRM) para pequenas e médias empresas brasileiras, entregue como serviço na internet (SaaS) e usada por várias empresas ao mesmo tempo, cada uma isolada da outra. Em uma frase: é uma versão focada e nacionalizada do GoHighLevel, reunindo num só lugar a captação de leads, a gestão desses leads, um centro de conversas que junta todos os canais (WhatsApp, Instagram, Messenger, e-mail, SMS), automações de marketing e vendas, e uma agenda com página pública de agendamento.

O GoHighLevel (GHL) é a referência oficial de paridade do produto: as telas, os fluxos e a nomenclatura do ModularCRM espelham o que o operador brasileiro já reconhece do GHL, com três diferenciais deliberados (interface em português, modo escuro completo que o GHL não tem, e experiência web responsiva no lugar de um aplicativo separado).

1.2 O problema que resolve

A PME brasileira que faz tráfego pago e atendimento por WhatsApp vive com as ferramentas espalhadas: os leads chegam por um formulário do Facebook, o atendimento acontece no WhatsApp pessoal de um vendedor, o acompanhamento fica numa planilha, e a cobrança é um Pix combinado no chat. Nada disso conversa entre si, o mesmo cliente aparece como três pessoas diferentes, e o dono não enxerga o funil. O ModularCRM unifica essa operação: o lead entra por qualquer canal e vira um único contato; toda conversa fica num só inbox; o funil, as tarefas e os agendamentos ficam visíveis; e as automações cuidam do follow-up.

1.3 Proposta de valor

• Um cliente, um contato. A pessoa que fala pelo WhatsApp, comenta no Instagram e preenche o formulário é reconhecida como o mesmo contato, com histórico unificado.
• Um inbox para todos os canais. WhatsApp, Instagram, Messenger, e-mail e SMS no mesmo lugar, com a ficha do contato ao lado.
• Paridade com uma ferramenta que o mercado já conhece. Quem já operou GHL encontra o mesmo mapa mental, em português.
• Multi-empresa de verdade. Cada empresa cliente enxerga apenas os próprios dados, com isolamento garantido no banco.
• Portal de agência. Uma agência pode operar várias contas de clientes, aplicar modelos prontos e revender com a própria marca.

1.4 Posicionamento e escopo

O ModularCRM é um produto interno da Modulareasy, distinto dos demais produtos da agência e com infraestrutura própria e isolada. O primeiro cliente real (tenant piloto) é a Hiit Fitwear, com a própria Modulareasy usando o sistema para si (dogfooding).

Fora de escopo, por decisão firmada: construtor de sites e funis de página (isso é um projeto separado), emissão automática de nota fiscal na V1 (fica manual na V1, automática na V2), e gateway de pagamento com cartão na V1 (a cobrança V1 é Pix manual).

1.5 Estado deste documento

Este DRS é retroativo: descreve um sistema que já foi construído e chegou a produção com o tenant piloto, e que foi congelado por volta de maio de 2026 aguardando ações operacionais (conexão de canais) e um ciclo de polimento de interface. As seções 1 a 10 refletem o que existe hoje e o que ficou pendente; a ordem de construção, o que está pronto e o que falta terminar aparecem no Roadmap de Implementação.

A seção 11 (Paridade GoHighLevel) foi acrescentada depois, a partir de um levantamento exaustivo da documentação oficial do GoHighLevel (a referência de paridade do produto), e reúne as funcionalidades e estruturas que o GoHighLevel documenta e que o ModularCRM ainda não tem. É um backlog de paridade com quase novecentos requisitos, para orientar a evolução do produto rumo à paridade completa.

2. Identidade

• Nome: ModularCRM
• Categoria: SaaS multi-empresa (multi-tenant) de CRM, inbox omnichannel, automações e agendamento
• Público: pequenas e médias empresas brasileiras; e agências que operam várias contas de clientes
• Referência de paridade: GoHighLevel (GHL)
• Modelo de operação: cada empresa cliente é uma organização isolada; a Modulareasy opera como fornecedor (Super Admin) e também como uma organização usuária

2.1 Base tecnológica (em linguagem de produto)

• Aplicação web moderna de página única, com modo claro e escuro, responsiva para celular.
• Banco de dados único compartilhado, com isolamento por empresa garantido por regras de segurança em nível de linha (RLS): toda tabela carrega o identificador da organização e cada empresa só enxerga as próprias linhas.
• Central de recebimento (serviço de webhook) que recebe e-mails, eventos das redes (Meta, Google) e mensagens de WhatsApp, e devolve as respostas.
• Fila de trabalhos para tarefas assíncronas (entregas de mensagens, automações, envios para plataformas de anúncio), com processadores dedicados.
• WhatsApp por dois caminhos à escolha da empresa: uma central própria e gratuita (Evolution) ou a via oficial paga da Meta (Cloud API).
• E-mail com envio transacional próprio e caixa de entrada por empresa (IMAP/SMTP).

2.2 Princípios

1. Core primeiro. Os quatro pilares (captação de leads, gestão de leads, conversas, interface) têm prioridade sobre qualquer funcionalidade lateral.
2. Paridade GHL como bússola. Diante de dúvida sobre comportamento ou nomenclatura, o padrão é o que o GHL faz, adaptado ao Brasil.
3. Isolamento absoluto entre empresas. Nenhuma consulta, tela ou automação pode vazar dados de uma empresa para outra.
4. Editável pelo administrador. Valores, regras e limites que a operação queira ajustar têm tela de edição; nada que exija mexer no banco para mudar.
5. Autossuficiência de infraestrutura. Serviços próprios e auto-hospedados no lugar de dependências pagas de terceiros, quando viável.

3. Atores e Papéis

Os papéis abaixo são descritos por função, não por pessoa. A operação detalhada de cada um está nas Jornadas dos Atores.

3.1 Super Admin (Modulareasy)

O fornecedor da plataforma. Enxerga e administra todas as empresas, cria e edita planos, acompanha a receita recorrente e a saúde do sistema, opera o portal de agência e define regras globais (por exemplo, regras de pontuação de lead herdadas por todas as empresas). É o único papel com visão cruzada entre organizações.

3.2 Dono da organização (Org Owner)

O responsável máximo por uma empresa cliente dentro do sistema. Configura a empresa, conecta os canais (WhatsApp, redes, e-mail), define o funil de vendas, gerencia a equipe, e tem acesso a tudo dentro da própria organização (e a nada de fora dela).

3.3 Administrador da organização (Org Admin)

Papel de gestão dentro de uma empresa, com poderes amplos de configuração e operação, subordinado ao dono. Ajusta campos, tags, automações, modelos de mensagem e relatórios da própria empresa.

3.4 Membro / Atendente (Member)

O executor do dia a dia: atende conversas no inbox, cria e move oportunidades no funil, cadastra contatos, cumpre tarefas e agendamentos. Enxerga apenas os dados da própria empresa, com o escopo que o administrador liberar.

3.5 Administrador de agência

Uma variação operacional do dono/Super Admin que opera várias contas de clientes pelo Portal de Agência: cria subcontas, aplica modelos prontos (snapshots), configura planos e revende o sistema com a própria marca (white-label).

3.6 Contato externo

A pessoa atendida (lead, cliente). Não faz login no sistema. Interage por fora: preenche formulários públicos, marca horário na página pública de agendamento, conversa pelos canais e clica em links rastreáveis. Cada interação vira ou atualiza um contato dentro da empresa.

4. Requisitos Funcionais

Os requisitos seguem o formato do MDS: código, descrição, prioridade, atores envolvidos e um critério de aceitação (H1) no formato "Dado, Quando, Então, E". Um requisito só é considerado pronto quando o H1 passa.

4.1 Captura de Leads (RF-CAPT)

RF-CAPT-001: Ingestão de Meta Lead Ads (Facebook e Instagram)

• Descrição: receber automaticamente os leads gerados por formulários de anúncio da Meta (Facebook e Instagram Lead Ads) de cada empresa conectada, criando ou atualizando o contato correspondente e registrando a origem. A captura segue o caminho canônico definido em RF-CAPT-008 (webhook assinado de leadgen), RF-CAPT-009 (enriquecimento com caixa de saída e retenção do lead) e RF-CAPT-010 (reconciliação por formulário): o registro do evento de lead independe do acesso da empresa e nenhum lead é descartado quando o acesso está fora do ar.
• Prioridade: Essencial
• Atores: Contato externo (gera o lead), Org Owner/Admin (conecta a conta), Super Admin (mantém o aplicativo Meta dedicado)
• Entrada: notificação de leadgen da Meta com o identificador do lead (leadgen_id), o formulário e a página.
• Saída: contato criado ou atualizado na empresa correta com a origem "Meta Lead Ads".
• H1: Dado que uma empresa conectou sua conta Meta (RF-INT-001) e tem um formulário de anúncio ativo, Quando um usuário do Facebook ou Instagram envia esse formulário, Então em poucos segundos aparece um contato novo (ou é atualizado um existente) na empresa correta com a origem "Meta Lead Ads", E o evento é registrado por leadgen_id no momento da notificação, antes de qualquer enriquecimento, de modo que dois avisos do mesmo leadgen_id produzem um único contato.
• Notas: revisado em 2026-07-22 (council GO, requisito do dono de conexão permanente e captura confiável). A ingestão do evento passou a independer do acesso da empresa (assinatura pelo segredo do aplicativo, RF-CAPT-008); o enriquecimento do conteúdo do lead depende do acesso vivo e da janela de recuperação da Meta (RF-CAPT-009).

RF-CAPT-002: Ingestão de Google Ads Lead Form

• Descrição: receber leads de formulários de anúncio do Google Ads, de forma análoga à Meta, criando ou atualizando contatos.
• Prioridade: Alta
• Atores: Contato externo, Org Owner/Admin, Super Admin
• H1: Dado que uma empresa conectou sua conta Google Ads, Quando um lead é submetido por um formulário de anúncio do Google, Então um contato é criado ou atualizado na empresa correta, E a origem é registrada como "Google Ads".
• Notas: dependia da liberação do aplicativo Google (OAuth) no congelamento; ver Entrega e Evolução.

RF-CAPT-003: Formulários públicos (construtor e incorporação)

• Descrição: permitir que a empresa crie formulários públicos com campos configuráveis, publique numa URL própria e/ou incorpore em um site externo por um trecho de código; cada envio vira um contato.
• Prioridade: Essencial
• Atores: Org Owner/Admin (cria o formulário), Contato externo (preenche)
• H1: Dado um formulário publicado por uma empresa, Quando um visitante preenche e envia, Então o envio é registrado e um contato é criado ou atualizado na empresa dona do formulário, E o formulário pode ser incorporado em um site externo pelo código de incorporação gerado.

RF-CAPT-004: Webhook genérico de ingestão de leads

• Descrição: oferecer um ponto de entrada de API configurável para que sistemas externos enviem leads ao ModularCRM (integração genérica, além dos conectores nativos).
• Prioridade: Alta
• Atores: Org Owner/Admin (configura), sistema externo (envia)
• H1: Dado um endpoint de ingestão habilitado e autenticado para uma empresa, Quando um sistema externo envia um lead no formato esperado, Então o lead é validado e vira um contato na empresa correta, E envios malformados ou não autenticados são rejeitados com resposta clara.

RF-CAPT-005: Cadastro rápido manual (Quick Add)

• Descrição: permitir que o atendente cadastre um contato manualmente em poucos cliques, a partir de um modal rápido acessível de qualquer tela.
• Prioridade: Essencial
• Atores: Member, Org Owner/Admin
• H1: Dado um operador logado em uma empresa, Quando ele aciona o cadastro rápido e informa ao menos um dado de contato, Então um novo contato é criado na empresa atual e fica imediatamente disponível na lista, E o operador pode abrir a ficha completa para complementar.

RF-CAPT-006: TikTok Lead Ads (complemento)

• Descrição: receber leads do TikTok Lead Ads reaproveitando o mesmo padrão de conexão dos demais conectores.
• Prioridade: Média
• Atores: Contato externo, Org Owner/Admin
• H1: Dado que uma empresa conectou sua conta TikTok, Quando um lead é gerado por um anúncio do TikTok, Então um contato é criado ou atualizado com a origem "TikTok Lead Ads".
• Notas: planejado como complemento reaproveitando o padrão de OAuth da Meta; LinkedIn fica para V2.

RF-CAPT-007: Roteamento e deduplicação na entrada

• Descrição: ao receber um lead de qualquer origem, decidir se ele cria um contato novo ou atualiza um existente, evitando duplicatas por telefone, e-mail ou identificador de canal.
• Prioridade: Essencial
• Atores: sistema (regra automática), Org Admin (parametriza)
• H1: Dado um lead entrando por qualquer canal, Quando já existe um contato com o mesmo telefone, e-mail ou identificador de canal na empresa, Então o lead atualiza o contato existente em vez de criar duplicata, E quando não há correspondência, um contato novo é criado.
• Notas: liga-se diretamente ao RF-LEAD-011 (matching cross-channel).

RF-CAPT-008: Webhook de leadgen assinado e ingestão idempotente

• Descrição: receber a notificação de leadgen da Meta num endpoint que valida a assinatura do aplicativo (cabeçalho X-Hub-Signature-256 com o segredo do aplicativo) e grava o evento cru (leadgen_id, formulário, página, momento) numa tabela de entrada, respondendo com sucesso em poucos segundos. A ingestão não depende do acesso da empresa: mesmo com o acesso da empresa vencido, o evento é registrado.
• Prioridade: Essencial
• Atores: sistema (recebe), Meta (envia), Super Admin (mantém o segredo do aplicativo dedicado)
• Entrada: corpo de leadgen assinado pelo segredo do aplicativo.
• Saída: uma linha de entrada por leadgen_id e resposta de sucesso rápida.
• H1: Dado o endpoint de leadgen habilitado, Quando chega uma notificação com assinatura válida do aplicativo, Então o evento é gravado por leadgen_id na tabela de entrada e a resposta é de sucesso em poucos segundos, E uma notificação com assinatura ausente ou inválida é recusada sem gravar, E a mesma notificação recebida duas vezes gera uma única linha de entrada (idempotência por leadgen_id), E o evento é gravado mesmo quando o acesso da empresa está vencido.
• Notas: introduzido em 2026-07-22 (council GO). A chave de idempotência leadgen_id e a verificação de assinatura pelo segredo do aplicativo são protocolo da Meta, não configuráveis.

RF-CAPT-009: Enriquecimento com caixa de saída e retenção do lead até reconectar

• Descrição: um processo assíncrono lê a tabela de entrada, busca o conteúdo do lead na Meta (nome, telefone, e-mail) usando o acesso da empresa, e faz a gravação idempotente do contato por leadgen_id. As tentativas usam recuo progressivo (backoff). Quando o acesso da empresa está morto, a linha fica no estado "aguardando reconexão" e nunca é descartada; ao reconectar, o acumulado é drenado.
• Prioridade: Essencial
• Atores: sistema, Org Owner/Admin (reconecta quando avisado)
• H1: Dado um evento de leadgen gravado na entrada, Quando o processo de enriquecimento roda com o acesso da empresa vivo, Então o contato é criado ou atualizado por leadgen_id uma única vez e a linha de entrada fica concluída, E quando o acesso está morto a linha fica em "aguardando reconexão" sem ser descartada, E ao reconectar dentro da janela de recuperação da Meta o acumulado é enriquecido e nenhum evento é perdido.
• Notas: introduzido em 2026-07-22 (council GO). Reusa a caixa de saída transacional (ver o card AUD-99 no Roadmap), agora também para o enriquecimento de leads. A janela de recuperação do conteúdo do lead é limite externo da Meta (aproximadamente 90 dias): passado o prazo o leadgen_id permanece, o conteúdo pode não ser mais recuperável, e o alerta de RF-INT-006 escala a urgência antes do prazo. O intervalo do enriquecimento e a política de recuo são editáveis pela operação (RNF-008).

RF-CAPT-010: Reconciliação periódica por formulário

• Descrição: em intervalos regulares, buscar na Meta os leads de cada formulário desde o último ponto lido (cursor) e convergir para o mesmo destino idempotente por leadgen_id, como rede de segurança para eventos que o webhook não entregou (a Meta não garante a entrega do webhook, e qualquer indisponibilidade nossa perde avisos).
• Prioridade: Essencial
• Atores: sistema, Super Admin (ajusta o intervalo)
• H1: Dado um formulário ativo de uma empresa, Quando a reconciliação roda no intervalo configurado, Então os leads do formulário desde o último cursor são trazidos e convergem por leadgen_id para o mesmo destino do webhook, E um lead já capturado pelo webhook não vira um segundo contato (deduplicação por leadgen_id), E um lead que o webhook não entregou passa a existir como contato após a reconciliação.
• Notas: introduzido em 2026-07-22 (council GO). Não diferível: sem a reconciliação, o caminho só de webhook tem perda silenciosa em qualquer indisponibilidade. O intervalo é editável pela operação (RNF-008), valor inicial 15 minutos.

4.2 Gestão de Leads (RF-LEAD)

RF-LEAD-001: Lista de contatos

• Descrição: exibir os contatos da empresa em uma lista com colunas relevantes (nome, telefone, e-mail, empresa, criado em, tags, última atividade), com busca, ordenação e paginação.
• Prioridade: Essencial
• Atores: Member, Org Owner/Admin
• H1: Dado um operador em uma empresa com contatos cadastrados, Quando ele abre a lista de contatos, Então vê os contatos apenas da própria empresa com as colunas principais, E pode buscar por nome, telefone ou e-mail e ordenar a lista.

RF-LEAD-002: Ficha do contato

• Descrição: exibir e editar todos os dados de um contato numa ficha única (dados de identificação, campos personalizados, tags, empresa vinculada, arquivos e histórico de atividades), com edição em linha.
• Prioridade: Essencial
• Atores: Member, Org Owner/Admin
• H1: Dado um contato existente, Quando o operador abre a ficha, Então vê os dados, campos personalizados, tags, arquivos e histórico do contato, E consegue editar os campos e ver a alteração persistida.

RF-LEAD-003: Campos personalizados (custom fields)

• Descrição: permitir criar campos personalizados por tipo de objeto (contato, empresa, oportunidade), organizados em pastas, com chave única reutilizável em modelos e automações.
• Prioridade: Essencial
• Atores: Org Owner/Admin
• H1: Dado um administrador de empresa, Quando ele cria um campo personalizado escolhendo tipo e objeto, Então o campo passa a aparecer na ficha do objeto correspondente, E pode ser referenciado por sua chave única em modelos de mensagem e automações.
• Notas: paridade GHL inclui organização em pastas e agrupamento; chave única no estilo de variável de modelo.

RF-LEAD-004: Tags

• Descrição: criar, aplicar e remover tags nos contatos, individualmente e em massa, para segmentação.
• Prioridade: Essencial
• Atores: Member, Org Owner/Admin
• H1: Dado um conjunto de contatos, Quando o operador aplica uma tag em massa a partir da seleção, Então todos os contatos selecionados recebem a tag, E a tag pode ser usada como critério em listas inteligentes e automações.

RF-LEAD-005: Empresas (companies)

• Descrição: cadastrar empresas e vincular contatos a elas (relação de muitos para muitos), para representar o cliente organizacional por trás das pessoas.
• Prioridade: Alta
• Atores: Member, Org Owner/Admin
• H1: Dado um contato e uma empresa cadastrada, Quando o operador vincula o contato à empresa, Então o vínculo aparece nas duas fichas, E um contato pode estar ligado a mais de uma empresa.

RF-LEAD-006: Arquivos anexados ao contato

• Descrição: anexar documentos e arquivos à ficha do contato (contratos, comprovantes, propostas).
• Prioridade: Média
• Atores: Member, Org Owner/Admin
• H1: Dado um contato, Quando o operador anexa um arquivo, Então o arquivo fica listado na ficha e disponível para download, E respeita o isolamento da empresa.

RF-LEAD-007: Pontuação de lead customizável (lead scoring)

• Descrição: definir regras de pontuação por engajamento (evento gatilho, filtro, ação de somar ou subtrair pontos), com liga/desliga do conjunto de regras. Diferencial sobre o GHL: as regras podem ser definidas em nível global pelo Super Admin (herdadas por todas as empresas) e também ajustadas por cada empresa.
• Prioridade: Alta
• Atores: Super Admin (regras globais), Org Owner/Admin (regras da empresa)
• H1: Dado um conjunto de regras de pontuação ativo, Quando um contato dispara um evento previsto (por exemplo, abre um e-mail ou confirma um agendamento), Então sua pontuação é ajustada conforme a regra, E o administrador consegue ligar ou desligar o conjunto de regras e ver o efeito.
• Notas: eventos de exemplo do GHL incluem abertura de e-mail, status de agendamento confirmado, resposta com determinada tag, agendamento em determinado calendário.

RF-LEAD-008: Listas inteligentes (smart lists)

• Descrição: salvar combinações de filtros como listas reutilizáveis e compartilháveis dentro da empresa.
• Prioridade: Alta
• Atores: Member, Org Owner/Admin
• H1: Dado um conjunto de filtros aplicado à lista de contatos, Quando o operador salva como lista inteligente, Então a lista fica disponível para reuso, E pode ser compartilhada com outros operadores da mesma empresa.

RF-LEAD-009: Filtros avançados e ordenação

• Descrição: filtrar a lista de contatos por múltiplos critérios combinados (campos, tags, atividade, pontuação) e ordenar por colunas.
• Prioridade: Alta
• Atores: Member, Org Owner/Admin
• H1: Dado a lista de contatos, Quando o operador combina filtros avançados, Então a lista mostra apenas os contatos que atendem a todos os critérios, E a combinação pode virar uma lista inteligente.

RF-LEAD-010: Mesclagem de duplicatas (merge)

• Descrição: unir dois ou mais contatos que representam a mesma pessoa em um único registro, preservando histórico e vínculos.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado dois contatos identificados como a mesma pessoa, Quando o operador executa a mesclagem, Então resta um único contato com os dados consolidados e o histórico preservado, E o registro de mesclagem fica auditável.

RF-LEAD-011: Contato unificado entre canais (cross-channel matching)

• Descrição: reconhecer que a pessoa que fala pelo WhatsApp, comenta no Instagram, escreve por Messenger e envia e-mail é o mesmo contato, mantendo identificadores de canal ligados a um contato único.
• Prioridade: Essencial
• Atores: sistema (regra automática), Org Admin
• H1: Dado um contato que já interagiu por um canal, Quando a mesma pessoa interage por outro canal com identificador reconciliável, Então as interações convergem para um único contato com todos os identificadores ligados, E o histórico unificado aparece na ficha.
• Notas: já em produção na V1; base do "um cliente, um contato".

RF-LEAD-012: Importação e exportação

• Descrição: importar contatos em massa por arquivo (CSV) e exportar contatos e relatórios (por exemplo, PDF).
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um arquivo de contatos válido, Quando o administrador importa, Então os contatos entram na empresa respeitando deduplicação e mapeamento de colunas, E o administrador consegue exportar a lista atual.

RF-LEAD-013: Histórico de atividades do contato

• Descrição: registrar num histórico cronológico as interações e mudanças do contato (mensagens, mudanças de estágio, tarefas, agendamentos, pontuação).
• Prioridade: Alta
• Atores: sistema (registra), Member/Admin (consulta)
• H1: Dado um contato com interações, Quando o operador abre o histórico, Então vê a linha do tempo das atividades em ordem cronológica, E cada item indica o canal ou a origem.

4.3 Conversas e Inbox Unificado (RF-CONV)

RF-CONV-001: Inbox unificado (layout e filtros)

• Descrição: apresentar um inbox de equipe com a lista de conversas de todos os canais, com abas de filtro (não lidas, todas, recentes, favoritas) e indicação do canal de cada conversa.
• Prioridade: Essencial
• Atores: Member, Org Owner/Admin
• H1: Dado um operador em uma empresa com conversas em vários canais, Quando ele abre o inbox, Então vê todas as conversas da empresa numa lista única com o canal identificado, E pode filtrar por não lidas, recentes e favoritas.

RF-CONV-002: Painel de conversa com ficha do contato

• Descrição: ao abrir uma conversa, mostrar o histórico de mensagens ao centro e a ficha do contato à direita (dados editáveis, tags, ações), no padrão de três painéis do GHL.
• Prioridade: Essencial
• Atores: Member, Org Owner/Admin
• H1: Dado uma conversa aberta, Quando o operador a visualiza, Então vê o histórico de mensagens e, ao lado, a ficha do contato editável, E consegue responder pelo mesmo canal da conversa.

RF-CONV-003: WhatsApp via Evolution (canal principal)

• Descrição: conectar o WhatsApp de cada empresa por uma central própria (Evolution), com uma instância por empresa, conexão por leitura de QR Code, e troca de mensagens nos dois sentidos dentro do inbox.
• Prioridade: Essencial
• Atores: Org Owner (conecta), Member (atende), Contato externo
• H1: Dado que a empresa conectou seu WhatsApp lendo o QR Code, Quando um cliente envia mensagem para esse número, Então a mensagem aparece no inbox da empresa como uma conversa, E a resposta enviada pelo operador chega ao cliente no WhatsApp.

RF-CONV-004: WhatsApp via Meta Cloud API (canal alternativo)

• Descrição: oferecer, como alternativa paga e oficial, o WhatsApp pela Cloud API da Meta, escolhível pela empresa na configuração.
• Prioridade: Alta
• Atores: Org Owner (escolhe e conecta), Member, Contato externo
• H1: Dado que a empresa optou pelo WhatsApp oficial da Meta e concluiu a conexão, Quando há troca de mensagens, Então elas circulam pelo inbox da mesma forma que o canal Evolution, E a empresa escolhe qual dos dois provedores usar.

RF-CONV-005: Messenger (Facebook)

• Descrição: integrar as mensagens de páginas do Facebook (Messenger) ao inbox, nos dois sentidos, com nome e foto reais do contato.
• Prioridade: Alta
• Atores: Org Owner (conecta a página), Member, Contato externo
• H1: Dado uma página do Facebook conectada, Quando alguém envia mensagem pelo Messenger, Então ela aparece no inbox com nome e foto do remetente, E a resposta do operador chega ao Messenger.

RF-CONV-006: Instagram (mensagens diretas e comentários)

• Descrição: integrar mensagens diretas e comentários do Instagram ao inbox, nos dois sentidos.
• Prioridade: Alta
• Atores: Org Owner (conecta), Member, Contato externo
• H1: Dado uma conta Instagram conectada, Quando chega uma mensagem direta ou um comentário, Então aparece no inbox vinculado ao contato, E o operador consegue responder pelo mesmo canal.

RF-CONV-007: E-mail por empresa (IMAP e SMTP)

• Descrição: conectar a caixa de e-mail de cada empresa (recebimento por IMAP, envio por SMTP) e tratar as trocas como conversas no inbox.
• Prioridade: Alta
• Atores: Org Owner (conecta), Member, Contato externo
• H1: Dado uma caixa de e-mail conectada a uma empresa, Quando chega um e-mail de um contato, Então vira uma conversa no inbox vinculada ao contato, E a resposta do operador sai pelo e-mail da empresa.

RF-CONV-008: SMS (Twilio)

• Descrição: enviar e receber SMS pelo Twilio dentro do inbox.
• Prioridade: Média
• Atores: Org Owner (configura), Member, Contato externo
• H1: Dado uma conta Twilio configurada na empresa, Quando um SMS é trocado, Então aparece como conversa no inbox, E o operador envia SMS pelo mesmo painel.

RF-CONV-009: Respostas prontas (snippets)

• Descrição: cadastrar respostas prontas reutilizáveis para agilizar o atendimento.
• Prioridade: Média
• Atores: Org Owner/Admin (cadastra), Member (usa)
• H1: Dado um conjunto de respostas prontas, Quando o operador insere uma numa conversa, Então o texto é colado na resposta, E variáveis do contato podem ser substituídas.

RF-CONV-010: Ações manuais (manual actions)

• Descrição: apresentar ao operador as tarefas manuais geradas por automações (por exemplo, "ligar para o contato"), numa aba dedicada.
• Prioridade: Média
• Atores: Member, sistema (gera)
• H1: Dado uma automação que gera uma tarefa manual, Quando ela é disparada para um contato, Então a tarefa aparece na aba de ações manuais do operador, E pode ser marcada como concluída.

RF-CONV-011: Não perturbe (DND) por contato

• Descrição: marcar um contato como "não perturbe" para suspender envios automáticos a ele.
• Prioridade: Média
• Atores: Member, Org Owner/Admin
• H1: Dado um contato, Quando o operador ativa o "não perturbe", Então os envios automáticos para esse contato ficam suspensos, E o operador ainda pode enviar mensagens manuais.

RF-CONV-012: Widget de webchat incorporável

• Descrição: oferecer um widget de chat em JavaScript para incorporar no site da empresa, cujas conversas caem no inbox.
• Prioridade: Média
• Atores: Org Owner (incorpora), Contato externo, Member
• H1: Dado o widget incorporado no site de uma empresa, Quando um visitante inicia uma conversa, Então ela aparece no inbox da empresa vinculada a um contato, E o operador responde pelo inbox.
• Notas: entregue e em produção desde 2026-07-11 ({AUD-04}): a página pública de chat e o widget incorporável funcionam, com a conversa aparecendo no inbox da empresa e o operador respondendo por ele.

RF-CONV-013: Notificações de novas mensagens

• Descrição: notificar o operador sobre novas mensagens em tempo real.
• Prioridade: Alta
• Atores: Member, sistema
• H1: Dado um operador com o inbox aberto, Quando chega uma nova mensagem, Então ele é notificado e a conversa sobe como não lida, E o contador de não lidas é atualizado.

RF-CONV-014: Links rastreáveis (trigger links)

• Descrição: gerar links curtos rastreáveis para usar em mensagens, registrando os cliques e atribuindo cada clique a quem clicou. O administrador cria o link, a automação da empresa o insere na mensagem já com o id de envio daquele contato, o contato clica, e o sistema conta o clique, atribui o clique ao contato, registra o clique no histórico dele, redireciona ao destino e dispara as automações do gatilho de clique em link.
• Regra do id de envio (parte do requisito, não detalhe de implementação): o contato viaja no endereço curto como um id opaco de envio, e nunca como o identificador do contato. O endereço público resolve a empresa sozinho, a partir do próprio endereço, e não recebe a empresa nem o contato como parâmetro de quem chama, em conformidade com o RNF-010: identificador de contato não vale como credencial, ele nunca muda e é conhecido por quem um dia teve acesso, então aceitá-lo no endereço deixaria na mão de quem já foi desligado o poder de disparar automação em nome da empresa. O id de envio é por par de link e contato, é o mesmo em todos os envios daquele par, e só vale dentro do próprio link: apresentado em outro link, não atribui contato nenhum.
• Regra do link sem dono: link sem id de envio continua válido. Ele redireciona ao destino e conta o clique, e não atribui contato nem dispara automação. Clique anônimo é clique: entra no contador do link e não some da estatística.
• Regra do endereço curto único: o endereço curto de um link é único em todo o produto, e não por empresa. Unicidade por empresa não basta, e a diferença não é preciosismo: é o endereço que resolve de qual empresa é o link, e é do link que sai a empresa do evento, então o mesmo endereço curto em duas empresas faria o clique nascer para a empresa errada.
• Consequência aceita do rastreio de clique (decidida, não esquecida): quem recebe o link e o repassa a outra pessoa faz a automação disparar como se o contato tivesse clicado, porque o id de envio viaja junto com o endereço. Isso é inerente a rastrear clique e valeria para qualquer desenho, com id opaco ou sem ele: o sistema sabe que aquele endereço foi entregue àquele contato, e não qual dedo clicou. Este custo foi pesado e aceito em 2026-07-15, e fica registrado aqui para que não seja lido depois como defeito nem corrigido por conta própria: reverter esta escolha exige emenda deste requisito antes do código.
• Prioridade: Média
• Atores: Org Owner/Admin (cria), Contato externo (clica), sistema (registra o clique, atribui ao contato e dispara as automações)
• H1: Dado um link rastreável enviado a um contato pela automação da empresa dona do link, Quando aquele contato clica, Então ele é redirecionado ao destino, E o clique é registrado e contabilizado para aquele link com o contato atribuído, nunca sem contato quando o endereço traz id de envio válido, E o clique aparece no histórico daquele contato, na aba Atividade, E toda automação ativa no gatilho de clique em link roda para aquele contato, E o clique em link rastreável é oferecido na lista de gatilhos do editor de automações; E, Dado um clique sem id de envio, ou com id de envio que não pertence àquele link, ou com id de envio emitido por outra empresa, Então o visitante é redirecionado e o clique é contabilizado, E nenhum contato é atribuído, E nenhuma automação é iniciada, de nenhuma empresa; E dois links de empresas diferentes nunca existem com o mesmo endereço curto.
• Notas: este requisito prometia, até 2026-07-15, que o clique era registrado no histórico do contato e podia servir de gatilho para uma automação. As duas coisas eram falsas, e o erro estava na direção inversa da usual: não era o produto que estava atrasado em relação ao documento, era o documento que afirmava como existente o que nunca existiu. O clique era gravado sem contato atribuído, porque a chamada que o registrava passava o contato como nulo de forma fixa, então não havia a quem inscrever numa automação, e o clique não estava entre os gatilhos nomeados pelo RF-AUTO-002. Atribuir o contato exigiu que o link curto passasse a carregar o contato desde o momento do envio, e isso foi desenho novo, não ajuste. A correção foi decidida em 2026-07-15 na direção certa, pelo produto alcançar o documento e não pelo documento baixar a promessa: o H1 acima, que prometia só o redirecionamento e a contagem, passou a exigir o contato identificado no registro, a aparição no histórico do contato e o disparo da automação, e as regras acima passaram a dizer como o clique ganha dono. Quem entregou isso foi o {AUD-51} do Roadmap, irmão do {AUD-31}, fechado no mesmo dia, merge 109857f: o requisito passou a ser cumprido de fato, provado por clique real de um contato de teste, com a automação disparando e o histórico gravando o clique com o contato identificado. É exatamente para isso que o H1 serve, e requisito que não reprova nada não gateia nada. O RF-AUTO-002 nomeia o clique entre os gatilhos desde esta emenda, e a lista da tela só passa a oferecê-lo junto com o emissor, nunca antes dele, como manda a regra de honestidade da lista. Esta nota não é apagada por ter sido corrigida: o valor dela é lembrar que o documento já afirmou como existente o que não existia.

RF-CONV-054: Honestidade do envio (não despachar por canal não utilizável, nem registrar como enviado o que não saiu)

• Descrição: garantir que nenhum ponto do produto chame o canal externo quando o canal da empresa não está utilizável, e que a interface e o registro só apresentem uma mensagem como enviada quando ela de fato foi despachada pelo canal. Sem canal conectado, com o canal em erro, ou havendo falha no despacho, a mensagem nunca aparece nem fica registrada como enviada, e o motivo fica nomeado onde quem pode resolver vai encontrá-lo.
• Regra do alcance (é a regra que gera o conjunto, e é ela que vale, nunca uma lista): este requisito alcança todo ponto do produto que despacha mensagem de saída para um canal externo em nome de uma empresa, seja qual for o iniciador do despacho, haja ou não pessoa diante da tela. A propriedade é o critério e é a única condição: se o ponto chama o canal externo para entregar mensagem ao contato, ele está dentro, e nada mais o exclui. Um despachante novo entra no alcance por existir, e não por alguém se lembrar de acrescentá-lo a uma lista aqui. O conjunto é levantado por construção, a partir de quem chama o canal externo, e nunca por lista mantida à mão: lista à mão envelhece no dia em que nasce o despachante seguinte, e foi assim, sem que uma linha deste requisito mudasse, que ele deixou de alcançar a maior parte dos pontos que deveria alcançar.
• Regra do desfecho por iniciador (o invariante é único, o desfecho é que varia): o invariante vale para todos os despachantes, sem exceção, e é este: nunca chamar o canal externo com o canal não utilizável, e nunca afirmar envio que não houve. O desfecho depende de haver ou não uma pessoa diante da tela esperando por aquele envio. Havendo pessoa, o envio é impedido ou marcado como falha, com aviso claro na hora, porque há quem veja e resolva na hora. Não havendo pessoa, o despacho simplesmente não acontece, o fato fica registrado com o motivo nomeado no registro próprio daquele despachante, e o fluxo que o contém não é marcado como quebrado por causa disso, porque o problema é um só, é da empresa, e aparece no lugar dele, em Integrações. O passo ignorado da Regra da empresa sem canal conectado do RF-AUTO-044 é a instância desta regra no motor de automação, e não uma exceção a ela.
• Prioridade: Alta
• Atores: Member e Org Owner/Admin (despacham diante da tela), sistema (o motor de automação, as rotinas agendadas e o robô de conversa despacham sem pessoa diante da tela)
• H1: Dado uma empresa cujo canal não está utilizável (não conectado, ou em erro), Quando qualquer ponto do produto que despacha mensagem de saída tenta enviar por aquele canal, independentemente de quem iniciou o despacho e de haver ou não pessoa diante da tela, Então o canal externo não é chamado, E nenhuma mensagem é apresentada nem registrada como "enviada", E o motivo fica nomeado onde quem pode resolver o encontra; E o despacho iniciado por pessoa diante da tela é impedido ou marcado como falha, com aviso claro na hora; E o despacho iniciado sem pessoa diante da tela não marca como quebrado o fluxo que o contém; E, Dado o conjunto dos pontos do produto que despacham mensagem de saída, Quando esse conjunto é levantado por construção, a partir de quem chama o canal externo, e não por lista mantida à mão, Então todo ponto desse conjunto confere que o canal está utilizável antes de despachar, E o placar fecha: os que conferem são o conjunto inteiro, e os que não conferem são nenhum.
• Notas: emendado em 2026-07-16 pelo {AUD-88} do Roadmap de Implementação, que nasceu par do {AUD-83}, o card que entrega o produto a este texto. Até esta emenda o gatilho do H1 era "Quando o operador tenta enviar uma mensagem", e o verbo delimitava: "o operador tenta enviar" não alcança "o robô responde". O defeito era do documento, e não do produto, e é por isso que a emenda veio antes do código. O levantamento de 2026-07-16 encontrou quatro pontos despachando mensagem por WhatsApp, e um deles, o robô de conversa, não era reprovado por requisito nenhum: este requisito só disparava para o operador, e o RF-AUTO-044 só dispara quando a automação roda para um contato, e um robô respondendo uma conversa não é uma automação. Esse quatro é a contagem de uma data, e não é a definição do conjunto: quem define o conjunto é a Regra do alcance acima, e é de propósito que o requisito não dependa de quantos são, porque o número envelhece e a propriedade não. Enumerar os despachantes aqui seria repetir o erro que o {AUD-43} encontrou no RF-AUTO-002, onde uma lista ilustrativa conviveu com oito gatilhos sem emissor sem nunca ser violada. O texto anterior deste requisito nasceu da auditoria de 2026-07-10 (o {AUD-02}) e continua valendo no que dizia: este é a raiz do sintoma "parece conectado mas nada chega", indicar sucesso sem entrega real. Enquanto o {AUD-83} não fechar, este requisito está violado em produção nos pontos que ele passou a alcançar, o que é o estado correto do documento: quem alcança o requisito é o produto, não é o requisito que baixa a promessa.

4.4 Experiência e Interface (RF-UX)

RF-UX-001: Paridade estrutural com o GHL (navegação)

• Descrição: replicar a estrutura de navegação do GHL em dois níveis: a barra da agência (para o Super Admin/agência) e a barra da subconta (para a operação da empresa), com os mesmos grandes itens que o operador de GHL reconhece, em português.
• Prioridade: Essencial
• Atores: todos os papéis autenticados
• H1: Dado um operador logado, Quando ele navega pelo sistema, Então encontra a barra lateral da empresa com os itens equivalentes ao GHL (Painel, Conversas, Calendários, Contatos, Tarefas, Oportunidades, Produtos, Pagamentos, Marketing, Automação, Integrações, Relatórios), E o Super Admin/agência encontra a barra da agência (Painel, Subcontas, Planos, Modelos, Marca, Faturas, Configurações).

RF-UX-002: Modo escuro completo

• Descrição: oferecer modo claro e escuro em todo o sistema, com preferência persistida, sem áreas quebradas no escuro (diferencial sobre o GHL, que só tem claro).
• Prioridade: Alta
• Atores: todos os papéis autenticados
• H1: Dado um usuário, Quando ele alterna para o modo escuro, Então todas as telas ficam legíveis e consistentes no escuro, E a preferência é lembrada na próxima visita.

RF-UX-003: Responsividade para celular

• Descrição: funcionar de forma utilizável em telas de celular (a partir de 375px de largura), sem rolagem horizontal indevida, sendo web responsivo no lugar de um app separado.
• Prioridade: Alta
• Atores: todos os papéis autenticados
• H1: Dado um usuário em um celular de 375px, Quando ele usa as telas principais, Então o conteúdo se ajusta à largura sem rolagem horizontal quebrada, E as ações essenciais permanecem acessíveis.

RF-UX-004: Acessibilidade (WCAG AA)

• Descrição: atender aos critérios de acessibilidade nível AA (contraste, foco visível, navegação por teclado, rótulos), verificáveis por ferramenta automatizada e por revisão.
• Prioridade: Alta
• Atores: todos os papéis autenticados
• H1: Dado uma tela principal, Quando é auditada por ferramenta de acessibilidade e por teclado, Então não apresenta violações de nível A/AA nos itens verificados, E os fluxos essenciais são operáveis só com teclado.

RF-UX-005: Design system por tokens

• Descrição: centralizar os valores visuais (cores, tipografia, espaçamento, raio, sombra, formato de botão) em uma única fonte de tokens, da qual todas as telas puxam, no lugar de valores soltos espalhados.
• Prioridade: Alta
• Atores: equipe de produto (interno)
• H1: Dado o sistema de estilos, Quando uma tela nova é construída, Então ela consome os tokens centrais em vez de valores fixos, E uma mudança de token se reflete de forma consistente em todo o sistema.
• Notas: pendência explícita aberta no congelamento; validar com o dono antes de mexer em interface.

RF-UX-006: Microinterações e animações

• Descrição: prover transições e microinterações que deem resposta imediata às ações (estados de carregamento, transições suaves), sem prejudicar desempenho.
• Prioridade: Média
• Atores: todos os papéis autenticados
• H1: Dado uma ação do usuário, Quando ela é disparada, Então há resposta visual imediata (carregando, sucesso, erro), E as animações não travam a interface.

RF-UX-007: Estados vazios e de carregamento

• Descrição: apresentar estados vazios informativos com chamada para ação e estados de carregamento claros, em vez de telas em branco.
• Prioridade: Média
• Atores: todos os papéis autenticados
• H1: Dado uma tela sem dados ainda, Quando o usuário a abre, Então vê um estado vazio explicativo com uma ação sugerida, E durante o carregamento vê um indicador claro no lugar de tela branca.

5. Módulos Secundários

Os módulos abaixo entram depois dos quatro pilares core estarem completos. No congelamento, todos já tinham código em produção ou avançado; o estado de cada um aparece em Entrega e Evolução e no Roadmap de Implementação.

5.1 Automações (RF-AUTO)

RF-AUTO-001: Construtor visual de automações

• Descrição: montar automações num editor visual de arrastar e soltar, ligando um gatilho a uma sequência de ações e condições, no padrão de fluxo do GHL.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um administrador de empresa, Quando ele monta uma automação com um gatilho e ações no editor visual, Então a automação é salva com status de rascunho ou ativa, E passa a rodar para os contatos que atendem ao gatilho quando ativada.

RF-AUTO-002: Gatilhos

• Descrição: iniciar automações a partir de um conjunto fechado e nomeado de eventos. O produto oferece exatamente dezesseis gatilhos, e nenhum outro: contato criado, contato atualizado, contato respondeu, mensagem recebida, e-mail recebido, formulário enviado, tag adicionada, tag removida, etapa alterada, oportunidade ganha, oportunidade perdida, limite de armazenamento atingido, agendamento marcado, lembrete de agendamento, clique em link rastreável e execução manual. Os quinze primeiros são fatos do sistema: cada um tem um ponto no produto onde o fato acontece, e é desse ponto que o evento nasce. O décimo sexto, a execução manual, é caso à parte por desenho: nenhum fato o dispara sozinho, ele existe para que uma automação possa ser chamada por outra automação e para que o administrador possa rodá-la à mão pela tela, o que é objeto do RF-AUTO-043.
• Regra de honestidade da lista: a lista de gatilhos da tela não pode oferecer gatilho que o produto não dispara. Um gatilho só é oferecido ao administrador se existir, no ponto onde o fato acontece, o emissor que o dispara. Gatilho sem emissor sai da lista enquanto o emissor não existir, e não vale oferecê-lo com um aviso ao lado: a lista tem que dizer a verdade. A regra vale nos dois sentidos, e por canal: nada de gatilho oferecido sem emissor, nada de emissor sem o gatilho correspondente na lista, e nenhum gatilho que valha só para parte dos caminhos por onde o fato acontece.
• Regra do gatilho de contato atualizado (parte do requisito, não item opcional): ao escolher este gatilho, o administrador marca quais campos importam, e a automação só dispara quando um desses campos muda. Não existe a opção "qualquer campo". Sem o filtro o gatilho é enxurrada: corrigir um acento no nome mandaria mensagem ao cliente. A regra por canal vale aqui com força: o fato "o campo mudou" acontece pela tela, pela importação de contatos, pela interface de programação e pela ação de uma automação, e o gatilho tem que valer para todos esses caminhos, não só para a edição feita na tela. Guarda contra laço: a edição feita pela própria automação não a redispara.
• Regra do gatilho de clique em link rastreável (parte do requisito, não item opcional): o gatilho dispara quando um contato identificado clica num link rastreável da empresa, e é o RF-CONV-014 que descreve como o clique ganha dono. Só há disparo com contato atribuído: o clique anônimo redireciona o visitante e entra no contador do link, e não inicia automação nenhuma, porque não há a quem inscrever e toda ação da automação depende de um contato. Qualquer link da empresa dispara, e nesta entrega não se escolhe qual: a escolha do link é card próprio do Roadmap, o {AUD-63}. A diferença para a regra do contato atualizado, que exige filtro, é deliberada e não descuido de redação: lá, sem filtro o gatilho vira enxurrada, porque corrigir um acento no nome mandaria mensagem ao cliente; aqui o clique é sempre ato intencional do contato, então disparar em qualquer link não inunda ninguém.
• Regra do lembrete de agendamento (dono único): o lembrete é uma automação que a empresa monta, com o texto que ela escolher, e não uma mensagem que o sistema manda por conta própria. Ao entregar este gatilho, o agendador deixa de enviar o lembrete sozinho, e as duas coisas acontecem na mesma entrega: enquanto os dois caminhos conviverem, o contato recebe dois lembretes do mesmo agendamento. O texto fixo de hoje deixa de viver no código e vira modelo editável pela empresa, com as variáveis do agendamento e do contato.
• Regra de continuidade do lembrete, empresa que já existe (o que a troca de mecanismo não pode perder): hoje toda empresa com lembrete configurado recebe o lembrete sem montar nada. Trocar o mecanismo não pode apagar esse comportamento em silêncio. Na virada, cada empresa que hoje tem lembrete ativo ganha a automação equivalente já provisionada e ativa, montada a partir da configuração de canais vigente e reproduzindo o texto atual, de modo que nenhum contato deixe de receber o lembrete no dia da troca: tirar o lembrete de quem já o tem seria perda que ninguém decidiu. A empresa passa a poder editar o texto, os canais e o momento, ou desligar a automação, e a partir daí a ausência do lembrete é escolha dela. Empresa que hoje está com o lembrete desligado continua sem lembrete, e a automação nasce inativa.
• Regra de continuidade do lembrete, subconta nova (decidida em 2026-07-15): a subconta nova nasce sem automação nenhuma, de lembrete ou de qualquer outra coisa, e quem quiser lembrete monta a automação. Aqui não existe um comportamento de hoje a preservar, e por isso a regra é a oposta da anterior: nada roda que o cliente não pediu, e a tela não vem cheia de coisa pronta. A assimetria entre os dois casos é deliberada, e não descuido de redação: na empresa que já existe o que está em jogo é uma perda silenciosa, e na subconta nova é um envio que ninguém pediu.
• Consequência aceita da regra da subconta nova (decidida, não esquecida): quem abre subconta nova e não souber que o lembrete existe fica sem lembrete, e ninguém reclama de um lembrete que nunca existiu, então a falta passa despercebida. Este custo foi pesado e aceito em 2026-07-15, e fica registrado aqui para que não seja lido depois como defeito nem corrigido por conta própria provisionando automação na subconta nova: reverter esta escolha exige emenda deste requisito antes do código.
• Fora do escopo atual, por decisão firmada (não são oferecidos na tela e não serão construídos agora): agendamento cancelado, status da conversa alterado, status de oportunidade alterado, fatura paga e fatura vencida. Os motivos do status da conversa alterado e das duas faturas estão registrados no Roadmap de Implementação, nos cards {AUD-54} e {AUD-55}. Agendamento cancelado sai por não ser nomeado aqui, e status de oportunidade alterado sai por ser redundante: oportunidade ganha e oportunidade perdida já são gatilhos próprios e cobrem os dois únicos desfechos que o produto grava. Sair da lista é decisão, não esquecimento: a reentrada de qualquer um deles exige emenda deste requisito antes do código.
• Reentrada registrada em 2026-07-15: o lembrete de agendamento e o contato atualizado estavam na lista de fora do escopo e voltaram ao conjunto no mesmo dia, por decisão de produto, com as regras acima (dono único do lembrete e filtro por campo obrigatório). O motivo da volta é de produto, não técnico: o lembrete passa a ser da empresa, com o texto dela, e o contato atualizado é útil desde que não seja enxurrada. A volta fica registrada aqui, e não só nos cards {AUD-52} e {AUD-53} do Roadmap, para que a diferença entre os dezesseis gatilhos deste requisito e os catorze que a tela oferece hoje seja lida como backlog especificado, e não como drift a ser reconciliado apagando os dois do requisito.
• Prioridade: Alta
• Atores: sistema (dispara), Org Owner/Admin (configura)
• H1: Dado o editor de automações aberto, Quando o administrador abre a lista de gatilhos, Então vê exatamente os dezesseis gatilhos nomeados acima e nenhum outro, E cada um dos quinze que são fato do sistema tem emissor real: provocado o fato correspondente para um contato, por qualquer caminho por onde aquele fato aconteça, a automação ativa com aquele gatilho dispara, o contato é inscrito e o evento fica registrado no histórico do contato, E o gatilho de contato atualizado dispara quando muda um dos campos que o administrador marcou e fica calado quando muda qualquer outro campo, E um agendamento de teste com lembrete produz exatamente uma mensagem de lembrete ao contato, nunca duas, E, na virada do mecanismo, toda empresa que tinha lembrete ativo antes passa a ter a automação de lembrete equivalente ativa depois, sem ter montado nada, E uma subconta criada depois da virada nasce com zero automações, de lembrete ou de qualquer outra, e não produz lembrete nenhum enquanto a empresa não montar e ativar a automação.
• Notas: o clique em link rastreável entrou na lista em 2026-07-15 como décimo sexto gatilho, com o {AUD-51} do Roadmap, e é o RF-CONV-014 que descreve como o clique ganha dono. Requisito emendado três vezes em 2026-07-15. Na primeira, deixou de listar "eventos como" isto ou aquilo: lista ilustrativa não reprova nada, e foi ela que permitiu que oito gatilhos sem emissor nenhum convivessem com este requisito sem violá-lo (ver {AUD-43}). Na segunda, recebeu de volta os dois gatilhos acima. Na terceira, recebeu o clique em link rastreável: o documento afirmava esse gatilho como existente antes de o emissor existir, e como a regra de honestidade da lista vale nos dois sentidos, o gatilho só entrou na lista junto com o emissor, nunca antes dele. A subconta nova era a última pendência deste requisito e foi respondida em 2026-07-15: nasce sem automação nenhuma, cabendo à empresa montar. As duas regras de continuidade acima registram os dois casos, assimétricos de propósito, e a consequência aceita da escolha; o registro da pergunta e do racional está no Questionário de Elicitação, pergunta {Q1}.

RF-AUTO-003: Ações

• Descrição: executar ações dentro da automação, como enviar mensagem por um canal, adicionar ou remover tag, criar tarefa, mover a oportunidade no funil, ajustar pontuação e ramificar por condição.
• Prioridade: Alta
• Atores: sistema
• H1: Dado um contato inscrito numa automação, Quando o fluxo chega a uma ação, Então a ação é executada (mensagem enviada, tag aplicada, tarefa criada, etc.), E o resultado é registrado no histórico do contato.

RF-AUTO-004: Espera temporizada

• Descrição: pausar o fluxo por um tempo definido (minutos, horas, dias) antes de seguir, usando a fila de trabalhos.
• Prioridade: Alta
• Atores: sistema
• H1: Dado uma automação com um passo de espera, Quando o contato chega nesse passo, Então o fluxo aguarda o tempo configurado, E retoma automaticamente no passo seguinte quando o tempo vence.

RF-AUTO-005: Condições de saída

• Descrição: remover um contato da automação quando ele atende a uma condição de saída (por exemplo, respondeu, agendou, comprou), evitando follow-up desnecessário.
• Prioridade: Média
• Atores: sistema, Org Admin (configura)
• H1: Dado uma automação com condição de saída, Quando um contato inscrito atende a essa condição, Então ele é retirado do fluxo, E não recebe os passos seguintes.

RF-AUTO-006: Modelos de automação

• Descrição: oferecer modelos prontos de automação que a empresa pode aplicar e adaptar.
• Prioridade: Média
• Atores: Org Owner/Admin, Super Admin (curadoria)
• Regra do modelo aplicável (emenda de 2026-07-16, e é o coração deste requisito): o modelo aplicado produz uma automação que o motor executa de verdade. Nenhum modelo grava configuração que o motor não honra, e todo dado que o modelo pressupõe (a tag que ele promete, o funil que ele aponta) ou já existe na empresa ou passa a existir no momento em que o modelo é aplicado. A regra vale no ato de aplicar, e não depois de o administrador consertar: um modelo que só funciona após edição manual não é modelo, é um rascunho quebrado.
• H1: Dado uma biblioteca de modelos, Quando o administrador aplica um modelo, Então uma automação editável é criada a partir dele, E pode ser ajustada antes de ativar, E todo passo dela aponta para referências que existem na empresa e que o motor resolve (a tag pelo identificador dela, o funil pelo identificador dele), E, Quando a automação resultante roda para um contato sem que o administrador tenha alterado nada, Então nenhum passo dela é registrado como falha por configuração inválida; passo registrado como ignorado por ausência de canal conectado da empresa não viola este aceite, porque é a divergência deliberada do RF-AUTO-044.
• Notas: a regra do modelo aplicável e o H1 correspondente nasceram em 2026-07-16, do planejamento do {AUD-75} do Roadmap de Implementação. A ausência tinha consequência, e é a mesma família do RF-AUTO-044: até esta data este requisito exigia apenas que a automação fosse criada e editável, então um modelo que entrega passo quebrado em um clique PASSAVA no aceite e convivia com o documento sem nunca violá-lo. O RF-AUTO-044 não cobria a lacuna, e mais: ele abençoava o estado, porque exige que configuração inválida vire falha nomeada, que é o que o produto passou a fazer. Requisito que não reprova nada não gateia nada. O aceite testa ausência de falha por configuração inválida, e não presença de efeito, de propósito: presença de efeito dependeria do canal conectado e colidiria com a divergência deliberada do RF-AUTO-044, além de ser impossível de exercitar na empresa de teste. Enquanto o {AUD-75} não fechar, este requisito está violado em produção pelo modelo "Welcome + Tag", o que é o estado correto do documento.

RF-AUTO-007: Organização, status e métricas

• Descrição: organizar automações em pastas, exibir status (rascunho/ativa) e métricas de inscritos (total e ativos) e data de atualização, no padrão da lista de workflows do GHL.
• Prioridade: Média
• Atores: Org Owner/Admin
• H1: Dado a lista de automações, Quando o administrador a consulta, Então vê nome, status, total de inscritos, inscritos ativos e última atualização, E pode agrupar em pastas.

RF-AUTO-043: Executar uma automação à mão para um contato escolhido

• Descrição: oferecer, na tela da automação, a ação de executar agora, que roda a automação na hora para um contato escolhido pelo administrador, sem esperar o gatilho. O uso principal é testar uma automação antes de ativá-la, vendo o que ela faz de verdade com um contato real de teste; o uso secundário é rodar sob demanda uma automação sem gatilho automático. A execução manual é registrada como qualquer outra, com o autor, o momento e o resultado de cada ação.
• Prioridade: Média
• Atores: Org Owner/Admin (executa), sistema (roda e registra)
• H1: Dado uma automação em rascunho e um contato escolhido, Quando o administrador manda executar agora pela tela e confirma o aviso de que as ações são reais, Então a automação roda para aquele contato na hora, inclusive estando em rascunho e inclusive sem gatilho automático, E a execução aparece no histórico de execuções da automação e no histórico do contato, identificada como execução manual e com o autor registrado, E quem não tem sessão válida com vínculo à empresa da automação não consegue executar nada por este caminho.
• Notas: decidido em 2026-07-15; ver o {AUD-56} do Roadmap de Implementação. Executar uma automação envia mensagem de verdade ao contato escolhido e consome cota, por isso o aviso antes de confirmar e a exigência de sessão com vínculo fazem parte do aceite, e não são detalhe de implementação (ver o RNF-010, Perímetro autenticado). Este requisito é o que torna honesto o rótulo do gatilho de execução manual do RF-AUTO-002: enquanto o botão não existir, a opção continua se apresentando como "sem gatilho automático (chamada por outra automação)", porque a tela não pode prometer o que não faz; entregue o botão, o rótulo passa a dizer que a automação roda por chamada de outra automação ou por execução manual pela tela. Não confundir com a ação manual dentro do fluxo (RF-AUTO-027), que é um passo que espera um usuário concluir: aqui se dispara a automação inteira à mão.

RF-AUTO-044: Honestidade do registro de execução (não registrar como concluído o passo que não teve efeito)

• Descrição: garantir que o estado registrado de cada passo de uma automação diga o que de fato aconteceu. O produto distingue três desfechos, e somente três: concluído, quando o efeito pretendido pelo passo aconteceu (a informação foi gravada, o canal aceitou o despacho, o desvio foi tomado); ignorado, quando uma pré-condição legítima estava ausente e não havia o que fazer; e falha, quando o passo foi montado de forma inválida ou sofreu um erro real. Passo ignorado não interrompe a automação, que segue para o passo seguinte. Passo em falha interrompe a automação. O motivo do ignorado e o erro da falha ficam nomeados no registro da execução, ao alcance de quem abre o histórico, e não apenas no registro técnico do servidor.
• Regra do discriminador (é o coração deste requisito, e é a pergunta que decide todo caso novo): a ausência que impediu o efeito é do dado ou da empresa, ou é da configuração do passo? Ausência do dado ou da empresa (o contato não tem telefone, o contato não tem e-mail, a empresa não conectou o canal, o contato pediu para não receber mensagens, não havia tag a remover) é propriedade do mundo, e não defeito do fluxo: o passo fica ignorado, com o motivo nomeado, e a automação segue. Ausência da configuração (o passo aponta para uma referência que não existe, o passo pede uma ação que o produto não executa, o desvio aponta para um passo que não existe) é erro de quem montou o fluxo, e não vai funcionar nunca por si mesma: o passo fica em falha, com o erro nomeado, e a automação para.
• Regra da empresa sem canal conectado (divergência deliberada, decidida em 2026-07-16): empresa sem canal conectado gera passo ignorado, e não falha. Isto divergiu da letra do RF-CONV-054 até 2026-07-16, e a divergência era de propósito, não descuido de redação. Desde a emenda que o {AUD-88} fez naquele requisito no mesmo dia, deixou de ser divergência: o RF-CONV-054 passou a prescrever o desfecho por iniciador, e este passo ignorado é a instância dele no motor, não uma exceção a ele. A razão nunca mudou, e é esta: lá quem tenta enviar é o operador diante da tela, que vê o aviso na hora e resolve; aqui quem roda é o motor, sozinho, sobre muitos contatos de uma vez. Uma automação de boas-vindas com mensagem, rodando para quinhentos contatos numa empresa que ainda não conectou o canal, produziria quinhentas execuções em vermelho acusando de quebrado um fluxo que está perfeito, por um problema que é um só, é da empresa, e aparece no lugar dele, em Integrações. Marcar falha demais não é barulho tolerável: é a mesma desonestidade deste requisito virada do avesso, porque um registro que grita falha onde não houve falha engana tanto quanto um que grita sucesso onde não houve efeito. Reverter esta escolha exige emenda deste requisito antes do código.
• Regra do estado desejado (decidida em 2026-07-16): quando o passo pede um estado que já vale, o passo fica concluído, e não ignorado. Remover uma tag que o contato não tem é concluído: o que o passo quer é que a tag não esteja lá, e ela não está. O mesmo vale para retirar o contato de uma automação em que ele não estava inscrito. O que se mede é o estado alcançado, e não a quantidade de trabalho feito.
• Regra de honestidade da lista de ações (espelha a regra que o RF-AUTO-002 firmou para os gatilhos): a lista de ações que a tela oferece é exatamente a lista de ações que o motor executa. A regra vale nos dois sentidos: nada de ação oferecida na tela que o motor não executa, nada de ação no motor que a tela não oferece. Ação que o produto não executa nunca é registrada como concluída, em circunstância nenhuma. A cláusula existe porque a alternativa é o pior desfecho possível deste requisito: um passo que o administrador configura, salva, ativa, vê verde, e que não faz nada, para sempre. O estado de hoje viola a regra nos dois sentidos, e o Roadmap de Implementação o trata no card {AUD-74}.
• Prioridade: Alta
• Atores: Org Owner/Admin (monta a automação e lê o histórico), sistema (roda e registra)
• H1: Dado uma automação ativa cujo passo não produz o efeito pretendido, seja porque a configuração é inválida (o passo aponta para uma referência que não existe, ou pede uma ação que o produto não executa), seja porque uma pré-condição legítima está ausente (o contato não tem telefone, a empresa não conectou o canal), Quando a automação roda para um contato, Então nenhum desses passos fica registrado como concluído, E o passo de configuração inválida fica registrado como falha, com o erro nomeado, e a automação para nele, E o passo sem pré-condição fica registrado como ignorado, com o motivo nomeado, e a automação segue para o passo seguinte; E, Dado uma automação cujos passos têm efeito, Quando ela roda, Então cada passo fica registrado como concluído e o efeito existe de verdade e é verificável fora do próprio registro (a tag está no contato, a atividade está no histórico, o canal aceitou o despacho), E a execução inteira não fica marcada como falha por causa de passo ignorado; E, Dado a lista de ações do editor de automações, Quando ela é comparada com as ações que o motor executa, Então as duas listas são idênticas, sem ação oferecida que o motor não execute nem ação no motor que a tela não ofereça.
• Notas: requisito novo em 2026-07-16, nascido do planejamento do {AUD-68} do Roadmap de Implementação. Ele não estava escrito, e a ausência tinha consequência: até esta data nenhum requisito reprovava um passo que afirma sucesso sem ter feito nada, então o comportamento convivia com o documento sem nunca violá-lo. É requisito próprio, e não emenda do RF-CONV-054, porque lá o objeto é a mensagem e aqui metade dos casos não é mensagem nenhuma (adicionar tag não é envio). Quando este requisito nasceu, a separação também se apoiava no gatilho do H1 de lá, que era o operador tentando enviar pela tela; o {AUD-88} emendou aquele gatilho no mesmo dia, para alcançar qualquer despachante, e a separação continua de pé pelo motivo que sempre a sustentou: o RF-CONV-054 governa o despacho pelo canal, venha ele de quem vier, e este governa o que o registro da execução afirma sobre cada passo, despache ele ou não. O RF-AUTO-003 continua sendo o requisito do que cada ação faz; este é o requisito do que o registro afirma sobre ela. A entrega está no {AUD-68}, e enquanto ela não acontecer este requisito está violado em produção, o que é o estado correto do documento: quem alcança o requisito é o produto, não é o requisito que baixa a promessa.

5.2 Calendário e Agendamento (RF-CAL)

RF-CAL-001: Calendários e regras de disponibilidade

• Descrição: criar calendários com regras de disponibilidade (dias, horários, duração, intervalos), como base para agendamentos.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um calendário com regras de disponibilidade, Quando um horário é solicitado, Então só os horários dentro das regras ficam disponíveis, E horários fora da regra não podem ser marcados.

RF-CAL-002: Página pública de agendamento

• Descrição: publicar uma página onde o contato externo escolhe um horário disponível e agenda, sem precisar de login.
• Prioridade: Alta
• Atores: Contato externo, Org Owner/Admin (configura)
• H1: Dado uma página pública de agendamento ativa, Quando um visitante escolhe um horário livre e confirma, Então um agendamento é criado e vinculado a um contato, E o horário deixa de aparecer como disponível.

RF-CAL-003: Sincronização com Google Calendar

• Descrição: sincronizar os agendamentos com o Google Calendar nos dois sentidos, evitando conflitos de horário.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um calendário conectado ao Google, Quando um agendamento é criado no ModularCRM ou no Google, Então ele aparece nos dois lados, E um horário ocupado no Google bloqueia a disponibilidade no ModularCRM.

RF-CAL-004: Reagendamento e cancelamento por link

• Descrição: permitir que o contato reagende ou cancele por um link seguro, sem login.
• Prioridade: Média
• Atores: Contato externo
• H1: Dado um agendamento com link de reagendamento, Quando o contato acessa o link e escolhe outro horário livre, Então o agendamento é atualizado, E o horário anterior é liberado.

RF-CAL-005: Exceções de disponibilidade

• Descrição: registrar exceções pontuais (bloqueios, folgas, horários extras) sobre as regras padrão.
• Prioridade: Média
• Atores: Org Owner/Admin
• H1: Dado uma regra de disponibilidade padrão, Quando o administrador cria uma exceção para uma data, Então essa data passa a respeitar a exceção, E as demais datas seguem a regra padrão.

RF-CAL-006: Confirmações e lembretes

• Descrição: enviar confirmação no ato do agendamento e lembretes antes do horário, pelos canais configurados.
• Prioridade: Média
• Atores: sistema, Contato externo
• H1: Dado um agendamento confirmado, Quando ele é criado e quando se aproxima do horário, Então o contato recebe confirmação e lembrete pelos canais configurados, E o envio fica registrado.

5.3 Oportunidades e Funis (RF-OPP)

RF-OPP-001: Funis e estágios configuráveis

• Descrição: criar funis de vendas com estágios personalizados por empresa.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um administrador de empresa, Quando ele cria um funil com estágios, Então o funil fica disponível para receber oportunidades, E os estágios podem ser renomeados e reordenados.

RF-OPP-002: Oportunidades no funil

• Descrição: cadastrar oportunidades ligadas a contatos e movê-las entre estágios num quadro visual (kanban).
• Prioridade: Alta
• Atores: Member, Org Owner/Admin
• H1: Dado um funil com estágios, Quando o operador cria uma oportunidade e a arrasta entre estágios, Então a posição é atualizada e registrada no histórico do contato, E o valor total por estágio é refletido.

RF-OPP-003: Produtos e valores

• Descrição: associar produtos e valores às oportunidades, compondo o valor do negócio.
• Prioridade: Média
• Atores: Member, Org Owner/Admin
• H1: Dado uma oportunidade, Quando o operador adiciona produtos com preço, Então o valor da oportunidade reflete a soma, E os produtos ficam registrados na oportunidade.

RF-OPP-004: Orçamentos e pedidos

• Descrição: gerar orçamentos e pedidos a partir de oportunidades e produtos.
• Prioridade: Média
• Atores: Member, Org Owner/Admin
• H1: Dado uma oportunidade com produtos, Quando o operador gera um orçamento, Então o orçamento é criado com os itens e valores, E pode evoluir para um pedido.

5.4 Tarefas (RF-TASK)

RF-TASK-001: Gestão de tarefas

• Descrição: criar, atribuir, agendar e concluir tarefas, ligadas a contatos ou oportunidades.
• Prioridade: Alta
• Atores: Member, Org Owner/Admin
• H1: Dado um contato ou oportunidade, Quando o operador cria uma tarefa com responsável e prazo, Então a tarefa aparece para o responsável, E pode ser marcada como concluída e fica no histórico.

5.5 Cobrança e Assinaturas (RF-BILL)

RF-BILL-001: Cobrança Pix manual (V1)

• Descrição: cobrar as assinaturas por Pix manual estático na V1, sem gateway de cartão.
• Prioridade: Essencial
• Atores: Super Admin, Org Owner
• H1: Dado uma assinatura a cobrar, Quando a cobrança é emitida, Então a empresa recebe os dados de Pix para pagamento, E o pagamento é conciliado e registrado na fatura.

RF-BILL-002: Faturas da organização

• Descrição: gerar e acompanhar faturas por empresa, com status (aberta, paga, vencida).
• Prioridade: Alta
• Atores: Super Admin, Org Owner
• H1: Dado o histórico de uma empresa, Quando uma fatura é gerada, Então ela aparece com valor, vencimento e status, E o status é atualizado quando paga.

RF-BILL-003: Renovação automática e lembretes

• Descrição: renovar assinaturas por rotina automática e enviar e-mails de lembrete de vencimento.
• Prioridade: Média
• Atores: sistema, Org Owner
• H1: Dado uma assinatura ativa, Quando se aproxima o vencimento, Então uma nova fatura é gerada pela rotina e um lembrete é enviado, E a falta de pagamento reflete no status.

RF-BILL-004: Receita recorrente (MRR) e ações em massa

• Descrição: apresentar ao Super Admin um painel de receita recorrente e permitir ações em massa e exportação sobre as faturas.
• Prioridade: Média
• Atores: Super Admin
• H1: Dado o conjunto de assinaturas, Quando o Super Admin abre o painel financeiro, Então vê a receita recorrente consolidada, E consegue exportar e agir em massa sobre as faturas.
• Notas: nota fiscal automática fica para a V2; na V1 é manual.

5.6 Portal de Agência e White-label (RF-AGY)

RF-AGY-001: Subcontas

• Descrição: permitir que uma agência crie e administre várias organizações-cliente (subcontas) a partir de um painel único.
• Prioridade: Alta
• Atores: Administrador de agência, Super Admin
• H1: Dado um administrador de agência, Quando ele cria uma subconta, Então uma nova organização isolada é provisionada, E ele consegue alternar entre as subcontas que administra.

RF-AGY-002: Modelos prontos (snapshots)

• Descrição: capturar uma configuração-modelo (funis, campos, automações, etc.) e aplicá-la a novas subcontas.
• Prioridade: Média
• Atores: Administrador de agência
• H1: Dado um modelo capturado, Quando o administrador o aplica a uma subconta, Então a subconta recebe a configuração do modelo, E o resultado da aplicação fica registrado.

RF-AGY-003: Planos

• Descrição: definir planos (limites, preços, recursos) atribuíveis às empresas.
• Prioridade: Alta
• Atores: Super Admin, Administrador de agência
• H1: Dado os planos cadastrados, Quando um plano é atribuído a uma empresa, Então os limites e recursos do plano passam a valer para ela, E a mudança de plano é editável sem depender de alteração no banco.

RF-AGY-004: White-label (marca própria)

• Descrição: permitir que a agência apresente o sistema com a própria marca (nome, logo, domínio, cores) para os clientes dela.
• Prioridade: Média
• Atores: Administrador de agência
• H1: Dado uma agência com marca configurada, Quando um cliente dela acessa o sistema, Então vê a identidade da agência, E não vê a marca do fornecedor.

RF-AGY-005: Faturas e revenda da agência

• Descrição: acompanhar as faturas no nível da agência, base para a revenda do sistema aos clientes.
• Prioridade: Média
• Atores: Administrador de agência, Super Admin
• H1: Dado uma agência com subcontas, Quando o período fecha, Então as faturas da agência refletem as subcontas ativas, E ficam disponíveis para consulta.

RF-AGY-006: Regras e modelos globais

• Descrição: permitir ao Super Admin definir regras e modelos globais (por exemplo, regras de pontuação) herdados por todas as empresas.
• Prioridade: Média
• Atores: Super Admin
• H1: Dado uma regra global definida pelo Super Admin, Quando uma empresa não sobrescreve essa regra, Então ela herda a regra global, E pode ajustá-la no próprio escopo.

5.7 Relatórios (RF-REP)

RF-REP-001: Relatórios e painéis

• Descrição: apresentar relatórios e painéis de métricas relevantes (leads, conversas, funil, agendamentos), com possibilidade de salvar configurações.
• Prioridade: Alta
• Atores: Org Owner/Admin, Super Admin
• H1: Dado dados de operação de uma empresa, Quando o administrador abre os relatórios, Então vê as métricas do próprio negócio, E pode salvar uma configuração de relatório para reuso.

5.8 Biblioteca de Mídia (RF-MED)

RF-MED-001: Biblioteca central de mídia

• Descrição: guardar arquivos de mídia da empresa num repositório central, com envio por arrastar e soltar, visualização em grade ou lista, pastas e um seletor reutilizável nas telas que precisam de mídia.
• Prioridade: Média
• Atores: Org Owner/Admin, Member
• H1: Dado a biblioteca de mídia, Quando o operador envia um arquivo, Então ele fica disponível na biblioteca da empresa, E pode ser selecionado por um seletor reutilizável em mensagens e telas.

5.9 API Pública e Desenvolvedores (RF-DEV)

RF-DEV-001: Chaves de API por empresa

• Descrição: emitir chaves de API por empresa, com escopos de permissão, para integração externa.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um administrador de empresa, Quando ele gera uma chave de API com escopos, Então a chave autentica chamadas externas dentro daqueles escopos, E chamadas fora do escopo ou sem chave válida são rejeitadas.

RF-DEV-002: Assinaturas de eventos (webhooks de saída)

• Descrição: permitir que sistemas externos assinem eventos do ModularCRM e os recebam por webhook, com assinatura de segurança (HMAC), novas tentativas em caso de falha, fila de mortos e reenvio.
• Prioridade: Alta
• Atores: Org Owner/Admin, sistema externo
• H1: Dado uma assinatura de eventos configurada, Quando um evento assinado ocorre, Então o ModularCRM entrega o evento ao destino com assinatura verificável, E em caso de falha há novas tentativas e possibilidade de reenvio manual.

RF-DEV-003: Idempotência

• Descrição: garantir que uma mesma requisição repetida não gere efeito duplicado, por chave de idempotência.
• Prioridade: Alta
• Atores: sistema externo, sistema
• H1: Dado uma requisição com chave de idempotência, Quando ela é reenviada com a mesma chave, Então o efeito ocorre uma única vez, E a resposta é consistente entre as tentativas.

RF-DEV-004: Limite de requisições (rate limiting)

• Descrição: aplicar limites de requisição por política, protegendo o sistema de abuso.
• Prioridade: Média
• Atores: sistema
• H1: Dado uma política de limite para uma chave, Quando o limite é excedido, Então as requisições excedentes são recusadas com resposta clara, E voltam a ser aceitas quando a janela reinicia.

RF-DEV-005: Documentação e auditoria de API

• Descrição: oferecer documentação da API e registrar as chamadas para auditoria.
• Prioridade: Média
• Atores: Org Owner/Admin (consulta), sistema (registra)
• H1: Dado a área de desenvolvedores, Quando o administrador a acessa, Então encontra a documentação da API, E as chamadas ficam registradas para auditoria.

5.10 Integrações de Plataforma (RF-INT)

RF-INT-001: Conexão permanente multi-empresa com a Meta

• Descrição: conectar a conta Meta de cada empresa uma única vez e mantê-la funcionando sem religar de tempos em tempos. O mecanismo primário é o Login do Facebook para Empresas (Facebook Login for Business) com identificador de configuração (config_id) que retorna um acesso de usuário de sistema do próprio negócio do cliente, preso ao negócio e não a uma pessoa, sem expiração no caminho feliz. Para a empresa que não conclui a verificação de negócio exigida pela Meta há um caminho alternativo (acesso de usuário de longa duração com renovação), sinalizado na tela como menos permanente. A conexão é isolada por empresa. O acesso é do aplicativo Meta dedicado ao ModularCRM (ver a pendência de infraestrutura em 9.1).
• Prioridade: Essencial
• Atores: Org Owner/Admin (conecta), Super Admin (mantém o aplicativo dedicado e a configuração)
• H1: Dado o fluxo de conexão Meta pelo Login do Facebook para Empresas, Quando uma empresa autoriza uma única vez pelo caminho primário, Então fica gravado um acesso de usuário de sistema do negócio do cliente que não expira no caminho feliz, isolado só para aquela empresa, E religar deixa de ser exigência de operação normal, E a conexão pode ser revogada, E quando a empresa não tem verificação de negócio o caminho alternativo é usado e a tela sinaliza que a conexão é menos permanente.
• Notas: revisado em 2026-07-22 (council GO, requisito do dono: conecta uma vez, funciona sempre). Permanente é o caminho feliz, não garantia absoluta: a Meta pode invalidar o acesso por revogação da empresa, ponto de verificação de segurança ou política, e por isso a saúde da conexão e o alerta de reconexão (RF-INT-006) e a retenção do lead até reconectar (RF-CAPT-009) são parte obrigatória, não opcionais. O identificador do aplicativo, o segredo e o config_id são configuráveis pela operação por produto (RNF-008), nunca fixos no código.

RF-INT-002: Eventos de conversão para a Meta (CAPI server-side)

• Descrição: enviar eventos de conversão (por exemplo, compra) para a Meta pelo servidor (CAPI), melhorando a mensuração de campanhas.
• Prioridade: Alta
• Atores: sistema, Org Owner/Admin (configura)
• H1: Dado uma empresa com envio de conversões habilitado, Quando ocorre um evento de conversão, Então ele é enviado à Meta pelo servidor de forma confiável, E a entrega fica registrada.

RF-INT-003: Conexão com o Google

• Descrição: conectar contas Google (Ads, Analytics, Search Console, Merchant, Calendar) por autorização, isoladas por empresa.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado o fluxo de conexão Google, Quando uma empresa autoriza, Então os recursos Google contratados ficam disponíveis só para ela, E a conexão pode ser revogada.
• Notas: dependia da liberação do aplicativo Google no congelamento.

RF-INT-004: Conversões para o Google Ads (server-side)

• Descrição: enviar conversões ao Google Ads pelo servidor, análogo ao CAPI da Meta.
• Prioridade: Média
• Atores: sistema, Org Owner/Admin
• H1: Dado uma empresa com conversões Google habilitadas, Quando ocorre um evento de conversão, Então ele é enviado ao Google Ads pelo servidor, E a entrega fica registrada.

RF-INT-005: Gestão de conexões e tokens

• Descrição: gerenciar as conexões e os tokens de acesso das integrações, guardados de forma cifrada em repouso, com visão de status. O status distingue a conexão viva, a conexão permanente (acesso de usuário de sistema que não expira no caminho feliz) e a conexão que precisa de atenção, e oferece o caminho de reconectar quando necessário. O status mostrado reflete a saúde real do acesso (RF-INT-006), nunca "conectada" sobre um acesso morto.
• Prioridade: Essencial
• Atores: Org Owner/Admin, Super Admin
• H1: Dado as integrações de uma empresa, Quando o administrador consulta as conexões, Então vê o status real de cada uma (viva, permanente ou precisa reconectar), E os tokens ficam guardados cifrados, nunca expostos em tela, E uma conexão com acesso morto nunca aparece como "conectada".
• Notas: revisado em 2026-07-22 (council GO). O card AUD-42 do Roadmap trata o defeito de origem (a tela dizia "conectada" sobre acesso morto) e passa a ser resolvido pela conexão permanente (RF-INT-001) e pela saúde da conexão (RF-INT-006).

RF-INT-006: Saúde da conexão Meta e alerta de reconexão

• Descrição: monitorar por empresa a saúde de cada conexão Meta (validade e vencimento do acesso, permissões concedidas, assinatura do formulário e da página ativa, relação de negócio ativa) e avisar de forma proativa quando a conexão precisa de atenção. O aviso vai para a Central de Notificações, por empresa, com a marca da agência (nunca a marca do fornecedor), é acionável ("reconecte sua conta Meta para continuar recebendo leads"), e nunca é enviado por WhatsApp. Quando o acesso morre, a ingestão de eventos continua (RF-CAPT-008), o enriquecimento e a reconciliação pausam para aquela empresa preservando o ponto de leitura, e nada é descartado (degradação graciosa, RF-CAPT-009).
• Prioridade: Essencial
• Atores: sistema (monitora e alerta), Org Owner/Admin (reconecta), Super Admin (ajusta os limiares)
• H1: Dado uma conexão Meta de uma empresa, Quando o acesso fica inválido, perde uma permissão crítica ou se aproxima do vencimento no caminho alternativo, Então a empresa recebe na Central de Notificações um aviso acionável com a marca da agência para reconectar, E o status da conexão deixa de dizer "conectada", E a ingestão de leads continua enquanto o enriquecimento fica retido até reconectar, E nenhum aviso desse tipo é enviado por WhatsApp.
• Notas: introduzido em 2026-07-22 (council GO). O prazo do alerta proativo (valor inicial 7 dias antes do vencimento no caminho alternativo) e a janela de retenção considerada (aproximadamente 90 dias, limite da Meta) são editáveis pela operação (RNF-008). A marca da agência no aviso obedece ao isolamento white-label do produto.

6. Modelo de Dados## 6. Modelo de Dados

O sistema usa um banco único compartilhado com isolamento por organização: toda tabela de negócio carrega o identificador da empresa e é protegida por regras de segurança em nível de linha (RLS), de modo que cada empresa só enxerga as próprias linhas. As entidades estão agrupadas por domínio abaixo. A ficha técnica de cada artefato de dados está no Inventário de Artefatos.

6.1 Empresas, pessoas e acesso

• Organização (a empresa cliente) e seus planos, configurações, contadores de uso e registros de auditoria.
• Perfil de usuário, com o marcador de Super Admin do fornecedor.
• Vínculo de membro entre pessoa e organização, com o papel (dono, administrador, membro), que é a base do controle de acesso.

6.2 Contatos e gestão de leads

• Contato (a pessoa), com estado, dados de identificação, avatar e metadados; empresa (company) e o vínculo muitos para muitos entre contato e empresa.
• Tags e a associação de tags aos contatos.
• Definições de campos personalizados (por objeto e pasta) e os valores nos contatos.
• Identificadores de canal do contato e o histórico de mesclagem, que sustentam o contato unificado entre canais.
• Regras de pontuação (globais e por empresa), listas inteligentes, arquivos anexados e o histórico de atividades.

6.3 Funil e vendas

• Funis e seus estágios; oportunidades ligadas a contatos; produtos e a composição de produtos na oportunidade; orçamentos e pedidos; links de pagamento e cupons.

6.4 Conversas e mensagens

• Conversas e mensagens (com anexos), o modelo de mensagem e as respostas prontas.
• Configurações de canal por empresa: WhatsApp (provedor Evolution ou Meta Cloud), SMS, e as contas de e-mail (com a senha de IMAP guardada cifrada).
• Notificações de novas mensagens.

6.5 Automações

• Automações e seus passos, as execuções por contato e o estado de cada passo, os passos agendados (esperas na fila), as condições de saída, os modelos de automação e os links rastreáveis com seus cliques.

6.6 Calendário e agendamento

• Calendários e seus membros, as regras de disponibilidade e as exceções, os agendamentos, os tokens de reagendamento e o cache de eventos do Google.

6.7 Cobrança e agência

• Faturas da organização e faturas da agência, os modelos prontos (snapshots) e o registro de aplicação de modelo a subcontas.

6.8 Integrações e API pública

• Conexões de integração com tokens cifrados em repouso; eventos de conversão enviados à Meta.
• Formulários públicos e seus envios; campanhas com aberturas e cliques; relatórios salvos; biblioteca de mídia.
• Camada de API pública: chaves de API (guardadas com hash e escopos), assinaturas de eventos de saída (com segredo cifrado), registro de entregas, chaves de idempotência, políticas de limite e o registro de auditoria dessa camada.

7. Requisitos Não Funcionais

RNF-001: Isolamento multi-empresa. Toda tabela com identificador de organização é protegida por RLS; nenhuma tela, consulta ou automação pode retornar dados de outra empresa, nem gravar, alterar ou disparar ação em nome de outra empresa. O isolamento vale para leitura e para escrita. É requisito não negociável.

RNF-002: Segurança de credenciais. Tokens de integração e senhas de canal ficam cifrados em repouso; chaves de API são guardadas com hash forte e escopos; segredos não aparecem em tela nem em log.

RNF-003: Confiabilidade da entrega assíncrona. Envios (mensagens, webhooks de saída, conversões) passam por fila, com novas tentativas, fila de mortos e possibilidade de reenvio; a idempotência evita efeito duplicado.

RNF-004: Desempenho percebido. As telas principais respondem com estados de carregamento imediatos; listas grandes usam paginação; a interface não trava durante operações em segundo plano.

RNF-005: Disponibilidade em produção. O sistema opera em produção com o tenant piloto; os serviços de banco, recebimento (webhook), fila e canais ficam ativos e monitorados.

RNF-006: Observabilidade. Há registros de auditoria por empresa e rastreamento de erros; a origem de cada evento é identificável.

RNF-007: Acessibilidade e responsividade. Nível AA de acessibilidade e uso pleno em celular a partir de 375px (ver RF-UX-003 e RF-UX-004).

RNF-008: Editável pela operação. Valores, regras e limites que a operação queira ajustar têm tela de edição; nada exige mexer no banco ou refazer implantação para mudar configuração de negócio.

RNF-009: Isolamento de infraestrutura entre produtos. A infraestrutura do ModularCRM (banco, WhatsApp, fila) é dedicada e não é compartilhada com outros produtos do fornecedor.

RNF-010: Perímetro autenticado. Nenhum ator sem sessão válida pode ler, escrever ou disparar ação em nome de uma empresa. Todo endpoint de servidor alcançável pela internet exige token de sessão válido e a verificação de que essa sessão pertence a alguém com vínculo com a empresa alvo, sempre antes de qualquer efeito colateral (gravar dado, disparar automação, enviar mensagem a um contato, consumir cota). O identificador da empresa não vale como credencial: ele nunca muda e é conhecido por todo mundo que um dia teve acesso, então o endpoint que aceita o identificador como prova mantém na mão de quem já foi desligado o poder de agir em nome da empresa. Endpoints públicos por desenho (formulário público, página de agendamento, chat do site) são a exceção prevista: eles não recebem a empresa como parâmetro de quem chama, resolvem a empresa no servidor a partir do próprio endereço público e nunca expõem ação em nome de terceiro. A verificação de cada endpoint está no Plano de Testes e a fila de conserto no Roadmap.

8. Decisões Arquiteturais (ADRs)

ADR-001: Multi-tenant de banco único com RLS. Uma só base compartilhada, mesmo esquema para todas as empresas, isolamento por regras de segurança em nível de linha. Motivo: simplicidade operacional e custo, com isolamento garantido no banco.

ADR-002: Dois níveis de administração. Super Admin (fornecedor, visão cruzada) e papéis de organização (dono, administrador, membro). Motivo: separar a operação do fornecedor da operação de cada empresa.

ADR-003: WhatsApp com dois provedores à escolha. Central própria e gratuita (Evolution) como principal e a via oficial paga da Meta (Cloud API) como alternativa; a central Evolution é dedicada ao ModularCRM, nunca compartilhada com outro produto. Motivo: custo baixo por padrão, com opção oficial sem risco de bloqueio.

ADR-004: Cobrança Pix manual na V1. Gateway de cartão (Stripe) descartado; a V1 cobra por Pix manual, e a evolução para um meio automático (Asaas) fica para quando a operação justificar. Motivo: chegar ao mercado sem a complexidade de gateway.

ADR-005: Sites e funis de página fora de escopo. O ModularCRM não constrói sites nem funis de página; isso é um projeto separado. Motivo: foco no núcleo de CRM e conversas.

ADR-006: E-mail transacional auto-hospedado. Envio transacional por servidor próprio, no lugar de um serviço pago de terceiros. Motivo: autonomia e custo.

ADR-007: Tokens de integração cifrados em repouso. As credenciais de acesso das integrações ficam cifradas no banco. Motivo: reduzir o impacto de um vazamento de banco.

ADR-008: API pública desacoplada e resiliente. A camada de API pública usa fila para entregas, idempotência para evitar duplicidade, limite de requisições por política, chaves com hash e escopos, e assinatura de segurança nos webhooks de saída. Motivo: integrar com terceiros sem comprometer estabilidade nem segurança.

ADR-009: Contato unificado por identificadores de canal. Cada canal contribui com identificadores ligados a um único contato, reconciliados na entrada. Motivo: sustentar o princípio "um cliente, um contato".

ADR-010: Nota fiscal manual na V1. Emissão automática de nota fiscal fica para a V2; na V1 é manual. Motivo: reduzir escopo de integração fiscal no início.

ADR-011: Core primeiro. Os quatro pilares têm prioridade sobre qualquer funcionalidade lateral, com validação de escopo antes de construir. Motivo: garantir que o núcleo do produto esteja completo antes de expandir.

9. Entrega e Evolução

A ordem de construção e o estado de cada tarefa estão no Roadmap de Implementação. Em resumo, a evolução se deu em ondas:

Onda 1, os quatro pilares core (V1.0). Captura de leads, gestão de leads, conversas e interface, tratados como a base obrigatória antes de qualquer lateral. Em grande parte entregue e em produção.

Onda 2, módulos secundários. Automações, calendário e agendamento, oportunidades e funis, tarefas, cobrança, portal de agência, relatórios e biblioteca de mídia. Construídos após o núcleo, com código em produção ou avançado.

Onda 3, habilitação do primeiro cliente real. Um conjunto de sete frentes para colocar a Hiit Fitwear como primeiro tenant real e destravar recursos genéricos reutilizáveis por qualquer cliente futuro: portal de agência, variáveis de produção, API de eventos de saída, envio de conversões à Meta pelo servidor, envio de conversões ao Google Ads, WhatsApp multi-empresa de ponta a ponta, e o reforço de guardar tokens cifrados em repouso.

9.1 Estado no congelamento (referência para a retomada)

O projeto foi congelado por volta de maio de 2026 já em produção com o tenant piloto. Ficaram pendentes, como próximos passos para a retomada:

1. Conectar os canais da Hiit: ler o QR Code para conectar o WhatsApp e concluir a conexão da conta Meta da empresa piloto. São ações operacionais, não de código.
2. Revisão do aplicativo Meta: concluir o processo de revisão das permissões junto à Meta para sair do modo de desenvolvimento.
3. Conectores Google: finalizar a captura de leads e o envio de conversões pelo Google, que dependiam da liberação do aplicativo Google.
4. Envio de conversões à Meta pelo servidor (CAPI): frente que estava em andamento no congelamento.
5. Polimento de interface: concluir o ciclo de redesign e padronizar o sistema de estilos por tokens (validar com o dono antes de mexer em interface, ver RF-UX-005).
6. Dívida técnica pontual: separar a chave de serviço de inteligência artificial, hoje compartilhada com outro produto do fornecedor, antes de qualquer funcionalidade de IA entrar em produção.
7. Aplicativo Meta dedicado ao ModularCRM (pendência de infraestrutura, passo humano): criar na conta de negócio do fornecedor um aplicativo Meta dedicado à captura de leads, separado do aplicativo usado pelo módulo social de outro produto, para desacoplar o caminho crítico de lead do risco de política do social; configurar o identificador de configuração do Login do Facebook para Empresas e submeter à revisão de acesso avançado das permissões de leadgen. A criação do aplicativo e a verificação de negócio são gates externos da Meta, com passo humano do responsável pelo produto. Ver RF-INT-001 e a Onda C-MCRM no Roadmap.

10. Feedback pós-implantação

Como o sistema já roda em produção com um cliente real, a evolução é acompanhada por: métricas de operação (leads capturados, conversas atendidas, agendamentos, receita recorrente), verificações de saúde dos serviços em produção, e um canal de feedback do tenant piloto que alimenta os próximos ciclos. O que validar antes de cada entrega está no Plano de Testes.

11. Paridade GoHighLevel: funcionalidades candidatas

Esta seção reúne funcionalidades que o GoHighLevel documenta e que o ModularCRM ainda não tem, para servir de backlog de paridade e direção de evolução do produto.

Recorte de escopo (2026-07-10, decidido pelo dono). O ModularCRM é um painel interno da Modulareasy para atender os próprios clientes, cada um isolado na sua subconta, e não um SaaS white-label revendável. Sob esse recorte foram retiradas as áreas que não servem ao produto: Telefonia, Ecossistema de desenvolvedores e marketplace de apps de terceiros, Cursos e comunidades, Sites institucionais, Funis e Loja (captura já é atendida por formulários e por landing pages externas, e venda pela ferramenta não faz parte do produto), e a parte de revenda do modo Agência (rebilling, carteira, configurador de SaaS, cobrança automática, white-label, afiliados, prospecção). Da área de Agência permaneceu só o que ajuda a operar internamente: provisionar cliente rápido, configurar por modelo, e gerir acesso e isolamento das subcontas. A Inteligência Artificial foi mantida e recortada (conversa, conteúdo e ações em automação, com custo traga-sua-própria-chave); a IA de voz saiu com a telefonia. A Reputação foi mantida.

Natureza deste bloco. Backlog de paridade, não compromisso de entrega imediata. A priorização vive no Roadmap de Implementação. Notas dos requisitos marcam dependências (gateway de cartão ADR-004, infraestrutura de IA, serviços externos como Google Business e Meta).

Índice das subseções

• 11.1 Conversas avançadas (RF-CONV)
• 11.2 Contatos e CRM avançado (RF-LEAD)
• 11.3 Oportunidades avançadas (RF-OPP)
• 11.4 Calendário e agendamento avançado (RF-CAL)
• 11.5 Automações avançadas (RF-AUTO)
• 11.6 Pagamentos, cobrança e contratos (RF-BILL)
• 11.7 Permissões, equipe e configurações (RF-PERM)
• 11.8 Relatórios e analytics especializados (RF-REP)
• 11.9 Gestão de subcontas e provisionamento interno (RF-AGY)
• 11.10 Marketing (RF-MKT)
• 11.11 Recursos de Inteligência Artificial (RF-AI)
• 11.12 Reputação e presença online (RF-REPU)

11.1 Conversas avançadas (RF-CONV)

Requisitos de paridade com o Conversations do GoHighLevel na área de Inbox/Conversas. Cobrem os gaps do levantamento (filtros ricos, followers, chat interno, Conversation AI, SLAs, canais extras, envio avançado, DND por canal, timeline e widgets), sem repetir o que o ModularCRM já entrega (inbox unificado, ficha de contato, WhatsApp/Messenger/Instagram/Email/SMS, snippets, manual actions, DND por contato, trigger links, notificações).

Inbox, filtros e organização

RF-CONV-015: Inbox pessoal vs inbox da equipe

• Descrição: Painel de contexto do inbox com três visões, Meu Inbox (conversas atribuídas a mim ou que eu sigo), Inbox da Equipe (todas as conversas da conta) e Chat Interno, permitindo alternar o escopo das conversas listadas.
• Prioridade: Essencial
• Atores: Atendente, Gestor
• H1: Dado que o atendente está no inbox, Quando seleciona "Meu Inbox", Então a lista mostra apenas conversas atribuídas a ele ou que ele segue, E ao selecionar "Inbox da Equipe" a lista passa a mostrar todas as conversas da conta.
• Notas: Base para os RFs de follower (RF-CONV-022) e filtros por owner (RF-CONV-018). Painel colapsável.

RF-CONV-016: Divisor de não-lidas e contador em tempo real

• Descrição: Marcador "Novo" na primeira mensagem não lida do thread com auto-scroll até ela ao abrir, mais contador de não-lidas atualizado em tempo real em todas as abas e visões.
• Prioridade: Alta
• Atores: Atendente
• H1: Dado que uma conversa tem mensagens não lidas, Quando o atendente a abre, Então o sistema rola automaticamente até o divisor "Novo" na primeira não lida, E o contador de não-lidas some daquela conversa e se atualiza em tempo real nas demais abas.
• Notas: Divisor persiste até responder ou marcar como lido manualmente.

RF-CONV-017: Atalhos de teclado no inbox

• Descrição: Conjunto de atalhos de teclado para operar o inbox sem mouse (busca global, enviar mensagem, alternar composer em tela cheia, abrir lista de atalhos).
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente está no inbox, Quando pressiona Ctrl/Cmd mais Enter no composer, Então a mensagem é enviada, E ao pressionar "?" o sistema abre a lista de atalhos disponíveis (busca global, enviar, tela cheia).
• Notas: Atalhos fixos, não customizáveis nesta fatia.

RF-CONV-018: Motor de filtros ricos de conversa

• Descrição: Filtragem avançada da lista de conversas por owner/atribuído, follower, menção (@ de mim ou de usuário específico), direção da última mensagem (entrada vs saída), tipo da última mensagem de saída (manual vs automática), canal da última mensagem e tag do contato, com condições "É" / "Não é" e lógica AND/OR entre elas.
• Prioridade: Alta
• Atores: Atendente, Gestor
• H1: Dado que o gestor quer isolar conversas específicas, Quando monta um filtro combinando canal "É WhatsApp" AND última mensagem "É de entrada" AND tag "É lead-quente", Então a lista mostra somente conversas que satisfazem as três condições, E ao trocar a lógica para OR a lista passa a mostrar conversas que satisfaçam qualquer uma delas.
• Notas: Canais filtráveis incluem SMS, Email, Chamadas, Voicemail, Live Chat, WhatsApp, Facebook, Instagram, GBP e Submissão de Formulário.

RF-CONV-019: Conversas estreladas (Starred)

• Descrição: Possibilidade de estrelar/favoritar uma conversa e uma aba dedicada "Estreladas" que lista apenas as conversas marcadas.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente quer acompanhar uma conversa importante, Quando clica na estrela da conversa, Então a conversa passa a aparecer na aba "Estreladas", E ao remover a estrela a conversa sai dessa aba.

RF-CONV-020: Ordenação avançada da lista

• Descrição: Ordenação da lista de conversas por mais recentes/mais antigas (todas as mensagens), por mensagens manuais mais recentes/mais antigas e por SLA (maior atraso de SLA, próximo alvo de SLA).
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que o atendente precisa priorizar atendimentos atrasados, Quando ordena a lista por "Maior atraso de SLA", Então as conversas com SLA mais vencido aparecem no topo, E ao trocar para "Mensagens manuais mais recentes" a lista reordena pela última mensagem enviada manualmente.
• Notas: A ordenação por SLA depende de RF-CONV-030.

RF-CONV-021: Ações em massa no inbox

• Descrição: Seleção múltipla de conversas na lista para aplicar ações em massa (marcar como lida/não lida, estrelar/desestrelar, excluir), com limite por lote.
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que o atendente selecionou várias conversas na lista, Quando aplica "Marcar como lida" em massa, Então todas as selecionadas ficam lidas de uma vez, E o sistema respeita o limite de até 100 conversas por lote.

Followers e menções

RF-CONV-022: Followers de conversa

• Descrição: Usuários podem "seguir" uma conversa da qual não são donos, fazendo com que ela apareça no Meu Inbox deles e alimente o filtro por follower.
• Prioridade: Alta
• Atores: Atendente, Gestor
• H1: Dado que um gestor quer acompanhar uma conversa sem ser o dono, Quando clica em "Seguir" na conversa, Então ela passa a aparecer no Meu Inbox dele, E fica disponível no filtro "Por follower".
• Notas: Pré-requisito do filtro por follower em RF-CONV-018 e do Meu Inbox em RF-CONV-015.

RF-CONV-023: Comentários internos com @menção e notificação

• Descrição: Menção de colegas (@usuário) dentro dos comentários internos do thread, disparando notificação (in-app e email conforme preferência do usuário) para handoff com contexto, mais filtros de menção (menções a mim, menções a usuário específico, comentários internos).
• Prioridade: Alta
• Atores: Atendente, Gestor
• H1: Dado que um atendente precisa repassar um atendimento, Quando escreve um comentário interno mencionando @colega, Então o colega recebe notificação (in-app e email conforme preferência) com o contexto da conversa, E a conversa aparece no filtro "Menções a mim" do colega.
• Notas: Comentários internos permanecem invisíveis ao contato, sem anexos, não editáveis nem deletáveis após postados.

Chat interno

RF-CONV-024: Chat interno da equipe (DM e grupos)

• Descrição: Canal de chat privado entre usuários da conta, separado dos comentários internos e não ligado a nenhum contato, com mensagens diretas e canais de grupo, suporte a texto, emojis e anexos, e adição de usuários a chats existentes.
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que dois atendentes precisam conversar em privado, Quando um inicia uma mensagem direta com o outro, Então a conversa fica visível apenas para os participantes da conta, E ao criar um canal de grupo e adicionar usuários, todos os adicionados passam a ver e participar do chat.
• Notas: Usuários não podem ser removidos após adicionados. Acesso via "Login As" não enxerga chats internos (privacidade). Notificações configuráveis (toda mensagem ou só ao ser adicionado).

Conversation AI (bot)

RF-CONV-025: Bot de conversa com modos de resposta e tipos de agente

• Descrição: Bot de IA que atende conversas com três modos (Desligado, Sugestivo com rascunho para revisão humana, Autopilot com resposta automática) e dois tipos de agente (primário para inbound geral nos canais atribuídos, não primário para uso dentro de workflows).
• Prioridade: Alta
• Atores: Contato, Atendente, Gestor
• H1: Dado que o bot está em modo Sugestivo num canal atribuído, Quando o contato envia uma mensagem, Então o bot gera um rascunho de resposta para o atendente revisar antes de enviar, E ao trocar o modo para Autopilot o bot passa a responder automaticamente sem revisão.
• Regra do canal no Piloto Automático (ressalva remissiva, acrescentada em 2026-07-16): responder "sem revisão" é dispensa da revisão humana do conteúdo, e nunca é dispensa de conferir o canal. O robô é um despachante como qualquer outro e está inteiro dentro do RF-CONV-054, pela Regra do alcance de lá: com o canal da empresa não utilizável, ele não despacha, e o que não saiu nunca é apresentado nem registrado como enviado. Esta ressalva existe porque a frase do H1 acima, lida sozinha, abençoava o estado em que o robô despachava sem conferir nada, e ser omisso já seria ruim, mas abençoar é pior: dois requisitos publicados que se contradizem deixam o produto escolher o que preferir.
• Notas: Base para RF-CONV-026 a RF-CONV-029. A ressalva do canal foi acrescentada em 2026-07-16 pelo {AUD-88} do Roadmap de Implementação, par do {AUD-83}. Ela não cria requisito novo, porque o RF-CONV-054 emendado já alcança o robô por propriedade: ela impede que este requisito seja lido como licença contra aquele.

RF-CONV-026: Configuração e treino do bot

• Descrição: Painel de configuração do bot cobrindo Bot Settings (nome, status, canais atribuídos, delays de resposta, limites de mensagem, sleep/reativação, estilo Conciso/Balanceado/Detalhado), Bot Training (bases de conhecimento, documentos, URLs, FAQs), Brand Voice (tom consistente), Bot Goals (agendar, coletar info, qualificar lead, disparar workflow) e Additional Instructions (regras de tom e compliance).
• Prioridade: Alta
• Atores: Gestor, Administrador
• H1: Dado que o gestor configura o bot, Quando adiciona uma base de conhecimento em Bot Training e define o estilo de resposta como "Conciso", Então o bot passa a responder usando somente as fontes aprovadas no estilo escolhido, E ao definir um Bot Goal de qualificação de lead o bot conduz a conversa para coletar as informações do objetivo.

RF-CONV-027: Bot responde a áudio e notas de voz

• Descrição: O bot recebe notas de voz/áudio em WhatsApp, Messenger, Instagram e SMS/MMS, transcreve por speech-to-text (formatos OGG, MP3, MP4 áudio, AAC, M4A, MPEG) e responde sempre em texto, com toggle para habilitar resposta a notas de voz.
• Prioridade: Média
• Atores: Contato, Gestor
• H1: Dado que o toggle "responder a notas de voz" está ativo, Quando o contato envia um áudio no WhatsApp, Então o bot transcreve o áudio para texto e responde em texto, E áudios em formatos não suportados não disparam resposta.

RF-CONV-028: Resumo e transcrição da conversa por IA

• Descrição: Geração automática de resumo e transcript da conversa quando ela fica inativa (ex.: 15 min) e atinge um mínimo de mensagens, desligada por padrão, com roteamento do resultado via workflow (merge field de resumo) ou email para destinatários definidos, sem salvar no CRM automaticamente.
• Prioridade: Média
• Atores: Gestor, Atendente
• H1: Dado que o resumo por IA está habilitado nos Bot Goals, Quando a conversa fica inativa pelo tempo configurado e tem o mínimo de mensagens, Então o sistema gera resumo e transcript, E os roteia via workflow ou email conforme a configuração de destinatários.

RF-CONV-029: Analytics e logs do bot

• Descrição: Dashboard de desempenho do bot (contatos atendidos, ações, agendamentos, tempo economizado) e logs de ações do agente para auditoria.
• Prioridade: Média
• Atores: Gestor, Administrador
• H1: Dado que o bot está operando, Quando o gestor abre o dashboard do bot, Então vê métricas de contatos, ações e agendamentos com tempo economizado, E pode consultar os logs de ações do agente por conversa.

SLAs

RF-CONV-030: SLAs de conversa

• Descrição: Metas de tempo de resposta que contam regressivamente em cada thread de entrada, configuráveis como SLA único (universal) ou por canal (ex.: SMS 15 min, Email 2h), com estados visuais (Ativo cinza, Vence em breve laranja, Vencido vermelho), regras de parada do timer (mensagens de workflow, respostas do bot, só humano) e integração com filtros e ordenação por SLA.
• Prioridade: Alta
• Atores: Gestor, Atendente, Administrador
• H1: Dado que o SLA por canal está ativo com meta de 15 min para SMS, Quando um contato envia um SMS de entrada, Então inicia um timer regressivo que muda de cinza para laranja ao se aproximar do prazo e para vermelho ao vencer, E a conversa passa a ser filtrável por status de SLA e ordenável por maior atraso.
• Notas: Vale só para conversas novas após a ativação. Contagem por horas de calendário, não horário comercial.

Canais extras

RF-CONV-031: Google Business Messages e reviews no inbox

• Descrição: Recebimento de mensagens do Google Business Profile (GBP) e de threads de avaliações (reviews) dentro do inbox unificado, identificados pelo nome da página do perfil.
• Prioridade: Alta
• Atores: Atendente, Contato
• H1: Dado que o GBP está conectado, Quando um cliente envia mensagem ou avaliação pela ficha do Google, Então ela cai no inbox unificado identificada pelo nome da Business Profile, E o atendente responde pelo mesmo thread.

RF-CONV-032: Chamadas e voicemail como itens de conversa

• Descrição: Registro de chamadas telefônicas e voicemails na timeline da conversa, com log da chamada e transcrição quando disponível, e o canal Chamadas/Voicemail sendo filtrável.
• Prioridade: Alta
• Atores: Atendente, Gestor
• H1: Dado que houve uma chamada com o contato, Quando a chamada termina, Então aparece um card de chamada na timeline da conversa com duração e transcrição quando disponível, E o voicemail deixado vira um item filtrável pelo canal Voicemail.

RF-CONV-033: Submissões de formulário no thread

• Descrição: Submissões de formulário aparecendo como card dentro do thread de conversa do contato, com opção por formulário de "Criar conversa na submissão".
• Prioridade: Alta
• Atores: Contato, Atendente
• H1: Dado que um formulário tem "Criar conversa na submissão" ativo, Quando o contato envia o formulário, Então uma conversa é criada (ou atualizada) com um card de submissão exibindo os campos preenchidos, E o card fica filtrável pelo canal Submissão de Formulário.

Composer de email avançado

RF-CONV-034: CC e BCC no email

• Descrição: Campos CC (visível) e BCC (oculto) no composer de email do inbox, com dropdown dos emails do contato ou digitação manual, compatível com os provedores de email suportados.
• Prioridade: Alta
• Atores: Atendente
• H1: Dado que o atendente responde um email pelo inbox, Quando adiciona endereços em CC e BCC, Então o email é enviado com os destinatários em cópia visível (CC) e cópia oculta (BCC), E os demais destinatários não enxergam quem está em BCC.

RF-CONV-035: Encaminhar email do inbox

• Descrição: Encaminhamento (forward) de um email recebido a partir do inbox, com composer de forward contendo destinatário Para mais CC/BCC opcionais.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente recebeu um email na conversa, Quando escolhe "Encaminhar", Então abre um composer de forward com o conteúdo original e campo Para, E ao preencher o destinatário e enviar, o email é encaminhado com CC/BCC opcionais.

RF-CONV-036: Composer full-screen e reply inline threaded

• Descrição: Modo de composição em tela cheia para emails longos e reply inline posicionado abaixo da mensagem ativa dentro do thread, com persistência do canal selecionado ao colapsar/expandir o composer.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente redige um email longo, Quando alterna o composer para tela cheia, Então ganha a área ampliada para escrever, E ao responder inline a resposta aparece abaixo da mensagem ativa preservando o canal selecionado ao colapsar/expandir.

Snippets avançados

RF-CONV-037: Organização e tipos de snippet

• Descrição: Evolução dos snippets com organização por pastas (mover individual ou em massa), distinção de tipo Texto vs Email, busca e filtro por tipo, menu de duplicar/editar/deletar e envio de amostra (SMS/email) para teste antes de salvar.
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que a conta tem muitos snippets, Quando o gestor organiza-os em pastas e filtra por tipo "Email", Então vê somente os snippets de email daquela pasta, E ao duplicar um snippet e enviar uma amostra de teste, confirma o conteúdo antes de salvar.

Envio avançado

RF-CONV-038: Group Chat de SMS

• Descrição: Envio de SMS a múltiplos contatos num único thread de grupo (de 2 a 9 pessoas), com anexos (imagens inline e arquivos como chip), respeitando DND na adição de participantes.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente quer falar com vários contatos ao mesmo tempo por SMS, Quando cria um grupo com 4 contatos elegíveis, Então todos recebem no mesmo thread e as respostas ficam agregadas ali, E contatos em DND não podem ser adicionados ao grupo.
• Notas: Após criado, não é possível adicionar/remover participantes nem trocar o número de origem, cria-se um novo grupo.

RF-CONV-039: Agendar envio (Send Later e AI Schedule)

• Descrição: Opções no composer para enviar agora, enviar depois (data/hora escolhida) e AI Schedule (Smart Send Time, IA escolhe o melhor horário pelo comportamento histórico do contato).
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente redigiu uma mensagem, Quando escolhe "Enviar depois" e define data e hora, Então a mensagem é agendada e enviada no horário marcado, E ao escolher "AI Schedule" o sistema define automaticamente o melhor horário conforme o histórico do contato.

RF-CONV-040: Envio em massa (Bulk SMS e WhatsApp)

• Descrição: Disparo em massa de SMS e WhatsApp a partir de contatos/smart lists, com modos enviar tudo de uma vez, agendado e drip (quantidade por lote, repetir após, dias de envio, janela de horário), com preview, tracking e respeito ao DND.
• Prioridade: Alta
• Atores: Gestor, Atendente
• H1: Dado que o gestor selecionou uma smart list, Quando dispara um Bulk WhatsApp em modo drip com lote de 50 por vez dentro de uma janela de horário, Então o sistema envia em lotes respeitando a cadência configurada, E contatos em DND são pulados do disparo.

RF-CONV-041: Quick Replies e botões interativos (Messenger e Instagram)

• Descrição: Botões de resposta tap-to-respond em Messenger e Instagram (até 13 por mensagem, 20 caracteres cada), configurados via workflow, que ao serem selecionados pelo contato aparecem como resposta de entrada.
• Prioridade: Média
• Atores: Contato, Atendente
• H1: Dado que uma mensagem de saída no Messenger inclui quick replies, Quando o contato toca em uma opção, Então a seleção retorna como mensagem de entrada no thread, E no Instagram vale a restrição de usar botões OU quick replies, sem anexos junto.
• Notas: Facebook aceita quick replies mais botões mais imagens juntos. Seleção é irreversível e só funciona na mensagem mais recente.

RF-CONV-042: Seleção de número de origem e destino (SMS)

• Descrição: Escolha de qual telefone do contato usar como destino (Para) quando ele tem múltiplos números e de qual número da conta usar como origem (De) no envio de SMS.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o contato tem mais de um telefone cadastrado, Quando o atendente vai enviar um SMS, Então pode escolher para qual número enviar (Para) e de qual número da conta enviar (De), E o thread registra os números usados.

RF-CONV-043: Rascunho de mensagem ao cliente

• Descrição: Salvamento automático de rascunho de mensagem ao contato (não só de comentário interno) ao trocar de conversa ou de canal, recuperando o texto ao voltar.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que o atendente digitou parte de uma mensagem para o contato, Quando troca de conversa sem enviar, Então o texto é salvo como rascunho, E ao voltar para a conversa o rascunho é restaurado no composer.

DND avançado

RF-CONV-044: DND por canal e por direção

• Descrição: Evolução do DND do contato para granularidade por canal (Email, SMS, Chamadas, Facebook Messenger, GBP, WhatsApp) e por direção (entrada vs saída), com estados On, Off e Parcial, mais ativação automática de DND em unsubscribe, marcação de email como spam e bounces permanentes, e integração com workflows (trigger e action de DND).
• Prioridade: Alta
• Atores: Gestor, Atendente, Sistema
• H1: Dado que um contato deu unsubscribe no email, Quando o evento é processado, Então o DND de email é ativado automaticamente para ele mantendo os outros canais liberados (estado Parcial), E o outbound de email para esse contato passa a ser bloqueado enquanto os demais canais seguem permitidos.

Timeline, ficha e tarefas

RF-CONV-045: Timeline unificada com activity cards

• Descrição: Timeline da conversa que agrega, além das mensagens, cards de agendamentos, oportunidades, pagamentos, faturas, transcrições de chamada, logs de ação de IA, submissões de formulário, contatos e updates, com filtro por tipo (Tudo, Conversas, Atividades e tipos específicos).
• Prioridade: Alta
• Atores: Atendente, Gestor
• H1: Dado que o contato tem histórico de agendamento e pagamento, Quando o atendente abre a conversa, Então a timeline exibe cards de agendamento e pagamento junto das mensagens em ordem cronológica, E ao filtrar por "Agendamentos" apenas os cards desse tipo permanecem visíveis.

RF-CONV-046: Painel de registros relacionados do contato

• Descrição: Painel direito da conversa com abas de registros relacionados ao contato, incluindo Oportunidades, Agendamentos, Faturas/Pagamentos, Documentos e Associações, além da ficha e das atividades.
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que o atendente está numa conversa, Quando abre a aba "Oportunidades" no painel direito, Então vê as oportunidades vinculadas ao contato, E ao trocar para "Faturas/Pagamentos" vê os registros financeiros relacionados sem sair da conversa.

RF-CONV-047: Tarefas dentro da conversa

• Descrição: Criação e visualização de tarefas ligadas ao contato diretamente pelo painel da conversa.
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que o atendente precisa fazer um follow-up, Quando cria uma tarefa a partir do painel da conversa, Então a tarefa fica vinculada ao contato e visível no painel, E aparece na lista de tarefas do responsável.

Widgets de chat

RF-CONV-048: Configuração do Live Chat (Web Chat)

• Descrição: Widget de chat no site que entrega mensagens ao inbox em tempo real, com configuração de mensagem de introdução, avatar e branding do agente, mensagem de fallback por inatividade (coleta contato se ninguém responde), mensagem de timeout, código de instalação e atribuição manual ou via workflow.
• Prioridade: Alta
• Atores: Visitante, Atendente, Gestor
• H1: Dado que o Live Chat está instalado no site, Quando um visitante inicia um chat, Então a conversa cai no inbox em tempo real e pode ser atribuída manual ou por workflow, E se ninguém responder, o fallback de inatividade coleta o contato do visitante.

RF-CONV-049: Widget multicanal (All-in-One) e widgets de redirecionamento

• Descrição: Widget único que reúne múltiplos canais (Live Chat, SMS/Email, WhatsApp, Facebook, Instagram, Voice AI) com cor de marca única e greetings/offline por canal, mais widgets de Facebook e Instagram que redirecionam o visitante para o Messenger/DM nativo.
• Prioridade: Média
• Atores: Visitante, Gestor
• H1: Dado que o gestor configura o widget All-in-One com Live Chat, WhatsApp e Instagram habilitados, Quando um visitante abre o widget no site, Então escolhe por qual canal falar respeitando os pré-requisitos de cada um, E ao usar um widget de redirecionamento de Instagram o visitante é levado ao DM nativo em vez do web messenger.
• Notas: Pré-requisitos por canal (FB/IG conectados, Voice AI configurado, WhatsApp ativo; Live Chat/Email sempre disponíveis).

Status, anexos e engajamento

RF-CONV-050: Status de entrega e erro por mensagem

• Descrição: Indicador visual de status de entrega por mensagem (enviada, falhou, não entregue) com triângulo de erro que ao passar o mouse exibe código numérico e descrição da causa (DND, número inválido/não-SMS, carrier/device).
• Prioridade: Alta
• Atores: Atendente
• H1: Dado que uma mensagem não foi entregue, Quando o atendente passa o mouse sobre o triângulo vermelho de erro, Então vê o código numérico e a descrição da causa da falha, E consegue distinguir falha por DND de falha por número inválido.

RF-CONV-051: Gestão consistente de anexos por canal

• Descrição: Tratamento uniforme de anexos nas conversas, com imagens exibidas inline e arquivos como chip para download, respeitando limites de tamanho por canal/carrier (SMS/MMS).
• Prioridade: Média
• Atores: Atendente, Contato
• H1: Dado que uma mensagem contém uma imagem e um PDF, Quando o thread é exibido, Então a imagem aparece inline e o PDF aparece como chip clicável para download, E anexos que excedem o limite do canal são sinalizados.

RF-CONV-052: Engagement score do contato na conversa

• Descrição: Exibição do score de engajamento do contato no contexto da conversa.
• Prioridade: Média
• Atores: Atendente, Gestor
• H1: Dado que o atendente abre uma conversa, Quando o painel do contato carrega, Então mostra o score de engajamento do contato, E o valor reflete a atividade recente do contato.

RF-CONV-053: Comportamentos transversais do inbox

• Descrição: Comportamentos gerais de consistência, resposta cross-channel pelo mesmo thread por qualquer canal, exibição de detalhes de origem da mensagem (message source) para provedores custom/marketplace e formato de data consistente na timeline.
• Prioridade: Média
• Atores: Atendente
• H1: Dado que uma conversa tem mensagens de vários canais, Quando o atendente responde pelo composer, Então pode escolher qualquer canal disponível no mesmo thread, E as mensagens mostram origem/source e datas em formato consistente.

11.2 Contatos e CRM avançado (RF-LEAD)

Requisitos derivados do mapeamento exaustivo da área de Contacts/CRM do GoHighLevel, cobrindo apenas as lacunas em relação ao que o ModularCRM já entrega. Foco nos três maiores gaps estruturais (Objetos personalizados, Associações com labels, Valores personalizados) e nas demais funcionalidades granulares de ficha, campos, deduplicação, empresa e ações em massa.

Objetos personalizados (Custom Objects)

RF-LEAD-014: Definição de objetos personalizados por sub-conta

• Descrição: O sistema deve permitir que um admin da conta defina tipos de registro totalmente novos além de Contato, Oportunidade e Empresa (ex: Imóveis, Veículos, Casos, Pets), com limite de até 10 objetos personalizados por sub-conta.
• Prioridade: Essencial
• Atores: Admin da conta
• H1: Dado que sou admin da sub-conta, Quando acesso a área de configuração de objetos e crio um novo objeto personalizado, Então o objeto passa a existir como tipo de registro próprio, E o sistema bloqueia a criação além do 11º objeto na mesma sub-conta.
• Notas: Usuários comuns têm acesso somente-leitura ao objeto; criação e edição do esquema são restritas a admin de nível de sub-conta.

RF-LEAD-015: Metadados de identidade do objeto personalizado

• Descrição: Cada objeto personalizado deve capturar nome no singular e no plural, chave interna de sistema, campo de exibição principal, ícone e descrição.
• Prioridade: Essencial
• Atores: Admin da conta
• H1: Dado que estou criando ou editando um objeto personalizado, Quando defino nome singular, nome plural, chave interna, campo de exibição principal, ícone e descrição, Então esses metadados passam a rotular o objeto nas listas e na navegação, E a chave interna e o campo de exibição principal ficam bloqueados para alteração após a criação.
• Notas: A chave interna é editável apenas no momento da criação; o campo de exibição principal não pode ser trocado depois, para preservar identidade dos registros nas listas.

RF-LEAD-016: Campos, pastas e registros próprios do objeto personalizado

• Descrição: Cada objeto personalizado deve ter seus próprios custom fields, pastas de campos e registros, independentes dos campos de Contato.
• Prioridade: Essencial
• Atores: Admin da conta, Usuário operacional
• H1: Dado um objeto personalizado criado, Quando adiciono campos e pastas a ele e crio registros, Então os campos e registros pertencem exclusivamente àquele objeto, E não aparecem no esquema de Contato nem de outros objetos.

RF-LEAD-017: List View e Smart Lists próprias do objeto personalizado

• Descrição: Cada objeto personalizado deve oferecer visão de lista própria com ordenação e filtro (crescente e decrescente por campo) e smart lists dedicadas.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado um objeto personalizado com registros, Quando abro sua visão de lista e aplico ordenação e filtros por campo, Então os registros são exibidos conforme os critérios, E posso salvar o resultado como smart list específica daquele objeto.

RF-LEAD-018: Objetos personalizados suportados em fluxos, formulários, filtros e integrações

• Descrição: Objetos personalizados devem ser utilizáveis em workflows (triggers e actions), formulários, pesquisas, smart lists, filtros avançados, relatórios, APIs, webhooks e tarefas.
• Prioridade: Alta
• Atores: Admin da conta, Integração externa
• H1: Dado um objeto personalizado, Quando configuro um workflow, formulário, filtro avançado ou chamada de API referenciando esse objeto, Então o objeto e seus campos ficam disponíveis nesses contextos, E triggers dedicados de criação e alteração do objeto disparam automações.
• Notas: Triggers dedicados equivalentes a Objeto Criado, Objeto Alterado e Webhook de entrada.

RF-LEAD-019: Deleção controlada e irreversível de objeto personalizado

• Descrição: A exclusão de um objeto personalizado deve ser restrita a admin, exigir confirmação explícita e remover em cascata todos os registros, associações, workflows e campos vinculados.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado um objeto personalizado com registros e associações, Quando um admin solicita a exclusão do objeto, Então o sistema exige confirmação clara de irreversibilidade, E ao confirmar remove o objeto junto com todos os registros, associações, campos e workflows dependentes.

Associações (Associations com labels)

RF-LEAD-020: Definição de associação estruturada entre objetos

• Descrição: O sistema deve permitir criar relacionamentos estruturados entre registros de objetos quaisquer (contato com contato, contato com objeto personalizado, oportunidade com empresa, etc), dando visão consolidada do relacionamento.
• Prioridade: Essencial
• Atores: Admin da conta
• H1: Dado que sou admin, Quando crio uma associação escolhendo o objeto de origem e o objeto associado, Então passa a existir um tipo de relacionamento reutilizável entre esses objetos, E ele fica disponível para vincular registros na ficha.

RF-LEAD-021: Labels Single e Pair na associação

• Descrição: Cada associação deve suportar rótulo único aplicado aos dois lados (ex: Colega) ou par de rótulos distintos por lado (ex: Gestor e Liderado, Comprador e Vendedor).
• Prioridade: Essencial
• Atores: Admin da conta
• H1: Dado que estou definindo uma associação, Quando escolho entre rótulo único ou par de rótulos, Então cada registro vinculado exibe o rótulo correspondente ao seu lado do relacionamento, E o sistema aplica o rótulo espelhado automaticamente no registro relacionado.
• Notas: Este é o diferencial central sobre o vínculo N:N simples de Empresas que já existe; os labels nomeados por lado dão semântica ao relacionamento.

RF-LEAD-022: Cardinalidade configurável da associação

• Descrição: A associação deve suportar cardinalidade Muitos para Muitos e Muitos para Um.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado que estou definindo uma associação, Quando seleciono a cardinalidade entre Muitos para Muitos e Muitos para Um, Então o sistema passa a permitir ou restringir a quantidade de vínculos conforme a cardinalidade escolhida, E impede vínculos que violem a regra.

RF-LEAD-023: Vincular registros associados na ficha

• Descrição: A ficha do registro deve exibir um painel de registros relacionados onde o usuário adiciona vínculos, escolhe o registro alvo e atribui o rótulo, atualizando ambos os lados.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado um registro aberto com painel de registros relacionados, Quando adiciono um vínculo escolhendo o registro alvo e o rótulo, Então a associação aparece nas fichas dos dois registros, E a atualização é refletida automaticamente no perfil relacionado.

RF-LEAD-024: Limites de associação por registro e por label

• Descrição: O sistema deve impor limites de associações por registro e por rótulo (máximo de 10 associações por contato, um rótulo vinculando até 1000 contatos, até 10 rótulos únicos entre dois objetos quaisquer).
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado um registro próximo do limite de associações, Quando tento criar um vínculo que ultrapassa o limite definido, Então o sistema bloqueia a operação, E informa qual limite foi atingido.

RF-LEAD-025: Associações em smart lists, filtros e workflows

• Descrição: Associações devem ser utilizáveis como critério em smart lists e filtros, e o sistema deve oferecer ações de workflow para adicionar, remover e localizar registros associados, além de criar e associar registros a partir de automação.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado um workflow ou smart list, Quando uso associações como condição ou ação, Então posso filtrar registros por seus vínculos e adicionar, remover ou localizar registros associados via automação, E criar um registro já associado a um contato dentro do fluxo.

Valores personalizados (Custom Values)

RF-LEAD-026: Valores personalizados globais da sub-conta

• Descrição: O sistema deve permitir definir variáveis globais nomeadas no nível da sub-conta (ex: endereço da empresa, link de portal, nome de programa), distintas de custom fields, organizáveis em pastas.
• Prioridade: Essencial
• Atores: Admin da conta
• H1: Dado que sou admin, Quando crio um valor personalizado informando nome, valor e pasta, Então ele fica disponível como token global reutilizável na sub-conta, E posso editá-lo ou removê-lo posteriormente.
• Notas: Diferente de custom field, que pertence a um registro. O valor personalizado é uma variável de configuração da conta inteira.

RF-LEAD-027: Propagação de valor personalizado nas comunicações e páginas

• Descrição: Valores personalizados devem ser inseríveis como tokens em conversas (SMS, email, redes), workflows, páginas, campanhas e templates (inclusive assunto, nome do remetente e campos de cor), e a alteração na fonte deve propagar automaticamente onde forem usados.
• Prioridade: Alta
• Atores: Admin da conta, Usuário operacional
• H1: Dado um valor personalizado usado como token em vários pontos, Quando altero o valor na origem, Então todos os pontos que usam o token passam a refletir o novo valor sem edição individual, E o token é resolvido no envio da comunicação.

RF-LEAD-028: Biblioteca de merge fields por categoria

• Descrição: O sistema deve oferecer um catálogo organizado de tokens de personalização por categoria (Contato, Usuário, Agendamento, Calendário e Campanha, Mensagem, Conta, Data e hora dinâmica, Atribuição) para uso em comunicações.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado que estou compondo uma mensagem ou template, Quando abro o seletor de tokens, Então vejo os tokens agrupados por categoria, E ao inserir um token ele é substituído pelo valor real do registro no momento do envio.

Tipos de campo

RF-LEAD-029: Campo do tipo Upload de arquivo

• Descrição: O sistema deve oferecer um tipo de custom field de upload de arquivo, distinto da funcionalidade de arquivos anexados ao contato.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado que estou criando um custom field, Quando escolho o tipo Upload de arquivo, Então o campo passa a aceitar o envio de um arquivo no preenchimento do registro e de formulários, E o arquivo fica associado àquele campo específico.

RF-LEAD-030: Campo do tipo Assinatura

• Descrição: O sistema deve oferecer um tipo de custom field de assinatura, que captura assinatura desenhada no preenchimento.
• Prioridade: Média
• Atores: Usuário operacional, Contato
• H1: Dado um custom field do tipo Assinatura, Quando o campo é preenchido em um formulário ou ficha, Então a assinatura capturada é armazenada no registro, E fica disponível para visualização posterior.

RF-LEAD-031: Campo do tipo Monetário

• Descrição: O sistema deve oferecer um tipo de custom field monetário, com formatação e semântica de valor em moeda.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado um custom field do tipo Monetário, Quando informo um valor no campo, Então ele é armazenado e exibido com formatação de moeda, E pode ser usado em filtros numéricos.

RF-LEAD-032: Campos de escolha múltipla, seleção única e grupo de checkboxes

• Descrição: O sistema deve oferecer dropdown de múltipla seleção (sem limite prático de opções), seleção única por radio e grupo de checkboxes de múltipla escolha, além do dropdown de seleção única.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado que estou criando um custom field de escolha, Quando seleciono entre dropdown único, dropdown de múltipla seleção, radio ou grupo de checkboxes, Então o campo passa a aceitar o padrão de escolha correspondente, E o dropdown de múltipla seleção aceita mais de 50 opções.

RF-LEAD-033: Campo do tipo Lista de texto

• Descrição: O sistema deve oferecer um tipo de campo de lista de texto, para valores em lista.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado um custom field do tipo Lista de texto, Quando informo múltiplos itens no campo, Então cada item é preservado como entrada da lista, E a lista fica disponível na ficha do registro.

RF-LEAD-034: Campos de data com hora, URL e email como tipos dedicados

• Descrição: O sistema deve oferecer seletor de data com opção de hora, campo de URL e campo de email como tipos de custom field dedicados, com validação apropriada.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado que estou criando um custom field, Quando escolho o tipo Data com hora, URL ou Email, Então o campo valida a entrada conforme o formato esperado, E rejeita valores mal formados.

Campos de Oportunidade

RF-LEAD-035: Custom fields no escopo de Oportunidade

• Descrição: O sistema deve suportar custom fields próprios do objeto Oportunidade, que aparecem nos registros e visões de pipeline e nos workflows de oportunidade, separados dos campos de Contato.
• Prioridade: Alta
• Atores: Admin da conta, Usuário operacional
• H1: Dado que estou criando um custom field, Quando defino seu escopo como Oportunidade, Então o campo aparece nos registros de oportunidade e nas visões de pipeline, E não pode ter seu escopo trocado para Contato depois de criado.
• Notas: Regra de bloqueio de troca de escopo vale entre Contato e Oportunidade.

DND por canal e direção

RF-LEAD-036: DND granular por canal

• Descrição: O sistema deve permitir configurar Do Not Disturb globalmente ou por canal específico (Email, SMS, Chamadas, Facebook Messenger, Google My Business, WhatsApp).
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado um contato aberto, Quando habilito DND para um canal específico, Então o sistema bloqueia envio outbound apenas naquele canal, E mantém os demais canais liberados.

RF-LEAD-037: DND por direção inbound e outbound

• Descrição: Além do canal, o DND deve distinguir direção, com DND de entrada aplicável a chamadas e SMS.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado um contato com DND de entrada habilitado, Quando chega uma chamada ou SMS de entrada, Então o sistema aplica a restrição de entrada configurada, E registra o estado correspondente.

RF-LEAD-038: DND via workflow e aplicativo

• Descrição: O sistema deve oferecer trigger e action de workflow para habilitar e desabilitar DND por canal e direção, e permitir marcar DND direto da tela de chamada ou inbox, sincronizando entre plataformas.
• Prioridade: Média
• Atores: Admin da conta, Usuário operacional
• H1: Dado um workflow ou a tela de atendimento, Quando altero o DND de um contato por canal ou direção, Então a alteração é persistida no contato, E sincroniza entre web e aplicativo.

RF-LEAD-039: Filtros booleanos de DND por canal em smart lists

• Descrição: As smart lists devem oferecer filtros booleanos de DND por canal e direção (DND geral, SMS, Email, Chamadas e Correio de voz, WhatsApp, Entrada, FB Messenger, GMB Messenger).
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado o construtor de smart list, Quando adiciono um filtro de DND por canal, Então os contatos são segmentados conforme o estado do DND naquele canal, E posso combinar com outros filtros.

Duplicatas automáticas

RF-LEAD-040: Ferramenta de varredura de duplicatas

• Descrição: O sistema deve oferecer varredura automática de potenciais duplicatas por Email (padrão), Telefone ou Nome, apresentando grupos revisáveis individualmente.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado que sou admin, Quando executo a varredura de duplicatas escolhendo o critério, Então o sistema exibe grupos de contatos potencialmente duplicados para revisão, E permite abrir cada grupo individualmente.

RF-LEAD-041: Rejeição persistente de sugestão de duplicata

• Descrição: Ao revisar duplicatas, o usuário deve poder rejeitar uma sugestão, e o par rejeitado não deve reaparecer em varreduras futuras.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um grupo de duplicatas sugerido, Quando rejeito a sugestão, Então o sistema deixa de tratar aquele par como duplicata, E não o apresenta em varreduras seguintes.

RF-LEAD-042: Merge automático via ação de workflow

• Descrição: O sistema deve oferecer uma ação de workflow que executa merge de contatos automaticamente dentro de uma automação.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um workflow com a ação de merge de contato, Quando o fluxo é executado para um contato com duplicata elegível, Então o sistema realiza o merge automaticamente, E registra a operação no histórico.

RF-LEAD-043: Critério configurável de detecção de duplicata

• Descrição: O sistema deve permitir configurar se contatos duplicados são permitidos e definir critério primário e secundário de detecção, aplicável a entradas de formulários e integrações.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado o painel de preferências de duplicatas, Quando defino o critério primário e o secundário e a política de permitir duplicatas, Então novas submissões são anexadas a contato existente ou criam novo registro conforme a regra, E a política se aplica às entradas de formulários e integrações.

Emails e telefones adicionais

RF-LEAD-044: Múltiplos emails com designação de primário

• Descrição: O contato deve suportar até 10 emails adicionais além do primário (11 no total), com marcação clara do primário, que é o único usado em envios outbound.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado um contato, Quando adiciono emails além do primário e marco qual é o primário, Então o sistema armazena todos os emails, E usa apenas o primário para envio de email de saída.

RF-LEAD-045: Múltiplos telefones com rótulo e primário

• Descrição: O contato deve suportar até 11 telefones, cada um com rótulo (Celular, Trabalho, Casa, etc) e um marcado como primário, sendo o primário o único usado para chamada e SMS de saída.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado um contato, Quando adiciono telefones com seus rótulos e defino o primário, Então o sistema armazena todos os números rotulados, E usa apenas o primário para chamada e SMS de saída, assumindo o primeiro como primário se nenhum for marcado.

RF-LEAD-046: Inclusão de emails e telefones adicionais na busca de contato

• Descrição: Nas ações de localizar contato em workflows, deve haver opção de incluir emails e telefones adicionais no critério de correspondência.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um workflow que localiza contato por email ou telefone, Quando ativo a opção de incluir adicionais na busca, Então a correspondência considera também os emails e telefones secundários, E encontra o contato mesmo pelo identificador não primário.

Followers

RF-LEAD-047: Seguidores de registro com acesso herdado

• Descrição: O sistema deve permitir que até 10 usuários sigam um contato ou oportunidade, com direito de ver e editar o registro mesmo sob a restrição de acesso somente aos dados atribuídos, herdando permissões do responsável.
• Prioridade: Média
• Atores: Usuário operacional, Admin da conta
• H1: Dado um registro com restrição de acesso somente a dados atribuídos, Quando adiciono um usuário como seguidor do registro, Então esse usuário passa a ver e editar o registro mesmo sem ser o responsável, E o sistema impede ultrapassar 10 seguidores por registro.

Campos de empresa

RF-LEAD-048: Custom fields no objeto Empresa

• Descrição: O objeto Empresa deve suportar custom fields próprios (ex: segmento, faixa de faturamento, número de funcionários), além dos campos padrão.
• Prioridade: Alta
• Atores: Admin da conta, Usuário operacional
• H1: Dado o objeto Empresa, Quando crio custom fields no escopo de Empresa, Então esses campos aparecem nos registros de empresa, E ficam disponíveis para filtros e colunas de lista de empresas.

RF-LEAD-049: Lista de empresas com colunas e filtros próprios

• Descrição: O objeto Empresa deve ter visão de lista própria com gestão de colunas, filtros avançados por campos padrão e customizados, ordenação e busca, e smart lists de empresa salvas e compartilháveis.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado a lista de empresas, Quando ajusto colunas, aplico filtros e ordenação e salvo o resultado, Então a visão é persistida como smart list de empresa, E pode ser compartilhada com outros usuários.

RF-LEAD-050: Workflows no nível do objeto Empresa

• Descrição: O sistema deve suportar workflows com triggers e actions no nível do objeto Empresa (onboarding de conta, sincronização, ciclo de vida, higiene de dados).
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um workflow de Empresa, Quando um evento no objeto Empresa ocorre, Então o trigger de empresa dispara o fluxo, E as ações operam sobre o registro de empresa.

RF-LEAD-051: Auto-criação e associação de empresa por Business Name

• Descrição: O sistema deve criar ou associar automaticamente uma empresa a partir do campo Business Name do contato, inclusive durante importação de CSV, conforme automação configurável do objeto Empresa.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado que a automação de empresa está ativa, Quando um contato é criado ou importado com Business Name preenchido, Então o sistema cria a empresa correspondente ou associa a uma existente com o mesmo nome, E vincula o contato à empresa automaticamente.

RF-LEAD-052: Exclusão e restauração em massa de empresas com exportação

• Descrição: O sistema deve permitir exclusão e restauração em massa de empresas e exportação de empresas para CSV.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um conjunto de empresas selecionadas, Quando executo exclusão em massa e depois restauração, Então as empresas são removidas e podem ser recuperadas na janela de restauração, E posso exportar o conjunto de empresas para CSV.

Ações em massa (Bulk actions)

RF-LEAD-053: Painel central de ações em massa com monitoramento

• Descrição: O sistema deve oferecer um painel que lista todas as operações em massa com status ao vivo, métricas e logs, filtrável por status, tipo de ação, usuário e data, com estados Em andamento, Concluída, Cancelada, Pausada e Na fila.
• Prioridade: Alta
• Atores: Admin da conta, Usuário operacional
• H1: Dado que executei ações em massa, Quando abro o painel de ações em massa, Então vejo cada operação com seu status ao vivo, métricas e logs, E posso filtrar a lista por status, tipo, usuário e data.

RF-LEAD-054: Controle de execução de jobs em massa

• Descrição: O sistema deve permitir pausar, cancelar e reagendar jobs elegíveis, restaurar registros deletados na janela, e visualizar estatísticas de sucesso e erro com download do log de erros.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um job em massa na fila ou em andamento, Quando pauso, cancelo ou reagendo o job, Então o sistema aplica o comando ao job elegível, E disponibiliza as estatísticas de sucesso e erro e o download do log de erros.

RF-LEAD-055: Verificação de email em massa

• Descrição: O sistema deve oferecer uma ação em massa de verificação de emails dos contatos selecionados.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um conjunto de contatos selecionados, Quando executo a verificação de email em massa, Então o sistema valida os emails e reporta o resultado por contato, E registra a operação no painel de ações em massa.

RF-LEAD-056: Associação em massa de contatos a empresa

• Descrição: O sistema deve oferecer uma ação em massa para associar contatos selecionados a uma empresa.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um conjunto de contatos selecionados, Quando executo a associação em massa a uma empresa, Então todos os contatos passam a ficar vinculados à empresa escolhida, E a operação aparece no painel de ações em massa.

RF-LEAD-057: Modos de inscrição em massa em automação

• Descrição: A inscrição de contatos em workflow ou campanha em massa deve suportar modo imediato, agendado por data e hora, e distribuído em lotes.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um conjunto de contatos filtrados, Quando os inscrevo em uma automação escolhendo o modo imediato, agendado ou em lotes, Então o sistema executa a inscrição conforme o modo selecionado, E respeita a data ou cadência definida.

Atribuição first e last touch

RF-LEAD-058: Atribuição de primeira e última interação como dado nativo do contato

• Descrição: O contato deve registrar nativamente dados de atribuição de primeira e de última interação (origem de sessão, URL, campanha, UTMs de origem, meio, conteúdo, campanha, palavra-chave e tipo de correspondência, referenciador, fbclid, gclid, ids de grupo e anúncio).
• Prioridade: Alta
• Atores: Usuário operacional, Integração externa
• H1: Dado um contato originado de uma campanha, Quando ele é criado e depois interage novamente, Então o sistema preserva os dados de atribuição da primeira interação e atualiza os da última interação, E esses campos ficam disponíveis em filtros e tokens de personalização.

Ficha do contato (UX)

RF-LEAD-059: Layout de três painéis com módulos de ação colapsáveis

• Descrição: A ficha do contato deve adotar layout de três painéis (informações à esquerda, conversas e atividades ao centro, módulos de ação à direita) com módulos colapsáveis que lembram o último estado.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado a ficha de um contato, Quando abro o registro, Então vejo os três painéis com os módulos de ação colapsáveis, E os painéis e abas retomam o último estado da sessão anterior.

RF-LEAD-060: Auto-save e navegação por teclado na ficha

• Descrição: A ficha deve oferecer salvamento automático ao sair do campo (ativável), navegação entre contatos pelas setas, colapso do painel direito por tecla de escape e salvamento manual por atalho quando o auto-save estiver desligado.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado que estou editando a ficha com auto-save ativo, Quando saio de um campo alterado, Então a alteração é salva automaticamente, E quando o auto-save está desligado o salvamento ocorre pelo atalho de teclado, com navegação entre contatos pelas setas.

RF-LEAD-061: Ocultar campos vazios e busca dentro dos campos da ficha

• Descrição: A ficha deve oferecer opção de ocultar campos vazios e busca dentro dos campos do contato.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado uma ficha com muitos campos vazios, Quando ativo a opção de ocultar campos vazios, Então apenas os campos preenchidos são exibidos, E posso localizar um campo específico pela busca dentro da ficha.

RF-LEAD-062: Módulo de pagamentos na ficha do contato

• Descrição: A ficha deve exibir um módulo de pagamentos com faturas, assinaturas e transações do contato.
• Prioridade: Média
• Atores: Usuário operacional
• H1: Dado um contato com histórico financeiro, Quando abro o módulo de pagamentos na ficha, Então vejo suas faturas, assinaturas e transações, E acesso o detalhe de cada item.

Tipo de contato e formulário de cadastro

RF-LEAD-063: Tipo de contato como campo de segmentação obrigatório opcional

• Descrição: O sistema deve oferecer um campo padrão de Tipo de Contato para segmentação (ex: Lead, Cliente) com opção de torná-lo obrigatório.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado a configuração de contatos, Quando marco o Tipo de Contato como obrigatório, Então o cadastro manual exige o preenchimento do tipo, E impede salvar o contato sem essa informação.

RF-LEAD-064: Customização do formulário de novo contato

• Descrição: O sistema deve permitir customizar o formulário de adição manual de contato, adicionando ou removendo campos padrão e customizados, reordenando por arrastar e soltar, marcando obrigatoriedade por campo e pré-visualizando antes de salvar.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado o formulário de novo contato, Quando adiciono, removo, reordeno campos e defino obrigatoriedade, Então o formulário de entrada manual reflete a configuração após salvar, E a customização não afeta importação por CSV nem API, que mantêm validação própria.

Restauração de contatos

RF-LEAD-065: Restauração de contatos dentro da janela de retenção

• Descrição: O sistema deve manter contatos deletados restauráveis por 60 dias, após os quais a exclusão é permanente, sendo que a restauração de contato individual não recupera dados associados.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado um contato deletado há menos de 60 dias, Quando o restauro pela aba de restauração, Então o contato volta a existir, E o sistema informa que dados associados como conversas, notas e tarefas não são recuperados na restauração individual.

RF-LEAD-066: Desfazer exclusão em massa com dados associados

• Descrição: A restauração de uma exclusão em massa deve recuperar os contatos junto com seus dados associados, e o mesmo mecanismo de exclusão e restauração em massa deve valer para objetos personalizados, empresas e tarefas.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado uma exclusão em massa de contatos, Quando a restauro na janela de retenção, Então os contatos voltam com seus dados associados, E o mesmo comportamento se aplica a objetos personalizados, empresas e tarefas.
• Notas: Contas com regime de dados sensíveis podem restringir restauração, conforme política do cliente.

Merge manual (detalhes)

RF-LEAD-067: Merge manual com registro mestre e escolha de identificadores

• Descrição: No merge manual de até 10 contatos, o usuário deve escolher o registro mestre que permanece e o email e telefone primários dentre os selecionados, sendo que campos customizados do secundário só entram quando o campo do mestre está vazio, sem sobrescrever.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado dois ou mais contatos selecionados para merge, Quando escolho o registro mestre e os identificadores primários e confirmo a irreversibilidade, Então o sistema consolida conversas, notas, tarefas, oportunidades, tags, agendamentos e pagamentos no mestre, E preenche campos customizados a partir do secundário apenas onde o mestre estiver vazio.

Pontuação de engajamento

RF-LEAD-068: Modo rascunho e publicação da pontuação de engajamento

• Descrição: A configuração de regras de pontuação de engajamento deve suportar modo rascunho para testar e modo publicado para ativar ao vivo, com catálogo amplo de ações positivas e negativas.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado que estou configurando regras de pontuação, Quando salvo em modo rascunho, Então as regras não afetam a pontuação ao vivo até serem publicadas, E ao publicar o catálogo de ações passa a somar e subtrair pontos conforme os eventos ocorrem.
• Notas: Sem decaimento automático de pontuação; decaimento exige workflow temporizado. Catálogo inclui aberturas e cliques de email, submissões de formulário e pesquisa, pagamentos, respostas, agendamentos e pedidos como positivos, e bounces e descadastros como negativos.

Importação avançada

RF-LEAD-069: Importação de CSV avançada com criação de campo e consentimento

• Descrição: A importação por CSV deve aceitar arquivos de até 50MB, mapear colunas para campos, permitir criar custom field durante o import, ignorar colunas não mapeadas, definir nome do import, listas e preferências de consentimento, e aplicar ações pós-import.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado um arquivo CSV de até 50MB, Quando mapeio as colunas, crio campos novos durante o import e defino nome, listas, consentimento e ações pós-import, Então os contatos são importados conforme o mapeamento, E as colunas não mapeadas são ignoradas quando escolho essa opção.

RF-LEAD-070: Deduplicação automática na importação por CSV

• Descrição: Na importação por CSV, contatos duplicados devem ser identificados e tratados automaticamente por telefone ou email, independentemente da política geral de permitir duplicatas.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado uma importação de CSV com registros que já existem, Quando o sistema processa o arquivo, Então ele identifica duplicados por telefone ou email e os concilia automaticamente, E não cria registros redundantes mesmo com a política de permitir duplicatas ativa.

Filtros avançados

RF-LEAD-071: Operadores de data relativa e de conjunto nos filtros

• Descrição: Os filtros avançados devem oferecer operadores de data relativa (Nos últimos X, Nos próximos X, Este trimestre, Este mês, Este ano, Mais de X atrás, Menos de X atrás, Entre, Antes e Depois de data) e operadores de conjunto para strings (É qualquer um de, Não é nenhum de), além de vazio e não vazio.
• Prioridade: Alta
• Atores: Usuário operacional
• H1: Dado o construtor de filtros avançados, Quando aplico um operador de data relativa ou de conjunto, Então os contatos são segmentados conforme a janela temporal ou a lista de valores, E posso combinar esses operadores com lógica E e OU aninhada.

11.3 Oportunidades avançadas (RF-OPP)

Esta seção cobre os gaps do ModularCRM na área de Oportunidades e Funis frente ao GoHighLevel, além do que já temos (funis com estágios configuráveis, kanban, produtos e valores, orçamentos e pedidos). Os RFs abaixo endereçam campos personalizados de oportunidade, previsão de receita, visão em lista, filtros avançados, status e motivo de perda, seguidores, ações em massa, importação e automação nativa de funil.

Campos personalizados de oportunidade

RF-OPP-005: Custom fields próprios do objeto Oportunidade

• Descrição: O objeto Oportunidade deve ter seus próprios campos personalizados, separados dos campos de contato, gerenciáveis via tela de gestão de campos. Tipos suportados: linha única, texto multilinha, seleção única (dropdown), rádio, número, monetário, telefone e data.
• Prioridade: Alta
• Atores: Administrador (cria/gerencia campos), Gerente de vendas, Vendedor (preenche)
• H1: Dado que sou administrador na configuração de campos, Quando crio um campo personalizado do tipo número, dropdown ou data para o objeto Oportunidade, Então o campo passa a existir apenas no objeto Oportunidade sem se misturar aos campos de contato, E fica disponível no modal de criar/editar oportunidade.
• Notas: Base para forecasting, list view e filtros avançados abaixo.

RF-OPP-006: Uso transversal dos campos personalizados de oportunidade

• Descrição: Cada campo personalizado de oportunidade deve poder ser exibido no modal, usado como coluna e critério de ordenação na visão em lista, usado como condição em filtros avançados, e lido/escrito como valor em automações.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas, Administrador
• H1: Dado que existe um campo personalizado de oportunidade, Quando abro a visão em lista, os filtros ou monto uma automação, Então esse campo aparece disponível como coluna, ordenação, condição de filtro e valor de ação, E o comportamento é idêntico ao dos campos padrão.

Card e origem da oportunidade

RF-OPP-007: Card agrega notas, tarefas e comunicações

• Descrição: O detalhe da oportunidade deve reunir notas, tarefas e histórico de comunicação vinculados àquela oportunidade, para que toda a atividade viva no próprio card.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que abro o detalhe de uma oportunidade, Quando visualizo o card, Então vejo notas, tarefas e comunicações associadas àquela oportunidade num só lugar, E consigo criar uma nova nota ou tarefa direto do card.

RF-OPP-008: Campo Origem da oportunidade rastreável

• Descrição: A oportunidade deve ter um campo dedicado de origem (formulário, campanha, anúncio, importação, criação manual, automação) preenchido automaticamente quando possível e rastreável em filtros e automações.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas, Administrador
• H1: Dado que uma oportunidade é criada por um formulário, importação ou automação, Quando ela é registrada, Então o campo de origem é preenchido com a fonte correspondente, E esse campo pode ser usado como condição em filtros e automações.

RF-OPP-009: Nome da empresa na oportunidade

• Descrição: A oportunidade deve permitir informar o nome da empresa (Business Name) como campo próprio, exibível no modal, na lista e em filtros.
• Prioridade: Média
• Atores: Vendedor, Gerente de vendas
• H1: Dado que crio ou edito uma oportunidade, Quando informo o nome da empresa, Então o valor é salvo na oportunidade, E fica disponível como coluna na visão em lista e como condição de filtro.

Status e motivo de perda

RF-OPP-010: Quarto status Abandonada

• Descrição: Além de Aberta, Ganha e Perdida, a oportunidade deve suportar o status Abandonada (descartada e removida da consideração ativa), distinto de Perdida.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que trabalho uma oportunidade que não avançará mas não foi propriamente perdida, Quando defino o status como Abandonada, Então ela sai da consideração ativa mantendo-se distinta das perdidas, E pode ser filtrada por esse status.
• Notas: Mapear impacto no funil e nos indicadores (Abandonada não conta como perda).

RF-OPP-011: Motivo de perda estruturado

• Descrição: Ao marcar uma oportunidade como Perdida, o sistema deve permitir registrar um motivo de perda a partir de uma lista estruturada, usável em filtros, automações e no momento da criação/atualização.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas, Administrador (gerencia a lista de motivos)
• H1: Dado que marco uma oportunidade como Perdida, Quando seleciono o motivo de perda na lista, Então o motivo fica gravado de forma estruturada na oportunidade, E pode ser usado como condição em filtros e automações e em relatórios.

Configuração de estágio e do funil

RF-OPP-012: Cor por estágio

• Descrição: Cada estágio do funil deve ter opção de exibição de cor no cartão/coluna: sem cor (padrão), ponto colorido ou fundo com tom, configurável por estágio.
• Prioridade: Média
• Atores: Administrador, Gerente de vendas
• H1: Dado que configuro um estágio do funil, Quando escolho a opção de cor (sem cor, ponto colorido ou fundo com tom), Então os cartões e a coluna daquele estágio no kanban passam a refletir a exibição escolhida, E a configuração é preservada por estágio.

RF-OPP-013: Visibilidade seletiva de estágio em relatórios

• Descrição: Cada estágio deve ter controle individual para aparecer ou não nos gráficos de funil e de pizza dos dashboards, ligável/desligável por estágio.
• Prioridade: Média
• Atores: Administrador, Gerente de vendas
• H1: Dado que configuro os estágios de um funil, Quando desligo a visibilidade de um estágio nos gráficos de funil e pizza, Então esse estágio deixa de aparecer nesses gráficos, E os demais estágios permanecem visíveis.

RF-OPP-014: Exclusão de estágio com realocação de oportunidades

• Descrição: Ao excluir um estágio que contém oportunidades, o sistema deve oferecer mover todas as oportunidades daquele estágio para outro estágio destino escolhido, em vez de perdê-las.
• Prioridade: Alta
• Atores: Administrador, Gerente de vendas
• H1: Dado que tento excluir um estágio com oportunidades, Quando confirmo a exclusão, Então o sistema pede um estágio destino e move todas as oportunidades para ele, E nenhuma oportunidade é perdida no processo.

RF-OPP-015: Visibilidade do funil em dashboards

• Descrição: Cada funil deve ter controle de aparecer ou não nos gráficos de funil e de pizza dos dashboards.
• Prioridade: Média
• Atores: Administrador, Gerente de vendas
• H1: Dado que configuro um funil, Quando ligo ou desligo sua visibilidade nos gráficos de funil e pizza, Então o funil aparece ou some desses gráficos conforme a escolha, E a configuração é persistida.

Owner e atribuição

RF-OPP-016: Desacoplar responsável do contato e da oportunidade

• Descrição: Deve existir configuração que permita ao responsável (owner) da oportunidade ser diferente do responsável do contato. Por padrão a oportunidade herda o responsável do contato, editável depois.
• Prioridade: Média
• Atores: Administrador (liga a configuração), Gerente de vendas, Vendedor
• H1: Dado que a configuração de desacoplar responsáveis está ativa, Quando crio uma oportunidade para um contato, Então ela herda o responsável do contato por padrão mas posso trocar para outro usuário, E o responsável do contato permanece inalterado.

RF-OPP-017: Sincronização entre seguidor e responsável

• Descrição: Devem existir configurações para sincronizar seguidor do contato com responsável da oportunidade e seguidor da oportunidade com responsável do contato.
• Prioridade: Média
• Atores: Administrador, Gerente de vendas
• H1: Dado que ativo a sincronização de seguidor com responsável, Quando o responsável correspondente muda, Então o seguidor é sincronizado automaticamente conforme a regra configurada, E a sincronização respeita a direção escolhida (contato para oportunidade ou o inverso).

Seguidores (followers)

RF-OPP-018: Seguidores da oportunidade

• Descrição: Cada oportunidade deve suportar até 10 usuários seguidores, adicionáveis no detalhe da oportunidade ou via automação. Seguidores podem ver e editar a oportunidade, mas não podem alterar o responsável (ownership).
• Prioridade: Média
• Atores: Vendedor, Gerente de vendas, Administrador
• H1: Dado que abro o detalhe de uma oportunidade, Quando adiciono usuários como seguidores até o limite de 10, Então esses usuários passam a poder ver e editar a oportunidade, E nenhum deles consegue alterar o responsável da oportunidade.

Visão em lista

RF-OPP-019: Visão em lista (tabela) de oportunidades

• Descrição: Além do kanban, deve existir uma visão em lista/tabela das oportunidades, ativável por alternância, com escolha de quais campos (padrão e personalizados) exibir como colunas.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que estou na área de oportunidades, Quando alterno para a visão em lista, Então vejo as oportunidades em tabela, E consigo escolher quais campos padrão e personalizados aparecem como colunas.

RF-OPP-020: Ordenar, redimensionar e reordenar colunas na lista

• Descrição: Na visão em lista, o usuário deve poder ordenar por qualquer campo (crescente/decrescente), redimensionar e reordenar as colunas.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que estou na visão em lista, Quando clico no cabeçalho de uma coluna, Então as oportunidades são ordenadas por aquele campo em ordem crescente ou decrescente, E consigo redimensionar e reordenar as colunas conforme minha preferência.

RF-OPP-021: Visão consolidada de todos os funis (Todos os Pipelines)

• Descrição: A visão em lista deve oferecer uma opção de exibir oportunidades de todos os funis numa lista única, com uma coluna identificando o funil de cada oportunidade.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas, Administrador
• H1: Dado que estou na visão em lista, Quando seleciono a opção de todos os funis, Então vejo as oportunidades de todos os funis numa lista única, E uma coluna indica a qual funil cada oportunidade pertence.
• Notas: Ordenação por estágio pode ser desabilitada no modo todos os funis (limitação aceitável).

Filtros avançados

RF-OPP-022: Filtros avançados de oportunidade

• Descrição: Deve existir um conjunto de filtros avançados, com paridade entre kanban e lista, cobrindo: responsável (com valor dinâmico "eu"), seguidores (com "eu"), status, origem, tipo de campanha, valor, data da última mudança de estágio, data da última mudança de status, criado em, atualizado em, ganho em, perdido em, campos personalizados, tags, funil e estágio.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas, Administrador
• H1: Dado que estou na visão de oportunidades, Quando aplico filtros por responsável, status, origem, valor, datas de mudança ou campos personalizados, Então a lista e o kanban mostram apenas as oportunidades que atendem às condições, E o mesmo conjunto de filtros está disponível nas duas visões.

RF-OPP-023: Operadores de filtro por tipo de campo

• Descrição: Os filtros devem oferecer operadores conforme o tipo do campo. Texto/seleção: é, não é, está vazio, não está vazio. Numérico: igual a, diferente de, menor que, maior que, está vazio, não está vazio.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que escolho um campo para filtrar, Quando o campo é de texto ou numérico, Então os operadores oferecidos correspondem ao tipo do campo, E o resultado do filtro respeita o operador selecionado.

RF-OPP-024: Presets e valores relativos de data nos filtros

• Descrição: Os filtros de data devem oferecer presets (Ontem, Hoje, Esta Semana, Semana Passada, Últimos 7 Dias, Últimos 30 Dias, Este Mês, Mês Passado, Este Ano, Ano Passado, Personalizado) e valores relativos (nos próximos X dias, nas últimas X semanas).
• Prioridade: Média
• Atores: Vendedor, Gerente de vendas
• H1: Dado que filtro por uma data, Quando escolho um preset ou um valor relativo, Então o filtro aplica o intervalo correspondente automaticamente, E a opção Personalizado permite definir um intervalo manual.

RF-OPP-025: Combinação de filtros com E/OU

• Descrição: O usuário deve poder combinar condições de filtro com lógica E (todas as condições) ou OU (pelo menos uma condição).
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que defino várias condições de filtro, Quando escolho a lógica E ou OU, Então o resultado respeita a combinação escolhida, E consigo alternar entre E e OU sem refazer as condições.

RF-OPP-026: Busca de oportunidades por palavra-chave

• Descrição: Deve existir busca por palavra-chave/nome de oportunidade, disparando a partir de um mínimo de 3 caracteres.
• Prioridade: Média
• Atores: Vendedor, Gerente de vendas
• H1: Dado que digito na busca de oportunidades, Quando informo pelo menos 3 caracteres, Então a busca dispara e retorna as oportunidades que casam com o termo, E com menos de 3 caracteres a busca não é acionada.

Ações em massa

RF-OPP-027: Seleção múltipla de oportunidades no kanban

• Descrição: No kanban deve ser possível selecionar múltiplas oportunidades via caixa de seleção no cartão, com opção de selecionar todas as visíveis do funil atual. Durante a seleção, o arrastar de cartões e a abertura de card ficam pausados para evitar erro.
• Prioridade: Média
• Atores: Vendedor, Gerente de vendas, Administrador
• H1: Dado que estou no kanban de oportunidades, Quando marco a caixa de seleção de vários cartões ou seleciono todas as visíveis, Então as oportunidades ficam selecionadas para ação em massa, E o arrastar e a abertura de card ficam pausados enquanto a seleção está ativa.

RF-OPP-028: Ações em massa sobre oportunidades

• Descrição: Sobre a seleção múltipla, devem estar disponíveis: atribuir novo responsável, mudar funil e estágio, atualizar status (Aberta/Ganha/Perdida/Abandonada) e excluir em massa.
• Prioridade: Alta
• Atores: Gerente de vendas, Administrador
• H1: Dado que tenho várias oportunidades selecionadas, Quando escolho atribuir responsável, mudar funil/estágio, atualizar status ou excluir, Então a ação é aplicada a todas as oportunidades selecionadas de uma vez, E o resultado é refletido no kanban e na lista.

RF-OPP-029: Edição em massa de múltiplos campos

• Descrição: Deve existir edição em massa que permita selecionar quais campos atualizar e informar os novos valores, aplicando a várias oportunidades simultaneamente.
• Prioridade: Média
• Atores: Gerente de vendas, Administrador
• H1: Dado que tenho várias oportunidades selecionadas, Quando escolho os campos a atualizar e informo os novos valores, Então esses campos são atualizados em todas as oportunidades selecionadas, E os campos não selecionados permanecem inalterados.

Importação

RF-OPP-030: Importação de oportunidades via CSV

• Descrição: Deve existir importação de oportunidades por CSV, com opção de importar só oportunidades ou contatos e oportunidades juntos, nos modos adicionar novas ou atualizar existentes (via identificador de oportunidade). O mapeamento coluna para campo deve cobrir campos padrão e personalizados, contato válido obrigatório, funil obrigatório e aplicação de tags. Requisitos de arquivo: CSV, tamanho limite, uma única aba, cabeçalho na primeira linha.
• Prioridade: Média
• Atores: Administrador (importa)
• H1: Dado que sou administrador na área de oportunidades, Quando importo um CSV mapeando as colunas para campos padrão e personalizados, Então as oportunidades são criadas ou atualizadas conforme o modo escolhido vinculadas a um contato válido, E as tags informadas são aplicadas às oportunidades importadas.
• Notas: Restringir importação ao perfil Administrador.

RF-OPP-031: Monitoramento e correção de importação

• Descrição: A importação deve ter uma página de acompanhamento com estatísticas do lote, log de erros baixável e detalhe de cada erro com orientação de correção.
• Prioridade: Média
• Atores: Administrador
• H1: Dado que executei uma importação de oportunidades, Quando acesso o acompanhamento do lote, Então vejo as estatísticas do processamento e posso baixar o log de erros, E cada erro traz o detalhe e a orientação de como corrigir.

Previsão / forecasting

RF-OPP-032: Data esperada de fechamento

• Descrição: A oportunidade deve ter campo de data esperada de fechamento, usável para previsão temporal por semana, mês ou trimestre.
• Prioridade: Alta
• Atores: Vendedor, Gerente de vendas
• H1: Dado que trabalho uma oportunidade, Quando informo a data esperada de fechamento, Então o valor fica gravado na oportunidade, E é usado como base para a previsão temporal.

RF-OPP-033: Probabilidade por estágio e override manual

• Descrição: Deve existir probabilidade de fechamento com peso padrão por estágio e possibilidade de sobrescrever manualmente a probabilidade em cada oportunidade.
• Prioridade: Média
• Atores: Administrador (define peso por estágio), Gerente de vendas, Vendedor (override)
• H1: Dado que um estágio tem probabilidade padrão configurada, Quando uma oportunidade está nesse estágio, Então ela assume a probabilidade do estágio, E o usuário pode sobrescrever manualmente a probabilidade daquela oportunidade.

RF-OPP-034: Receita esperada ponderada

• Descrição: O sistema deve calcular a receita esperada como valor multiplicado pela probabilidade, resultando no funil ponderado (weighted pipeline).
• Prioridade: Média
• Atores: Gerente de vendas, Administrador
• H1: Dado que uma oportunidade tem valor e probabilidade, Quando visualizo a previsão, Então o sistema exibe a receita esperada como valor multiplicado pela probabilidade, E o total ponderado do funil é apresentado.

RF-OPP-035: Painel resumo de previsão

• Descrição: Deve existir uma visão resumo de previsão com métricas consolidadas e drill-down até as oportunidades que compõem cada número.
• Prioridade: Média
• Atores: Gerente de vendas, Administrador
• H1: Dado que acesso a previsão, Quando abro a visão resumo, Então vejo as métricas consolidadas de previsão, E consigo fazer drill-down até as oportunidades que compõem cada métrica.

RF-OPP-036: Linha do tempo de previsão

• Descrição: Deve existir uma visão de previsão em linha do tempo, agrupando por semana, mês ou trimestre.
• Prioridade: Média
• Atores: Gerente de vendas, Administrador
• H1: Dado que acesso a previsão, Quando escolho a granularidade semana, mês ou trimestre, Então a linha do tempo reorganiza as oportunidades previstas por aquele período, E os totais por período são recalculados.

RF-OPP-037: Risco de atraso na previsão

• Descrição: A previsão deve classificar risco de atraso/slippage em níveis Alto, Médio e Baixo por oportunidade, com limiares configuráveis (thresholds de atraso/vencimento).
• Prioridade: Média
• Atores: Administrador (configura limiares), Gerente de vendas
• H1: Dado que uma oportunidade tem data esperada de fechamento, Quando a data se aproxima ou vence conforme os limiares configurados, Então a oportunidade recebe classificação de risco Alto, Médio ou Baixo, E os limiares podem ser ajustados pelo administrador.

RF-OPP-038: Higiene de dados da previsão

• Descrição: A previsão deve destacar problemas de dados que comprometem a projeção, como valor ausente, data ausente e oportunidades paradas.
• Prioridade: Média
• Atores: Gerente de vendas, Administrador
• H1: Dado que acesso a previsão, Quando há oportunidades sem valor, sem data ou paradas, Então o sistema sinaliza esses problemas de higiene de dados, E consigo identificar quais oportunidades precisam de correção.

Automação nativa de funil

RF-OPP-039: Gatilhos de automação de oportunidade

• Descrição: Devem existir gatilhos nativos: oportunidade criada, estágio do funil alterado (inclusive regressão de estágio e reatribuição), status da oportunidade alterado e campos da oportunidade alterados. Os gatilhos devem ser filtráveis por campos padrão e personalizados (responsável, tag, funil, valor, motivo de perda, estágio, status).
• Prioridade: Alta
• Atores: Administrador, Gerente de vendas
• H1: Dado que monto uma automação, Quando escolho um gatilho de oportunidade como estágio alterado ou status alterado, Então a automação dispara na condição correspondente, E consigo restringir o disparo por filtros de campos padrão e personalizados.

RF-OPP-040: Gatilho de oportunidade parada (stale)

• Descrição: Deve existir gatilho que dispara quando a oportunidade fica um número X de dias sem mudança no mesmo estágio, com filtros por funil e estágio, para detectar oportunidades estagnadas (rotting).
• Prioridade: Alta
• Atores: Administrador, Gerente de vendas
• H1: Dado que configuro o gatilho de oportunidade parada com uma duração em dias, Quando uma oportunidade permanece esse tempo no mesmo estágio sem mudança, Então a automação dispara, E o disparo pode ser restrito por funil e estágio.

RF-OPP-041: Ações de automação sobre oportunidade

• Descrição: Devem existir ações nativas: criar oportunidade (com funil, estágio, nome, origem, status, motivo de perda), atualizar oportunidade (nome, funil, estágio, status, origem, valor, com opção de permitir mover para estágio anterior), adicionar responsável (com opção de aplicar só a não atribuídas), remover oportunidade e localizar oportunidade para dar contexto às ações seguintes. Deve haver condicional se/senão baseado em campos de oportunidade.
• Prioridade: Alta
• Atores: Administrador, Gerente de vendas
• H1: Dado que monto uma automação com gatilho de oportunidade, Quando adiciono ações de criar, atualizar, adicionar responsável, remover ou localizar oportunidade, Então cada ação opera sobre a oportunidade em contexto conforme os parâmetros informados, E consigo ramificar o fluxo com condicional se/senão sobre campos da oportunidade.

RF-OPP-042: Notificação interna em mudança ou estagnação

• Descrição: A automação deve permitir enviar notificação interna à equipe ou gestor quando ocorrer mudança de estágio, mudança de status ou estagnação, cobrindo o caso de notificar o time em trocas de estágio (modelo automação-driven, não toggle no funil).
• Prioridade: Alta
• Atores: Administrador, Gerente de vendas, Vendedor (destinatário)
• H1: Dado que uma oportunidade muda de estágio, muda de status ou fica parada, Quando o gatilho correspondente dispara, Então a automação envia uma notificação interna ao usuário ou gestor configurado, E a mensagem identifica a oportunidade e o evento ocorrido.

RF-OPP-043: Controle de movimentação para estágio anterior

• Descrição: A movimentação de oportunidade por automação deve ter um controle (toggle) que permite ou bloqueia mover a oportunidade para um estágio anterior (regressão de estágio via workflow).
• Prioridade: Média
• Atores: Administrador
• H1: Dado que configuro uma ação de atualizar oportunidade numa automação, Quando ligo a opção de permitir mover para estágio anterior, Então a automação consegue regredir a oportunidade de estágio, E com a opção desligada a regressão é bloqueada.

11.4 Calendário e agendamento avançado (RF-CAL)

Cobre os GAPS do ModularCRM frente ao GoHighLevel na área de calendário/agendamento. Já temos calendário 1-a-1 com regras de disponibilidade, página pública, sync bidirecional Google, reagendamento por link, exceções e lembretes; estes RFs endereçam os tipos de calendário multi-pessoa, recursos físicos, pagamento no booking, status rico, sincronização multi-provedor e widget avançado.

RF-CAL-007: Calendário Round Robin (distribuição entre vários membros)

• Descrição: Tipo de calendário que distribui agendamentos entre múltiplos membros da equipe, compartilhando todas as configurações do calendário simples mas atendendo mais de uma pessoa. Ideal para vendas, suporte e clínicas.
• Prioridade: Alta
• Atores: Admin da conta, Membro da equipe, Lead/Contato
• H1: Dado que um admin configurou um calendário Round Robin com 3 membros, Quando um lead abre a página pública e escolhe um slot, Então o sistema atribui o agendamento a um dos membros conforme a lógica de distribuição, E bloqueia o slot na agenda do membro escolhido.
• Notas: Base de motor compartilhada com Collective e Class; construir o núcleo multi-membro uma vez.

RF-CAL-008: Lógica de distribuição do Round Robin (disponibilidade vs equidade)

• Descrição: O admin escolhe entre dois métodos de distribuição: otimizar por disponibilidade (atribui ao próximo membro livre na sequência, priorizando preencher slots) ou otimizar por distribuição igualitária (equilibra a carga entre os membros).
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado um calendário Round Robin em modo distribuição igualitária, Quando chegam vários agendamentos ao longo do dia, Então o sistema equilibra a quantidade atribuída a cada membro, E ao trocar para modo disponibilidade passa a atribuir ao primeiro membro livre na ordem definida.
• Notas: O método é configurável por calendário, não global.

RF-CAL-009: Seleção de membro preferido pelo cliente (Staff Selection)

• Descrição: Toggle que permite ao próprio cliente escolher, no ato da reserva, qual membro da equipe prefere, em vez de deixar o sistema atribuir automaticamente.
• Prioridade: Média
• Atores: Admin da conta, Lead/Contato
• H1: Dado que o Staff Selection está ligado num calendário Round Robin, Quando o cliente abre a página de reserva, Então ele vê a lista de membros disponíveis e pode selecionar o preferido, E o agendamento vai para o membro escolhido respeitando a disponibilidade dele.
• Notas: Quando desligado, cai na lógica de distribuição automática (RF-CAL-008).

RF-CAL-010: Calendário Coletivo (Collective, multi-host simultâneo)

• Descrição: Tipo de calendário em que vários hosts precisam estar livres ao mesmo tempo para o slot existir. Exige no mínimo 2 e no máximo 100 membros; quanto mais membros, menos slots comuns.
• Prioridade: Alta
• Atores: Admin da conta, Membros da equipe, Lead/Contato
• H1: Dado um calendário Coletivo com 3 hosts obrigatórios, Quando o sistema calcula os slots disponíveis, Então só exibe horários em que os 3 hosts estão livres simultaneamente, E ao reservar, bloqueia o slot na agenda de todos os hosts.
• Notas: Interseção de disponibilidade, não união.

RF-CAL-011: Dono principal (Primary Owner) do agendamento coletivo

• Descrição: Um dos hosts é o dono principal, que lidera o agendamento, recebe a atribuição de contato e cede sua localização de reunião quando o campo de local fica vazio. Default é o primeiro membro adicionado, alterável, e não pode ser removido sem antes transferir a titularidade.
• Prioridade: Média
• Atores: Admin da conta, Membro dono principal
• H1: Dado um calendário Coletivo com dono principal definido, Quando o admin tenta remover o dono principal, Então o sistema bloqueia a remoção até que a titularidade seja transferida a outro membro, E ao concluir a reserva, atribui o contato ao dono principal vigente.
• Notas: Local de reunião do dono principal é usado como fallback quando o local do calendário está vazio.

RF-CAL-012: Calendário de Turma (Class Booking, 1 host para muitos)

• Descrição: Tipo de calendário de um host para muitos participantes (webinar, aula, workshop, evento esportivo), com um único dono do agendamento e múltiplos participantes por slot.
• Prioridade: Alta
• Atores: Admin da conta, Host/Instrutor, Participantes
• H1: Dado um calendário de Turma com 20 vagas por slot, Quando 15 pessoas reservam o mesmo horário, Então o sistema aceita todas no mesmo slot sem criar conflito, E continua exibindo o slot como disponível até esgotar as vagas.
• Notas: Suporta até milhares de participantes por slot (limite alto configurável).

RF-CAL-013: Controle de vagas e exibição de assentos por slot

• Descrição: Configuração do número de vagas por slot na Turma, com exibição ao cliente da quantidade de assentos ainda disponíveis, e toggles de permitir cancelamento e permitir reagendamento para os participantes.
• Prioridade: Média
• Atores: Admin da conta, Participante
• H1: Dado um slot de Turma com 5 assentos restantes, Quando o cliente abre a página de reserva, Então ele vê a quantidade de assentos disponíveis naquele slot, E ao esgotar as vagas o slot deixa de ser reservável.
• Notas: Class Booking não suporta recorrência customizada.

RF-CAL-014: Calendário de Serviço (Service Calendar) para serviços físicos

• Descrição: Tipo de calendário voltado a serviços físicos presenciais (salão, spa, detailing, fotografia), com disponibilidade atrelada ao staff atribuído, intervalo de slot fixo, formulário, consentimento, página de confirmação e valor cobrado do participante principal.
• Prioridade: Alta
• Atores: Admin da conta, Staff, Cliente
• H1: Dado um Calendário de Serviço com staff atribuído e intervalo de slot de 15 minutos, Quando o cliente escolhe um serviço e horário, Então o sistema oferece apenas horários em que o staff está disponível, E registra duração, buffer pós-atendimento e antecedência mínima definidos no serviço.
• Notas: Serviço físico não usa Zoom ou Google Meet como local; local é telefone, endereço ou custom.

RF-CAL-015: Assets visuais por serviço (logo e imagem de capa)

• Descrição: Cada serviço tem logo próprio, exibido no widget de reserva, e imagem de capa, exibida na vitrine de serviços. Assets carregáveis em runtime pelo admin, não fixos no código.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado que o admin está editando um serviço, Quando ele faz upload do logo e da capa do serviço, Então o widget de reserva passa a exibir o logo, E a vitrine de serviços passa a exibir a imagem de capa daquele serviço.
• Notas: Validar tipo de imagem por magic bytes; barrar SVG por segurança; preservar o valor na edição.

RF-CAL-016: Salas (Rooms) com capacidade e associação a calendários

• Descrição: Cadastro de salas (local físico onde o serviço é prestado, como sala de massagem, cadeira de salão, estação de pedicure) com nome, descrição, capacidade total (número máximo de agendamentos simultâneos) e associação a calendários de serviço.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado uma sala com capacidade total de 2 associada a um serviço, Quando já existem 2 agendamentos simultâneos na sala, Então o sistema bloqueia novas reservas concorrentes naquele horário para aquela sala, E libera o slot quando um dos agendamentos termina.
• Notas: Capacidade controla concorrência e impede overbooking da sala.

RF-CAL-017: Equipamentos (Equipment) com quantidade

• Descrição: Cadastro de equipamentos (ferramentas ou dispositivos usados no serviço, como máquinas e cadeiras) com quantidade disponível, associados aos serviços que os consomem.
• Prioridade: Alta
• Atores: Admin da conta
• H1: Dado um equipamento com quantidade 3 associado a um serviço, Quando 3 agendamentos simultâneos já usam esse equipamento, Então o sistema impede um quarto agendamento no mesmo horário, E volta a permitir quando um dos três for concluído ou cancelado.
• Notas: Quantidade funciona como capacidade concorrente do recurso.

RF-CAL-018: Reserva automática e anti-double-booking de sala e equipamento

• Descrição: Ao confirmar um agendamento, o motor reserva automaticamente a sala e o equipamento necessários, evitando conflito de duplo agendamento não só do staff mas também dos recursos físicos.
• Prioridade: Alta
• Atores: Cliente, Staff, Motor de agendamento
• H1: Dado um serviço que exige uma sala e um equipamento específicos, Quando o cliente confirma o agendamento, Então o sistema reserva sala, equipamento e staff em conjunto, E só oferece o slot quando os três recursos estão simultaneamente livres.
• Notas: Conflito de qualquer um dos três recursos remove o slot da disponibilidade.

RF-CAL-019: Menu de Serviços (vitrine multi-serviço brandeada)

• Descrição: Vitrine em link único que reúne vários calendários de serviço, com título, descrição, slug próprio e formulário de nível de menu, permitindo ao cliente navegar e reservar serviços a partir de uma página única com a marca da empresa.
• Prioridade: Alta
• Atores: Admin da conta, Cliente
• H1: Dado um Menu de Serviços com 5 serviços selecionados, Quando o cliente abre o link do menu, Então ele vê os serviços disponíveis em uma página brandeada, E pode escolher um serviço e seguir para a reserva do horário.
• Notas: Serviços precisam pertencer a um grupo de calendário para entrarem no menu; responsivo mobile com campo de código customizado para pixels de tracking.

RF-CAL-020: Ordenação e limite de serviços no Menu

• Descrição: No Menu de Serviços o admin seleciona quais calendários aparecem via checkboxes, reordena por arrastar e soltar, e liga o toggle de limitar a um serviço por reserva (quando desligado, o cliente pode reservar vários serviços de uma vez).
• Prioridade: Média
• Atores: Admin da conta, Cliente
• H1: Dado um Menu de Serviços com o limite de um serviço ligado, Quando o cliente adiciona um serviço, Então o sistema impede a seleção de um segundo serviço na mesma reserva, E ao desligar o toggle permite múltiplos serviços na mesma sessão.
• Notas: Ordem definida pelo admin via drag-and-drop reflete na exibição pública.

RF-CAL-021: Calendário de Evento (Event Calendar)

• Descrição: Tipo de calendário voltado a eventos, com notificações default direcionadas aos admins da conta.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um Calendário de Evento configurado, Quando um agendamento é criado, Então os admins da conta recebem a notificação por default, E o evento fica registrado no calendário conforme as regras definidas.
• Notas: Menor prioridade entre os tipos; pode ser fatia final.

RF-CAL-022: Grupos de Calendário (link único agrupando calendários)

• Descrição: Container que agrupa vários calendários sob um único link, servindo de base para o Menu de Serviços e para páginas de reserva consolidadas.
• Prioridade: Alta
• Atores: Admin da conta, Cliente
• H1: Dado um grupo com 4 calendários, Quando o cliente abre o link do grupo, Então ele vê os calendários agrupados em uma única página, E pode escolher para qual calendário deseja agendar.
• Notas: Pré-requisito estrutural do Menu de Serviços (RF-CAL-019).

RF-CAL-023: Pagamento no agendamento com múltiplos gateways

• Descrição: Toggle de aceitar pagamentos no ato da reserva, com suporte a múltiplos gateways de pagamento, cobrança apenas pelo gateway default, suporte a múltiplas moedas e descrição de pagamento configurável.
• Prioridade: Alta
• Atores: Admin da conta, Cliente
• H1: Dado um calendário com pagamento habilitado e gateway configurado, Quando o cliente escolhe um horário, Então o sistema exige o pagamento antes de confirmar a reserva, E confirma o agendamento somente após o pagamento aprovado.
• Notas: Alinhar com a decisão oficial do ModularCRM sobre gateways (Pix manual em V1, Asaas em V2); manter multi-currency como configuração.

RF-CAL-024: Pagamento parcial ou depósito no agendamento

• Descrição: Toggle de aceitar pagamento parcial, com escolha entre valor fixo ou percentual sobre o total. A transação registra o valor do depósito e uma fatura registra o saldo restante em rascunho para cobrança manual.
• Prioridade: Média
• Atores: Admin da conta, Cliente, Financeiro
• H1: Dado um serviço com depósito de 30 por cento habilitado, Quando o cliente reserva, Então o sistema cobra apenas 30 por cento do total no ato, E gera uma fatura em rascunho com o saldo restante para cobrança posterior.
• Notas: Pagamento parcial não funciona com agendamentos recorrentes.

RF-CAL-025: Aba de pagamentos por calendário

• Descrição: Área dentro do calendário para rastrear e coletar os pagamentos dos agendamentos, listando o que foi pago, pendente e a coletar.
• Prioridade: Média
• Atores: Admin da conta, Financeiro
• H1: Dado um calendário com pagamentos habilitados, Quando o admin abre a aba de pagamentos, Então ele vê a lista de agendamentos com status de pagamento, E pode acompanhar valores pendentes e coletados.
• Notas: Complementa RF-CAL-023 e RF-CAL-024.

RF-CAL-026: Agendamentos recorrentes padrão

• Descrição: Toggle de recorrência na disponibilidade, com frequência diária, semanal, mensal ou customizada, limite máximo de recorrências, e respeito às horas de trabalho, buffers e distribuição. Fim da recorrência configurável como nunca, data específica ou após X ocorrências.
• Prioridade: Média
• Atores: Admin da conta, Cliente
• H1: Dado um calendário com recorrência semanal habilitada e término após 8 ocorrências, Quando o cliente reserva o primeiro agendamento, Então o sistema cria a série respeitando horas de trabalho e buffers, E encerra a série após a oitava ocorrência.
• Notas: Recorrência padrão exige 1 membro atribuído e não pode ter horas por data específica; não suportado em Serviço e Turma.

RF-CAL-027: Recorrência customizada no modal de agendamento

• Descrição: Regra de recorrência livre criada no modal do agendamento interno (por exemplo a cada 5 dias, dias úteis, segunda terça-feira do mês, terminar após X ocorrências ou em data específica), que ignora a disponibilidade e pode gerar sobreposição.
• Prioridade: Média
• Atores: Admin da conta, Staff
• H1: Dado que o staff cria um agendamento interno com recorrência a cada 5 dias, Quando ele salva a regra customizada, Então o sistema gera as ocorrências conforme a regra mesmo em horários fora da disponibilidade, E sinaliza que a regra customizada ignora a checagem de disponibilidade.
• Notas: Uso interno; diferente da recorrência padrão da página pública.

RF-CAL-028: Estratégias de slot indisponível na recorrência

• Descrição: Quando um slot da série recorrente cai em horário indisponível, o sistema aplica uma de três estratégias: pular a reserva, continuar a reserva (confirmada ou não confirmada) ou reservar o próximo disponível (parando após 3 slots consecutivos indisponíveis).
• Prioridade: Média
• Atores: Admin da conta, Motor de agendamento
• H1: Dado uma série recorrente configurada com a estratégia reservar próximo disponível, Quando uma ocorrência cai em horário indisponível, Então o sistema busca o próximo slot livre, E interrompe a busca após 3 slots consecutivos indisponíveis.
• Notas: Estratégia definida por calendário.

RF-CAL-029: Status de agendamento rico

• Descrição: Conjunto ampliado de status de agendamento além de confirmado: não confirmado, cancelado, compareceu, não compareceu e inválido, essenciais para métricas e follow-up.
• Prioridade: Alta
• Atores: Admin da conta, Staff
• H1: Dado um agendamento realizado, Quando o staff marca o cliente como não compareceu, Então o sistema registra o status não compareceu, E disponibiliza esse status para segmentação e relatórios.
• Notas: Atualizações apenas de status (compareceu, não compareceu) não são empurradas para o calendário externo.

RF-CAL-030: Automação sobre mudança de status de agendamento

• Descrição: Gatilho de automação disparado por mudança de status do agendamento e ação de automação para atualizar o status, permitindo fluxos de follow-up (por exemplo, sequência de recuperação de não comparecimento).
• Prioridade: Alta
• Atores: Admin da conta, Motor de automação
• H1: Dado um fluxo de automação com gatilho status igual a não compareceu, Quando um agendamento passa para não compareceu, Então o sistema dispara o fluxo configurado, E pode atualizar o status do agendamento via ação de automação.
• Notas: Integra com o motor de workflows do CRM.

RF-CAL-031: Sincronização com Outlook, Office365, iCloud e Calendly

• Descrição: Ampliar a sincronização externa além do Google para Outlook/Office365, iCloud e Calendly, com autorização de acesso de leitura e escrita por conta externa.
• Prioridade: Alta
• Atores: Admin da conta, Membro da equipe
• H1: Dado um membro que conecta sua conta Outlook, Quando ele autoriza acesso de leitura e escrita, Então o sistema passa a ler os eventos externos para calcular disponibilidade, E escreve os novos agendamentos na conta conectada.
• Notas: Cada membro conecta a própria conta em suas configurações de perfil.

RF-CAL-032: Camadas de calendário conectado, vinculado, de conflito e primário

• Descrição: Modelar a granularidade das conexões externas em camadas: calendário conectado (autoriza a conta), vinculado (importa eventos para mostrar disponibilidade real), de conflito (bloqueia slots quando há evento externo) e primário (destino de escrita dos novos agendamentos).
• Prioridade: Média
• Atores: Admin da conta, Membro da equipe
• H1: Dado um membro com um calendário externo marcado como de conflito e outro como primário, Quando existe um evento no calendário de conflito, Então o sistema bloqueia o slot correspondente, E grava os novos agendamentos apenas no calendário primário.
• Notas: Reconexão deve ressincronizar os agendamentos futuros automaticamente.

RF-CAL-033: Política de eventos externos ocupado versus livre

• Descrição: Ler a marcação dos eventos externos e tratar eventos marcados como ocupado como bloqueadores de slot, e eventos marcados como livre como visíveis mas não bloqueadores.
• Prioridade: Média
• Atores: Admin da conta, Motor de agendamento
• H1: Dado um evento externo marcado como livre na conta conectada, Quando o sistema calcula a disponibilidade, Então ele exibe o evento mas não bloqueia o slot, E bloqueia o slot apenas quando o evento externo está marcado como ocupado.
• Notas: Sincronização unidirecional entra o evento externo como slot bloqueado sem criar contato; bidirecional cria contato do convidado e dispara fluxos.

RF-CAL-034: Widget de reserva moderno com aparência customizável e passos reordenáveis

• Descrição: Estilo de widget moderno com cores, fundo e texto de botão customizáveis, capacidade de reordenar os passos (formulário, data e hora, pagamento) e de ocultar campos do painel (nome, descrição, duração, data e hora, detalhes de recorrência, fuso horário).
• Prioridade: Alta
• Atores: Admin da conta, Cliente
• H1: Dado um widget moderno com o passo de pagamento reordenado para antes da escolha de horário, Quando o cliente abre a reserva, Então os passos aparecem na ordem configurada, E as cores e o texto do botão refletem a customização definida pelo admin.
• Notas: Trocar de estilo de widget não afeta agendamentos existentes; manter também um estilo clássico simples.

RF-CAL-035: Incorporação do widget via iframe ou script

• Descrição: Permitir incorporar o widget de reserva em qualquer site externo via iframe ou script HTML, de forma responsiva a mobile.
• Prioridade: Média
• Atores: Admin da conta, Desenvolvedor do cliente
• H1: Dado o código de incorporação de um calendário, Quando o desenvolvedor cola o script no site do cliente, Então o widget de reserva aparece embutido na página, E o cliente consegue agendar sem sair do site.
• Notas: Widget deve ser mobile-friendly.

RF-CAL-036: Campos customizados no formulário de reserva

• Descrição: Formulário de reserva com campos customizados além de nome, sobrenome, email e telefone, conectado ao calendário, cujos dados são salvos no contato do CRM após a escolha do slot.
• Prioridade: Alta
• Atores: Admin da conta, Cliente
• H1: Dado um calendário com um campo customizado de observações no formulário, Quando o cliente escolhe o slot e preenche o formulário, Então o sistema salva o valor do campo no contato do CRM, E vincula o dado ao agendamento criado.
• Notas: Formulário preenchido após a escolha do horário.

RF-CAL-037: Caixa de consentimento no agendamento

• Descrição: Caixa de consentimento com mensagem customizável exibida no formulário de reserva, exigindo aceite explícito do cliente antes de confirmar.
• Prioridade: Média
• Atores: Admin da conta, Cliente
• H1: Dado um calendário com caixa de consentimento habilitada, Quando o cliente vai confirmar a reserva sem marcar o consentimento, Então o sistema impede a confirmação, E só prossegue após o cliente marcar a caixa.
• Notas: Mensagem de consentimento definida pelo admin.

RF-CAL-038: Página de confirmação com mensagem ou redirecionamento

• Descrição: Configuração da página exibida após a reserva, com opção de mensagem de agradecimento customizada ou redirecionamento para uma URL.
• Prioridade: Média
• Atores: Admin da conta, Cliente
• H1: Dado um calendário configurado para redirecionar após a reserva, Quando o cliente confirma o agendamento, Então o sistema o redireciona para a URL definida, E ao usar o modo mensagem, exibe o texto de agradecimento customizado.
• Notas: Escolha exclusiva entre mensagem e redirecionamento.

RF-CAL-039: Convidados adicionais no agendamento

• Descrição: Permitir que o cliente adicione múltiplos convidados (nome e email) ao agendamento no widget; os convidados recebem a notificação no email informado, mas não recebem os links de reagendamento ou cancelamento.
• Prioridade: Média
• Atores: Cliente, Convidados
• H1: Dado um agendamento em que o cliente adicionou 2 convidados, Quando a reserva é confirmada, Então os convidados recebem a notificação por email, E não recebem os links de reagendamento nem de cancelamento (que ficam apenas com o participante principal).
• Notas: Convite externo pode ser enviado a todos os hosts conforme o tipo de calendário.

RF-CAL-040: Notificações multicanal incluindo WhatsApp

• Descrição: Notificações de agendamento por múltiplos canais (email, SMS, in-app e WhatsApp via templates aprovados), configuráveis por calendário e por destinatário, com merge fields e seleção de template.
• Prioridade: Alta
• Atores: Admin da conta, Contato, Membro atribuído, Convidado
• H1: Dado um calendário com notificação por WhatsApp habilitada, Quando um agendamento é confirmado, Então o contato recebe a mensagem pelo template de WhatsApp aprovado, E os merge fields são preenchidos com os dados do agendamento.
• Notas: Destinatários incluem contato, usuário atribuído, convidado e emails ou telefones adicionais.

RF-CAL-041: Múltiplos lembretes escalonados e follow-up

• Descrição: Configuração de múltiplos gatilhos de tempo para lembretes antes do agendamento e follow-up após o agendamento, cobrindo os eventos de reservado não confirmado, reservado confirmado, cancelamento, reagendamento, lembrete e acompanhamento.
• Prioridade: Alta
• Atores: Admin da conta, Contato
• H1: Dado um calendário com dois lembretes configurados (24 horas e 1 hora antes), Quando o horário do agendamento se aproxima, Então o sistema envia o primeiro lembrete 24 horas antes, E envia o segundo lembrete 1 hora antes.
• Notas: Follow-up dispara tempo definido após o agendamento.

RF-CAL-042: Modo parecer ocupado (Look Busy)

• Descrição: Recurso que oculta parte dos slots livres para dar a impressão de agenda mais cheia, exibindo apenas uma fração dos horários disponíveis.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um calendário com o modo parecer ocupado ligado a 50 por cento, Quando o cliente abre a página de reserva, Então o sistema exibe apenas metade dos slots realmente livres, E mantém os demais ocultos.
• Notas: Percentual ou intensidade configurável.

RF-CAL-043: Teto diário de agendamentos (Appointments per Day)

• Descrição: Limite máximo de agendamentos que um calendário aceita por dia, independentemente da quantidade de slots livres.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um calendário com teto de 8 agendamentos por dia, Quando o oitavo agendamento do dia é confirmado, Então o sistema deixa de oferecer novos horários naquele dia, E volta a oferecer horários no dia seguinte.
• Notas: Complementa as regras de duração e intervalo de slot.

RF-CAL-044: Janela e política de cancelamento e reagendamento

• Descrição: Definição de uma janela de política em que, após determinado tempo antes do agendamento, o cliente perde o acesso aos links de reagendamento e cancelamento.
• Prioridade: Média
• Atores: Admin da conta, Cliente
• H1: Dado um calendário com política de fechar links 2 horas antes do agendamento, Quando faltam menos de 2 horas para o horário, Então o link de reagendamento e cancelamento deixa de funcionar para o cliente, E antes desse limite os links funcionam normalmente.
• Notas: Já temos reagendamento por link; falta a janela de política.

RF-CAL-045: Distinção entre duração, intervalo e agendamentos por slot

• Descrição: Configurações separadas de duração do agendamento, intervalo de início dos slots (frequência com que os horários começam) e quantidade de agendamentos concorrentes no mesmo slot.
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um calendário com duração de 30 minutos, intervalo de 60 minutos e 2 agendamentos por slot, Quando o cliente vê os horários, Então os slots começam de hora em hora, E cada slot aceita até 2 reservas concorrentes.
• Notas: Base de disponibilidade compartilhada por todos os tipos de calendário.

RF-CAL-046: Cor do evento sincronizada ao calendário externo

• Descrição: Definição de uma cor de evento por calendário ou serviço, que é sincronizada como cor do evento no calendário externo (Google e afins).
• Prioridade: Média
• Atores: Admin da conta
• H1: Dado um serviço com cor de evento definida, Quando um agendamento é criado e sincronizado ao Google, Então o evento aparece no Google com a cor definida, E mantém a identificação visual do tipo de serviço.
• Notas: Melhoria de organização visual na agenda externa.

RF-CAL-047: Título do convite e notas adicionais no convite externo

• Descrição: Configuração do título do convite (nome do evento exibido nos apps de calendário) e de notas adicionais incluídas no convite externo, por calendário ou serviço.
• Prioridade: Média
• Atores: Admin da conta, Cliente, Staff
• H1: Dado um serviço com título de convite e notas adicionais configurados, Quando o agendamento é sincronizado ao calendário externo, Então o convite aparece com o título definido, E inclui as notas adicionais no corpo do convite.
• Notas: Aplica-se aos convites gerados no Google e provedores equivalentes.

RF-CAL-048: Suporte a calendários de serviço no app mobile

• Descrição: Suporte específico aos calendários de serviço no aplicativo mobile do CRM, permitindo gestão de agendamentos de serviço fora do desktop.
• Prioridade: Média
• Atores: Admin da conta, Staff
• H1: Dado um staff com o app mobile do CRM, Quando ele acessa os agendamentos de serviço no celular, Então ele vê e gerencia os agendamentos de serviço atribuídos a ele, E as ações refletem no sistema em tempo real.
• Notas: Depende da existência de app mobile do ModularCRM; pode ser fatia posterior.

11.5 Automações avançadas (RF-AUTO)

Esta seção cobre os gaps do construtor de automações do ModularCRM frente ao GoHighLevel, cuja área de Workflows tem cerca de 89 gatilhos e 70 ações. O construtor visual e as ações básicas (mensagem, tag, tarefa, mover no funil, pontuar, condicional, espera temporizada) já existem. Os gatilhos básicos existiam só pela metade, e este documento afirmava o contrário até 2026-07-15: dos vinte gatilhos que o editor oferecia, onze disparavam de fato e oito eram oferecidos na tela, salvavam a automação como ativa e nunca rodavam. Isso foi corrigido em 2026-07-15 pelo {AUD-43} do Roadmap: a tela passou a oferecer treze gatilhos, todos com emissor real. No mesmo dia, por decisão de produto, o RF-AUTO-002 recebeu de volta dois gatilhos, o lembrete de agendamento e o contato atualizado, e recebeu o clique em link rastreável, que o RF-CONV-014 exige, como décimo sexto. O {AUD-51} entregou o emissor do clique ainda no mesmo dia, merge 109857f, subindo a tela para catorze, e por isso o requisito nomeia dezesseis enquanto a tela oferece catorze: os dois que faltam são backlog especificado nos cards {AUD-52} e {AUD-53}, não defeito. O botão de executar uma automação à mão ganhou requisito próprio, o RF-AUTO-043, e está no {AUD-56}. Os RFs abaixo tratam do que falta, agrupado por categoria de gatilho, ação, tipo de espera, configuração e observabilidade do builder.

Gatilhos de contato e CRM

RF-AUTO-008: Gatilhos de ciclo de vida e mudança de campo do contato

• Descrição: Novos gatilhos que disparam a partir do estado do contato, e não apenas da sua criação. Cobre: Contact Changed (campo específico muda para valor definido), Contact DND (DND ligado ou desligado), Birthday Reminder (aniversário com offset configurável de dias antes ou depois), Custom Date Reminder (antes, no dia ou depois de qualquer campo de data em contato, oportunidade ou objeto custom) e Contact Engagement Score (score atinge um limiar).
• Prioridade: Alta
• Atores: Administrador, Gestor de automações
• H1: Dado que um contato tem o campo "aniversário" preenchido, Quando faltarem 3 dias para a data configurada no gatilho Birthday Reminder, Então o workflow inscreve o contato automaticamente, E o gatilho respeita o offset e o fuso configurados sem inscrever o mesmo contato duas vezes no mesmo ciclo anual.
• Notas: Cada gatilho expõe filtros de qual campo observar e qual valor alvo; Custom Date Reminder deve suportar recorrência anual para datas como renovação.

RF-AUTO-009: Gatilhos de notas e tarefas do contato

• Descrição: Gatilhos disparados por atividade de notas e tarefas: Note Added (nova nota), Note Changed (nota editada), Task Added (tarefa criada), Task Reminder (horário de lembrete atingido) e Task Completed (tarefa concluída).
• Prioridade: Média
• Atores: Gestor de automações, Vendedor
• H1: Dado que um vendedor marca uma tarefa do contato como concluída, Quando o gatilho Task Completed está ativo no workflow, Então o contato é inscrito, E os dados da tarefa (título, responsável, data) ficam disponíveis como variáveis nos passos seguintes.

Gatilhos de agendamento e oportunidade

RF-AUTO-010: Gatilhos de agendamento por status e por tipo de reserva

• Descrição: Amplia o gatilho de agendamento para reagir a mudanças de status e a novos tipos de reserva. Cobre: Appointment Status (booked, rescheduled, canceled, no-show), Service Booking (reserva via módulo de serviços) e Rental Booking (reserva de aluguel).
• Prioridade: Alta
• Atores: Gestor de automações, Atendimento
• H1: Dado um contato com agendamento marcado, Quando o status do agendamento muda para no-show, Então o workflow com gatilho Appointment Status filtrado em no-show inscreve o contato, E permite ramificar por cada status distinto no mesmo workflow.

RF-AUTO-011: Gatilhos de oportunidade e pipeline

• Descrição: Novos gatilhos de pipeline além da mudança de estágio já existente. Cobre: Opportunity Created (nova oportunidade), Opportunity Changed (campos selecionados da oportunidade mudam, como valor ou responsável) e Stale Opportunities (oportunidade sem movimentação além de N dias configurados).
• Prioridade: Alta
• Atores: Gestor de automações, Vendedor
• H1: Dado uma oportunidade parada em um estágio, Quando ela ultrapassa o limite de dias sem atualização definido no gatilho Stale Opportunities, Então o workflow inscreve a oportunidade, E dispara ação de reengajamento sem reinscrever enquanto ela permanecer stale.

Gatilhos de pagamento e faturamento

RF-AUTO-012: Gatilhos de pagamento e faturamento

• Descrição: Bloco inteiro de gatilhos financeiros hoje ausente. Cobre: Invoice (created, sent, due, paid), Payment Received (pagamento capturado), Order Form Submission e Order Submitted (checkout submetido), Subscription (create, update, pause, resume, cancel), Refund (reembolso emitido), Estimates (orçamento sent, accepted, declined) e Documents & Contracts (documento sent, signed, declined).
• Prioridade: Alta
• Atores: Administrador, Financeiro, Gestor de automações
• H1: Dado que uma fatura foi enviada a um contato, Quando o pagamento é capturado com sucesso e dispara o gatilho Payment Received, Então o workflow inscreve o contato com valor, método e id da transação disponíveis como variáveis, E permite filtrar o gatilho por tipo de evento (paga, vencida, cancelada).
• Notas: Cada gatilho deve expor o subtipo de evento como filtro para não obrigar um workflow por evento.

RF-AUTO-013: Gatilhos de cupom

• Descrição: Gatilhos do ciclo de vida de cupons de desconto. Cobre: Coupon Code Applied (aplicado no checkout), Coupon Code Redeemed (resgatado), Coupon Redemption Limit Reached (limite de resgates atingido) e Coupon Code Expired (expirado).
• Prioridade: Média
• Atores: Administrador, Marketing
• H1: Dado um cupom com limite de resgates configurado, Quando o número de resgates atinge esse limite e dispara Coupon Redemption Limit Reached, Então o workflow é acionado, E notifica os responsáveis e pode encerrar a campanha vinculada.

Gatilhos de e-commerce

RF-AUTO-014: Gatilhos de loja e e-commerce

• Descrição: Gatilhos de eventos de loja. Cobre: Order Fulfilled (pedido da loja cumprido), Abandoned Checkout (sessão de checkout abandonada), Product Review Submitted (avaliação de produto) e, quando houver integração externa, os eventos Shopify (Order Placed, Order Fulfilled, Abandoned Cart) enquanto ainda suportados.
• Prioridade: Média
• Atores: Administrador, Marketing
• H1: Dado um contato que iniciou um checkout e não concluiu, Quando o gatilho Abandoned Checkout dispara após o tempo de inatividade, Então o workflow inscreve o contato, E envia sequência de recuperação com o link do carrinho preservado.

Gatilhos de marketing e captação

RF-AUTO-015: Gatilhos de formulários de lead externos

• Descrição: Captação vinda de plataformas de anúncio. Cobre: Facebook Lead Form Submitted, TikTok Form Submitted, LinkedIn Lead Form Submitted, Google Lead Form Submitted e Click To WhatsApp Ads (thread iniciada por anúncio de clique para WhatsApp).
• Prioridade: Alta
• Atores: Marketing, Gestor de automações
• H1: Dado uma campanha de lead ads no Facebook conectada, Quando um usuário submete o lead form e dispara Facebook Lead Form Submitted, Então o contato é criado ou atualizado no CRM e inscrito no workflow, E os campos do formulário são mapeados para os campos do contato.
• Notas: revisado em 2026-07-22 (council GO). A entrada do lead do Facebook usa o caminho canônico de captura (RF-CAPT-008, RF-CAPT-009 e RF-CAPT-010); este gatilho consome o contato já capturado por leadgen_id e o inscreve no workflow.

RF-AUTO-016: Gatilhos de eventos de email, SMS e chamada

• Descrição: Gatilhos de resultado de comunicação. Cobre: Email Events (delivered, opened, clicked, bounced, spam, unsubscribed), Messaging Error SMS (SMS de saída retorna erro específico), Number Validation (resultado da validação de telefone) e Call Details (log de chamada bate com detalhes ou desfechos selecionados). Amplia também Customer Replied para qualquer canal conectado.
• Prioridade: Alta
• Atores: Marketing, Atendimento, Gestor de automações
• H1: Dado um email de campanha enviado por um workflow, Quando o contato clica em um link e dispara Email Events com evento "clicked", Então o workflow ramifica para o passo de reengajamento, E distingue clique de simples abertura.

RF-AUTO-017: Gatilhos de engajamento web e conteúdo

• Descrição: Gatilhos de comportamento em páginas e conteúdo. Cobre: Funnel/Website PageView (visita a URLs ou UTMs específicas), Video Tracking (viewer atinge percentual escolhido do vídeo), Survey Submitted, Quiz Submitted, New Review Received (nova avaliação em Reputation) e Prospect Generated.
• Prioridade: Média
• Atores: Marketing, Gestor de automações
• H1: Dado um contato navegando em uma página de vendas monitorada, Quando ele assiste a 75 por cento do vídeo e dispara Video Tracking, Então o workflow inscreve o contato como lead quente, E registra o percentual atingido como variável.

Gatilhos de integração e customização

RF-AUTO-018: Gatilho de webhook de entrada (Inbound Webhook)

• Descrição: Uma URL de webhook por workflow que aceita payload de sistemas externos e inicia o fluxo. Deve permitir mapear campos do payload para variáveis do workflow e para campos do contato, com opção de identificar ou criar o contato a partir do payload.
• Prioridade: Alta
• Atores: Administrador, Gestor de automações, Integrador
• H1: Dado um sistema externo configurado para enviar dados, Quando ele faz POST na URL de Inbound Webhook do workflow, Então o workflow é acionado com o corpo recebido disponível como variáveis, E identifica ou cria o contato conforme o mapeamento definido.

RF-AUTO-019: Gatilhos customizados e de IA

• Descrição: Gatilhos abertos para eventos definidos pelo usuário ou por IA. Cobre: Custom Trigger (evento custom definido no CRM), Conversation AI Trigger (evento configurado do assistente de conversa) e External Tracking Event (evento de tracking client ou server-side capturado).
• Prioridade: Média
• Atores: Administrador, Gestor de automações
• H1: Dado um evento custom emitido por outro módulo do CRM, Quando esse evento ocorre e casa com o Custom Trigger configurado, Então o workflow correspondente é acionado, E recebe o payload do evento como contexto.

Gatilhos de voz e comentários sociais

RF-AUTO-020: Gatilhos de voz e IVR

• Descrição: Gatilhos ligados a telefonia. Cobre: Start IVR Trigger (chamador entra em uma opção configurada do IVR) e Transcript Generated (transcrição de chamada ou conversa criada).
• Prioridade: Média
• Atores: Atendimento, Gestor de automações
• H1: Dado uma chamada recebida que entra no menu de IVR, Quando o chamador escolhe a opção configurada e dispara Start IVR Trigger, Então o workflow correspondente àquela opção é acionado, E encaminha o atendimento conforme a árvore definida.

RF-AUTO-021: Gatilhos de comentários em redes sociais

• Descrição: Gatilhos disparados por comentários em posts sociais conectados. Cobre: Facebook comment(s) on a post, Instagram comment(s) on a post e TikTok comment(s) on a video.
• Prioridade: Média
• Atores: Marketing, Atendimento
• H1: Dado um post do Facebook conectado ao CRM, Quando um usuário comenta uma palavra-chave configurada e dispara o gatilho de comentário, Então o workflow inscreve o autor do comentário, E disponibiliza o texto do comentário para as ações de resposta.

Gatilhos de verticais

RF-AUTO-022: Gatilhos de cursos, memberships e certificados

• Descrição: Bloco vertical de educação e acesso a produtos. Cobre: Category Started, Category Completed, Lesson Started, Lesson Completed, Product Started, Product Completed, New Signup, Offer Access Granted, Offer Access Removed, Product Access Granted, Product Access Removed, User Login (portal de aprendizado) e Certificates Issued.
• Prioridade: Média
• Atores: Administrador, Gestor de automações
• H1: Dado um aluno inscrito em um curso, Quando ele conclui a última lição e dispara Lesson Completed da categoria final, Então o workflow emite o certificado e inscreve o aluno na sequência de próximos passos, E marca o progresso no perfil do contato.

RF-AUTO-023: Gatilhos de comunidades e afiliados

• Descrição: Bloco vertical de comunidades e programa de afiliados. Cobre comunidades: Group Access Granted, Group Access Revoked, Private Channel Access Granted, Private Channel Access Revoked e Community Group Member Leaderboard Level Changed. Cobre afiliados: Affiliate Created, New Affiliate Sales, Affiliate Enrolled In Campaign e Lead Created (atribuído a afiliado).
• Prioridade: Média
• Atores: Administrador, Gestor de automações
• H1: Dado um programa de afiliados ativo, Quando uma venda atribuída a um afiliado ocorre e dispara New Affiliate Sales, Então o workflow registra a comissão e notifica o afiliado, E mantém o vínculo da venda com o afiliado responsável.

Ações de gestão de contato

RF-AUTO-024: Ações de manipulação de registro de contato

• Descrição: Ações que criam, localizam ou removem contatos de dentro do fluxo. Cobre: Create Contact, Find Contact, Copy Contact (duplica para outra conta ou tenant), Delete Contact e Add ou Remove Contact Followers.
• Prioridade: Alta
• Atores: Gestor de automações, Administrador
• H1: Dado um payload recebido por Inbound Webhook, Quando a ação Find Contact não encontra correspondência, Então a ação Create Contact cria o registro com os campos mapeados, E o fluxo continua com o novo contato como alvo.

RF-AUTO-025: Ações de atribuição, conversa e DND

• Descrição: Ações internas sobre o contato. Cobre: Assign to User, Remove Assigned User, Edit Conversation (marcar como lida, arquivar, desarquivar), Add Note e Disable ou Enable DND.
• Prioridade: Alta
• Atores: Gestor de automações, Atendimento
• H1: Dado um lead recém-inscrito, Quando a ação Assign to User é executada com regra de rodízio, Então o contato é atribuído ao próximo vendedor disponível, E a atribuição aparece na ficha do contato e nas conversas.

Ações de canal de mensagem

RF-AUTO-026: Ações de canais de mensagem além de email e SMS

• Descrição: Envio por canais adicionais. Cobre: WhatsApp, Facebook Messenger, Instagram DM, GMB Messaging (Google Business), Send Live Chat Message e Send Slack Message.
• Prioridade: Alta
• Atores: Gestor de automações, Atendimento, Marketing
• H1: Dado um contato que respondeu por WhatsApp, Quando o workflow executa a ação WhatsApp, Então a mensagem é enviada pela conta conectada dentro da janela permitida pelo canal, E o envio fica registrado na thread da conversa.

RF-AUTO-027: Ações de voz, ação manual e notificação

• Descrição: Ações que envolvem intervenção de usuário ou voz. Cobre: Call (liga para o contato e conecta o usuário), Manual Action (Manual Call e Manual SMS que exigem execução de um usuário), Record Voicemail, Send Internal Notification (notifica usuários internos) e Send Review Request.
• Prioridade: Média
• Atores: Atendimento, Vendedor, Gestor de automações
• H1: Dado um lead de alto valor inscrito, Quando o workflow chega em uma ação Manual Call, Então uma tarefa de ligação é criada e atribuída ao usuário responsável, E o fluxo aguarda a conclusão manual antes de seguir.

RF-AUTO-028: Ações de resposta a comentários sociais

• Descrição: Ações que respondem publicamente ou por mensagem a comentários. Cobre: Facebook Interactive Messenger, Instagram Interactive Messenger e Reply in Comments (resposta pública em posts do Facebook e Instagram).
• Prioridade: Média
• Atores: Marketing, Atendimento
• H1: Dado um comentário que disparou o gatilho de comentário social, Quando o workflow executa Reply in Comments, Então uma resposta pública é publicada no comentário original, E opcionalmente inicia uma conversa privada pela ação de Interactive Messenger.

Ações de lógica de fluxo

RF-AUTO-029: Ações de fluxo avançado

• Descrição: Mecanismos de controle de fluxo além da condicional simples. Cobre: Goal Event (direciona quem atinge um objetivo para um ramo, pulando passos intermediários), Split (teste A/B com distribuição percentual aleatória), Go To ou Add to Workflow (envia o contato a outro workflow), Remove from Workflow (remove deste ou de outros workflows) e Drip Mode (libera contatos em lotes controlando a cadência).
• Prioridade: Alta
• Atores: Gestor de automações, Marketing
• H1: Dado um workflow de nutrição, Quando um contato realiza a compra que corresponde ao Goal Event configurado, Então ele salta os passos de nutrição restantes e segue direto para o ramo pós-venda, E deixa de receber as mensagens intermediárias.

RF-AUTO-030: Ações de lógica e transformação de dados

• Descrição: Ações que calculam e formatam valores dentro do fluxo. Cobre: Update Custom Value, Text Formatter (formatação e transformação de texto), Number Formatter (formatação numérica), Math Operation (cálculos sobre números e datas, útil para lead scoring e agendamento) e Array Functions (Find, Filter, Find by Index, Line Items e agregações Sum, Min, Max, Average, Count).
• Prioridade: Alta
• Atores: Gestor de automações, Integrador
• H1: Dado um contato com vários eventos de engajamento acumulados, Quando a ação Math Operation soma os pesos configurados, Então o resultado é gravado no campo de score do contato, E fica disponível para condicionais e segmentação posteriores.

RF-AUTO-031: Ações de webhook de saída, planilha e código

• Descrição: Ações de integração e extensibilidade. Cobre: Custom Webhook (envia dados do CRM para apps externos, com método, headers e corpo configuráveis), Google Sheets (atualiza ou consulta linhas) e Custom Code (executa JavaScript custom com acesso às variáveis do fluxo).
• Prioridade: Alta
• Atores: Integrador, Gestor de automações, Administrador
• H1: Dado um contato que atingiu uma etapa do fluxo, Quando a ação Custom Webhook é executada, Então o CRM faz a requisição HTTP configurada ao endpoint externo com o payload montado, E a resposta pode ser mapeada de volta para variáveis do fluxo.
• Notas: Custom Code e Array Functions são marcadas como premium no GHL; avaliar cota ou plano no ModularCRM.

Ações de IA no workflow

RF-AUTO-032: Ações de IA no workflow

• Descrição: Ações que usam IA dentro do fluxo. Cobre: AI Prompt (geração de resposta a partir de prompt com modelo tipo GPT), Conversation AI (gerencia conversa inbound com IA em SMS, Messenger, Instagram, WhatsApp e Live Chat), AI Agent (planeja e executa tarefas de forma autônoma com ferramentas, cobrando por execução), Custom Code AI (gera código com IA) e as ações de voz Eliza AI Appointment Booking e Send to Eliza Agent Platform.
• Prioridade: Alta
• Atores: Gestor de automações, Atendimento, Administrador
• H1: Dado um contato que enviou uma dúvida por WhatsApp, Quando o workflow entrega a conversa à ação Conversation AI, Então o assistente responde com base no contexto e nas instruções configuradas, E devolve o controle ao fluxo humano quando detecta intenção de compra ou pedido de atendente.
• Notas: As ações de IA devem registrar tokens ou execuções consumidos para controle de custo por tenant.

Ações de agendamento, oportunidade e pagamento

RF-AUTO-033: Ações de agendamento e oportunidade

• Descrição: Ações que alteram agendamentos e oportunidades a partir do fluxo. Cobre: Update Appointment Status (rescheduled, no-show, completed), Generate One Time Booking Link (link de agendamento de uso único) e Remove Opportunity (remove de um ou vários pipelines).
• Prioridade: Média
• Atores: Gestor de automações, Atendimento
• H1: Dado um contato que não compareceu ao agendamento, Quando o workflow executa Update Appointment Status para no-show, Então o status é atualizado no calendário, E o fluxo pode gerar um novo link de reagendamento de uso único para reenvio.

RF-AUTO-034: Ações de pagamento

• Descrição: Ações financeiras iniciadas pelo fluxo. Cobre: cobrança avulsa de valor único no gateway (equivalente ao Stripe One-Time Charge, adaptado ao Pix ou gateway do ModularCRM), Send Invoice (envia fatura criada no CRM) e Send Documents and Contracts (envia documento ou contrato a partir de template).
• Prioridade: Média
• Atores: Financeiro, Gestor de automações
• H1: Dado um contato que aceitou uma proposta, Quando o workflow executa Send Invoice, Então a fatura é gerada e enviada ao contato pelo canal configurado, E o fluxo aguarda o gatilho de pagamento para seguir.
• Notas: Respeitar a decisão de escopo de que V1 usa Pix manual, sem Stripe; a ação de cobrança deve mapear para o gateway suportado.

Ações de conversão server-side

RF-AUTO-035: Ações de conversão e públicos de anúncio

• Descrição: Ações de marketing server-side e gestão de públicos. Cobre: Facebook Conversion API (envio de conversão server-side ao Meta), Add to Google AdWords (conversão do Google Ads), Add to Google Analytics, Add to Custom Audience (Facebook) e Remove from Custom Audience (Facebook).
• Prioridade: Alta
• Atores: Marketing, Gestor de automações
• H1: Dado um contato que efetivou compra dentro do fluxo, Quando o workflow executa a ação Facebook Conversion API, Então o evento de conversão é enviado server-side ao Meta com os parâmetros de correspondência, E melhora a otimização da campanha sem depender apenas do pixel do navegador.

Ações de verticais

RF-AUTO-036: Ações de verticais (afiliados, cursos, comunidades, IVR)

• Descrição: Ações dos blocos verticais. Cobre afiliados: Add to Affiliate Manager, Update Affiliate, Add ou Remove from Affiliate Campaign. Cobre cursos: Course Grant Offer e Course Revoke Offer. Cobre comunidades: Grant Group Access e Revoke Group Access. Cobre IVR: Gather Input on Call, Play Message, Connect to Call, End Call e Record Voicemail.
• Prioridade: Média
• Atores: Administrador, Gestor de automações, Atendimento
• H1: Dado um aluno que concluiu o pagamento de um curso, Quando o workflow executa Course Grant Offer, Então o acesso à oferta é liberado para o contato, E o fluxo pode revogar o acesso automaticamente caso um reembolso seja registrado depois.

Tipos de espera avançados

RF-AUTO-037: Esperas por tempo, data e condição

• Descrição: Amplia a espera temporizada única para os demais tipos de espera do GHL. Cobre: A Specific Date and Time (até data e hora exata, fixa ou vinda de campo), A Recurring Schedule (próxima ocorrência de um padrão recorrente, como toda terça ou dia 15), An Upcoming Appointment or Booking (relativo a agendamento, booking ou vencimento de fatura, antes, no dia ou depois) e Specific Conditions to be Met (aguarda até um segmento custom com regras AND ou OR virar verdadeiro).
• Prioridade: Alta
• Atores: Gestor de automações
• H1: Dado um contato com agendamento futuro, Quando o workflow usa a espera An Upcoming Appointment com offset de 24 horas antes, Então o fluxo pausa e retoma exatamente 24 horas antes do horário marcado, E envia o lembrete no momento certo mesmo que a data seja diferente para cada contato.

RF-AUTO-038: Esperas por resposta e por ação

• Descrição: Esperas que retomam o fluxo com base em interação. Cobre: The Contact to Reply (aguarda o contato responder em um canal, com timeout), The Contact to Take an Action (aguarda engajamento, como clique em trigger link, abertura, clique ou bounce de email) e A User to Reply (aguarda um membro da equipe responder em um canal, com timeout para escalonamento).
• Prioridade: Alta
• Atores: Gestor de automações, Atendimento
• H1: Dado um lead que recebeu uma pergunta por mensagem, Quando o workflow usa a espera The Contact to Reply com timeout de 2 horas, Então o fluxo segue pelo ramo de resposta se o contato responder, E segue pelo ramo de timeout com follow-up automático caso o prazo expire.

Configurações de workflow

RF-AUTO-039: Configurações de execução e reinscrição

• Descrição: Configurações que governam como o contato entra e sai do workflow. Cobre: Allow Re-entry (permite reinscrição após concluir ou ser removido), Allow multiple Opportunities (entra como instância separada por oportunidade) e Stop on Response (encerra o workflow para o contato que responder a uma mensagem enviada por este workflow, por canal SMS, email ou call).
• Prioridade: Alta
• Atores: Gestor de automações, Administrador
• H1: Dado um contato que respondeu a um SMS de campanha, Quando a configuração Stop on Response está ativa, Então o workflow encerra para aquele contato e interrompe as mensagens seguintes, E não afeta os demais contatos ainda no fluxo.

RF-AUTO-040: Configurações de comunicação e janela de horário

• Descrição: Configurações que controlam remetente, fuso e janela de envio. Cobre: Timezone (fuso da conta ou do contato, com a conta como fallback), Time Window (restringe ações de comunicação a horas e dias definidos, Start Time, End Time e Include Days, afetando só comunicação e não ações internas), From Name, From Email, From Number e Conversations Mark as Read.
• Prioridade: Alta
• Atores: Gestor de automações, Administrador
• H1: Dado um workflow com Time Window das 8h às 18h em dias úteis, Quando uma ação de envio de SMS é alcançada às 22h, Então o envio é adiado para o próximo horário permitido dentro da janela, E as ações internas como aplicar tag continuam executando fora da janela.

Gestão e observabilidade do builder

RF-AUTO-041: Logs de execução e histórico de inscrição

• Descrição: Observabilidade do fluxo. Cobre: Execution Logs (registro por execução de cada passo), Enrollment History (histórico de inscrição de contatos no workflow) e o tratamento de re-entrada de contatos em passos de espera quando o workflow é movido para rascunho.
• Prioridade: Alta
• Atores: Gestor de automações, Administrador, Suporte
• H1: Dado um contato que passou por um workflow, Quando o gestor abre o Execution Log daquele contato, Então ele vê a sequência de passos executados com horário, resultado e ramo tomado em cada nó, E consegue diagnosticar por que uma mensagem não foi enviada.

RF-AUTO-042: Ferramentas de autoria e versionamento do builder

• Descrição: Recursos do construtor além do canvas e status já existentes. Cobre: Test Workflow (executa em modo teste com um contato selecionado), Version History (histórico de versões e alterações), Workflow Switcher (navegação rápida entre workflows), Draft e Publish toggle, Stats View por action (métricas de performance de comunicação por nó) e o assistente Workflow AI Builder e Workflow AI Assistant (recomendação e geração de fluxo por prompt).
• Prioridade: Média
• Atores: Gestor de automações, Administrador
• H1: Dado um workflow em rascunho, Quando o gestor usa Test Workflow com um contato de teste, Então o fluxo executa em modo teste percorrendo os nós sem afetar métricas de produção, E o gestor valida o comportamento antes de publicar.
• Notas: Version History deve permitir comparar e restaurar uma versão anterior; o AI Builder é premium e opcional.

11.6 Pagamentos, cobrança e contratos (RF-BILL)

Esta seção cobre os gaps do módulo Payments/Commerce do GoHighLevel frente ao que o ModularCRM já entrega na V1 (cobrança Pix manual, faturas com status, renovação automática com lembretes, painel de receita recorrente/MRR, produtos e valores, orçamentos e pedidos, links de pagamento). Onde um gap depende de gateway de cartão (descartado na V1 em favor do Pix manual), o RF traz a nota do ADR-004; os demais temas (Documentos e Contratos, Orçamentos, Cupons, Text2Pay, Produtos, Recibos) não dependem de cartão e entram com prioridade normal.

Faturas avançadas

RF-BILL-005: Planos de pagamento na fatura (parcelamento programado)

• Descrição: Permitir dividir o valor de uma fatura em um cronograma de parcelas programadas, com datas e valores definidos, e acompanhar o total pago versus o total devido.
• Prioridade: Alta
• Atores: Operador de cobrança, Cliente final
• H1: Dado que crio uma fatura de valor alto, Quando defino um plano de pagamento em N parcelas com datas, Então cada parcela vira um vencimento próprio com link de pagamento, E a fatura assume o status Parcialmente Paga até quitar todas as parcelas.
• Notas: Cada parcela gera cobrança Pix manual na V1.

RF-BILL-006: Cronograma de pagamentos parciais ajustável

• Descrição: Permitir configurar e reajustar um cronograma de pagamentos parciais sobre uma fatura em aberto, alterando datas ou valores enquanto ela não estiver quitada.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que uma fatura tem plano de pagamento ativo, Quando ajusto o cronograma de uma parcela ainda não paga, Então o novo valor e a nova data passam a valer, E as parcelas já pagas permanecem inalteradas.

RF-BILL-007: Depósito ou entrada na fatura

• Descrição: Permitir exigir um valor de entrada (depósito) como primeira parcela do plano de pagamento, cobrado antes do restante.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que crio uma fatura com plano de pagamento, Quando marco a primeira parcela como depósito de entrada, Então o cliente recebe primeiro a cobrança da entrada, E o saldo restante segue o cronograma configurado.

RF-BILL-008: Gorjeta no checkout da fatura

• Descrição: Permitir configurar a aceitação de gorjeta (tip) no checkout da fatura, com valores sugeridos ou valor livre informado pelo pagador.
• Prioridade: Média
• Atores: Cliente final, Operador de cobrança
• H1: Dado que o checkout da fatura tem gorjeta habilitada, Quando o cliente escolhe um percentual ou valor de gorjeta, Então esse valor é somado ao total a pagar, E a gorjeta aparece destacada na fatura e no recibo.

RF-BILL-009: Multa por atraso e taxa de processamento na fatura

• Descrição: Permitir configurar multa por atraso (late fee) e taxa de processamento (processing fee) aplicadas automaticamente à fatura conforme regra definida.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que uma fatura vence sem pagamento, Quando a regra de multa por atraso está ativa, Então o sistema acrescenta a multa ao valor devido, E o cliente vê o novo total com a multa discriminada.

RF-BILL-010: Anexos na fatura

• Descrição: Permitir anexar arquivos (contrato, comprovante, briefing) à fatura enviada ao cliente.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que estou montando uma fatura, Quando anexo um arquivo permitido, Então o cliente recebe a fatura com o anexo disponível para download, E o anexo fica registrado junto à fatura.

RF-BILL-011: Criar e enviar fatura pelo aplicativo mobile

• Descrição: Permitir criar, editar e enviar faturas a partir de um aplicativo mobile, com paridade das ações essenciais da versão web.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que estou no aplicativo mobile, Quando crio uma fatura com cliente, itens e valores, Então consigo enviá-la ao cliente pelo próprio app, E ela aparece na lista de faturas com o mesmo status da web.

RF-BILL-012: Envio de fatura por email e SMS

• Descrição: Permitir enviar a fatura tanto por email quanto por SMS, e reenviar pelo canal escolhido, garantindo entrega mesmo sem email válido.
• Prioridade: Alta
• Atores: Operador de cobrança, Cliente final
• H1: Dado que preciso cobrar um cliente sem email confiável, Quando escolho enviar a fatura por SMS, Então o cliente recebe o link de pagamento por mensagem, E o histórico da fatura registra o canal e o horário do envio.

RF-BILL-013: Clonar fatura ou orçamento anterior

• Descrição: Permitir criar uma nova fatura a partir de uma fatura ou orçamento anterior, reaproveitando cliente, itens e valores.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que já emiti uma fatura semelhante antes, Quando escolho clonar essa fatura, Então uma nova fatura em rascunho nasce com os mesmos dados, E posso ajustá-la antes de enviar sem afetar a original.

RF-BILL-014: Envio antecipado da fatura recorrente (send in advance)

• Descrição: Permitir configurar o disparo da fatura recorrente alguns dias antes do vencimento, dando prazo de pagamento ao cliente.
• Prioridade: Alta
• Atores: Operador de cobrança, Cliente final
• H1: Dado que tenho uma fatura recorrente mensal, Quando defino envio antecipado de 5 dias, Então a fatura é gerada e enviada 5 dias antes do vencimento, E o cliente tem esse prazo para pagar antes de ficar em atraso.

RF-BILL-015: Data de início e condição de término da recorrência

• Descrição: Permitir definir a data do primeiro envio da fatura recorrente e a condição de término (data final ou número de ocorrências).
• Prioridade: Alta
• Atores: Operador de cobrança
• H1: Dado que configuro um template de fatura recorrente, Quando defino a data de início e limito a 12 ocorrências, Então o primeiro envio ocorre na data escolhida, E após a 12ª fatura o template é concluído automaticamente.

RF-BILL-016: Ciclo de vida do template recorrente e ações

• Descrição: Manter o template de fatura recorrente com estados (Rascunho, Ativo, Agendado, Cancelado, Concluído), bloquear edição de template ativo e oferecer ações de ver histórico, encerrar, clonar e converter em template.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que um template recorrente está Ativo, Quando tento editá-lo diretamente, Então o sistema exige cancelar antes de alterar, E consigo consultar o histórico de todas as faturas já geradas por ele.

RF-BILL-017: Enviar fatura recorrente via automação

• Descrição: Disponibilizar uma ação de automação que dispara o envio de uma fatura recorrente dentro de um fluxo (workflow), sem envio manual.
• Prioridade: Alta
• Atores: Operador de cobrança, Sistema de automação
• H1: Dado que um cliente entra em um fluxo de onboarding, Quando o fluxo chega na ação de enviar fatura recorrente, Então a fatura é gerada e enviada automaticamente, E o histórico do contato registra o envio.

RF-BILL-018: Cadências de lembrete e templates de notificação de cobrança

• Descrição: Permitir múltiplas cadências de lembrete antes e depois do vencimento e customizar os templates de email e SMS de cobrança (assunto, corpo, variáveis).
• Prioridade: Alta
• Atores: Operador de cobrança, Cliente final
• H1: Dado que configuro lembretes de uma fatura, Quando defino um aviso 3 dias antes e dois avisos após o vencimento, Então cada lembrete sai no momento certo pelo template customizado, E o cliente recebe as mensagens com os dados corretos da fatura.

Orçamentos avançados

RF-BILL-019: Aceite ou recusa do orçamento pelo cliente no próprio link

• Descrição: Permitir que o cliente aceite ou recuse o orçamento diretamente no link recebido, com opção de adicionar notas ao recusar.
• Prioridade: Alta
• Atores: Cliente final, Operador de vendas
• H1: Dado que o cliente abre o link do orçamento, Quando ele clica em aceitar ou recusar, Então o status do orçamento é atualizado automaticamente, E ao recusar ele pode registrar o motivo em uma nota.

RF-BILL-020: Converter orçamento aprovado em fatura

• Descrição: Permitir converter um orçamento aceito em fatura com um clique, reaproveitando cliente, itens e valores.
• Prioridade: Alta
• Atores: Operador de vendas, Operador de cobrança
• H1: Dado que um orçamento foi aceito, Quando escolho converter em fatura, Então nasce uma fatura com os mesmos itens e valores, E o orçamento passa ao status Faturado vinculado à fatura gerada.

RF-BILL-021: Templates de orçamento reutilizáveis

• Descrição: Permitir salvar orçamentos como templates reutilizáveis para acelerar a criação de novos orçamentos padronizados.
• Prioridade: Média
• Atores: Operador de vendas
• H1: Dado que emito orçamentos parecidos com frequência, Quando salvo um orçamento como template, Então posso criar um novo orçamento a partir dele, E só ajusto o cliente e os detalhes específicos.

RF-BILL-022: Enviar orçamento via automação

• Descrição: Disponibilizar uma ação de automação que envia um orçamento a partir de um template dentro de um fluxo.
• Prioridade: Média
• Atores: Operador de vendas, Sistema de automação
• H1: Dado que um lead qualificado entra em um fluxo, Quando o fluxo chega na ação de enviar orçamento, Então o orçamento é gerado do template e enviado ao contato, E o envio fica registrado no histórico.

RF-BILL-023: Card de dashboard com valor de orçamentos no pipeline

• Descrição: Exibir no dashboard o valor total de orçamentos em aberto no pipeline, apoiando a previsão de receita.
• Prioridade: Média
• Atores: Gestor comercial
• H1: Dado que existem orçamentos enviados e não decididos, Quando abro o dashboard de pagamentos, Então vejo o valor somado dos orçamentos em aberto, E o número reflete apenas os orçamentos ainda no pipeline.

RF-BILL-024: Vincular orçamentos e faturas a oportunidades do CRM

• Descrição: Permitir vincular automaticamente orçamentos e faturas à oportunidade correspondente no CRM, via automação ou ação manual.
• Prioridade: Média
• Atores: Operador de vendas, Sistema de automação
• H1: Dado que uma oportunidade avança no funil, Quando gero um orçamento vinculado a ela, Então o orçamento aparece na oportunidade no CRM, E a mudança de status do orçamento fica visível na oportunidade.

RF-BILL-025: Múltiplos destinatários em orçamentos e propostas

• Descrição: Permitir enviar um orçamento ou proposta a mais de um destinatário do mesmo cliente.
• Prioridade: Média
• Atores: Operador de vendas, Cliente final
• H1: Dado que o cliente tem mais de um decisor, Quando adiciono vários destinatários ao orçamento, Então todos recebem o link, E o aceite ou recusa fica registrado com identificação de quem respondeu.

RF-BILL-026: Expiração e ciclo de vida do orçamento

• Descrição: Manter data de expiração no orçamento e os estados (Rascunho, Enviado, Aceito, Recusado, Faturado), refletindo o andamento no funil.
• Prioridade: Média
• Atores: Operador de vendas
• H1: Dado que um orçamento tem data de expiração, Quando essa data passa sem decisão, Então o orçamento é marcado como expirado, E deixa de contar como aberto no pipeline.

Documentos e Contratos com assinatura eletrônica

RF-BILL-027: Criação de documento a partir de branco, upload de PDF ou template

• Descrição: Permitir criar documentos em editor próprio, por upload de PDF existente com sobreposição de campos, ou a partir de template, incluindo elementos ricos (texto, imagens, vídeos, tabelas, lista de produtos com preço, quebras de página, colunas).
• Prioridade: Alta
• Atores: Operador de contratos, Cliente final
• H1: Dado que preciso enviar um contrato, Quando faço upload de um PDF e posiciono os campos por cima, Então o documento fica pronto para envio com os campos editáveis, E consigo incluir uma lista de produtos com preços no corpo.

RF-BILL-028: Assinatura eletrônica legalmente vinculante

• Descrição: Permitir coleta de assinatura eletrônica juridicamente válida no documento, por desenho (draw) ou digitação (type) do signatário.
• Prioridade: Alta
• Atores: Cliente final, Operador de contratos
• H1: Dado que recebo um contrato para assinar, Quando desenho ou digito minha assinatura, Então o documento registra a assinatura de forma vinculante, E o status do documento avança para assinado.

RF-BILL-029: Certificado de auditoria e trilha de atividade

• Descrição: Gerar certificado de auditoria com dados do signatário, IP, email e carimbo de data e hora, além de trilha completa de atividade do documento (visualização, assinatura).
• Prioridade: Alta
• Atores: Operador de contratos, Auditor
• H1: Dado que um documento foi assinado, Quando consulto o certificado de auditoria, Então vejo IP, email e horário de cada assinatura, E o histórico mostra quando cada parte visualizou e assinou.

RF-BILL-030: Campos preenchíveis no documento

• Descrição: Oferecer campos preenchíveis de assinatura, texto, data, iniciais e caixa de seleção, posicionáveis no documento.
• Prioridade: Alta
• Atores: Operador de contratos, Cliente final
• H1: Dado que monto um documento para assinatura, Quando adiciono campos de assinatura, data e caixa de seleção, Então o signatário só consegue concluir preenchendo os campos obrigatórios, E os valores informados ficam gravados no documento final.

RF-BILL-031: Múltiplos signatários com ordem de assinatura

• Descrição: Permitir vários signatários com ordem definida (sequencial ou simultânea), campos atribuídos a cada um e acompanhamento de quem já concluiu.
• Prioridade: Alta
• Atores: Operador de contratos, Cliente final
• H1: Dado que um contrato exige duas assinaturas em ordem, Quando defino a sequência de assinatura, Então o segundo signatário só recebe após o primeiro assinar, E acompanho no painel quem já concluiu e quem falta.

RF-BILL-032: Pagamento embutido no contrato

• Descrição: Permitir cobrança única ou recorrente embutida no documento, cobrada no ato da assinatura, incluindo adicionar produtos recorrentes à lista do contrato.
• Prioridade: Alta
• Atores: Cliente final, Operador de contratos
• H1: Dado que o contrato tem um valor a cobrar, Quando o cliente assina, Então o pagamento é solicitado no mesmo fluxo sem fatura separada, E o contrato assinado registra a cobrança vinculada.
• Notas: A cobrança recorrente automática por cartão depende de gateway de cartão, hoje fora do escopo V1 (ADR-004); na V1 a cobrança embutida usa Pix manual.

RF-BILL-033: Geração automática de fatura a partir de documento assinado

• Descrição: Gerar fatura automaticamente quando um documento é assinado, inclusive via automação disparada pela assinatura.
• Prioridade: Alta
• Atores: Operador de contratos, Sistema de automação
• H1: Dado que um contrato com valor foi assinado, Quando a assinatura é concluída, Então uma fatura é gerada automaticamente para o cliente, E o envio da fatura pode ser encadeado por automação.

RF-BILL-034: Templates, biblioteca de conteúdo e campos dinâmicos

• Descrição: Permitir templates reutilizáveis, converter documentos prontos em template, biblioteca de blocos e páginas, e placeholders dinâmicos (data de criação, número de referência, nome da conta, campos personalizados e valores de oportunidade).
• Prioridade: Alta
• Atores: Operador de contratos
• H1: Dado que uso o mesmo contrato para vários clientes, Quando crio um template com campos dinâmicos, Então cada envio preenche os dados do cliente e da oportunidade automaticamente, E editar o template não altera documentos já enviados.

RF-BILL-035: Gatilhos e lembretes de documento em automação

• Descrição: Disponibilizar gatilhos de automação para documento criado, enviado, visto e assinado, com filtro por status e nome do template, além de lembretes automáticos para documentos não assinados.
• Prioridade: Alta
• Atores: Operador de contratos, Sistema de automação
• H1: Dado que um documento foi enviado e não assinado, Quando o prazo de lembrete é atingido, Então o sistema dispara automaticamente um lembrete ao signatário, E ao ser assinado um gatilho pode iniciar o próximo passo do fluxo.

RF-BILL-036: Gestão, status e entrega de documentos

• Descrição: Manter estados do documento (Rascunho, Aguardando outros, Concluído, Pagamentos, Arquivado, Expirado), ações rápidas (visualizar, clonar, marcar como concluído, baixar PDF, converter em template, compartilhar por link, mover para rascunho, marcar como recusado), colunas de listagem, override de email de envio, redirecionamento pós-assinatura, anexos e data de expiração.
• Prioridade: Alta
• Atores: Operador de contratos
• H1: Dado que gerencio vários documentos, Quando abro a lista de documentos, Então vejo título, status, cliente, valor e data de modificação, E consigo baixar o PDF ou clonar qualquer documento pela ação rápida.

RF-BILL-037: Orçamento ou proposta com itens opcionais selecionáveis

• Descrição: Permitir enviar propostas com itens opcionais em formato de checklist, deixando o signatário escolher o que incluir antes de aceitar.
• Prioridade: Média
• Atores: Cliente final, Operador de vendas
• H1: Dado que envio uma proposta com itens opcionais, Quando o cliente marca os itens que deseja, Então o valor total é recalculado conforme a seleção, E a proposta aceita reflete apenas os itens escolhidos.

RF-BILL-038: Documentos na ficha do contato, mobile e segurança

• Descrição: Disponibilizar a gestão de documentos dentro da ficha do contato, uso pelo aplicativo mobile e segurança (SSL nos documentos e dados de pagamento, sem armazenar dados de cartão).
• Prioridade: Média
• Atores: Operador de contratos, Cliente final
• H1: Dado que abro a ficha de um contato, Quando acesso a aba de documentos, Então vejo todos os documentos ligados a ele, E consigo enviar ou acompanhar assinaturas também pelo app mobile.

RF-BILL-039: Propostas como documento rico distinto do orçamento

• Descrição: Suportar propostas como documento customizado e rico para fechar contrato ou projeto, distinto do orçamento simples de estimativa de custo.
• Prioridade: Média
• Atores: Operador de vendas, Cliente final
• H1: Dado que preciso apresentar uma proposta elaborada, Quando monto o documento com seções, textos e produtos, Então o cliente recebe uma proposta rica para decisão, E ela se diferencia do orçamento simples de valores.

Text2Pay (cobrança por SMS na conversa)

RF-BILL-040: Solicitar pagamento dentro da conversa

• Descrição: Permitir, dentro da conversa por mensagem, solicitar pagamento selecionando um produto, ajustando o preço e definindo o vencimento, gerando um link de cobrança enviado ao contato.
• Prioridade: Alta
• Atores: Atendente, Cliente final
• H1: Dado que estou conversando com um cliente por mensagem, Quando aciono solicitar pagamento, escolho o produto e defino o vencimento, Então um link de cobrança é enviado na conversa, E o pagamento fica registrado quando o cliente quita.
• Notas: Requer um número de telefone configurado e ao menos um produto ativo; na V1 o link usa checkout Pix manual.

RF-BILL-041: Checkout brandado e ajustes no envio Text2Pay

• Descrição: Gerar página de checkout com a marca (cores e logo), aplicar desconto e imposto no momento do envio, exibir data de vencimento e suportar modo teste e produção.
• Prioridade: Média
• Atores: Atendente, Cliente final
• H1: Dado que envio uma cobrança por conversa, Quando aplico desconto e imposto antes de enviar, Então o cliente abre um checkout com a marca e o valor final correto, E o vencimento aparece no link.

Assinaturas e recuperação de pagamento (dunning)

RF-BILL-042: Página de assinaturas ativas

• Descrição: Listar todas as assinaturas com produto, cliente, status e próximo ciclo de cobrança, permitindo consulta e gestão central.
• Prioridade: Alta
• Atores: Operador de cobrança, Gestor
• H1: Dado que existem várias assinaturas ativas, Quando abro a página de assinaturas, Então vejo cada uma com produto, cliente, status e data do próximo ciclo, E posso filtrar pelas que precisam de atenção.

RF-BILL-043: Pausar e retomar assinatura

• Descrição: Permitir pausar uma assinatura e retomá-la depois, sem cancelar nem perder o histórico.
• Prioridade: Alta
• Atores: Operador de cobrança, Cliente final
• H1: Dado que um cliente pede uma pausa, Quando pauso a assinatura, Então as próximas cobranças ficam suspensas, E ao retomar o ciclo de cobrança volta a partir da data escolhida.

RF-BILL-044: Modificar assinatura existente

• Descrição: Permitir alterar uma assinatura ativa (valor, produto, frequência) sem precisar recriá-la.
• Prioridade: Alta
• Atores: Operador de cobrança
• H1: Dado que preciso mudar o plano de um cliente, Quando altero o produto ou o valor da assinatura, Então a mudança passa a valer no próximo ciclo, E o histórico registra a alteração.

RF-BILL-045: Cancelar assinatura por ação e por gatilho

• Descrição: Permitir cancelar uma assinatura tanto pela página quanto por gatilho de automação.
• Prioridade: Alta
• Atores: Operador de cobrança, Sistema de automação
• H1: Dado que uma assinatura precisa ser encerrada, Quando cancelo pela página ou por automação, Então as cobranças futuras cessam, E o status passa a cancelada com data registrada.

RF-BILL-046: Gestão da assinatura pelo portal do cliente

• Descrição: Permitir que o cliente gerencie a própria assinatura em um portal (consultar, atualizar dados, pausar ou cancelar conforme regra).
• Prioridade: Média
• Atores: Cliente final
• H1: Dado que sou cliente com assinatura ativa, Quando acesso o portal do cliente, Então vejo minha assinatura e o próximo ciclo, E consigo executar as ações permitidas sem acionar o suporte.

RF-BILL-047: Gatilho de assinatura e reembolso para automações

• Descrição: Disponibilizar gatilhos de eventos de assinatura e reembolso para uso em fluxos de automação.
• Prioridade: Média
• Atores: Sistema de automação, Operador de cobrança
• H1: Dado que uma assinatura é cancelada ou um reembolso ocorre, Quando o evento acontece, Então o fluxo de automação vinculado é disparado, E as ações configuradas (notificação, tag, tarefa) são executadas.

RF-BILL-048: Venda de produto por assinatura em loja, memberships e cursos

• Descrição: Permitir vender produtos por assinatura nas superfícies de venda (loja, áreas de membros, cursos), criando a recorrência a partir da compra.
• Prioridade: Média
• Atores: Cliente final, Operador de cobrança
• H1: Dado que ofereço um curso por assinatura, Quando o cliente compra, Então uma assinatura recorrente é criada automaticamente, E o acesso é liberado enquanto a assinatura estiver ativa.

RF-BILL-049: Geração de fatura em falha de pagamento

• Descrição: Ao falhar uma cobrança recorrente, gerar e enviar automaticamente uma fatura ao cliente com link de pagamento para regularização.
• Prioridade: Alta
• Atores: Operador de cobrança, Cliente final
• H1: Dado que uma cobrança de assinatura falha, Quando o sistema detecta a falha, Então gera e envia uma fatura de regularização ao cliente, E a assinatura fica marcada como pendente até o pagamento.

RF-BILL-050: Tentativas automáticas de recobrança configuráveis

• Descrição: Permitir configurar o número de tentativas de recobrança (por exemplo 1 a 3) e o intervalo entre elas (por exemplo 1, 3, 5 ou 7 dias), aplicando a assinaturas novas e existentes.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que uma cobrança recorrente falhou, Quando o sistema executa a política de tentativas configurada, Então repete a cobrança no intervalo definido até o limite de tentativas, E a mudança de política vale também para assinaturas já em tentativa.
• Notas: A recobrança automática por cartão depende de gateway de cartão, hoje fora do escopo V1 (ADR-004); na V1 a regularização se dá pela fatura Pix do RF-BILL-049.

RF-BILL-051: Resolução da falha e cancelamento automático

• Descrição: Executar as tentativas em paralelo com a opção de o cliente pagar a fatura, parar as tentativas se o pagamento ocorrer, reativar a assinatura em caso de sucesso e cancelá-la automaticamente após esgotar as tentativas, conforme configuração.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que uma assinatura está em tentativas de recobrança, Quando o cliente paga a fatura antes do fim das tentativas, Então as tentativas param e a assinatura volta a ativa, E se todas as tentativas falharem a assinatura é cancelada conforme a regra.
• Notas: Recobrança automática depende de gateway de cartão, hoje fora do escopo V1 (ADR-004).

RF-BILL-052: Notificações de falha de pagamento ao cliente

• Descrição: Notificar o cliente sobre a falha de pagamento e a fatura gerada, com mensagens claras de regularização.
• Prioridade: Alta
• Atores: Cliente final, Operador de cobrança
• H1: Dado que uma cobrança de assinatura falhou, Quando a fatura de regularização é gerada, Então o cliente recebe uma notificação sobre a falha e como regularizar, E o histórico registra o envio da notificação.

Cupons

RF-BILL-053: Cupom percentual ou de valor fixo

• Descrição: Permitir criar cupons de desconto percentual ou de valor fixo aplicáveis à cobrança.
• Prioridade: Alta
• Atores: Operador de marketing, Cliente final
• H1: Dado que crio uma campanha promocional, Quando cadastro um cupom percentual ou de valor fixo, Então o cliente que aplica o código recebe o desconto correspondente, E o total a pagar reflete o abatimento.

RF-BILL-054: Aplicabilidade do cupom por superfície de venda

• Descrição: Permitir definir em quais superfícies o cupom vale (links de pagamento, formulários de pedido, loja, calendário e serviços, entre outras) e restringir onde não se aplica.
• Prioridade: Alta
• Atores: Operador de marketing
• H1: Dado que crio um cupom para um canal específico, Quando defino que ele vale só em links de pagamento, Então o desconto é aceito nesses links, E é recusado nas superfícies não habilitadas.

RF-BILL-055: Restrições de uso do cupom

• Descrição: Permitir limitar o total de resgates, restringir por produto, preço ou variante, e limitar a um uso por cliente.
• Prioridade: Alta
• Atores: Operador de marketing, Cliente final
• H1: Dado que um cupom tem limite de resgates e um uso por cliente, Quando um cliente que já usou tenta aplicá-lo de novo, Então o sistema recusa o segundo uso, E ao atingir o total de resgates o cupom deixa de ser aceito.

RF-BILL-056: Validade temporal do cupom

• Descrição: Permitir definir data e hora de início e fim do cupom, ou deixá-lo ativo indefinidamente.
• Prioridade: Média
• Atores: Operador de marketing
• H1: Dado que crio um cupom com janela de validade, Quando o cliente tenta usá-lo fora do período, Então o cupom é recusado, E dentro do período ele é aceito normalmente.

RF-BILL-057: Cupom em assinaturas

• Descrição: Permitir aplicar cupom em produtos por assinatura com regra de duração (apenas primeira cobrança, para sempre, ou por N ciclos), sem incidir sobre taxa de setup e distribuindo o desconto proporcionalmente entre produtos.
• Prioridade: Média
• Atores: Operador de marketing, Cliente final
• H1: Dado que aplico um cupom em uma assinatura por 3 ciclos, Quando o cliente assina, Então o desconto vale nas três primeiras cobranças, E a partir da quarta a cobrança volta ao valor cheio.

RF-BILL-058: Códigos de cupom e gatilho de aplicação

• Descrição: Suportar códigos alfanuméricos únicos e insensíveis a maiúsculas, permitir zerar o carrinho quando o desconto cobre o total e oferecer gatilho de automação quando um cupom é aplicado.
• Prioridade: Média
• Atores: Operador de marketing, Sistema de automação
• H1: Dado que um cliente aplica um código de cupom válido, Quando o desconto é aceito, Então o gatilho de cupom aplicado dispara o fluxo configurado, E o código é reconhecido independente de maiúsculas ou minúsculas.

Cartões-presente (gift cards)

RF-BILL-059: Criar produtos de cartão-presente brandados

• Descrição: Permitir criar produtos de cartão-presente com arte da marca, denominações, expiração e termos.
• Prioridade: Média
• Atores: Operador de marketing, Cliente final
• H1: Dado que quero oferecer vale-presente, Quando crio um produto de cartão-presente com denominações e validade, Então ele fica disponível para venda com a arte da marca, E os termos definidos aparecem para o comprador.

RF-BILL-060: Vender cartão-presente por link, embed e QR

• Descrição: Permitir vender o cartão-presente por link de checkout dedicado, código de incorporação em site e QR Code.
• Prioridade: Média
• Atores: Cliente final, Operador de marketing
• H1: Dado que publiquei um cartão-presente à venda, Quando compartilho o link, o embed ou o QR Code, Então o cliente consegue comprar por qualquer um deles, E a compra gera um cartão com saldo registrado.

RF-BILL-061: Enviar cartão-presente a um contato sem compra

• Descrição: Permitir emitir e enviar um cartão-presente diretamente a um contato sem compra, com valor customizado e entrega por email, SMS ou PDF, registrando no contato.
• Prioridade: Média
• Atores: Operador de relacionamento, Cliente final
• H1: Dado que quero presentear um cliente, Quando emito um cartão-presente de valor custom para o contato, Então ele recebe o cartão pelo canal escolhido, E o cartão fica registrado na ficha do contato.

RF-BILL-062: Página de pedidos de cartões-presente

• Descrição: Manter uma página que rastreia cada cartão-presente emitido, com saldo e status.
• Prioridade: Média
• Atores: Operador de cobrança, Gestor
• H1: Dado que vários cartões-presente foram emitidos, Quando abro a página de pedidos de cartão-presente, Então vejo cada cartão com valor, saldo e status, E consigo acompanhar o uso ao longo do tempo.

Produtos avançados

RF-BILL-063: Taxa de setup no produto

• Descrição: Permitir configurar uma taxa única de entrada (setup fee) cobrada apenas na primeira compra, além do valor recorrente.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que um produto recorrente tem taxa de setup, Quando o cliente contrata pela primeira vez, Então a taxa de setup é somada à primeira cobrança, E as cobranças seguintes trazem apenas o valor da recorrência.

RF-BILL-064: Período de trial no produto recorrente

• Descrição: Permitir configurar um período de teste em dias antes de iniciar a cobrança da recorrência.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que um produto tem trial de 7 dias, Quando o cliente assina, Então a primeira cobrança só ocorre após o período de trial, E durante o trial o acesso já é liberado.

RF-BILL-065: Número de cobranças da recorrência

• Descrição: Permitir limitar o número de cobranças de um produto recorrente, encerrando a assinatura automaticamente ao atingir o total.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que um produto recorrente é limitado a 12 cobranças, Quando a 12ª cobrança é concluída, Então a assinatura é encerrada automaticamente, E nenhuma cobrança adicional é gerada.

RF-BILL-066: Preço de comparação (de/por) no produto

• Descrição: Permitir informar um preço de comparação (compare-at) para exibir o valor cheio riscado ao lado do preço promocional.
• Prioridade: Média
• Atores: Operador de marketing, Cliente final
• H1: Dado que um produto está em promoção, Quando defino o preço de comparação e o preço de venda, Então o cliente vê o valor cheio riscado e o preço promocional, E a cobrança usa o preço de venda.

RF-BILL-067: Rótulo e coleção de produtos

• Descrição: Permitir marcar produtos com rótulos (por exemplo Novo, Mais vendido) e agrupá-los em coleções.
• Prioridade: Média
• Atores: Operador de marketing
• H1: Dado que quero destacar produtos, Quando aplico um rótulo e agrupo em uma coleção, Então os produtos aparecem com o selo na vitrine, E ficam agrupados pela coleção definida.

RF-BILL-068: Variantes de produto

• Descrição: Permitir variantes de produto (por exemplo Básico, Premium, Pro) com preço, preço de comparação e estoque por variante.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que um produto tem variantes, Quando o cliente escolhe uma variante, Então o preço e o estoque daquela variante são aplicados, E a cobrança usa o valor da variante selecionada.

RF-BILL-069: Controle de estoque do produto

• Descrição: Permitir ativar o controle de estoque por produto ou variante, com quantidade disponível e monitoramento.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que um produto tem controle de estoque ativo, Quando o estoque chega a zero, Então o produto deixa de aceitar novas vendas, E o monitoramento reflete a quantidade disponível.

RF-BILL-070: Produto físico versus digital

• Descrição: Distinguir produtos físicos (que coletam frete no checkout) de digitais (que pulam frete e exigem upload de arquivo para download pelo comprador).
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que cadastro um produto digital, Quando faço o upload do arquivo entregável, Então o checkout não pede endereço de entrega, E o cliente recebe o arquivo para download após pagar.

RF-BILL-071: SEO e mídia do produto

• Descrição: Permitir configurar título e descrição de SEO, slug de URL, e mídia rica (imagem ou vídeo) do produto.
• Prioridade: Média
• Atores: Operador de marketing
• H1: Dado que publico um produto na vitrine, Quando preencho título de SEO, descrição e slug, Então a página do produto usa esses metadados, E a mídia cadastrada é exibida na página.

RF-BILL-072: Código de imposto e descritor de fatura do produto

• Descrição: Permitir associar código de imposto ao produto, definir inclusão ou exclusão de imposto e um descritor que aparece na fatura do banco do cliente.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que um produto tem código de imposto e descritor definidos, Quando o cliente paga, Então o imposto é aplicado conforme a regra, E o descritor configurado aparece na fatura do meio de pagamento.
• Notas: O descritor na fatura do banco depende de gateway de cartão, hoje fora do escopo V1 (ADR-004).

Impostos

RF-BILL-073: Cadastro de impostos

• Descrição: Permitir cadastrar impostos com nome, percentual, descrição, identificação fiscal e órgão, com precisão de até quatro casas decimais no percentual.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que preciso aplicar um imposto, Quando cadastro nome, percentual e identificação fiscal, Então o imposto fica disponível para uso em faturas e produtos, E o valor calculado respeita a precisão configurada.

RF-BILL-074: Imposto inclusivo versus exclusivo

• Descrição: Permitir configurar se o imposto está embutido no preço (inclusivo) ou é somado por cima (exclusivo).
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que um produto usa imposto exclusivo, Quando o cliente vai pagar, Então o imposto é somado ao preço base, E em modo inclusivo o preço exibido já contém o imposto.

RF-BILL-075: Aplicação de imposto em faturas e isenção

• Descrição: Permitir adicionar imposto manualmente em faturas, aplicar automaticamente em produtos e checkout, marcar itens isentos com 0% e registrar refund de imposto de forma manual.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que monto uma fatura tributável, Quando adiciono o imposto manualmente, Então o total da fatura reflete o imposto, E itens marcados como isentos não recebem imposto.
• Notas: O cálculo dinâmico de imposto por gateway externo e a nota fiscal automática são V2 (relacionado a NF V2).

Reembolsos

RF-BILL-076: Reembolso total ou parcial na transação

• Descrição: Permitir emitir reembolso total ou parcial a partir da transação, com múltiplos reembolsos parciais somando no máximo o valor original e histórico de tentativas.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que uma transação precisa de estorno, Quando emito um reembolso parcial, Então o valor devolvido é registrado na transação, E novos reembolsos parciais só são aceitos até completar o valor original.
• Notas: O estorno automático no meio de pagamento depende de gateway de cartão, hoje fora do escopo V1 (ADR-004); no Pix o reembolso é manual.

Cartões salvos e cobrança automática

RF-BILL-077: Cartão salvo e cobrança automática (autopay)

• Descrição: Permitir salvar o cartão do cliente na ficha, exibir apenas os últimos dígitos e validade, reusar em transações, faturas e assinaturas, e cobrar automaticamente faturas e recorrências.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que um cliente autoriza cobrança automática, Quando uma fatura recorrente vence, Então o sistema cobra usando o cartão salvo, E o cliente vê apenas os últimos dígitos do cartão na ficha.
• Notas: Depende de gateway de cartão, hoje fora do escopo V1 (ADR-004); nenhum dado completo de cartão é armazenado no sistema.

Links de pagamento avançados

RF-BILL-078: Quantidades editáveis no link de pagamento

• Descrição: Permitir que itens de compra única no link tenham quantidade editável pelo cliente, com mínimo e máximo definidos.
• Prioridade: Média
• Atores: Cliente final, Operador de cobrança
• H1: Dado que um link permite quantidade editável, Quando o cliente aumenta a quantidade dentro do limite, Então o total é recalculado, E a compra é bloqueada fora do mínimo e máximo configurados.

RF-BILL-079: Cupom e expiração no link de pagamento

• Descrição: Permitir aplicar cupom aos produtos elegíveis no link e configurar expiração automática do link.
• Prioridade: Alta
• Atores: Cliente final, Operador de cobrança
• H1: Dado que um link tem cupom e data de expiração, Quando o cliente aplica um cupom válido antes de expirar, Então o desconto é aplicado ao total, E após a expiração o link deixa de aceitar pagamentos.

RF-BILL-080: Link personalizado e opções de checkout

• Descrição: Permitir gerar link genérico ou personalizado com dados do cliente pré-preenchidos, além de configurar CTA custom, coleta de telefone e endereço, e redirecionamento pós-compra.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que quero cobrar um cliente específico, Quando gero um link personalizado com os dados dele pré-preenchidos, Então o cliente abre o checkout já preenchido, E após pagar é redirecionado para a URL configurada.

RF-BILL-081: Exportar pedidos do link em CSV

• Descrição: Permitir exportar os pedidos gerados por um link de pagamento em arquivo CSV.
• Prioridade: Média
• Atores: Operador de cobrança, Gestor
• H1: Dado que um link acumulou vários pedidos, Quando exporto os pedidos em CSV, Então recebo um arquivo com os dados das compras, E consigo usá-lo em análises externas.

Pedidos, transações e exportação

RF-BILL-082: Exportar pedidos, transações e assinaturas em CSV

• Descrição: Permitir exportar listas de pedidos, transações e assinaturas em formato CSV.
• Prioridade: Alta
• Atores: Operador de cobrança, Gestor
• H1: Dado que preciso de um relatório de cobrança, Quando exporto pedidos, transações ou assinaturas em CSV, Então recebo os arquivos com os registros do período, E os dados batem com o que aparece na tela.

RF-BILL-083: Importar transações e pedidos via CSV

• Descrição: Permitir importar transações e pedidos por CSV para migração ou carga de histórico.
• Prioridade: Média
• Atores: Operador de cobrança
• H1: Dado que migro dados de outro sistema, Quando importo um CSV de transações e pedidos, Então os registros passam a constar no ModularCRM, E o histórico financeiro fica completo.

RF-BILL-084: Perfis de frete

• Descrição: Permitir configurar perfis de frete com tarifas customizadas para produtos físicos no checkout.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que vendo produtos físicos, Quando configuro um perfil de frete, Então o valor do frete é somado no checkout conforme a regra, E o cliente vê o custo de envio antes de pagar.

Provedores de pagamento e integrações

RF-BILL-085: Provedores de pagamento plugáveis e mapa de capacidade

• Descrição: Suportar uma arquitetura de provedores de pagamento plugáveis, com método manual (análogo ao Pix atual) sempre disponível, e um mapa de qual método funciona em cada superfície de venda (formulários, loja, faturas, links, calendário, entre outros).
• Prioridade: Média
• Atores: Administrador, Operador de cobrança
• H1: Dado que quero habilitar um meio de pagamento, Quando ativo um provedor e defino onde ele vale, Então as superfícies habilitadas passam a aceitá-lo, E o método manual permanece disponível como opção.
• Notas: Provedores de cartão (Stripe e similares) dependem de gateway de cartão, hoje fora do escopo V1 (ADR-004); a V1 opera com Pix manual como método principal.

Superfícies de venda correlatas

RF-BILL-086: Formulário de pedido com cobrança

• Descrição: Suportar formulários de pedido (order forms) que cobram produtos diretamente no checkout.
• Prioridade: Média
• Atores: Cliente final, Operador de marketing
• H1: Dado que publico um formulário de pedido, Quando o cliente escolhe os produtos e paga, Então o pedido é registrado com o pagamento, E o contato e a compra ficam vinculados no CRM.

RF-BILL-087: Loja de comércio eletrônico com método manual

• Descrição: Suportar uma loja de comércio eletrônico nativa com catálogo e checkout, incluindo método de pagamento manual (equivalente ao Pix atual).
• Prioridade: Média
• Atores: Cliente final, Operador de cobrança
• H1: Dado que tenho uma loja publicada, Quando o cliente finaliza a compra pelo método manual, Então o pedido é criado aguardando confirmação de pagamento, E o operador confirma o pagamento para liberar o pedido.

RF-BILL-088: Cobrança em email, formulários e pesquisas

• Descrição: Suportar checkout direto em campanhas de email e cobrança em formulários e pesquisas.
• Prioridade: Média
• Atores: Cliente final, Operador de marketing
• H1: Dado que envio uma campanha de email com produto, Quando o cliente clica em comprar no email, Então ele é levado direto ao checkout, E a compra é registrada vinculada à campanha.

RF-BILL-089: Cobrança no agendamento e cupom em calendários

• Descrição: Suportar cobrança em calendário, serviços e menu de serviços no momento do agendamento, com aplicação de cupom.
• Prioridade: Média
• Atores: Cliente final, Operador de cobrança
• H1: Dado que um serviço agendável é pago, Quando o cliente agenda e aplica um cupom válido, Então o valor com desconto é cobrado no agendamento, E o horário só é confirmado após o pagamento.

RF-BILL-090: Cobrança de acesso a grupos, comunidades e cursos

• Descrição: Suportar cobrança de acesso a grupos pagos, comunidades e cursos, liberando o acesso após o pagamento.
• Prioridade: Média
• Atores: Cliente final, Operador de cobrança
• H1: Dado que um curso tem acesso pago, Quando o cliente conclui o pagamento, Então o acesso ao conteúdo é liberado, E a perda de pagamento (quando recorrente) suspende o acesso.

RF-BILL-091: Cobrança avulsa na ficha do contato

• Descrição: Permitir gerar uma cobrança avulsa diretamente na ficha do contato.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que estou na ficha de um contato, Quando gero uma cobrança avulsa de um valor, Então o cliente recebe o link de pagamento, E a cobrança fica registrada no histórico do contato.

RF-BILL-092: Venda presencial (POS e leitores de cartão)

• Descrição: Suportar venda presencial com ponto de venda e leitores de cartão.
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que atendo um cliente presencialmente, Quando registro a venda no ponto de venda, Então a cobrança é processada na hora, E o pedido é registrado no sistema.
• Notas: Depende de gateway de cartão e leitores físicos, hoje fora do escopo V1 (ADR-004).

Recibos e notas

RF-BILL-093: Recibos de venda automáticos

• Descrição: Emitir recibo de venda automático após o pagamento de formulários de pedido, agendamentos e faturas.
• Prioridade: Alta
• Atores: Cliente final, Operador de cobrança
• H1: Dado que um cliente concluiu um pagamento, Quando o pagamento é confirmado, Então o cliente recebe automaticamente um recibo de venda, E o recibo fica registrado junto à transação.

RF-BILL-094: Confirmações pós-compra e configuração de recibos

• Descrição: Enviar confirmações pós-compra e permitir configurar o recibo em uma área de settings dedicada (aparência, remetente, conteúdo).
• Prioridade: Média
• Atores: Operador de cobrança, Cliente final
• H1: Dado que configuro o recibo em settings, Quando um cliente compra, Então ele recebe a confirmação e o recibo no formato configurado, E o remetente e o conteúdo seguem a configuração definida.

11.7 Permissões, equipe e configurações (RF-PERM)

Cobre a lacuna entre o modelo simples de papéis do ModularCRM (dono/administrador/membro) e a matriz granular de permissões por módulo, visibilidade por dados atribuídos, valores globais reutilizáveis, integrações privadas com rotação de token, integrações nativas adicionais, perfil de negócio completo, feature flags por tenant e configurações de infraestrutura (domínios, redirects, email, telefone, objetos personalizados, auditoria profunda). Base de segurança multiusuário, por isso vários itens são Essenciais.

Matriz granular de permissões por módulo

RF-PERM-001: Controle de acesso por papel e módulo com catálogo canônico

• Descrição: O acesso às ações do produto é governado por papéis: cada organização define papéis, e cada membro recebe um papel. Um papel concede, por módulo, quais ações o membro pode executar. Os módulos e as ações válidas são fixados num catálogo canônico único, fonte única que a tela de Papéis e Permissões renderiza, que as telas consultam e que o banco reforça. O catálogo é: Contatos (ver, criar, editar, excluir, exportar), Conversas (ver, criar, editar, excluir), Oportunidades (ver, criar, editar, excluir), Calendário (ver, criar, editar, excluir), Automação (ver, criar, editar, excluir), Pagamentos (ver, criar, editar, excluir), Produtos (ver, criar, editar, excluir), Tarefas (ver, criar, editar, excluir), Formulários (ver, criar, editar, excluir), Campanhas (ver, criar, editar, excluir, enviar), Relatórios (ver, exportar), Configurações (ver, editar) e Administração (ver, editar). Cada tela consulta a permissão pelo módulo da própria entidade que manipula: é proibido pegar carona no módulo de outra entidade e proibido consultar módulo ou ação fora do catálogo. A verificação ocorre no frontend (para orientar a interface) e no banco (para impedir bypass por chamada direta de API). Dono, administrador e Super Admin não são restringidos. Membro sem papel atribuído mantém padrões seguros nomeados por módulo: pode ver em qualquer módulo, não pode excluir em nenhum módulo, e não pode editar Configurações nem Administração, os dois módulos sensíveis do catálogo, tratados por simetria. O padrão de editar Administração é NEGADO, igual ao de Configurações. O modelo é fail closed: na ausência de permissão explícita, nega.
• Prioridade: Essencial
• Atores: Administrador, Dono
• H1: Dado que sou administrador, Quando abro Papéis e Permissões, crio um papel marcando módulos e ações do catálogo e o atribuo a um membro, Então o membro passa a enxergar e poder somente o que foi liberado, E o banco recusa o que o papel nega, E nenhuma tela consulta módulo ou ação fora do catálogo, E um membro sem papel atribuído não consegue editar Configurações nem Administração.
• Notas: Este requisito é violado quando alguma tela consulta módulo ou ação fora do catálogo acima, ou quando um membro cujo papel nega uma ação a executa por qualquer via, ou quando um membro sem papel atribuído edita Configurações ou Administração. Decisão de 2026-07-22 (Wladimir): o padrão do membro sem papel para editar Administração passa a ser NEGADO, em simetria com Configurações, eliminando a assimetria anterior em que Administração vinha liberada por padrão. Entrega rastreada por partes: reforço de escrita no banco (feito), catálogo canônico e alinhamento das telas (feito), reforço no banco dos módulos Produtos, Tarefas, Formulários e Campanhas (pendente), tela de Papéis e Permissões (pendente), reforço de ver e exportar (pendente), simetria do padrão de editar entre Configurações e Administração para o membro sem papel (pendente).

RF-PERM-002: Escopos de permissão e hierarquia acumulativa

• Descrição: Classificar cada permissão em um de três escopos: Somente Agência (só admin da company: criar/editar/deletar contas de cliente, integrações globais, audit logs, branding/white-label), Somente Conta (pipelines, workflows, calendários, biblioteca de mídia, conversas, reputação, builder), e Disponível em Ambos (gestão de usuários, relatórios de dashboard, gestão de contatos e smart lists). Aplicar regra de hierarquia onde admin de agência supera admin de conta, com permissões que acumulam (stack) e não se cancelam.
• Prioridade: Essencial
• Atores: Administrador, Dono
• H1: Dado que uma permissão é marcada como Somente Agência, Quando um usuário de conta tenta acessá-la, Então o acesso é negado independentemente das outras permissões dele, E quando um usuário tem permissões vindas de escopos diferentes elas se somam em vez de se anular.
• Notas: Reflete a matriz Agency-Only / Sub-Account-Only / Both do GHL.

RF-PERM-003: Tipo de usuário com acesso global vs contas selecionadas

• Descrição: Distinguir, no nível da company, entre usuário do tipo Agência (acessa todas as contas de cliente da company) e usuário do tipo Conta (acessa apenas as contas explicitamente atribuídas a ele). Hoje o produto tem apenas papéis planos sem essa distinção de abrangência de acesso.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que crio um usuário do tipo Conta, Quando atribuo a ele duas contas de cliente específicas, Então ele acessa somente essas duas contas, E quando crio um usuário do tipo Agência ele acessa automaticamente todas as contas presentes e futuras da company.

RF-PERM-004: Permissões operacionais notáveis (Login As, Export data, gestão de usuários)

• Descrição: Expor permissões específicas de alto impacto: Login As (administrador impersona outro usuário para suporte/diagnóstico), Export data (quem pode exportar dados de widgets/relatórios), e distinção entre Ver e Gerenciar Usuários vs Somente Ver Usuários dentro do módulo de gestão de usuários.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que tenho a permissão Login As habilitada, Quando seleciono outro usuário para impersonar, Então passo a operar o sistema com a visão e as permissões dele, E toda ação nesse modo fica registrada na auditoria com meu identificador real, E quem tem apenas Somente Ver Usuários consegue listar a equipe mas não editar nem criar usuários.
• Notas: Login As default habilitado no GHL, controlável por usuário; registrar impersonação na auditoria é requisito de segurança.

RF-PERM-005: Permissão granular de calendários (booking vs gestão)

• Descrição: No módulo de Calendários, separar dois direitos: acesso de agendamento (booking) a calendários específicos e direito total de gestão de calendários. Um usuário pode ter apenas booking em um subconjunto de calendários sem poder configurá-los.
• Prioridade: Média
• Atores: Administrador, Membro
• H1: Dado que concedo a um usuário apenas booking em um calendário, Quando ele acessa o módulo, Então consegue agendar naquele calendário mas não editar disponibilidade, regras ou integrações do calendário, E um usuário com gestão total pode configurar qualquer aspecto do calendário liberado.

RF-PERM-006: Reuso de perfil de permissões (clonagem e templates)

• Descrição: Permitir copiar as permissões granulares de um usuário para outro (clone role) e evoluir para templates de papel nomeados e reutilizáveis, evitando reconfiguração manual a cada novo usuário. O GHL hoje só oferece cópia manual entre usuários existentes, sem templates formais.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que já configurei as permissões de um usuário vendedor, Quando crio um novo vendedor e escolho clonar as permissões do primeiro, Então o novo usuário nasce com o mesmo conjunto de permissões, E posso salvar esse conjunto como um template de papel para aplicar a futuros usuários com um clique.
• Notas: Templates de papel são melhoria sobre o GHL, que só tem clonagem manual.

RF-PERM-007: Permissão de criação e gestão de integrações privadas por usuário

• Descrição: Controlar por usuário quem pode criar e gerenciar integrações privadas (tokens de API). Por padrão restrito a administradores, com toggle individual para liberar ou bloquear usuários específicos.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que um usuário não tem a permissão de integrações privadas, Quando ele acessa as configurações, Então a área de integrações privadas fica oculta ou bloqueada, E ao habilitar a permissão para ele o usuário passa a poder criar e rotacionar tokens.

RF-PERM-008: Permissões por pipeline e por dashboard

• Descrição: Controlar quais pipelines de oportunidades e quais dashboards/relatórios cada usuário pode ver e gerenciar, permitindo restringir visibilidade de funis e painéis sensíveis a subconjuntos da equipe.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que restrinjo um usuário a um único pipeline, Quando ele acessa Oportunidades, Então vê apenas aquele pipeline e não os demais, E quando limito o acesso a dashboards ele só abre os painéis liberados para ele.

Visibilidade "somente dados atribuídos"

RF-PERM-009: Toggle "Somente Dados Atribuídos"

• Descrição: Adicionar um toggle por usuário que, quando ativo, restringe a visão dele a apenas: contatos atribuídos a ele, oportunidades onde ele é o dono, e agendamentos/tarefas vinculados ao nome dele. Central em CRM multivendedor para isolar carteiras.
• Prioridade: Essencial
• Atores: Administrador, Dono
• H1: Dado que ativo Somente Dados Atribuídos para um vendedor, Quando ele abre Contatos, Oportunidades e Tarefas, Então vê apenas os registros atribuídos ou pertencentes a ele, E não consegue acessar registros de outros vendedores por listagem, busca ou link direto, E ao desativar o toggle ele volta a enxergar todos os dados permitidos pelo módulo.

Valores personalizados (custom values globais)

RF-PERM-010: Valores personalizados globais (key:value reutilizáveis)

• Descrição: Criar o conceito de Valores Personalizados: pares chave:valor definidos uma vez por conta e reutilizados como merge fields globais em toda a plataforma (emails, SMS, workflows, documentos), por exemplo nome da empresa, link de agendamento ou oferta atual. Editar o valor em um lugar propaga em todos os usos. Conceito distinto de campos personalizados (que são por registro).
• Prioridade: Alta
• Atores: Administrador, Membro
• H1: Dado que crio um valor personalizado com nome "Link de Agendamento", Quando o sistema gera a chave automática correspondente, Então posso inserir a variável em emails e workflows via sintaxe de merge, E ao atualizar o valor central todos os usos passam a refletir o novo valor sem edição individual.
• Notas: Sintaxe de merge no padrão custom_values.nome_em_minusculo_com_underscores; mudar o nome de exibição não altera a chave já gerada.

RF-PERM-011: Organização de valores personalizados (pastas, ações em massa, busca)

• Descrição: Organizar valores personalizados em pastas não aninhadas (cada valor em no máximo uma pasta), com ações de item (mover para pasta, editar nome/valor/pasta, deletar com confirmação), ações em massa (mover ou deletar vários) e busca por palavra-chave na lista de todos os valores.
• Prioridade: Média
• Atores: Administrador, Membro
• H1: Dado que tenho dezenas de valores personalizados, Quando crio pastas e movo valores para elas, Então cada valor fica em uma única pasta e as pastas não podem ser aninhadas, E consigo selecionar vários valores para mover ou deletar em massa com uma confirmação, E consigo localizar um valor por busca de palavra-chave.

RF-PERM-012: Catálogo de merge fields nativos

• Descrição: Disponibilizar um catálogo de merge fields nativos do sistema (dados de contato, agendamento, oportunidade, usuário e conta) para uso em mensagens e documentos personalizados, complementando os valores personalizados definidos pelo usuário.
• Prioridade: Média
• Atores: Administrador, Membro
• H1: Dado que estou compondo um email, Quando abro o seletor de variáveis, Então vejo tanto os valores personalizados quanto o catálogo de merge fields nativos organizados por entidade, E ao inserir um merge field ele é substituído pelo dado real no envio.

Objetos personalizados

RF-PERM-013: Objetos personalizados (registros CRM de primeira classe)

• Descrição: Permitir criar tipos de registro CRM totalmente novos (Property, Pet, Project, Policy, Subscription, etc.) além dos objetos padrão (Contatos, Empresas, Oportunidades), com nome, campo de exibição primário, chave do objeto, campos personalizados próprios, associações com outros objetos e uso em workflows, formulários e relatórios.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que preciso modelar uma entidade que não é pessoa nem empresa, Quando crio um objeto personalizado definindo nome, campo de exibição e chave, Então posso adicionar campos personalizados e associações a ele, E posso usá-lo em triggers e ações de workflow, formulários e relatórios após defini-lo.
• Notas: Objetos padrão mantêm features exclusivas (email em massa, campanhas de marketing) que objetos personalizados não têm.

RF-PERM-014: Campos únicos, associações e limites de objetos personalizados

• Descrição: Suportar campos únicos por objeto (Texto de Linha Única, Texto Multilinha, Número, Telefone) com unicidade imposta em toda a conta e em todos os pontos de entrada (UI, workflows, formulários, API), associações entre objetos (Oportunidade com objeto, Contato com objeto), e limites configuráveis inspirados no GHL (referência: até 10 objetos por conta e até 10 campos únicos por objeto).
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que defino um campo único em um objeto personalizado, Quando um registro tenta ser criado com valor duplicado por qualquer ponto de entrada, Então o sistema rejeita a duplicidade, E consigo associar registros desse objeto a contatos e oportunidades respeitando os limites de quantidade configurados.

Integrações privadas com rotação de token

RF-PERM-015: Integrações privadas (tokens de API com escopos)

• Descrição: Substituir as chaves de API simples por integrações privadas baseadas em tokens de acesso estáticos com seleção de escopos (least privilege). Ao criar, o admin define nome, descrição e escopos, e o token é exibido apenas uma vez. Deve ser possível editar nome, descrição e escopos sem gerar um novo token.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que crio uma integração privada, Quando seleciono apenas os escopos necessários e confirmo, Então o token é exibido uma única vez para eu copiar, E posso depois editar nome, descrição e escopos da integração sem invalidar o token existente.
• Notas: Header de autorização no padrão Authorization com o token; escopos granulares por recurso (contatos leitura/escrita, conversas, oportunidades, calendários, etc.).

RF-PERM-016: Rotação de token com sobreposição e expiração de emergência

• Descrição: Implementar rotação de token com dois modos: rotação de rotina (recomendada a cada 90 dias) com janela de sobreposição de 7 dias em que o token antigo e o novo coexistem antes do antigo expirar, e rotação de emergência que invalida o token imediatamente. Durante a sobreposição deve haver opções de cancelar a rotação ou expirar agora.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que inicio uma rotação de rotina de um token, Quando a rotação é criada, Então um novo token passa a valer enquanto o antigo continua válido por 7 dias, E posso cancelar a rotação ou forçar a expiração imediata do antigo, E na rotação de emergência o token antigo é invalidado na hora.

RF-PERM-017: Limites e seletor de escopos das integrações privadas

• Descrição: Aplicar limites de quantidade de tokens por nível (referência GHL: até 5 no nível da company e até 5 por conta de cliente) e oferecer um seletor de escopos completo por recurso da API, orientado a least privilege, para restringir cada token ao mínimo necessário.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que atingi o limite de tokens de um nível, Quando tento criar mais um, Então o sistema bloqueia e orienta a deletar ou reaproveitar um token existente, E ao criar um token vejo a lista completa de escopos para marcar somente os necessários.

Integrações nativas adicionais

RF-PERM-018: Catálogo expandido de integrações nativas

• Descrição: Além de Meta e Google já existentes, oferecer integrações nativas adicionais priorizadas pelo ICP: gateways de pagamento (Stripe, PayPal, Square, Authorize.net, NMI), financeiro (QuickBooks), e-commerce (Shopify), calendário/vídeo (Zoom), email/calendário bidirecional (Gmail, Outlook), TikTok, Google Business Profile, e verticais de serviço (Jobber, ServiceTitan, ActiveProspect). Priorizar por relevância; decisões já cravadas do produto (ex.: Stripe descartado no MCRM) prevalecem.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que acesso a área de Integrações, Quando escolho uma integração nativa disponível, Então sou guiado pelo fluxo de autorização específico dela, E ao concluir os dados passam a sincronizar conforme o escopo da integração.
• Notas: Escopo e ordem de implementação a validar com produto; não reabrir decisões já cravadas.

RF-PERM-019: Marketplace de desenvolvedores e apps OAuth de terceiros

• Descrição: Prover um marketplace de apps de terceiros e um caminho para desenvolvedores publicarem apps OAuth que se integram ao produto, formando um ecossistema extensível de integrações além das nativas.
• Prioridade: Média
• Atores: Administrador, Dono, Desenvolvedor externo
• H1: Dado que existe um marketplace de apps, Quando um administrador instala um app de terceiro, Então o app solicita os escopos que precisa e o admin autoriza, E um desenvolvedor externo consegue submeter um app OAuth para publicação seguindo o processo definido.

Perfil de negócio

RF-PERM-020: Perfil de negócio completo por conta

• Descrição: Ampliar o perfil da conta com campos hoje ausentes: Nome Legal separado do Nome Amigável, Nicho/Categoria de indústria, Domínio de Marca (subdomínio custom para links e formulários), além de logo, email, telefone, endereço e website. O fuso horário da conta deve reger os eventos automáticos de campanha.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que edito o perfil de negócio de uma conta, Quando preencho Nome Legal, Nicho e Domínio de Marca, Então esses campos ficam disponíveis para uso em documentos, filtros e links, E os eventos automáticos de campanha passam a respeitar o fuso horário configurado.

RF-PERM-021: Dados de compliance e representante autorizado

• Descrição: Adicionar seção de informações de registro para compliance (verificação de mensageria e afins): Tipo de Empresa, Indústria, Tipo e Número de Registro (ex.: CNPJ/EIN/VAT), Regiões de Operação (multi-seleção), e dados do Representante Autorizado (nome e contato).
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que preciso habilitar mensageria em conformidade, Quando preencho tipo, indústria, número de registro, regiões de operação e representante autorizado, Então esses dados ficam armazenados e disponíveis para os processos de verificação, E campos obrigatórios ausentes bloqueiam a verificação com aviso claro.

RF-PERM-022: Configurações gerais da conta (toggles de comportamento)

• Descrição: Expor toggles de comportamento por conta hoje inexistentes: Permitir Oportunidade Duplicada, Mesclar Contatos do Facebook por Nome, Desabilitar Fuso do Contato para agendamento, Marcar Emails como Não Verificados por Hard Bounce, Validar Telefone no primeiro SMS, Verificar Email no primeiro envio, e opções de conformidade de mensagem (adicionar mensagem de opt-out ao SMS, adicionar informação do remetente ao SMS, adicionar link de descadastro ao email).
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que ativo o toggle de adicionar link de descadastro aos emails, Quando um email é enviado pela conta, Então o link de descadastro é anexado automaticamente, E cada toggle de comportamento passa a valer imediatamente para as operações da conta após ser salvo.

RF-PERM-023: Preferências de duplicação de contato (dedupe configurável)

• Descrição: Permitir configurar por conta a política de duplicação de contatos: toggle Permitir Contatos Duplicados, fator primário de determinação de duplicidade (EMAIL ou TELEFONE) e fator de confirmação secundário. Hoje o produto não tem dedupe configurável.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que defino EMAIL como fator primário de duplicidade e desligo Permitir Duplicados, Quando um novo contato chega com email já existente, Então o sistema trata como duplicado conforme a regra, E ao trocar o fator primário para TELEFONE a deduplicação passa a considerar o número.

RF-PERM-024: Chamadas, correio de voz e retorno de chamada perdida

• Descrição: Adicionar configurações de voz por conta: arquivo de correio de voz (upload MP3/WAV), tempo de espera de chamada recebida (segundos até cair na caixa) e mensagem automática de retorno por SMS para chamadas perdidas (Missed Call Text Back) com função de teste.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que configuro o retorno automático de chamada perdida, Quando uma chamada não é atendida, Então o contato recebe automaticamente a mensagem SMS configurada, E consigo enviar um teste da mensagem antes de ativar, E o correio de voz enviado usa o arquivo carregado após o tempo de espera definido.

RF-PERM-025: Internacionalização por conta (idioma da interface e de saída)

• Descrição: Suportar idioma da plataforma por conta (i18n da interface) e idioma de comunicação de saída (idioma dos campos personalizados em mensagens), independentes entre si.
• Prioridade: Média
• Atores: Administrador, Membro
• H1: Dado que defino o idioma da plataforma de uma conta, Quando um usuário dela acessa a interface, Então a UI aparece no idioma configurado, E o idioma de comunicação de saída rege como os campos personalizados são renderizados nas mensagens, mesmo que difira do idioma da interface.

Feature flags / Labs

RF-PERM-026: Programa de features beta por tenant (Labs)

• Descrição: Criar um mecanismo de opt-in de features beta por company e por conta, apresentado como cards com título, descrição, estimativa de dias até liberação geral, toggle liga/desliga, link de changelog, link de documentação de suporte e canal de envio de feedback. Permite lançar features gradualmente por tenant.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que existe uma feature em beta no Labs, Quando ativo o toggle dela para minha conta, Então a feature passa a ficar disponível somente para essa conta, E vejo os metadados de prazo até liberação geral, changelog e documentação, E posso enviar feedback pelo card.

RF-PERM-027: Ativação em massa de features beta por conta

• Descrição: Permitir que a company ative ou desative features de Labs em massa para múltiplas contas de cliente de uma vez, com abas separadas para escopo de company e de conta.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que sou admin da company, Quando seleciono uma feature de Labs e escolho aplicá-la a um conjunto de contas, Então a feature é ativada em massa nessas contas, E consigo gerenciar separadamente as features de escopo de company e de conta.

Redirecionamentos de URL e domínios

RF-PERM-028: Gestão de domínios e subdomínios por conta

• Descrição: Permitir adicionar domínios raiz e subdomínios a uma conta e associá-los a funis e sites, requisito para publicar páginas em domínio próprio do cliente e para criar redirects.
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que adiciono um domínio a uma conta, Quando associo um funil ou site a esse domínio, Então as páginas passam a ser servidas sob o domínio configurado, E um domínio precisa estar adicionado à conta antes de ser usado em redirects.

RF-PERM-029: Redirecionamentos de URL 301 (tipos e regex)

• Descrição: Suportar redirects 301 com quatro tipos: para um step específico de funil (funil associado a domínio da conta), para uma página específica de site, redirect de todos os paths de um domínio para outro (ex.: www para raiz), e suporte a REGEX. Orientar uso de URLs absolutas e evitar cadeias de redirect.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que crio um redirect 301 de www para o domínio raiz, Quando um visitante acessa qualquer path em www, Então é redirecionado para o path equivalente no domínio raiz, E consigo criar redirects por step de funil, por página de site e por padrão REGEX, com aviso ao formar cadeias de redirect.

Auditoria (profundidade adicional)

RF-PERM-030: Auditoria com valores antes/depois e filtros

• Descrição: Aprofundar os audit logs existentes para capturar valores field-level antes e depois de cada mudança, nome e identificador de assets deletados, e filtros por Usuário, Módulo, Tipo de Ação (Criar/Atualizar/Deletar) e Intervalo de Tempo, com um drawer de detalhe navegável (avançar/voltar entre registros sem fechar).
• Prioridade: Alta
• Atores: Administrador, Dono
• H1: Dado que abro um registro de auditoria de uma atualização, Quando visualizo o detalhe, Então vejo o valor anterior e o novo do campo alterado, E consigo filtrar a lista por usuário, módulo, tipo de ação e período, E navego entre registros pelo drawer sem fechá-lo.

RF-PERM-031: Auditoria de objetos personalizados e retenção configurável

• Descrição: Estender a auditoria para cobrir objetos personalizados (histórico de mudanças por objeto) e os demais módulos relevantes (usuários, contas, contatos, oportunidades, sites/funis, page builder), com política de retenção configurável (referência GHL: 60 dias antes da purga), separando escopo de company e de conta.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que altero um registro de um objeto personalizado, Quando consulto a auditoria daquele objeto, Então vejo o histórico de mudanças com autor e horário, E o escopo de company mostra atividade da company enquanto o escopo de conta mostra apenas a atividade daquela conta, E registros mais antigos que a retenção configurada são purgados.

Serviços de email

RF-PERM-032: Provedores de email e ordem de envio

• Descrição: Suportar múltiplos provedores de envio de email por conta (provedor padrão do produto, Mailgun com domínio dedicado verificado por DNS, e SMTP próprio de terceiros como Gmail/SendGrid/SES), com ordem configurável de qual provedor envia primeiro e credenciais por domínio adicionado.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que conecto um SMTP próprio e também tenho Mailgun configurado, Quando defino a ordem dos provedores, Então os envios seguem a ordem definida com fallback para o próximo, E cada domínio adicionado usa suas próprias credenciais de envio.

RF-PERM-033: Configuração de resposta e encaminhamento de email

• Descrição: Configurar endereço de encaminhamento e BCC (suportados apenas pelos provedores compatíveis) e habilitar respostas de forma que replies inbound entrem e sejam rastreados em Conversas.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que habilito respostas no provedor ativo, Quando um contato responde a um email, Então a resposta entra e é rastreada em Conversas, E o encaminhamento e BCC funcionam quando o provedor os suporta.

Números de telefone

RF-PERM-034: Configuração por número de telefone

• Descrição: Permitir configurar cada número: rótulo interno, identificador de chamada (Caller ID entre números verificados), mensagem de whisper na conexão (pede tecla para aceitar, contando como conectado só quando há atendimento humano), gravação automática de chamada, tempos de espera de entrada e saída (padrão 60s), toque simultâneo em múltiplos usuários (limite de 7), e number pool para rastreamento de origem, além de preferências padrão para novas contas.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que edito a configuração de um número, Quando defino whisper e toque simultâneo em vários usuários, Então a chamada só conta como conectada quando um humano atende e toca em até 7 usuários ao mesmo tempo, E a gravação automática e os tempos de espera configurados passam a valer para as chamadas daquele número.

Provedores de conversa

RF-PERM-035: Provedores de conversa plugáveis

• Descrição: Permitir plugar canais/provedores externos (ex.: WhatsApp custom, provedores de SMS) que passam a aparecer dentro de Conversas, com o rastreamento de reply inbound dependente do provedor configurado.
• Prioridade: Média
• Atores: Administrador, Dono
• H1: Dado que conecto um provedor de conversa externo, Quando mensagens chegam por esse canal, Então elas aparecem em Conversas como uma thread, E as respostas inbound são rastreadas conforme o provedor.

Gestão de tags (profundidade adicional)

RF-PERM-036: Tag como gatilho e gestão central de tags

• Descrição: Além das tags já existentes, suportar tag adicionada/removida como gatilho de automação e gestão central de tags (renomear e mesclar tags), evitando proliferação de tags redundantes.
• Prioridade: Média
• Atores: Administrador, Membro
• H1: Dado que configuro um workflow com gatilho de tag adicionada, Quando uma tag é aplicada a um contato, Então a automação dispara, E na gestão central consigo renomear uma tag e mesclar duas tags em uma só, atualizando todos os contatos afetados.

Campos personalizados (profundidade adicional)

RF-PERM-037: Tipos e organização de campos personalizados

• Descrição: Garantir que os campos personalizados existentes cubram os tipos monetário, dropdown e data, agrupamento em pastas, opção de esconder campos vazios, e a distinção entre campos de contato e campos de oportunidade, com criação rápida a partir de formulários.
• Prioridade: Média
• Atores: Administrador, Membro
• H1: Dado que crio um campo personalizado do tipo monetário e o agrupo em uma pasta, Quando ele é exibido em um contato sem valor, Então posso escolher escondê-lo quando vazio, E consigo distinguir campos de contato de campos de oportunidade e criar campos rapidamente a partir de um formulário.
• Notas: Complementa o que já existe; foco em profundidade (tipos, pastas, hide-empty), não em recriar o básico.

11.8 Relatórios e analytics especializados (RF-REP)

O ModularCRM já tem relatórios e painéis salvos genéricos com métricas do próprio negócio. Faltam os relatórios pré-construídos por domínio que o GHL entrega (atribuição de origem, anúncios, chamadas, equipe, agendamentos, email, funil) mais o pipeline de entrega de relatório com marca ao cliente e o motor de métricas calculadas. Os RFs abaixo cobrem todas as 16 áreas do mapeamento, sem repetir o painel genérico que já existe.

Dashboards especializados (multi-time, permissões, filtros)

RF-REP-002: Múltiplos dashboards nomeados por time com default

• Descrição: Permitir criar quantidade ilimitada de dashboards nomeados (Vendas, Marketing, Finanças) por conta, marcar um como default do usuário e alternar entre eles.
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado que um admin precisa de visões separadas por área, Quando ele cria vários dashboards nomeados e marca um como default, Então cada dashboard aparece na lista de seleção, E o default abre automaticamente ao entrar em Relatórios.
• Notas: Ilimitados em todos os planos no GHL.

RF-REP-003: Permissões granulares por dashboard e por papel

• Descrição: Cada dashboard tem um toggle privado versus compartilhado e níveis de acesso por papel (usuário da agência, admin da conta, usuário da conta) com os graus VER, EDITAR, TOTAL e SEM ACESSO.
• Prioridade: Alta
• Atores: Admin da conta, usuário da agência, usuário da conta
• H1: Dado que um dashboard tem dados sensíveis, Quando o admin define o dashboard como privado ou atribui nível de acesso por papel, Então usuários sem permissão não veem nem editam o dashboard, E o dono mantém acesso total.
• Notas: Reforça o modelo multi-tenant Company/Account do ModularCRM.

RF-REP-004: Quick Filters globais no dashboard

• Descrição: Barra de filtros no topo do dashboard que aplica um recorte global (período, origem, usuário, pipeline) a todos os widgets de uma vez, com override de período por widget individual.
• Prioridade: Alta
• Atores: Usuário da conta, admin da conta
• H1: Dado um dashboard com vários widgets, Quando o usuário aplica um Quick Filter global no topo, Então todos os widgets recalculam sob aquele recorte, E um widget com data própria configurada sobrescreve o recorte global só para ele.

RF-REP-005: Clonar dashboard, favoritar e personalizar tema

• Descrição: Ações de clonar um dashboard existente, fixar favoritos e aplicar tema, cores e imagem de fundo por dashboard.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado um dashboard já montado, Quando o usuário clona, fixa como favorito ou troca tema e fundo, Então a cópia nasce idêntica e editável, E o favorito aparece em destaque na lista.

RF-REP-006: Tipos de gráfico e filtros compostos por widget

• Descrição: Suporte aos tipos numérico (scorecard), rosca, linha, barra, barra horizontal e tabela, com linha/barra aceitando múltiplas métricas, tabela aceitando múltiplos campos como colunas, filtros com operadores E/OU em grupos compostos e agrupamento por campo de lista.
• Prioridade: Alta
• Atores: Usuário da conta, admin da conta
• H1: Dado que o usuário configura um widget, Quando ele escolhe o tipo de gráfico e monta grupos de filtro com E/OU, Então o widget renderiza conforme o tipo escolhido, E respeita a lógica composta dos grupos de filtro e o agrupamento por picklist.

Atribuição de origem

RF-REP-007: Atribuição first-touch e last-touch persistida no contato

• Descrição: Gravar por contato a primeira interação (valor estático que nunca muda) e a interação mais recente (atualiza a cada evento qualificador), ambas persistidas no registro do contato na aba de atividade.
• Prioridade: Alta
• Atores: Sistema, usuário da conta, admin da conta
• H1: Dado que um contato interage pela primeira vez, Quando o evento qualificador ocorre, Então o first-touch é gravado de forma imutável, E a cada nova interação o last-touch é atualizado sem apagar o first-touch.
• Notas: Campos por toque incluem Session Source, Session Medium, Session Campaign, além de content, term, match type e IDs de campanha/anúncio.

RF-REP-008: Classificação determinística em categorias de origem

• Descrição: Resolver a origem de cada toque em nove categorias por ordem determinística: paid search (gclid/wbraid/gbraid ou utm_source=adwords), paid search Bing/Yahoo (msclkid), paid social (fb_ad, linkedin_ad, twitter_ad, reddit_ad, ctwa_clid do WhatsApp), organic social, organic search (termo cifrado vira Unknown SSL), referral, direct traffic, others (ligação, SMS, email, WhatsApp, mensagem FB) e CRM UI/terceiros.
• Prioridade: Alta
• Atores: Sistema
• H1: Dado um toque com parâmetros de sessão e referrer, Quando o motor de atribuição avalia a origem, Então ele aplica a ordem de resolução e classifica em uma das nove categorias, E registra a categoria junto com os campos de sessão.

RF-REP-009: Eventos nativos que disparam atribuição

• Descrição: Disparar a captura de atribuição na mesma sessão apenas para ativos nativos do CRM: envio de formulário ou pesquisa, agendamento em calendário, chat widget após informar contato e order form de um ou dois passos; formulários externos não disparam.
• Prioridade: Média
• Atores: Sistema, contato
• H1: Dado um contato numa sessão rastreada, Quando ele envia um formulário nativo, agenda, usa o chat widget ou completa um order form, Então a atribuição daquela sessão é capturada, E um formulário externo embarcado não gera atribuição.

RF-REP-010: Widget de atribuição por origem, meio e campanha

• Descrição: Widget que agrupa e exibe por Session Source, Session Medium ou Session Campaign, com escolha entre first-touch e last-touch, e filtros de atribuição/UTM aplicáveis a widgets customizados.
• Prioridade: Alta
• Atores: Usuário da conta, admin da conta
• H1: Dado um widget de atribuição, Quando o usuário escolhe o tipo de atribuição e agrupa por origem/meio/campanha, Então o widget mostra o volume por dimensão, E limita a um único grupo de filtro composto quando há campo de atribuição envolvido.
• Notas: Campos de atribuição exigem Attribution Type definido e desabilitam múltiplos grupos de filtro.

Relatório de anúncios Meta

RF-REP-011: Painel Meta Ads do custo ao ROI

• Descrição: Painel vivo de campanhas Meta com o funil financeiro custo, lead, venda e ROI usando a terminologia oficial: impressions, clicks, conversions, client spend (custo mais fee de agência, só admin), average CPC, cost per conversion (CPA), conversion rate, revenue, ROI, sales, CPS, leads e CPL.
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado uma conta Meta conectada nas integrações, Quando o usuário abre o painel Meta Ads, Então ele vê o funil de custo a ROI por campanha, E o client spend com fee só aparece para papéis admin.
• Notas: Requer conta Meta conectada e permissões LeadConnector; nomes de campanha/anúncio únicos para evitar contatos duplicados.

RF-REP-012: Widgets Meta Ad e rankings de campanha

• Descrição: Widgets Meta Ad para dashboards e relatórios (website purchases, conversions, Meta ad clicks, amount spent, average CPC, cost per conversion, ad impressions, reach, average CPM, CTR) e widgets de ranking por maior spend, mais conversões, mais purchases, mais clicks, mais impressões e maior reach.
• Prioridade: Média
• Atores: Usuário da conta, admin da conta
• H1: Dado dados de Meta Ads conectados, Quando o usuário adiciona widgets Meta ou um ranking de campanhas, Então cada widget exibe a métrica escolhida no tipo de gráfico numérico, rosca, linha, barra ou tabela, E o ranking ordena as campanhas pelo critério selecionado.

Relatório de anúncios Google

RF-REP-013: Painel Google Ads com atribuição por anúncio e grupo

• Descrição: Painel de Google Ads conectado por integração que rastreia leads via UTM e gclid, com breakdown por anúncio e grupo de anúncio, coluna de leads (contatos criados por paid search), coluna de sales (só oportunidades ganhas, flutua com status) e métricas de negócio análogas ao Meta (spend, CPC, conversões, CPA, CPL, revenue, ROI).
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado uma conta Google Ads conectada com templates de tracking corretos, Quando o usuário abre o painel Google Ads, Então ele vê leads e vendas atribuídos por anúncio e grupo de anúncio com custo e ROI, E templates de tracking incorretos são sinalizados como falhas de conversão.

Ad Manager consolidado

RF-REP-014: Consolidação multi-plataforma de anúncios em tempo real

• Descrição: Camada que consolida Facebook, Instagram, Google e LinkedIn Ads numa visão única em tempo real com impressions, clicks, conversions, spend e métricas de conversão, evitando trocar entre plataformas.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado múltiplas plataformas de anúncio conectadas, Quando o usuário abre o Ad Manager, Então ele vê as métricas consolidadas das quatro plataformas em tempo real num só painel, E consegue todos os relatórios de performance sem sair do Ad Manager.

Relatórios agendados e com marca

RF-REP-015: Construtor de relatório documento com capa e marca

• Descrição: Construtor de relatório no formato documento (distinto do dashboard), do zero ou convertendo um dashboard, com upload de logo, headers por página, cor de fundo por página, propriedades de página, menu de elementos (títulos, seções), temas predefinidos mais tema custom e páginas reordenáveis por arrastar.
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado a necessidade de um relatório de marca, Quando o usuário monta o documento com logo, temas e páginas ou converte um dashboard existente, Então o relatório sai com a identidade visual aplicada por página, E as páginas podem ser adicionadas, reordenadas e renomeadas.

RF-REP-016: Agendamento e entrega por email a clientes não-usuários

• Descrição: Agendar o envio do relatório por frequência (diária, semanal, mensal e demais) para qualquer endereço de email, inclusive de clientes que não são usuários do sistema, com remetente, assunto e corpo customizáveis.
• Prioridade: Alta
• Atores: Admin da conta, cliente final destinatário
• H1: Dado um relatório pronto, Quando o usuário agenda a frequência e informa os destinatários e o texto do email, Então o relatório é enviado automaticamente no intervalo definido, E o destinatário recebe mesmo sem ser usuário do sistema.

RF-REP-017: Export PDF, persistência de filtros e distribuição por Snapshot

• Descrição: Exportar o relatório em PDF (com preview por email), preservar date ranges e filtros salvos com o override de data por widget, e permitir que métricas e widgets custom sejam incluídos em Snapshots para distribuição a subcontas.
• Prioridade: Média
• Atores: Admin da conta, usuário da agência
• H1: Dado um relatório configurado, Quando o usuário exporta em PDF ou inclui os widgets custom num Snapshot, Então o PDF gerado respeita filtros e datas salvos, E o Snapshot leva os widgets custom às subcontas de destino.
• Notas: PDF exclui imagens e iframes por segurança; JPEG/PNG renderizam melhor e o preview por email inclui os visuais.

Relatório de chamadas

RF-REP-018: Painel de chamadas entrantes

• Descrição: Seção de chamadas recebidas com donut de status (perdida, ocupada, atendida), widget de first-time calls (status, duração média e total) e top call sources (canal de origem por volume, deals ganhos e duração).
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado um histórico de chamadas recebidas, Quando o usuário abre o painel de chamadas entrantes, Então ele vê o donut de status, os first-time calls e as principais origens, E cada origem mostra volume, deals ganhos e duração.

RF-REP-019: Painel de chamadas saintes

• Descrição: Seção de chamadas realizadas com call status split (distribuição de status de saída) e top agents (agentes que mais ligaram com contagem única de leads contatados).
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado um histórico de chamadas realizadas, Quando o usuário abre o painel de chamadas saintes, Então ele vê a distribuição de status de saída, E o ranking de agentes com a contagem única de leads contatados.

RF-REP-020: Tabela histórica de chamadas com gravações e export CSV

• Descrição: Tabela com todas as chamadas categorizadas por entrada e saída, filtro por número (todos ou individual), acesso a múltiplas gravações por chamada IVR via dropdown e export CSV com colunas customizáveis e filtros por duração, status e origem.
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado a tabela histórica de chamadas, Quando o usuário filtra por número, duração ou status e abre o dropdown de gravações, Então ele acessa cada gravação da chamada IVR, E exporta em CSV com as colunas que escolher.
• Notas: Call Reporting rastreia por número atribuído; Agent Reporting rastreia por agente. Requer plano Agency Pro no GHL.

Produtividade da equipe

RF-REP-021: Painel de produtividade por agente

• Descrição: Painel de produtividade da equipe com visão de oportunidades, stats de conversão, stats de SMS, stats de email, métricas de chamada e eficiência por usuário/agente.
• Prioridade: Alta
• Atores: Admin da conta, gestor de equipe
• H1: Dado a atividade da equipe num período, Quando o gestor abre o painel de produtividade, Então ele vê por agente as oportunidades, conversão, SMS, email, chamadas e eficiência cruzados, E consegue avaliar o desempenho individual.
• Notas: Requer plano Agency Pro no GHL.

RF-REP-022: Leaderboard e comparação entre períodos

• Descrição: Leaderboard com most opportunities e most won opportunities mais comparação de métricas entre dois intervalos de data.
• Prioridade: Média
• Atores: Admin da conta, gestor de equipe
• H1: Dado o painel de produtividade, Quando o gestor abre o leaderboard e escolhe dois períodos para comparar, Então ele vê o ranking de mais oportunidades e mais oportunidades ganhas, E a variação das métricas entre os períodos.

Relatório de agendamentos

RF-REP-023: Agendamentos por status e por canal

• Descrição: Painel de agendamentos com gráficos numéricos por status (booked, confirmed, cancelled, new, showed, no-show, invalid e demais) e donut de canais/origens (funis, usuários).
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado os agendamentos de um período, Quando o usuário abre o relatório de agendamentos, Então ele vê a contagem por cada status, E o donut de origens mostra a distribuição por canal.

RF-REP-024: Rankings de calendário e análise de cancelamento e reschedule

• Descrição: Rankings de top calendars por volume, top 5 usuários por agendamentos, dias da semana mais populares, top 5 calendars com mais cancelamentos e top 5 com mais reschedules, além de contabilizar Event Sync appointments (eventos com ao menos um attendee sincronizado de Google, Outlook, iCloud ou Calendly).
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado o histórico de agendamentos, Quando o usuário abre os rankings, Então ele vê os calendários e usuários líderes, os dias mais populares e os campeões de cancelamento e reschedule, E os eventos sincronizados de calendários externos entram na contagem.

Métricas calculadas

RF-REP-025: Motor de métricas calculadas multi-fonte

• Descrição: Editor de fórmula que combina até quatro métricas de fontes diferentes com operadores de soma, subtração, multiplicação e divisão mais constantes, cada métrica com propriedade de data própria (ex.: page views por visited on versus appointments por created on), validação ao vivo e uso em dashboards, relatórios e Snapshots.
• Prioridade: Alta
• Atores: Admin da conta, usuário da conta
• H1: Dado a necessidade de um KPI calculado como conversion rate, CPA ou ROI, Quando o usuário monta a fórmula combinando até quatro métricas com datas independentes, Então o sistema valida a fórmula ao vivo e calcula o resultado, E a métrica fica disponível em dashboards, relatórios e Snapshots.
• Notas: Fontes incluem CRM padrão mais Meta Ads e Google Analytics. Plano $497+ no GHL.

Widgets de objetos customizados

RF-REP-026: Reporting sobre objetos customizados

• Descrição: Widgets sobre custom objects criados na conta (até dez por location, como pets, imóveis, casos, projetos) com métricas de contagem, soma e média, tipos numérico, tabela, barra, barra horizontal, linha e rosca, quick filters, filtro por widget, date range e agrupamento por picklist, misturando contato, oportunidade e custom object no mesmo dashboard.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado um custom object com registros, Quando o usuário cria um widget de contagem, soma ou média sobre ele, Então o widget mostra a métrica no tipo de gráfico escolhido, E pode conviver com widgets de contato e oportunidade no mesmo dashboard.

Analytics de site e funil

RF-REP-027: Dashboard de analytics cross-asset com KPI cards

• Descrição: Dashboard central de analytics que analisa um tipo de asset por vez (funis, websites, blogs, webinars, formulários, pesquisas, QR codes, tracking externo) com KPI cards que funcionam como abas: page views (e unique), page views by step, opt-in, time on page, sales/revenue e opt-in conversion rate.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado os ativos de site e funil, Quando o usuário escolhe um asset type e um KPI card, Então o dashboard mostra a métrica correspondente àquele tipo de asset, E QR codes exibem visão simplificada sem os toggles de KPI.

RF-REP-028: Funil por etapa, opt-in rate e comparação de período

• Descrição: Drill-down de page views by step para navegar o funil ou webinar etapa a etapa, cálculo de opt-in conversion rate (opt-ins divididos por unique page views), filtro por asset específico ou todos, date range com default de 14 dias e comparação automática com o período anterior de igual tamanho.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado um funil com várias etapas, Quando o usuário abre page views by step e define o período, Então ele vê o volume por etapa e o opt-in conversion rate, E o sistema compara automaticamente com o período anterior de mesmo tamanho.

RF-REP-029: Stats por funil e por página

• Descrição: Aba de estatísticas dentro do próprio funil no nível página com as definições oficiais: visitors (únicos), page views, conversions, conversion rate e revenue.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado um funil específico, Quando o usuário abre a aba de stats do funil, Então ele vê visitors únicos, page views, conversões, taxa de conversão e revenue daquele funil, E os números batem com as definições oficiais de stats.

Widgets de Google Analytics

RF-REP-030: Widgets GA4 embutidos no dashboard

• Descrição: Doze widgets GA4 nativos (após conectar property e data stream nas integrações): total/active/new users, new vs returning, sessions over time, engagement rate, bounce rate, avg engagement time, top events, sessions by channel, sessions by source/medium, top pages by views e device category breakdown.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado uma property GA4 conectada, Quando o usuário adiciona widgets GA4 ao dashboard, Então cada widget exibe a métrica de site no tipo numérico, rosca, linha, barra ou tabela, E as métricas de site podem ser misturadas com as do CRM no mesmo dashboard.

Estatísticas de email

RF-REP-031: Deliverability detalhada de email

• Descrição: Estatística de email com breakdown de entrega: recipients, delivered, failed (email inválido ou API key ruim), soft bounce (temporário), hard bounce (permanente) e accepted/rejected (SMTP), além de compliance com unsubscribed e spam complaints.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado um envio de email, Quando o usuário abre a estatística do envio, Então ele vê a entrega separada em delivered, failed, soft bounce e hard bounce e o compliance de unsub e spam, E as taxas de bounce, unsub e spam são calculadas.

RF-REP-032: Engajamento, recipient-level e top emails

• Descrição: Métricas de engajamento (opened, clicked, replied), taxas de delivery, open, click, bounce, unsubscribe e spam, tendência ao longo do tempo, top emails por open e click, detalhe recipient-level (quem abriu, clicou ou descadastrou) e filtro por date range, com SMTP externo rastreando só opens, clicks, replies e bounces.
• Prioridade: Média
• Atores: Admin da conta, usuário da conta
• H1: Dado uma série de envios de email, Quando o usuário abre o engajamento, Então ele vê opens, clicks e replies com tendência no tempo e os top emails, E consegue abrir o detalhe recipient-level de quem abriu, clicou ou descadastrou.
• Notas: Em envios via SMTP externo o delivered é inferido no open.

Rollup de agência

RF-REP-033: Reporting rolado multi-tenant nível agência

• Descrição: Visão nível agência que consolida todas as subcontas com métricas roladas: active users, appointments, contacts, communications (email/SMS/call inbound e outbound mais talk time), submissions (forms, surveys, FB forms), social messaging (WhatsApp, GBP, IG, FB in e out), reviews (total, positivas, negativas) e sites created (funnels, sites, forms, surveys), com até oito colunas selecionáveis nos cards por subconta.
• Prioridade: Alta
• Atores: Admin da agência
• H1: Dado várias subcontas ativas, Quando o admin da agência abre o rollup, Então ele vê as métricas consolidadas por subconta, E escolhe até oito colunas para exibir nos cards de resumo.
• Notas: Relevante para o modelo Company que atende Accounts do ModularCRM. Plano Pro $497+ no GHL.

RF-REP-034: Gestão central de relatórios agendados

• Descrição: Console na visão de agência para gerir os relatórios agendados de todas as subcontas: pausar e retomar em massa via checkbox, filtro por ativos ou pausados, ação de pausar todos e toggle para auto-criar relatórios agendados para novas subcontas.
• Prioridade: Média
• Atores: Admin da agência
• H1: Dado muitos relatórios agendados espalhados por subcontas, Quando o admin abre a gestão central e seleciona relatórios, Então ele pausa ou retoma em massa e filtra por ativos ou pausados, E pode ligar a auto-criação de agendados para novas subcontas.

Auditoria de marketing

RF-REP-035: Relatório de auditoria de marketing de prospect

• Descrição: Relatório de auditoria de marketing local de um prospect que analisa e compara a performance de marketing local com detecção de website, usado como ferramenta de prospecção e vendas.
• Prioridade: Média
• Atores: Usuário de vendas, admin da conta
• H1: Dado um prospect a ser abordado, Quando o usuário gera o relatório de auditoria de marketing, Então o sistema detecta o website e monta a análise comparativa de performance local, E o relatório serve de material de prospecção e vendas.

11.9 Gestão de subcontas e provisionamento interno (RF-AGY)

No modelo interno da Modulareasy (sem revenda pela ferramenta), esta área guarda apenas o que ajuda a operar as subcontas dos clientes: provisionar cliente novo rápido a partir de modelos, atualizar configuração em lote, aprovar e controlar acesso, e manter o isolamento entre clientes. Ficaram de fora rebilling, carteira, configurador de SaaS, cobrança automática, white-label, afiliados e prospecção.

Atualização incremental de modelo pronto (push update)

RF-AGY-007: Envio incremental de atualizações de modelo pronto (push update)

• Descrição: A agência deve poder enviar as mudanças de um modelo pronto atualizado para subcontas que já o carregaram, sincronizando apenas os itens originados do modelo, sem duplicar conteúdo e sem tocar cópias criadas manualmente pelo usuário, valores custom nem usuários atribuídos.
• Prioridade: Média
• Atores: Dono da agência, Admin da agência, Sistema
• H1: Dado um modelo pronto atualizado e subcontas que já o carregaram, Quando a agência dispara o envio de atualização escolhendo as subcontas e os itens, Então o Sistema sobrescreve nas subcontas alvo apenas os itens originados do modelo, E preserva cópias manuais, valores custom e usuários atribuídos.
• Notas: O processo deve capturar as mudanças do modelo antes de enviar. Processar em lotes para não sobrecarregar. Subcontas de agências externas não recebem o envio e precisam reimportar.

RF-AGY-008: Distinção entre carregar e enviar atualização

• Descrição: O Sistema deve distinguir a operação de carregar um modelo (adiciona itens numa subconta sem apagar/alterar o existente, uso típico de onboarding) da operação de enviar atualização (sincroniza itens já carregados), deixando claro ao operador o efeito de cada uma para evitar duplicatas indesejadas.
• Prioridade: Média
• Atores: Dono da agência, Admin da agência
• H1: Dado um modelo pronto e uma subconta, Quando a agência escolhe entre carregar e enviar atualização, Então o Sistema explicita que carregar adiciona sem apagar e enviar atualização sobrescreve o que veio do modelo, E executa apenas a operação escolhida.
• Notas: Carregar o mesmo modelo duas vezes gera duplicatas; a interface deve alertar.

RF-AGY-009: Versionamento de modelo pronto

• Descrição: Cada captura bem-sucedida de mudanças de um modelo deve gerar uma nova versão datada com resumo do que foi adicionado, removido e sincronizado, e o Sistema deve manter um histórico de versões consultável, com o número de versão visível nas listagens de modelos próprios, importados e compartilhados.
• Prioridade: Média
• Atores: Dono da agência, Admin da agência
• H1: Dado um modelo pronto, Quando a agência captura mudanças com sucesso, Então o Sistema cria uma nova versão com data e resumo de itens adicionados/removidos/sincronizados, E a lista no histórico de versões do modelo.
• Notas: Não é exigido reverter para versões anteriores nesta fatia, apenas visibilidade do histórico.

RF-AGY-010: Criação forçada de modelo com relatório de itens ignorados

• Descrição: Quando a captura de um modelo falhar em incluir certos itens, o Sistema deve oferecer a criação forçada, salvando os itens que carregaram e apresentando um relatório dos itens ignorados para o operador decidir como tratá-los.
• Prioridade: Média
• Atores: Dono da agência, Admin da agência, Sistema
• H1: Dado que a captura de um modelo falha em alguns itens, Quando a agência opta por criar forçado, Então o Sistema salva o modelo com os itens que carregaram, E apresenta um relatório dos itens ignorados.
• Notas: Útil para não travar a criação do modelo por causa de poucos itens problemáticos.

RF-AGY-011: Tipos de link de compartilhamento de modelo pronto

• Descrição: A agência deve poder compartilhar um modelo pronto por diferentes tipos de link (reutilizável, uso único, por e-mail, restrito a agências, restrito a subcontas e via marketplace), controlando quem pode importá-lo para a própria biblioteca.
• Prioridade: Média
• Atores: Dono da agência, Admin da agência
• H1: Dado um modelo pronto, Quando a agência gera um link de compartilhamento de uso único, Então o Sistema permite uma única importação por aquele link, E adiciona o modelo à biblioteca de quem importou.
• Notas: Cada tipo de link tem regra de reuso e escopo de destinatário distintos.

Painel consolidado de gestão das subcontas

RF-AGY-012: Painel consolidado de status e uso por subconta

• Descrição: painel único onde a Modulareasy vê todas as subcontas dos clientes com status (ativa, suspensa), uso operacional e saúde, para gerir a operação interna.
• Prioridade: Alta
• Atores: Super Admin
• H1: Dado o conjunto de subcontas, Quando o Super Admin abre o painel, Então vê o status e o uso de cada cliente num só lugar, E consegue entrar em qualquer subconta para dar suporte.
• Notas: sem cobrança nem faturamento, pois não há venda pela ferramenta.

Aprovação de subconta e verificação

RF-AGY-013: Aprovação manual de novas subcontas

• Descrição: a Modulareasy pode exigir que novas subcontas fiquem pausadas aguardando aprovação manual antes de serem ativadas, controlando quem entra na plataforma.
• Prioridade: Média
• Atores: Super Admin
• H1: Dado que a aprovação manual está ativa, Quando uma nova subconta é criada, Então ela fica pausada aguardando aprovação, E só é ativada após o Super Admin aprovar.

RF-AGY-014: Verificação de e-mail e duas etapas no acesso

• Descrição: o acesso às subcontas exige verificação de e-mail e oferece verificação em duas etapas, para reduzir fraude e acessos indevidos.
• Prioridade: Média
• Atores: Org Owner/Admin, sistema
• H1: Dado um novo acesso de usuário, Quando ele conclui o cadastro, Então o sistema exige a verificação do e-mail antes de liberar o acesso completo, E oferece verificação em duas etapas.

RF-AGY-015: Acesso e integração transversal às subcontas (operação Modulareasy)

• Descrição: a operação da Modulareasy pode ter papéis e credenciais que atuam sobre várias subcontas ao mesmo tempo, para suporte, automação e integração, sempre respeitando o isolamento dos dados de cada cliente.
• Prioridade: Alta
• Atores: Super Admin
• H1: Dado um membro da operação com papel transversal, Quando ele acessa o sistema, Então tem acesso conforme a permissão às subcontas do escopo, E o isolamento entre dados de clientes diferentes é preservado.
• Notas: substitui a antiga transferência entre agências e o SMTP white-label do GHL, que não se aplicam ao modelo interno.

RF-AGY-016: Modo "entrar como empresa" para suporte

• Descrição: permitir que o Super Admin entre numa empresa específica para dar suporte e enxergue os dados reais dela (contatos, conversas, oportunidades, configurações), preservando o isolamento entre empresas para todos os demais papéis. Refina o acesso transversal do RF-AGY-015 com a mecânica concreta do painel (o "entrar como esta empresa").
• Prioridade: Alta
• Atores: Super Admin
• H1: Dado o Super Admin no portal, Quando ele entra numa empresa que possui dados, Então vê os contatos, conversas, oportunidades e configurações reais daquela empresa, E ao sair do modo volta à visão global; nenhum outro papel ganha visão cruzada.
• Notas: acrescentado pela auditoria de 2026-07-10 (ver {AUD-01} do Roadmap). A regra de isolamento por linha precisa abrir exceção para o Super Admin apenas neste modo de suporte.

RF-AGY-017: Ingresso de usuários sem auto-atendimento público

• Descrição: o ModularCRM é um painel interno (ver o recorte de escopo da seção 11.9) e não admite auto-cadastro. Uma conta de usuário só passa a existir por provisão da operação da Modulareasy, pelo assistente de criação de subconta do Super Admin (RF-AGY-001), ou por convite a uma empresa existente feito pelo servidor com token de serviço. Não há caminho público de auto-registro: nenhuma página, rota ou configuração do sistema de autenticação pode permitir que um visitante crie a própria conta. Isto reconcilia a palavra "cadastro" do RF-AGY-014, que trata da verificação de e-mail e das duas etapas ao concluir um acesso já provisionado ou convidado, e não de auto-registro público.
• Prioridade: Alta
• Atores: Super Admin, Administrador de agência, sistema
• H1: Dado qualquer visitante sem convite, Quando ele tenta criar uma conta por conta própria (página pública de cadastro, rota de auto-registro ou auto-cadastro habilitado no sistema de autenticação), Então nenhuma conta é criada, E as contas só nascem por provisão do Super Admin (RF-AGY-001) ou por convite feito pelo servidor com token de serviço, que seguem funcionando.
• Notas: acrescentado em 2026-07-22 para tornar falseável a decisão de painel interno já registrada na seção 11.9 e no {AUD-41} do Roadmap de Implementação; o conserto correspondente é o {AUD-107}. Antes dele nenhum requisito reprovava a existência de uma porta pública de auto-cadastro: o RF-AGY-001 governa a criação de subcontas (organizações), não a de contas de usuário, e o RF-AGY-014 pressupunha um "cadastro" de auto-atendimento herdado do modelo revendável, hoje fora do escopo.

11.10 Marketing (RF-MKT)

Módulo NOVO de marketing outbound no ModularCRM. Hoje só existem Trigger Links e uma base simples de campanhas; todo o restante (email marketing, social planner, ad manager, affiliate manager, brand boards, broadcasts, template library) é construção do zero, paridade com o menu Marketing do GoHighLevel.

Email Marketing

RF-MKT-001: Construtor visual de email drag-and-drop

• Descrição: Editor visual de email com painel dockável (esquerda ou direita), edição in-line de conteúdo e blocos que podem ser adicionados, duplicados, deletados e rearranjados por arrastar e soltar.
• Prioridade: Alta
• Atores: Gestor de Marketing, Operador de Company
• H1: Dado um usuário criando um email, Quando abre o construtor visual, Então consegue arrastar blocos para o corpo do email e reordená-los sem escrever código, E vê o resultado renderizado em tempo real no editor.
• Notas: Base do bloco de email; equivale ao Email Builder do GHL.

RF-MKT-002: Biblioteca de elementos de conteúdo do construtor

• Descrição: Conjunto de elementos inseríveis no construtor: texto (com editor in-line), imagem, vídeo, botão, logo, rodapé, ícones sociais, spacer e código HTML custom.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado um email em edição, Quando o usuário escolhe um tipo de elemento na paleta, Então o elemento é inserido no ponto selecionado com suas opções de estilo próprias, E pode ser editado, duplicado ou removido individualmente.

RF-MKT-003: Elementos avançados de conteúdo (carrinho, FAQ, formulário, RSS, social)

• Descrição: Elementos ricos do construtor: Shopping Cart (e-commerce dentro do email), FAQ, formulário ou pesquisa embutida (inline forms/surveys), bloco de RSS (feed dinâmico) e bloco de ícones de redes sociais.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um email em edição, Quando o usuário adiciona um bloco de RSS ou de formulário embutido, Então o conteúdo dinâmico é populado no envio a partir da fonte configurada, E o destinatário interage com o formulário ou vê os itens do feed diretamente no email.

RF-MKT-004: Conteúdo condicional e visibilidade por dispositivo

• Descrição: Regras de personalização que mostram ou ocultam blocos por condição (segmento, campo, tag) e controle de visibilidade de seções por dispositivo (desktop ou mobile).
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um bloco de email com regra condicional, Quando o email é montado para um destinatário específico, Então o bloco aparece ou é ocultado conforme a condição avaliada para aquele contato, E seções marcadas para um único dispositivo só renderizam no dispositivo correspondente.

RF-MKT-005: Controles de layout, tipografia e Google Fonts

• Descrição: Ajustes de margens de layout, espaçamento de texto, escolha de Google Fonts e geração de versão em texto puro (plain text) do email.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um email em edição, Quando o usuário ajusta margens, espaçamento ou fonte, Então o preview reflete as mudanças imediatamente, E o sistema mantém uma versão em texto puro coerente para clientes de email que não renderizam HTML.

RF-MKT-006: Anexos e preview de custom fields no construtor

• Descrição: Anexar arquivos a campanhas de email e visualizar no construtor como os custom fields (merge fields) serão renderizados com dados reais de exemplo.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um email com custom fields e anexos, Quando o usuário aciona o preview, Então os campos de mesclagem são substituídos por valores de amostra e os anexos aparecem listados, E o usuário confirma a aparência final antes do envio.

RF-MKT-007: Templates de email reutilizáveis

• Descrição: Criar, editar, salvar e reutilizar templates de email como layouts base para campanhas, incluindo templates prontos de pedido de avaliação (review request) com a marca da Company.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado que o usuário criou um layout de email, Quando o salva como template, Então ele fica disponível para iniciar novas campanhas a partir dele, E qualquer campanha nova pode escolher um template como ponto de partida.

RF-MKT-008: Importadores de templates externos (HTML, Mailchimp, ActiveCampaign, Kajabi)

• Descrição: Importar templates de email de HTML custom e de plataformas externas (Mailchimp, ActiveCampaign, Kajabi) convertendo para o construtor interno.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um template existente em outra plataforma ou em HTML, Quando o usuário aciona o importador correspondente, Então o template é convertido e fica editável no construtor interno, E o usuário pode ajustar e salvar como template próprio.

RF-MKT-009: Spintax e defaults de merge fields

• Descrição: Suporte a Spintax (variações dinâmicas automáticas de texto para reduzir spam) e definição de valores padrão (fallback) para custom values quando o contato não tem o dado preenchido.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um email com Spintax e merge fields, Quando o email é enviado, Então cada destinatário recebe uma variação sorteada do texto e os campos vazios usam o valor padrão configurado, E nenhum email é enviado com placeholder cru visível.

RF-MKT-010: Organização de campanhas e templates em pastas aninhadas

• Descrição: Estrutura de pastas aninhadas para organizar campanhas, templates e sequences de email.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um volume grande de campanhas e templates, Quando o usuário cria pastas e subpastas, Então consegue mover itens para dentro delas, E localiza campanhas e templates pela navegação hierárquica.

RF-MKT-011: Compartilhamento white-label de templates entre Companies

• Descrição: Compartilhar templates de email entre Companies (agências) mantendo isolamento e white-label.
• Prioridade: Média
• Atores: Super Admin do vendor, Gestor de Marketing da Company
• H1: Dado um template marcado como compartilhável, Quando outra Company autorizada acessa a biblioteca, Então consegue clonar o template para o próprio ambiente, E nenhum dado sensível da Company de origem é exposto no processo.

RF-MKT-012: Campanha de email com escolha de template e destinatários

• Descrição: Criar campanha de email selecionando um template, personalizando o conteúdo, definindo os destinatários e configurando o envio, com fluxo de campanha e página de resumo.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado um template e uma lista de contatos, Quando o usuário monta uma campanha, Então escolhe destinatários, personaliza o conteúdo e avança pelo fluxo até a página de resumo, E vê o estado da campanha (rascunho, agendada, enviando, enviada) claramente identificado.

RF-MKT-013: Métodos de envio (Send Now, Schedule, Batch, RSS)

• Descrição: Métodos de disparo de campanha: envio imediato (Send Now), agendamento para data e hora futura (Schedule), envio em lotes para deliverability e pacing (Batch), e campanhas disparadas por feed RSS (auto-newsletter de blog).
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado uma campanha pronta, Quando o usuário escolhe o método de envio, Então o sistema dispara imediatamente, agenda para o horário definido, distribui em lotes conforme o pacing, ou aciona automaticamente ao surgir novo item no feed RSS, E o método escolhido fica registrado no resumo da campanha.

RF-MKT-014: Smart Send (melhor horário de envio por contato)

• Descrição: Recomendação data-driven do melhor horário de envio por contato (Best Time Recommendation), com envio otimizado individualmente.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado uma campanha com Smart Send ativo, Quando o sistema processa o disparo, Então calcula para cada contato o horário de maior probabilidade de abertura e agenda o envio individual, E o gestor vê que a campanha usa envio otimizado por contato.

RF-MKT-015: Reenvio automático para não-abertos (Resend to Un-opened)

• Descrição: Reenviar automaticamente a campanha, opcionalmente com assunto ou conteúdo variado, para os contatos que não abriram o email, incluindo variação para campanhas RSS e Batch.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado uma campanha enviada, Quando decorre a janela definida e o contato não abriu, Então o sistema reenvia a campanha para os não-abertos conforme a regra configurada, E não reenvia para quem já abriu.

RF-MKT-016: Controle de ciclo de vida da campanha (pausar, cancelar, reagendar, editar em andamento)

• Descrição: Pausar ou cancelar campanha agendada, reagendar dentro do construtor e alterar o conteúdo de uma campanha em andamento (ongoing).
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado uma campanha agendada ou em andamento, Quando o usuário aciona pausar, cancelar, reagendar ou editar, Então a campanha muda de estado ou tem o conteúdo atualizado sem afetar os envios já concluídos, E o novo estado é refletido na página de resumo.

RF-MKT-017: Duplicar e copiar campanha entre ambientes

• Descrição: Duplicar uma campanha e copiá-la para outra Location ou Account.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado uma campanha existente, Quando o usuário aciona duplicar ou copiar para outra Location, Então uma cópia editável é criada no destino, E a campanha original permanece inalterada.

RF-MKT-018: Preview e teste de email antes do envio

• Descrição: Preview e envio de email de teste em versões desktop e mobile antes do disparo real.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado uma campanha em edição, Quando o usuário solicita preview ou email de teste, Então recebe a renderização desktop e mobile e um envio de teste ao endereço informado, E consegue validar a aparência real antes de disparar para a lista.

RF-MKT-019: Segmentação de destinatários e importação assistida por IA

• Descrição: Construir segmentos de destinatários dentro do fluxo da campanha e importar contatos de qualquer plataforma com apoio de IA (Email AI).
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado uma campanha em criação, Quando o usuário monta um segmento por filtros ou importa uma lista externa via IA, Então o público de envio é definido com base nesses critérios, E o total de destinatários é exibido antes da confirmação.

RF-MKT-020: Configurações de campanha (remetente, atribuição, UTM, tracking, regras)

• Descrição: Configurar endereço remetente (From Address), parar sequência na resposta (Stop on Response), permitir múltiplas entradas do mesmo contato (Allow Multiple), âncora de data de evento (Event Start Date), ajustes de atribuição, parâmetros UTM e rastreamento de links e tags no envio.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado uma campanha em configuração, Quando o usuário define remetente, regras de resposta, UTM e tracking, Então os envios usam essas configurações e os cliques são rastreados com os parâmetros definidos, E a atribuição de conversão segue a regra escolhida.

RF-MKT-021: Email Sequences nativas

• Descrição: Criar sequências de emails encadeados (série nativa, fora do construtor de automação), com visão geral e gestão das sequences.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado uma série de emails planejada, Quando o usuário cria uma sequence nativa, Então define a ordem e o intervalo entre os emails, E os contatos inscritos avançam automaticamente pela sequência conforme as regras.

RF-MKT-022: Estatísticas e analytics de email

• Descrição: Estatísticas de campanha (aberturas, cliques, bounces, entregas), página de resumo, performance de cliques, guia de rastreamento de cliques e ações de email de automação incluídas nas estatísticas.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado uma campanha enviada, Quando o usuário abre as estatísticas, Então vê aberturas, cliques, bounces e entregas com a página de resumo e o detalhamento de performance de cliques, E as ações de email disparadas por automações também aparecem nos números.

RF-MKT-023: Métricas de ROI, conversão e dashboard de email

• Descrição: Rastrear conversão e receita atribuída às campanhas (ROI Conversion Metrics) e consolidar num dashboard all-in-one de email marketing.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado campanhas com atribuição ativa, Quando o usuário abre o dashboard de email marketing, Então vê a receita e a conversão atribuídas às campanhas em um painel consolidado, E consegue comparar o desempenho entre campanhas.

RF-MKT-024: Ações a partir das estatísticas (taggear, exportar)

• Descrição: Taggear contatos a partir das estatísticas (por exemplo, quem abriu ou clicou) e exportar os dados de email marketing.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado o relatório de estatísticas de uma campanha, Quando o usuário seleciona um grupo (abriu, clicou) e aplica uma tag ou exporta, Então os contatos recebem a tag ou os dados são exportados em arquivo, E a ação fica disponível diretamente da tela de estatísticas.

RF-MKT-025: Teste A/B de campanhas de email

• Descrição: Testar variações de assunto e conteúdo em campanhas de email com divisão de audiência e escolha do vencedor.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado uma campanha com duas ou mais variações, Quando o usuário ativa o teste A/B, Então cada variação é enviada a uma parcela do público e a de melhor desempenho pode ser enviada ao restante, E os resultados por variação aparecem nas estatísticas.
• Notas: Item marcado no relatório como a validar em plataforma; no GHL o teste hoje é feito via workflow e Smart Send. Manter como RF próprio no ModularCRM.

Social Planner

RF-MKT-026: Conexão de contas de redes sociais

• Descrição: Conectar e gerenciar contas das redes suportadas: Facebook (Pages e Groups), Instagram (via Facebook ou integração direta), Google Business Profile, LinkedIn (perfil e Business Pages), TikTok, YouTube, X/Twitter, Pinterest, Meta Threads e Bluesky.
• Prioridade: Alta
• Atores: Gestor de Social Media, Operador de Company
• H1: Dado que o usuário quer publicar em redes sociais, Quando conecta uma conta suportada via OAuth da rede, Então a conta fica disponível como canal de publicação no planner, E o sistema alerta quando a conexão expira ou é desconectada.

RF-MKT-027: Composição de post com customização por rede

• Descrição: Criar um post e customizá-lo individualmente por rede (mesmo post com texto ou mídia diferente por canal), com @mention de perfil, marcação de localização, grupos de hashtags reutilizáveis, múltiplas marcas d'água e auto-otimização de imagens.
• Prioridade: Alta
• Atores: Gestor de Social Media
• H1: Dado um post para múltiplas redes, Quando o usuário ajusta texto ou mídia por canal, Então cada rede recebe a versão específica configurada com suas hashtags, menções e marca d'água, E o preview mostra como o post ficará em cada rede.

RF-MKT-028: Tipos de post por rede (stories, reels, carrosséis, polls, pins, text posts)

• Descrição: Suporte a formatos específicos por rede: Instagram Story, Reels e Collaborator Posts; Facebook Reel, Story e Text Posts com fundo; TikTok post; YouTube Shorts e vídeos; LinkedIn carousel (PDF como fotos) e Poll Posts; Pinterest Pins; primeiro comentário automático (follow-up comment); e transformar review em post social.
• Prioridade: Média
• Atores: Gestor de Social Media
• H1: Dado o formato desejado em uma rede, Quando o usuário escolhe o tipo de post (story, reel, carousel, poll, pin, text post), Então o composer apresenta os campos e limites daquele formato, E o post é publicado no formato nativo da rede, respeitando limites de mídia (até 10 itens, imagem até 10 MB, vídeo até 1 GB).

RF-MKT-029: Agendamento e opções de publicação

• Descrição: Opções de publicação por post: salvar para depois, publicar agora, agendar para depois, enviar para aprovação e recorrente. Inclui posts recorrentes (dia, semana, mês, ano) e agendamento em comunidades.
• Prioridade: Alta
• Atores: Gestor de Social Media
• H1: Dado um post pronto, Quando o usuário escolhe a opção de publicação, Então o post é salvo, publicado imediatamente, agendado, enviado para aprovação ou configurado como recorrente, E aparece no calendário na data e hora correspondentes.

RF-MKT-030: Calendário e melhor horário de publicação

• Descrição: Visão de calendário dos posts, recomendação data-driven de melhor horário de publicação por engajamento da audiência (Best Time to Post), fila por categoria de conteúdo evergreen (Category Queue) e busca com filtro inteligente do calendário.
• Prioridade: Média
• Atores: Gestor de Social Media
• H1: Dado o calendário de conteúdo, Quando o usuário ativa a recomendação de melhor horário ou usa a fila por categoria, Então o sistema sugere ou preenche horários com maior engajamento estimado, E o usuário filtra e localiza posts pelo calendário.

RF-MKT-031: Agendamento em massa via CSV e RSS

• Descrição: Agendamento em massa via planilha CSV (modos básico e avançado, com requisitos de arquivo documentados) e agendamento automático de posts a partir de URL de feed RSS.
• Prioridade: Média
• Atores: Gestor de Social Media
• H1: Dado um lote grande de posts, Quando o usuário sobe um CSV válido ou informa um feed RSS, Então dezenas ou centenas de posts são criados e agendados de uma vez, E erros de formato do arquivo são reportados antes do agendamento.

RF-MKT-032: Fluxo de aprovação e colaboração

• Descrição: Fluxo de aprovação de posts por outro membro antes de publicar, aprovação de links externos, agrupamento de perfis sociais e compartilhamento de conteúdo do planner entre sub-accounts via snapshot.
• Prioridade: Média
• Atores: Gestor de Social Media, Aprovador
• H1: Dado um post enviado para aprovação, Quando o aprovador revisa, Então pode aprovar ou rejeitar antes da publicação e o post só vai ao ar após aprovado, E links externos passam pelo mesmo controle quando exigido.

RF-MKT-033: Notificações de status do planner

• Descrição: Notificações por email e in-app para post que falhou, conta expirada ou desconectada e post pendente de aprovação, com banner in-app para contas desconectadas.
• Prioridade: Média
• Atores: Gestor de Social Media
• H1: Dado um post que falhou ou uma conta desconectada, Quando o evento ocorre, Então o usuário recebe notificação por email e vê o banner in-app correspondente, E consegue reconectar a conta ou reprocessar o post a partir do aviso.

RF-MKT-034: Analytics, listening e engajamento social

• Descrição: Analytics avançado de performance social, estatísticas específicas de LinkedIn, social listening e descoberta de tendências, gestão de comentários em inbox (incluindo DMs e automações de comentário do TikTok), sincronização de posts existentes (Facebook e Instagram Post Sync), encurtador de link nativo e canais de mensagem no Google Business Profile.
• Prioridade: Média
• Atores: Gestor de Social Media
• H1: Dado contas conectadas com histórico de publicação, Quando o usuário abre o painel de analytics e o inbox de comentários, Então vê métricas de performance, tendências monitoradas por social listening e todos os comentários e DMs num só lugar, E consegue responder aos comentários sem sair do sistema.

RF-MKT-035: Social Planner no app mobile e troubleshooting

• Descrição: Uso do Social Planner no app mobile, biblioteca de templates de Social Planner e ferramentas de troubleshooting (falha de publicação no Facebook, limpar cache de preview de link do LinkedIn).
• Prioridade: Média
• Atores: Gestor de Social Media
• H1: Dado um usuário em campo, Quando abre o Social Planner no app mobile, Então cria e agenda posts a partir do celular e acessa templates prontos, E consegue diagnosticar e reprocessar posts com falha pelas ferramentas de troubleshooting.

Ad Manager

RF-MKT-036: Setup e conexão de contas de anúncio

• Descrição: Dashboard consolidando Meta (Facebook e Instagram), Google e LinkedIn Ads. Cobre criar Meta Business Manager e ad account, conectar Facebook com as permissões corretas, definir página padrão, conectar Google e LinkedIn, e as configurações gerais do Ad Manager.
• Prioridade: Alta
• Atores: Gestor de Tráfego, Operador de Company
• H1: Dado uma Company que anuncia, Quando o usuário conecta as contas de Meta, Google e LinkedIn com as permissões exigidas, Então as contas ficam disponíveis no dashboard unificado, E a página do Facebook padrão fica definida para novas campanhas.

RF-MKT-037: Criação e gestão de campanhas Meta

• Descrição: Criar campanhas Facebook e Instagram respeitando a hierarquia Campaign, Ad Set e Ad (1 ad set + 1 ad por padrão), definir orçamento, controles de audiência, objetivos (engajamento CTX, vendas/conversão), formatos (carousel, Instagram Ads), clonar e editar campanhas publicadas ou em revisão.
• Prioridade: Alta
• Atores: Gestor de Tráfego
• H1: Dado uma conta Meta conectada, Quando o usuário cria uma campanha, Então define objetivo, orçamento, público, ad set e ad dentro do sistema, E a campanha é publicada na Meta e pode ser clonada ou editada depois.

RF-MKT-038: Públicos de anúncio (custom, lookalike, customer list)

• Descrição: Criar e gerenciar públicos: audiências custom, lookalike e Customer List Custom Audience, além dos controles da aba de Audiences.
• Prioridade: Alta
• Atores: Gestor de Tráfego
• H1: Dado dados de audiência disponíveis, Quando o usuário cria um público custom, lookalike ou por lista de clientes, Então o público é criado na plataforma de anúncio e fica disponível para segmentar campanhas, E pode ser reutilizado em novas campanhas.

RF-MKT-039: Formulários de lead e conversação em anúncios

• Descrição: Criar formulário de lead do Facebook (lead form) e formulário de conversação (conversation form) no Ad Manager, com captura de leads integrada ao CRM.
• Prioridade: Alta
• Atores: Gestor de Tráfego
• H1: Dado uma campanha de geração de leads, Quando o usuário cria um lead form ou conversation form, Então os leads capturados pelo anúncio entram automaticamente como contatos no CRM, E ficam vinculados à campanha de origem.

RF-MKT-040: Preview, opportunity score e templates de anúncio

• Descrição: Preview avançado com links compartilháveis de anúncios Meta, Opportunity Score no Ad Manager e criação de campanhas a partir de templates (Template Library in Ads Manager), além de Run As Ad e Create Engagement Ad.
• Prioridade: Média
• Atores: Gestor de Tráfego
• H1: Dado uma campanha em criação, Quando o usuário gera o preview compartilhável ou parte de um template, Então recebe um link de visualização para aprovação e o score de oportunidade da campanha, E consegue publicar reaproveitando templates prontos.

RF-MKT-041: Google Ads

• Descrição: Conectar Google e criar campanhas Search e Demand Gen, com múltiplos ad groups, assets adicionais a nível de campanha, segmentos de audiência, offline conversions e visualização de estatísticas.
• Prioridade: Alta
• Atores: Gestor de Tráfego
• H1: Dado uma conta Google conectada, Quando o usuário cria uma campanha Search ou Demand Gen, Então define ad groups, assets e audiências dentro do sistema, E acompanha as estatísticas e registra conversões offline da campanha.

RF-MKT-042: LinkedIn Ads

• Descrição: Criar e gerenciar campanhas LinkedIn Ads, incluindo lead form, segmentação de audiência e estatísticas.
• Prioridade: Média
• Atores: Gestor de Tráfego
• H1: Dado uma conta LinkedIn conectada, Quando o usuário cria uma campanha LinkedIn, Então define público, formato e lead form dentro do sistema, E acompanha as estatísticas da campanha no dashboard.

RF-MKT-043: Conversão server-side (CAPI) e tracking

• Descrição: Enviar dados de conversão ao Ad Manager, ação de Meta Conversion API server-side dentro de automação, datasets de conversão, pixel, parâmetros de tracking e relatório de anúncios com UTM.
• Prioridade: Alta
• Atores: Gestor de Tráfego, Executor técnico
• H1: Dado uma conversão ocorrida no CRM, Quando a automação dispara a ação de Conversion API, Então o evento é enviado server-side à plataforma de anúncio com os parâmetros de conversão e pixel, E o relatório de anúncios reflete a conversão atribuída via UTM.

RF-MKT-044: Revenda white-label do Ad Manager

• Descrição: Habilitar e revender o Ad Manager para sub-accounts (grátis para a Company, revendável), inclusive com plano SaaS, e inclusão do Ad Manager em snapshots. Cobre também a pasta de troubleshooting do Ad Manager.
• Prioridade: Média
• Atores: Super Admin do vendor, Gestor de Company
• H1: Dado uma Company que revende serviços, Quando habilita o Ad Manager para uma Account, Então a Account passa a usar o Ad Manager conforme o plano definido pela Company, E o recurso pode ser incluído em snapshots para replicação.

Affiliate Manager

RF-MKT-045: Campanhas de afiliados

• Descrição: Criar campanha de afiliados a partir de funnel, website ou store, com múltiplas campanhas gerenciáveis, pré-requisitos de lançamento, glossário e migração a partir do FirstPromoter. Cada afiliado ganha link único de tracking e portal automático.
• Prioridade: Média
• Atores: Gestor de Afiliados, Operador de Company
• H1: Dado que a Company quer um programa de afiliados, Quando cria uma campanha vinculada a um funnel, site ou loja, Então a campanha entra em operação com regras de comissão e atribuição, E cada afiliado inscrito recebe link único e portal automaticamente.

RF-MKT-046: Estrutura de comissões

• Descrição: Definir comissão padrão (valor fixo ou percentual), comissão por produto, comissões multi-tier (níveis e sub-afiliados), comissões variáveis, duração da comissão (commission length) e janela de atribuição por cookie (cookie duration).
• Prioridade: Média
• Atores: Gestor de Afiliados
• H1: Dado uma campanha de afiliados, Quando o gestor define a estrutura de comissão, Então cada venda gera a comissão conforme valor fixo, percentual, produto, nível e duração configurados, E a atribuição respeita a janela de cookie definida.

RF-MKT-047: Rastreamento de leads e vendas de afiliados

• Descrição: Rastrear leads de campanha de afiliados, pagar por lead gerado (pay-per-lead), rastrear cliques em link de referência, suportar rastreamento de vendas em site externo e rastrear vendas por cupom.
• Prioridade: Média
• Atores: Gestor de Afiliados
• H1: Dado um afiliado com link e cupom, Quando um lead ou venda é gerado por ele, Então o sistema atribui o lead, o clique ou a venda ao afiliado correto (inclusive em site externo ou via cupom), E a comissão correspondente é calculada.

RF-MKT-048: Gestão de afiliados e sub-afiliados

• Descrição: Adicionar afiliados (import de contatos ou manual, com portal e link automáticos), adicionar sub-afiliados, página de perfil do afiliado, portal do afiliado (login, links, comissões), adicionar vendas manuais, comissões custom por afiliado, gestão de clientes sob afiliados, reatribuir contatos entre afiliados, tiers automáticos por performance, pay per sale para forms/surveys/calendars e ações rápidas em massa.
• Prioridade: Média
• Atores: Gestor de Afiliados, Afiliado
• H1: Dado um programa ativo, Quando o gestor adiciona um afiliado ou sub-afiliado, Então o afiliado recebe portal e link próprios, acompanha suas comissões no portal e pode subir de tier automaticamente por performance, E o gestor consegue ajustar comissões custom e reatribuir contatos entre afiliados.

RF-MKT-049: Payouts de afiliados

• Descrição: Vincular método de payout, gerenciar payouts e comissões (aprovar ou negar, breakdown por campanha e mês), gateways suportados para venda de produto, PayPal Auto Payouts, termos de pagamento com delay (NET-30 e similares para janela de reembolso), reversão automática de comissão em refund ou chargeback, ações em massa, exportar lista de afiliados e valores devidos, aba de payout negado.
• Prioridade: Média
• Atores: Gestor de Afiliados, Financeiro da Company
• H1: Dado comissões acumuladas, Quando o gestor processa os payouts, Então aprova ou nega comissões com breakdown por campanha e mês, paga via PayPal automático ou exporta a lista para pagar no gateway e marcar como pago, E comissões de vendas com refund ou chargeback são revertidas automaticamente respeitando os termos de pagamento.

RF-MKT-050: Automação e relatórios de afiliados

• Descrição: Triggers de automação (afiliado inscrito em campanha, nova venda de afiliado), ação de adicionar venda manual para um afiliado, atribuição e notificação de leads automatizadas, e dashboard de relatórios e insights do Affiliate Manager, além de biblioteca de mídia com criativos para afiliados.
• Prioridade: Média
• Atores: Gestor de Afiliados
• H1: Dado eventos no programa de afiliados, Quando um afiliado se inscreve ou gera uma venda, Então as automações configuradas disparam follow-ups e notificações, E o gestor acompanha o desempenho do programa no dashboard de relatórios e insights.

Brand Boards

RF-MKT-051: Criação e edição de Brand Board (Design Kit)

• Descrição: Espaço centralizado de identidade visual com Design Kit (logos, cores, tipografia). Criar Brand Board do zero, por template ou gerado a partir de uma URL de site. Limites de até 2 logos, 10 cores e 5 fontes. Inclui edição do Design Kit e definição de Brand Board padrão aplicada a novos funnels e websites.
• Prioridade: Média
• Atores: Designer da Company, Gestor de Marketing
• H1: Dado a identidade visual de uma marca, Quando o usuário cria um Brand Board do zero, por template ou a partir da URL do site, Então logos, cores e fontes ficam centralizados no Design Kit respeitando os limites, E o Brand Board pode ser definido como padrão para novos funnels e sites.

RF-MKT-052: Aplicação do Brand Board em funnels, sites e emails

• Descrição: Usar Brand Boards em funnels, websites e emails, com cores globais custom no color picker (Global Custom Colors) e cores do Brand Board disponíveis no builder de Form, Survey e Quiz.
• Prioridade: Média
• Atores: Designer da Company, Gestor de Marketing
• H1: Dado um Brand Board definido, Quando o usuário edita um funnel, site, email, form, survey ou quiz, Então as cores, fontes e logos do Brand Board ficam disponíveis no color picker e nos estilos, E aplicar o kit mantém a identidade visual consistente entre superfícies.

RF-MKT-053: Brand Voice (tom de voz para IA)

• Descrição: Definir Brand Voice no Brand Board (tom de voz para geração por IA), criando a voz da marca a partir de texto ou URL.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado a necessidade de conteúdo alinhado à marca, Quando o usuário cria a Brand Voice a partir de texto ou URL, Então o tom de voz fica registrado no Brand Board, E ferramentas de IA usam essa voz ao gerar conteúdo para a marca.

Broadcasts (envio em massa)

RF-MKT-054: Bulk SMS e Bulk Email a partir da lista de contatos

• Descrição: Envio em massa único de SMS e Email a partir da lista de Contatos (Bulk Actions), com mensagem custom ou template, custom fields, emojis e anexos. Cobre também o setup inicial de Email, Phone e SMS.
• Prioridade: Alta
• Atores: Gestor de Marketing, Operador de Company
• H1: Dado uma seleção de contatos, Quando o usuário aciona o envio em massa de SMS ou Email, Então compõe a mensagem com template, custom fields e anexos e dispara para todos os selecionados, E acompanha o resultado no dashboard de Bulk Actions.

RF-MKT-055: Entrega, pacing e compliance do envio em massa

• Descrição: Opções de entrega do envio em massa (enviar já, agendar data e hora, ou drip em lotes para pacing e deliverability), exclusão automática de contatos unsubscribed ou em DND (compliance) e rastreamento de resultados via dashboard de Bulk Actions.
• Prioridade: Alta
• Atores: Gestor de Marketing
• H1: Dado um envio em massa configurado, Quando o usuário escolhe enviar já, agendar ou distribuir em lotes, Então o sistema respeita o pacing e exclui automaticamente contatos com unsubscribe ou DND, E os resultados ficam visíveis no dashboard de Bulk Actions.

Templates (biblioteca e snippets)

RF-MKT-056: SMS templates e text snippets

• Descrição: Templates de SMS (snippets) e trechos reutilizáveis de texto (Text Snippets) para reuso em mensagens, incluindo importação de templates externos (Kajabi Email Template Importer).
• Prioridade: Média
• Atores: Gestor de Marketing, Operador de Company
• H1: Dado mensagens repetitivas, Quando o usuário cria um SMS template ou text snippet, Então pode inseri-lo em mensagens com um clique reaproveitando o texto e os custom fields, E mantém consistência nas comunicações.

RF-MKT-057: Template Library cross-produto

• Descrição: Biblioteca central de templates cross-produto (emails, funnels, workflows, social, ads, webinars) com adicionar template custom, clonar, descrições, categorias, tipos e tags, favoritos, ocultar templates padrão ou individuais, controle de visibilidade e compartilhamento entre agências, gestão a partir da tela de admin e acesso estendido por plano.
• Prioridade: Média
• Atores: Super Admin do vendor, Gestor de Company
• H1: Dado múltiplos tipos de artefato, Quando o usuário abre a Template Library, Então adiciona, clona, categoriza, favorita e controla a visibilidade de templates de email, funnel, workflow, social, ads e webinar num só lugar, E pode compartilhar templates entre agências conforme o plano de acesso.

Trigger Links (evolução do que já temos)

RF-MKT-058: Automação disparada por clique em Trigger Link

• Descrição: Evolução dos Trigger Links já existentes para disparar automação no clique (Trigger Link Clicked), permitindo taggear, segmentar, iniciar sequência ou fazer unsubscribe a partir do clique, inseríveis em SMS, Email, GMB, DM de Facebook e Instagram, e WhatsApp.
• Prioridade: Média
• Atores: Gestor de Marketing
• H1: Dado um Trigger Link inserido em uma mensagem, Quando o contato clica no link, Então o clique é registrado e dispara a automação configurada (tag, segmentação, sequência ou unsubscribe), E o destino do link é aberto normalmente para o contato.
• Notas: Trigger Links já existe parcialmente no ModularCRM (criação de link rastreável). O disparo de automação no clique deixou de ser gap deste RF em 2026-07-15: virou lei no RF-CONV-014, que descreve como o clique ganha dono, e gatilho nomeado no RF-AUTO-002, e quem o entrega é o {AUD-51} do Roadmap de Implementação. O que este RF ainda cobre é o alcance por canal (SMS, GMB, DM de Facebook e Instagram) e as ações de segmentação e descadastro a partir do clique.

11.11 Recursos de Inteligência Artificial (RF-AI)

Inteligência artificial aplicada ao atendimento e à operação, recortada ao que serve a um painel interno: bot de conversa, geração de conteúdo e ações de IA dentro das automações. O custo segue o modelo traga-sua-própria-chave (IA gratuita padrão da Modulareasy, com opção de o cliente ativar IA paga usando a própria chave). IA de voz saiu junto com a telefonia.

IA de Conversa

RF-AI-001: Bot de conversa multicanal

• Descrição: Robô de IA que interpreta mensagens recebidas em vários canais, usa a base de conhecimento treinada e responde ou sugere respostas conforme comportamento, metas e instruções configuradas. É a entidade central do módulo de IA de conversa.
• Prioridade: Alta
• Atores: Administrador da conta, Atendente, Contato (lead)
• H1: Dado que a conta tem um bot de conversa criado e habilitado, Quando um contato envia uma mensagem em um canal atribuído ao bot, Então o bot processa a mensagem com base no que foi treinado e produz uma resposta conforme o modo configurado, E registra a interação na conversa do contato.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-002: Modos de resposta do bot

• Descrição: O bot opera em três modos: Desligado (não responde), Sugestivo (redige rascunho para revisão humana, sem enviar) e Piloto Automático (responde sozinho 24 por 7 com base em treino, configurações e metas).
• Prioridade: Alta
• Atores: Administrador da conta, Atendente
• H1: Dado que um administrador define o modo do bot, Quando o modo é Sugestivo e chega uma mensagem, Então o bot gera um rascunho que fica pendente de revisão humana sem ser enviado, E quando o modo é Piloto Automático a resposta é enviada automaticamente ao contato.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-003: Tipos de agente Primário e Secundário

• Descrição: Cada bot pode ser Primário (atende conversas inbound gerais dos canais atribuídos) ou Secundário (específico de automação, só responde quando invocado por um workflow).
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que existem bots Primário e Secundário na conta, Quando uma mensagem inbound geral chega, Então apenas o bot Primário responde, E o bot Secundário só é acionado quando uma automação o invoca explicitamente.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-004: Métodos de criação do bot

• Descrição: O bot pode ser criado por três métodos: Formulário Guiado (sem prompt, formulário estruturado para captura, agendamento e perguntas frequentes), Baseado em Prompt (templates ou do zero, com escolha de modelo) e Construtor de Fluxo (builder visual com ramificações e caminhos complexos).
• Prioridade: Alta
• Atores: Administrador da conta
• H1: Dado que um administrador vai criar um bot, Quando escolhe um dos três métodos de criação, Então a interface apresenta o fluxo correspondente ao método escolhido, E o bot resultante fica pronto para configuração e ativação.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-005: Canais suportados pelo bot

• Descrição: O bot atende nos canais SMS, Email, Facebook Messenger, Instagram Direct, WhatsApp, Chat Widget e Live Chat, com os canais habilitados por bot nas configurações.
• Prioridade: Alta
• Atores: Administrador da conta, Contato (lead)
• H1: Dado que um administrador habilita canais para um bot, Quando um contato escreve por um canal habilitado, Então o bot atende naquele canal, E ignora canais não habilitados para aquele bot.
• Notas: Depende de provisionar infraestrutura de IA dedicada. Reutiliza os canais de conversa já existentes no módulo de conversas do ModularCRM.

RF-AI-006: Configurações do bot

• Descrição: Painel de configurações do bot com nome, status (Desligado, Sugestivo, Piloto Automático), canais habilitados, mensagem inicial, tempo de espera antes de responder (1 segundo a 5 minutos, para agrupar mensagens), limite máximo de mensagens enviadas (1 a 100, com hibernação ao atingir), resposta a imagens e notas de voz, dormir ao receber mensagem manual ou de workflow, reativação após período configurável, estilo de resposta (Conciso, Equilibrado, Detalhado) e tratamento de anexos.
• Prioridade: Alta
• Atores: Administrador da conta
• H1: Dado que um administrador ajusta as configurações do bot, Quando define o tempo de espera e o limite de mensagens, Então o bot agrupa mensagens dentro da janela de espera antes de responder uma vez com contexto, E hiberna ao atingir o limite máximo até ser reativado conforme a regra configurada.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-007: Base de conhecimento e treino do bot

• Descrição: O bot é treinado a partir de fontes aprovadas: bases de conhecimento, documentos, URLs, perguntas frequentes e informações específicas do negócio. A base de conhecimento é compartilhável entre a IA de conversa, a IA de voz e o Agente de IA de automação.
• Prioridade: Alta
• Atores: Administrador da conta
• H1: Dado que um administrador adiciona documentos, URLs e perguntas frequentes à base de conhecimento, Quando o bot recebe uma pergunta coberta por esse material, Então a resposta é fundamentada no conteúdo treinado, E o bot não busca fontes externas livres fora do material aprovado.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-008: Voz da marca reutilizável

• Descrição: Objeto de Voz da Marca que mantém as respostas alinhadas ao tom, linguagem e estilo preferidos do negócio, reutilizável entre vários bots.
• Prioridade: Média
• Atores: Administrador da conta
• H1: Dado que uma Voz da Marca está definida e associada a um bot, Quando o bot gera qualquer resposta, Então o texto segue o tom e o estilo daquela Voz da Marca, E a mesma Voz da Marca pode ser reaproveitada por outros bots.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-009: Metas do bot

• Descrição: Definição de objetivos que o bot busca cumprir na conversa: guiar agendamento, coletar informações (nome, email, telefone, endereço, cidade e perguntas customizadas com opção de pular se já preenchido), disparar workflows, cancelar ou remarcar compromissos, gerar resumos de conversa após inatividade e notificar por email quando o bot não souber responder.
• Prioridade: Alta
• Atores: Administrador da conta, Contato (lead), Sistema de automação
• H1: Dado que um administrador define metas de coleta e agendamento para o bot, Quando o bot conversa com um contato, Então ele conduz a conversa para cumprir as metas e coleta os campos solicitados, E dispara os workflows e notificações configurados nos objetivos.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-010: Construtor de fluxo com ramificações

• Descrição: Builder visual de fluxo de conversa com ações como parar o bot, transferir para humano, follow-up automático, opções de agendamento e resumo de conversa, além de tom, personalidade, estilo e intenção globais.
• Prioridade: Média
• Atores: Administrador da conta
• H1: Dado que um administrador monta um fluxo com ramificações, Quando a conversa atinge uma condição de ramificação, Então o bot segue o caminho definido e executa a ação daquele nó, E o comportamento respeita o tom e a personalidade globais do fluxo.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-011: Instruções adicionais e guardrails

• Descrição: Campo de instruções adicionais com até 2.000 caracteres para contexto e guardrails, cobrindo casos de borda e garantindo consistência de processo.
• Prioridade: Média
• Atores: Administrador da conta
• H1: Dado que um administrador escreve instruções adicionais no bot, Quando o bot encontra um caso de borda coberto por essas instruções, Então ele responde seguindo o guardrail definido, E respeita o limite de 2.000 caracteres desse campo.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-012: Ciclo de feedback e treino contínuo

• Descrição: Cada resposta do modo Piloto Automático exibe controles de aprovar e reprovar, permitindo dar feedback, adicionar perguntas frequentes e treinar o bot a partir das interações reais.
• Prioridade: Média
• Atores: Administrador da conta, Atendente
• H1: Dado que uma resposta do bot em Piloto Automático foi exibida, Quando um usuário reprova a resposta e adiciona uma pergunta frequente corretiva, Então o item entra na base de treino do bot, E respostas futuras sobre o mesmo tema passam a refletir a correção.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-013: Painel de monitoramento da IA de conversa

• Descrição: Painel com métricas do bot: contatos atendidos, ações disparadas, agendamentos realizados e tempo economizado.
• Prioridade: Média
• Atores: Administrador da conta
• H1: Dado que o bot esteve ativo em um período, Quando um administrador abre o painel de monitoramento, Então vê as métricas de contatos, ações, agendamentos e tempo economizado do período, E consegue acompanhar o desempenho do bot ao longo do tempo.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-014: Transferência para atendimento humano

• Descrição: O bot transfere a conversa para um atendente humano por palavra-chave ou condição definida, em qualquer canal, encerrando a atuação automática naquela conversa.
• Prioridade: Alta
• Atores: Atendente, Contato (lead), Sistema de automação
• H1: Dado que uma condição de transferência para humano é satisfeita durante a conversa, Quando o gatilho é acionado, Então o bot para de responder e a conversa é encaminhada para atendimento humano, E o atendente assume a conversa a partir daquele ponto.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

IA de Conteúdo

RF-AI-015: Geração de texto por IA

• Descrição: Geração de texto por IA para blogs, posts de redes sociais, copy de email, descrição de produto, texto de site e copy de anúncio, a partir de palavras-chave, escolha de tom (do profissional ao descontraído) e comprimento, disponível nos editores de conteúdo do sistema.
• Prioridade: Alta
• Atores: Administrador da conta, Atendente
• H1: Dado que um usuário está em um editor de conteúdo e informa palavras-chave, tom e comprimento, Quando solicita a geração de texto por IA, Então recebe um texto correspondente ao pedido pronto para inserir e editar, E pode regenerar ou ajustar o resultado.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-016: Geração de imagem por IA

• Descrição: Geração de imagem a partir de descrição em linguagem natural, número de variações (1 a 5) e estilo (foto, filme, arte digital, pôster, vetor, colorido, 3D, aquarela, esboço, entre outros), disponível nos editores de posts, funis, sites, email e biblioteca de mídia, com diretrizes de descrição realista e específica.
• Prioridade: Média
• Atores: Administrador da conta, Atendente
• H1: Dado que um usuário informa uma descrição, o número de variações e o estilo, Quando solicita a geração de imagem por IA, Então recebe as variações no estilo escolhido, E pode salvá-las na biblioteca de mídia ou inseri-las no conteúdo em edição.
• Notas: Depende de provisionar infraestrutura de IA dedicada. A geração de imagem exige permissão específica no controle de acesso do usuário.

IA em Automação

RF-AI-017: Ação de IA generativa no workflow

• Descrição: Ação de workflow que envia um prompt a um modelo de linguagem, com variáveis dinâmicas do contato e do evento, temperatura configurável e memória de continuidade, cujo resultado fica referenciável em passos seguintes para gravar em campo customizado, email, SMS ou webhook.
• Prioridade: Alta
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de IA generativa com prompt e variáveis dinâmicas, Quando o contato atinge esse passo, Então o modelo gera o texto e o disponibiliza como variável de saída, E os passos seguintes usam essa saída para gravar em campo, email, SMS ou webhook.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-018: Ação de Agente de IA no workflow

• Descrição: Ação premium que automatiza tarefas de múltiplas etapas a partir de instruções em linguagem natural, com um conjunto de ferramentas (enviar SMS, atualizar campo, adicionar tag, buscar na base de conhecimento, atualizar valor customizado) que o agente decide usar em tempo de execução, memória de conversa por contato, acesso ao histórico entre canais e transcrições, e saída em texto ou JSON com esquema.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de Agente de IA com instruções e ferramentas habilitadas, Quando o contato atinge esse passo, Então o agente decide quais ferramentas usar e em que ordem para cumprir a tarefa, E devolve a saída no formato configurado (texto ou JSON).
• Notas: Depende de provisionar infraestrutura de IA dedicada. É uma ação premium com custo por execução (ver RF de medição de consumo).

RF-AI-019: Ação de decisão por IA no workflow

• Descrição: Ação premium que roteia contatos por ramos de acordo com condições descritas em linguagem natural, com campos de instruções e contexto adicional, variáveis dinâmicas, um ramo padrão de fallback não removível e ramos customizados nomeados.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de decisão por IA com ramos condicionais, Quando o contato atinge esse passo, Então a IA avalia as condições em linguagem natural e encaminha o contato pelo ramo correspondente, E se nenhuma condição for satisfeita o contato segue pelo ramo padrão de fallback.
• Notas: Depende de provisionar infraestrutura de IA dedicada. É uma ação premium com custo por execução.

RF-AI-020: Ação de detecção de intenção por IA

• Descrição: Ação premium que classifica a intenção de uma mensagem em categorias predefinidas para permitir roteamento subsequente na automação.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de detecção de intenção, Quando uma mensagem do contato é avaliada, Então a IA retorna a categoria de intenção identificada, E a automação usa essa categoria para rotear o próximo passo.
• Notas: Depende de provisionar infraestrutura de IA dedicada. É uma ação premium com custo por execução.

RF-AI-021: Ação de resumo por IA

• Descrição: Ação premium que condensa um texto longo em um resumo com comprimento configurável, disponível como saída para os passos seguintes.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de resumo por IA sobre um texto longo, Quando o passo é executado, Então a IA devolve um resumo no comprimento configurado, E o resumo fica referenciável nos passos seguintes.
• Notas: Depende de provisionar infraestrutura de IA dedicada. É uma ação premium com custo por execução.

RF-AI-022: Ação de tradução por IA

• Descrição: Ação premium que traduz um texto entre idiomas dentro da automação.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de tradução por IA, Quando o passo é executado sobre um texto de origem, Então a IA devolve o texto traduzido no idioma de destino, E o resultado fica disponível para os passos seguintes.
• Notas: Depende de provisionar infraestrutura de IA dedicada. É uma ação premium com custo por execução.

RF-AI-023: Ação de extração de dados por IA

• Descrição: Ação que extrai e estrutura informação a partir de texto não estruturado, incluindo o parse de emails, devolvendo os campos estruturados para uso posterior.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação contém uma ação de extração de dados sobre um texto não estruturado, Quando o passo é executado, Então a IA devolve os campos estruturados solicitados, E os passos seguintes usam esses campos, por exemplo para gravar dados de um email recebido.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

RF-AI-024: Ações da IA de conversa no workflow

• Descrição: Ações de automação que usam a IA de conversa como passo, permitindo o envio de múltiplas mensagens em uma única ação e a atualização do bot de conversa e de seu status dentro do fluxo.
• Prioridade: Média
• Atores: Administrador da conta, Sistema de automação
• H1: Dado que uma automação usa a IA de conversa como passo, Quando o contato atinge esse passo, Então o bot gera e envia as mensagens configuradas na ação, E a ação de atualização de bot ajusta o bot e o status conforme definido no fluxo.
• Notas: Depende de provisionar infraestrutura de IA dedicada.

Modelo de provisão e custo da IA (traga sua própria chave)

RF-AI-025: IA gratuita como padrão da plataforma

• Descrição: toda subconta nasce com uma IA gratuita provida pela Modulareasy (modelo padrão bancado pela plataforma), pronta para uso sem configuração e sem custo para o cliente.
• Prioridade: Alta
• Atores: Super Admin (define o provedor padrão), Org Owner/Admin (usa)
• H1: Dado uma subconta nova, Quando o cliente usa um recurso de IA, Então funciona no provedor gratuito padrão sem configurar nada, E sem custo adicional para o cliente.
• Notas: segue o padrão traga-sua-própria-chave já adotado em outros sistemas Modulareasy.

RF-AI-026: Ativação de IA paga com a chave do próprio cliente

• Descrição: no painel, a subconta pode ativar um provedor de IA pago e inserir a própria chave (token); a partir daí a IA daquela subconta usa essa chave, com o custo por conta do cliente.
• Prioridade: Alta
• Atores: Org Owner/Admin
• H1: Dado um cliente que quer um modelo de IA mais forte, Quando ele ativa a IA paga e informa a própria chave no painel, Então a subconta passa a usar essa chave nas funções de IA, E o consumo é cobrado no provedor do cliente, não da Modulareasy.
• Notas: mesmo padrão já adotado em outros sistemas Modulareasy.

RF-AI-027: Isolamento da configuração de IA por subconta

• Descrição: a configuração e a chave de IA de cada subconta ficam isoladas; a chave de um cliente nunca é usada por outro nem fica visível fora da subconta.
• Prioridade: Essencial
• Atores: sistema, Super Admin
• H1: Dado duas subcontas com IA configurada, Quando uma usa IA, Então usa apenas a própria configuração e chave, E a chave fica cifrada e nunca exposta a outra subconta ou em tela.

RF-AI-028: Escolha de provedor e retorno ao gratuito

• Descrição: ao ativar IA paga, o cliente escolhe o provedor e o modelo suportados; se a chave paga falhar ou for removida, a subconta volta a usar a IA gratuita padrão.
• Prioridade: Média
• Atores: Org Owner/Admin, sistema
• H1: Dado uma subconta com IA paga ativa, Quando a chave fica inválida ou é removida, Então a IA volta a funcionar no provedor gratuito padrão, E o cliente é avisado.

RF-AI-029: Permissão para configurar a IA

• Descrição: só papéis autorizados na subconta podem ativar IA paga, trocar chave ou provedor.
• Prioridade: Média
• Atores: Org Owner/Admin
• H1: Dado um operador sem permissão, Quando ele tenta alterar a configuração de IA, Então a ação é bloqueada, E fica registrada para auditoria.

11.12 Reputação e presença online (RF-REPU)

Módulo totalmente novo no ModularCRM (hoje não existe nenhuma gestão de reputação nem de listings). Cobre coleta e monitoramento de avaliações Google/Facebook, IA de resposta e sentimento, painel de reputação, widgets embeddáveis, gestão de diretórios locais (listings), análise de concorrentes, depoimentos em vídeo e otimização de perfil Google. Duas grandes dependências externas atravessam o módulo: reviews dependem das APIs Google Business Profile e Meta/Facebook Graph, e listings dependem de um motor terceiro (Yext ou Uberall).

Solicitação de avaliações multicanal (RF-REPU-001 a RF-REPU-011)

RF-REPU-001: Envio manual de pedido de avaliação

• Descrição: Permitir que o operador dispare um pedido de avaliação para um contato de três formas: por ação rápida no topo da interface, pela aba dedicada de Pedidos dentro de Reputação, e por ação de automação.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado um contato válido com telefone ou email, Quando o operador clica em Enviar pedido de avaliação, Então o pedido é criado e enfileirado para envio, E o operador que disparou fica registrado como remetente quando o contato não tem usuário atribuído.
• Notas: Requer Google Business Profile conectado ou um link de avaliação de terceiro configurado (dependência externa Google Business Profile).

RF-REPU-002: Pré-requisitos e habilitação de pedidos de avaliação

• Descrição: Antes de permitir envio de pedidos, o sistema exige que a conta tenha o perfil Google Business Profile conectado à localização correta e a funcionalidade de pedidos habilitada nas configurações.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado que o Google Business Profile não está conectado à localização, Quando o operador tenta habilitar ou enviar pedidos de avaliação, Então o sistema bloqueia o envio e informa qual pré-requisito falta, E oferece o caminho para conectar a conta.
• Notas: Dependência externa da API Google Business Profile (OAuth por localização).

RF-REPU-003: Canais de envio do pedido (SMS, Email, WhatsApp)

• Descrição: Suportar disparo do pedido de avaliação pelos canais SMS, Email e WhatsApp, respeitando o canal escolhido e a disponibilidade de contato do destinatário.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado um pedido de avaliação com canal selecionado, Quando o operador confirma o envio, Então o sistema envia pelo canal escolhido (SMS via telefonia, Email ou WhatsApp), E registra o canal usado no histórico do pedido.
• Notas: SMS e WhatsApp dependem dos provedores de telefonia e da API do WhatsApp já usados no ModularCRM.

RF-REPU-004: Rastreio de status de cada pedido

• Descrição: Cada pedido de avaliação enviado deve exibir seu estado de entrega ao longo do ciclo de vida com os estados na fila, enviado, entregue e falhou.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado um pedido de avaliação enviado, Quando o provedor retorna eventos de entrega, Então o sistema atualiza o status do pedido para na fila, enviado, entregue ou falhou, E o estado entregue só é exibido para SMS confirmado pelo provedor de telefonia.
• Notas: O evento de entrega confirmada é limitado ao SMS.

RF-REPU-005: Templates de mensagem por canal com campos dinâmicos

• Descrição: Permitir editar templates de pedido de avaliação separadamente por canal (Email e SMS) e usar campos dinâmicos como nome do cliente, serviço, data e localização.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado um template de pedido com campos dinâmicos, Quando o pedido é montado para um contato específico, Então o sistema substitui cada campo dinâmico pelo valor real do contato, E envia a mensagem personalizada sem deixar marcadores não resolvidos.

RF-REPU-006: Remetente conforme usuário atribuído ao contato

• Descrição: Quando o contato tem um usuário atribuído, o pedido de avaliação deve sair em nome desse usuário atribuído, e não do usuário que apenas disparou a ação.
• Prioridade: Média
• Atores: Team Manager, Workforce
• H1: Dado um contato com usuário atribuído, Quando qualquer operador dispara o pedido de avaliação, Então o sistema envia o pedido em nome do usuário atribuído ao contato, E usa o remetente que disparou apenas quando não há usuário atribuído.

RF-REPU-007: Múltiplos links de avaliação em um único email

• Descrição: Elemento de email que insere vários links de plataformas de avaliação em um único template, puxando automaticamente as plataformas conectadas, com customização de texto de chamada por plataforma, reordenação por arrastar e soltar, e mostrar ou esconder plataformas.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado um email de pedido com o elemento de links de avaliação, Quando o operador configura as plataformas, Então o sistema exibe cada plataforma conectada com texto de chamada editável e ordem definida por arrastar e soltar, E permite esconder uma plataforma sem desconectar a integração.
• Notas: Inclui seleção da localização Google Business Profile específica quando há várias e validação automática de URLs malformadas antes do envio. Reutilizável em pedido único, emails recorrentes e ação de automação.

RF-REPU-008: Geração e rastreio de QR Code de avaliação

• Descrição: Gerar QR Codes que apontam para a página de avaliação de uma plataforma específica, com customização de logo, imagens e texto, e rastrear em tempo real o total de leituras.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma página de avaliação selecionada, Quando o operador cria um QR Code, Então o sistema gera um QR único apontando para a plataforma escolhida com a customização visual definida, E contabiliza em tempo real quantas leituras o QR recebeu.
• Notas: Uso físico em balcão, recibos digitais e material impresso.

RF-REPU-009: Balanceamento de pedidos entre plataformas

• Descrição: Distribuir os pedidos de avaliação entre as várias plataformas conectadas para evitar concentrar todos em uma única plataforma.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado múltiplas plataformas de avaliação conectadas, Quando o sistema dispara pedidos em volume, Então distribui os pedidos entre as plataformas segundo a regra de balanceamento, E evita concentrar todos os pedidos em uma só plataforma.

RF-REPU-010: Emails recorrentes com rotação de templates

• Descrição: Permitir configurar envio de emails de pedido de avaliação de forma recorrente usando múltiplos templates, com rotação de conteúdo entre os envios.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado um envio recorrente configurado com vários templates, Quando cada ciclo de envio ocorre, Então o sistema seleciona um template segundo a rotação definida, E envia conteúdo variado ao longo dos ciclos recorrentes.

RF-REPU-011: Ação de automação Enviar pedido de avaliação

• Descrição: Disponibilizar uma ação dentro do construtor de automações que envia pedido de avaliação, com escolha de canal, nome de ação customizável e template vindo das configurações de Reputação.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado uma automação com a ação de enviar pedido de avaliação configurada, Quando um contato atinge essa etapa (por exemplo após um atendimento concluído), Então o sistema envia o pedido pelo canal configurado usando o template das configurações, E envia em nome do usuário atribuído quando houver.

Monitorar e responder avaliações Google e Facebook (RF-REPU-012 a RF-REPU-017)

RF-REPU-012: Ingestão e listagem de avaliações Google e Facebook

• Descrição: Conectar as contas Google Business Profile e Facebook via autorização e trazer as avaliações recebidas para uma lista unificada dentro de Reputação.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado as contas Google e Facebook conectadas por autorização, Quando novas avaliações são publicadas nessas plataformas, Então o sistema ingere e lista essas avaliações em um só lugar com plataforma de origem identificada, E mantém a lista atualizada com as novas avaliações.
• Notas: Dependência externa das APIs Google Business Profile e Meta/Facebook Graph (OAuth, quotas e endpoints de leitura de reviews).

RF-REPU-013: Responder avaliações com publicação de volta na plataforma

• Descrição: Permitir responder avaliações Google e Facebook diretamente na lista, publicando a resposta de volta na plataforma de origem.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado uma avaliação recebida na lista, Quando o operador escreve e confirma a resposta, Então o sistema publica a resposta na plataforma de origem via API, E reflete a resposta publicada na própria avaliação dentro do sistema.
• Notas: Dependência externa dos endpoints de resposta a review do Google Business Profile e Meta/Facebook Graph.

RF-REPU-014: Filtrar avaliações

• Descrição: Filtrar a lista de avaliações por plataforma de origem, por nota em estrelas e por outros critérios relevantes.
• Prioridade: Média
• Atores: Team Manager, Workforce
• H1: Dado a lista de avaliações, Quando o operador aplica filtros por plataforma ou por nota, Então o sistema exibe apenas as avaliações que atendem aos filtros, E mantém a contagem coerente com o filtro aplicado.

RF-REPU-015: Disputar avaliação do Google e acompanhar status

• Descrição: Reportar ao Google uma avaliação considerada inapropriada a partir do CRM e acompanhar o status da disputa por link dedicado.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma avaliação do Google na conversa do contato, Quando o operador aciona disputar esta avaliação, Então o sistema envia a denúncia ao Google e disponibiliza o acompanhamento do status, E informa a limitação de que contas com muitas localizações podem não conseguir usar o recurso.
• Notas: Dependência externa da API Google Business Profile; ao ser aceita, o Google pode remover a avaliação ou banir o autor.

RF-REPU-016: Detecção de avaliações de spam

• Descrição: Identificar avaliações com características de spam e sinalizá-las para tratamento pelo operador.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma avaliação recém ingerida, Quando o sistema detecta padrão de spam, Então marca a avaliação como possível spam para revisão, E permite ao operador tratá-la de acordo.

RF-REPU-017: Integração de múltiplas plataformas de avaliação

• Descrição: Conectar e monitorar mais de uma plataforma de avaliação em um só painel, além de Google e Facebook.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado várias plataformas de avaliação disponíveis para conexão, Quando o operador conecta plataformas adicionais, Então o sistema centraliza o monitoramento das avaliações dessas plataformas no mesmo painel, E identifica a origem de cada avaliação.
• Notas: Cada plataforma adicional depende da respectiva API externa.

IA de avaliações (RF-REPU-018 a RF-REPU-022)

RF-REPU-018: IA sugestiva de resposta a avaliação

• Descrição: Botão de resposta por IA que gera uma resposta personalizada com base no conteúdo da avaliação, para o operador revisar, editar e aprovar antes de publicar.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado uma avaliação recebida, Quando o operador clica em resposta por IA, Então o sistema gera uma sugestão de resposta baseada no texto da avaliação, E permite editar e aprovar antes de publicar na plataforma.
• Notas: Custeio por regenerações conforme RF-REPU-021.

RF-REPU-019: IA em piloto automático de resposta a avaliação

• Descrição: Modo que responde avaliações automaticamente segundo critérios pré-definidos, customizável por nota em estrelas, tempo de espera antes de responder, rodapé de resposta e fonte da avaliação.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado o piloto automático habilitado com critérios definidos, Quando uma nova avaliação chega, Então o sistema gera e publica a resposta automaticamente respeitando a nota, o tempo de espera, o rodapé e a fonte configurados, E aplica respostas diferentes para Google e Facebook conforme configurado.

RF-REPU-020: Habilitação e revenda da IA de avaliações por conta

• Descrição: Habilitar a IA de avaliações no nível da empresa para todas as contas ou seletivamente por conta, com possibilidade de revenda com margem aos clientes.
• Prioridade: Média
• Atores: Team Manager (super admin), Team Manager
• H1: Dado a IA de avaliações disponível, Quando o administrador habilita no nível da empresa ou seletivamente por conta, Então o sistema aplica a habilitação no escopo escolhido, E permite configurar margem de revenda ao cliente final.

RF-REPU-021: Cobrança por resposta gerada pela IA

• Descrição: Contabilizar e cobrar as respostas geradas pela IA segundo a política de gerações gratuitas e pagas.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado a IA de avaliações em uso, Quando o operador gera respostas para uma mesma avaliação, Então o sistema aplica a política de gerações gratuitas e cobradas por resposta, E registra o custo para faturamento.
• Notas: Regra herdada do GHL, algumas gerações gratuitas e as demais com custo unitário por resposta; valores exatos a definir na precificação Modulareasy.

RF-REPU-022: Resumo e sentimento de avaliações por IA

• Descrição: Analisar as avaliações de todas as plataformas conectadas e produzir um parágrafo de sentimento geral, temas comuns e marcadores de destaque, exibido em cartão dedicado.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado avaliações de várias plataformas conectadas, Quando o operador abre o cartão de resumo por IA, Então o sistema apresenta um resumo conciso do sentimento geral com temas comuns e marcadores de destaque, E permite filtrar por localização ou página e por intervalo de datas e atualizar manualmente.
• Notas: O cartão aparece na visão geral e na lista de avaliações; atualiza automaticamente quando chegam novas avaliações. Útil para alto volume e multi localização.

Painel de reputação e sentimento (RF-REPU-023 a RF-REPU-027)

RF-REPU-023: Indicadores do painel de reputação

• Descrição: Painel de visão geral com metas de convites, avaliações recebidas no período, nota média e análise de sentimento.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado avaliações e pedidos registrados, Quando o operador abre a visão geral de Reputação, Então o sistema exibe metas de convites, avaliações recebidas, nota média e sentimento do período, E permite filtrar cada seção por período.
• Notas: A nota média considera total de avaliações e de estrelas; o sentimento usa classificação automática positivo e negativo.

RF-REPU-024: Gráficos de tendências de convites e avaliações

• Descrição: Gráficos de tendência de convites enviados (SMS e Email) e de avaliações recebidas mês a mês.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado histórico de pedidos e avaliações, Quando o operador abre os gráficos de tendência, Então o sistema exibe a tendência de convites enviados e a de avaliações recebidas ao longo do tempo, E respeita o período filtrado.

RF-REPU-025: Seções complementares da visão geral

• Descrição: Seções de últimos pedidos de avaliação, últimas avaliações recebidas e status da integração de listings quando habilitada.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado a visão geral de Reputação, Quando o operador a consulta, Então o sistema exibe os últimos pedidos com destinatário, canal e data, as últimas avaliações com contato e plataforma, e o status da integração de listings quando habilitada.

RF-REPU-026: Gatilho de automação Avaliação recebida

• Descrição: Gatilho de automação disparado quando uma nova avaliação Google ou Facebook chega, com filtros por plataforma e por nota, mapeando os detalhes da avaliação para ações seguintes.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado uma automação com o gatilho de avaliação recebida, Quando uma nova avaliação chega, Então a automação dispara respeitando os filtros de plataforma e de nota, E disponibiliza os detalhes da avaliação para as ações seguintes.
• Notas: A avaliação não é vinculada a um contato específico (sem contato associado). Exemplo, nota alta gera email de agradecimento e nota baixa gera alerta interno.

RF-REPU-027: Metas incrementais de convites

• Descrição: Metas de convites pré-definidas e não editáveis que sobem conforme a conta atinge marcos.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado o volume de convites enviados, Quando a conta atinge um marco de meta, Então o sistema avança automaticamente para a próxima meta incremental, E exibe o progresso na visão geral.

Widget de avaliações (RF-REPU-028 a RF-REPU-031)

RF-REPU-028: Construtor de widget de avaliações

• Descrição: Construtor de widgets de avaliação para embutir no site do cliente, com templates prontos e vários tipos de layout como lista, grade, alvenaria, carrossel, deslizante, selo flutuante e legados.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado o construtor de widgets, Quando o operador escolhe um tipo e configura o widget, Então o sistema monta o widget no layout escolhido, E gera um código de incorporação para colar em qualquer site.

RF-REPU-029: Configuração de fontes, conteúdo e filtros do widget

• Descrição: Configurar fontes de avaliação (Google e Facebook), tipo e posição do resumo por IA, número máximo de avaliações, nota mínima exibida, título, descrição, botão de escrever avaliação e visibilidade de elementos.
• Prioridade: Média
• Atores: Team Manager, Workforce
• H1: Dado um widget em edição, Quando o operador ajusta fontes, resumo, número máximo, nota mínima e conteúdo, Então o sistema exibe apenas as avaliações que atendem à nota mínima e às fontes escolhidas, E aplica título, descrição, botão de escrever avaliação e demais elementos conforme configurado.
• Notas: Inclui opção de excluir avaliações sem texto.

RF-REPU-030: Aparência e atualização do widget após incorporado

• Descrição: Configurar tema claro, escuro ou personalizado, fonte tipográfica e cores individuais, com as mudanças propagando ao widget já incorporado após salvar.
• Prioridade: Média
• Atores: Team Manager, Workforce
• H1: Dado um widget já incorporado em um site, Quando o operador altera tema, fonte ou cores e salva, Então o sistema propaga as mudanças ao widget publicado sem exigir nova incorporação, E preserva o código de incorporação existente.

RF-REPU-031: Widget com depoimentos em vídeo

• Descrição: Exibir depoimentos em vídeo no widget de avaliações, filtrando por coletor de origem e permitindo variações de layout.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado depoimentos em vídeo coletados, Quando o operador configura o widget para exibi-los filtrando por coletor, Então o sistema mostra os vídeos do coletor selecionado no layout escolhido, E os integra à exibição de avaliações do widget.

Gestão de listings e diretórios (RF-REPU-032 a RF-REPU-044)

RF-REPU-032: Motor de listings integrado a provedor externo

• Descrição: Sincronizar as informações do negócio em diretórios locais (Google, Bing, Yelp, Apple Maps, Facebook e outros) por meio de um motor externo (Yext ou Uberall).
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado um negócio com dados cadastrados, Quando o operador publica as listings, Então o sistema envia os dados ao motor externo que os distribui aos diretórios suportados, E reflete o estado da publicação para o operador.
• Notas: Dependência externa forte de motor terceiro pago (Yext ou Uberall); replicar sem esse contrato é inviável.

RF-REPU-033: Seleção da engine no nível da agência com white-label

• Descrição: A escolha entre Yext e Uberall é feita no nível da agência e herdada por todas as contas, que sempre veem a versão white-label sem o nome da engine.
• Prioridade: Alta
• Atores: Team Manager (super admin)
• H1: Dado a escolha de engine no nível da agência, Quando uma conta acessa listings, Então o sistema aplica a engine escolhida de forma herdada, E apresenta sempre a versão white-label sem expor o nome do provedor.
• Notas: Uberall tem cobertura global e supressão de duplicados forte; Yext tem compliance específico e é o único com analytics de listings.

RF-REPU-034: Modelo de dados de entidade e NAP

• Descrição: Cadastrar por entidade os dados do negócio incluindo nome, endereço validado, telefone, email, horário de funcionamento, categorias, serviços, perfis sociais, fotos e atributos adicionais.
• Prioridade: Alta
• Atores: Team Manager, Workforce
• H1: Dado uma entidade de listing, Quando o operador preenche os dados do negócio, Então o sistema valida o endereço e armazena nome, telefone, horário, categorias, serviços, perfis sociais, fotos e atributos, E mantém a consistência de nome, endereço e telefone para o SEO local.
• Notas: Atributos adicionais incluem verticais específicas como alimentação e saúde.

RF-REPU-035: Sincronização e forçar sincronização

• Descrição: Enviar as atualizações aos diretórios com propagação típica de 24 a 72 horas e oferecer um recurso de forçar sincronização que prioriza a publicação da última versão sem esperar o ciclo de rotina.
• Prioridade: Alta
• Atores: Team Manager
• H1: Dado dados de entidade atualizados, Quando o operador salva as mudanças, Então o sistema envia as atualizações aos diretórios respeitando a janela de propagação, E permite forçar a sincronização para priorizar a publicação imediata da última versão.
• Notas: Dependência externa; a janela de propagação é determinada pelos diretórios e pelo motor.

RF-REPU-036: Sugestões de publishers com aprovação manual

• Descrição: Receber edições sugeridas pelos publishers (Google, Facebook, Yelp) para nome, horário, endereço e telefone, exibindo valor sugerido e atual lado a lado, com aceitar aplicando e sincronizando ou rejeitar removendo da fila.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma sugestão de publisher para um campo da entidade, Quando o operador compara o valor sugerido com o atual, Então pode aceitar aplicando e sincronizando em todos os publishers ou rejeitar removendo da fila, E o sistema nunca aplica sugestões automaticamente.

RF-REPU-037: Alertas de informação faltante dispensáveis

• Descrição: Sinalizar campos faltantes no perfil da entidade por meio de alertas que o operador pode dispensar.
• Prioridade: Média
• Atores: Team Manager, Workforce
• H1: Dado um perfil de entidade com campos faltantes, Quando o operador visualiza o perfil, Então o sistema exibe alertas de informação faltante, E permite dispensar cada alerta.

RF-REPU-038: Gestão multi localização em uma conta

• Descrição: Gerenciar várias listings dentro de uma mesma conta, com detalhes primários compartilhados e atributos únicos por localização, incluindo operações em massa com pré-visualização antes de confirmar.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma conta com várias localizações, Quando o operador aplica uma operação em massa (endereços, nichos, serviços), Então o sistema exibe uma pré-visualização das mudanças antes de confirmar, E aplica os dados por localização mantendo NAP correto em cada uma.
• Notas: Inclui painel unificado de todas as listings com métricas por localização.

RF-REPU-039: Painel de analytics de listings

• Descrição: Painel de métricas de listings com impressões, ações (cliques, ligações, pedidos de rota), visualizações de perfil e uso por dispositivo, com detalhamento por diretório e filtro por período.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado listings publicadas com a engine que oferece analytics, Quando o operador abre o painel de analytics, Então o sistema exibe impressões, ações, visualizações de perfil e uso por dispositivo detalhados por diretório, E filtra por período.
• Notas: Disponível apenas para a engine Yext; Uberall não oferece analytics (dependência externa).

RF-REPU-040: Relatórios de analytics white-label e agendados

• Descrição: Gerar relatórios de desempenho das listings com a marca da agência e permitir agendar o envio automático desses relatórios.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado analytics de listings disponíveis, Quando o operador configura um relatório com a marca da agência e uma agenda, Então o sistema gera o relatório white-label, E o envia automaticamente na periodicidade agendada.
• Notas: Depende da disponibilidade de analytics da engine Yext.

RF-REPU-041: Histórico e auditoria da entidade

• Descrição: Manter o histórico de mudanças de cada entidade de listing com registro de auditoria.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma entidade de listing, Quando seus dados são alterados, Então o sistema registra a mudança no histórico de auditoria com autor e momento, E permite consultar o histórico da entidade.

RF-REPU-042: Conexão de Google Business Profile e Facebook no listings

• Descrição: Conectar o Google Business Profile e a página do Facebook diretamente do módulo de listings, reutilizando token já conectado no planejador social, com um perfil Google e uma página Facebook por localização.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma localização em listings, Quando o operador conecta o Google Business Profile e a página do Facebook, Então o sistema estabelece a conexão reutilizando o token existente quando houver e exibe o estado conectado, E sincroniza horário, endereço, fotos, avaliações e detalhes da localização.
• Notas: Requer papel de administrador nas contas externas; remover a conexão dispara sincronização imediata e sinaliza ação necessária. Dependência externa Google e Meta.

RF-REPU-043: Cobertura de países e diretórios

• Descrição: Suportar a publicação de listings em múltiplos países com quantidade de diretórios variável por mercado, avisando quando a região não é suportada.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado uma localização em um país suportado, Quando o operador contrata listings, Então o sistema publica nos diretórios disponíveis para aquele mercado, E quando a região não é suportada exibe aviso e desabilita a contratação.
• Notas: Cobertura e contagem de diretórios são determinadas pelo motor externo (por exemplo Brasil com dezenas de diretórios).

RF-REPU-044: Revenda e onboarding de listings

• Descrição: Revender listings com margem por meio do faturamento em duas camadas, com planos por período (mensal, semestral e anual), deploy sem cobrar o cliente diretamente, onboarding self-service e cancelamento com resolução de estados do provedor.
• Prioridade: Média
• Atores: Team Manager (super admin)
• H1: Dado a oferta de listings configurada, Quando a agência vende para uma conta, Então o sistema aplica o plano por período escolhido no faturamento em duas camadas, E permite deploy sem cobrança direta, onboarding self-service e cancelamento tratando os estados de cancelado ou duplicado do provedor.
• Notas: Precificação e integração de pagamento a definir na esteira Modulareasy; estados de cancelamento dependem do provedor externo.

Análise de concorrentes (RF-REPU-045)

RF-REPU-045: Análise comparativa de concorrentes de reputação

• Descrição: Comparar a reputação do negócio com até três concorrentes usando fontes como Google, Facebook, Yelp e TripAdvisor, com nota, volume de avaliações, tendências e tempo de resposta lado a lado, atualização automática e insights exportáveis.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado até três concorrentes cadastrados, Quando o operador abre a análise de concorrentes, Então o sistema busca automaticamente e exibe nota, volume, tendências e tempo de resposta lado a lado por fonte, E destaca lacunas de desempenho e oportunidades em insights exportáveis para relatório do cliente.
• Notas: Coleta depende de fontes externas de avaliação com atualização periódica.

Depoimentos em vídeo (RF-REPU-046 a RF-REPU-047)

RF-REPU-046: Coletores de depoimento em vídeo branded

• Descrição: Coletores de vídeo com marca própria, sem aplicativo, onde o cliente grava ou envia vídeo por desktop ou mobile, com customização de logo, cores, imagem do porta-voz e mensagem, até três perguntas e limite de duração.
• Prioridade: Média
• Atores: Team Manager, contact
• H1: Dado um coletor de depoimento configurado, Quando o cliente acessa o link e grava ou envia um vídeo respondendo às perguntas, Então o sistema recebe o vídeo respeitando o limite de duração, E aplica a identidade visual configurada no coletor.
• Notas: Limite de duração por vídeo conforme padrão do GHL (dois minutos e meio); até três perguntas por coletor.

RF-REPU-047: Distribuição e gestão de depoimentos em vídeo

• Descrição: Distribuir o coletor por link, Email, SMS e WhatsApp, e revisar, gerenciar e baixar os vídeos recebidos em uma seção de respostas, com publicação no site via widget.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado um coletor de depoimentos, Quando o operador o distribui por link ou pelos canais Email, SMS e WhatsApp, Então os vídeos recebidos aparecem na seção de respostas para revisão e download, E podem ser publicados no site pelo widget de avaliações.

Otimização de perfil Google (RF-REPU-048 a RF-REPU-050)

RF-REPU-048: Otimização do perfil Google Business Profile

• Descrição: Otimizar os campos do Google Business Profile diretamente no sistema, como categorias, serviços e informações do perfil.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado um Google Business Profile conectado, Quando o operador edita categorias, serviços e informações do perfil no sistema, Então o sistema aplica as mudanças ao perfil Google via API, E reflete o estado atualizado do perfil.
• Notas: Dependência externa da API Google Business Profile.

RF-REPU-049: Agendador de posts no Google Business Profile

• Descrição: Agendar publicações de posts no Google Business Profile a partir do sistema.
• Prioridade: Média
• Atores: Team Manager, Workforce
• H1: Dado um Google Business Profile conectado, Quando o operador agenda um post com data e conteúdo, Então o sistema publica o post no perfil Google no horário agendado, E registra o status da publicação.
• Notas: Dependência externa da API Google Business Profile.

RF-REPU-050: Rastreio de chamadas e resposta a chamada perdida via Google Business Profile

• Descrição: Rastrear chamadas originadas do perfil Google e enviar automaticamente uma mensagem de texto em caso de chamada perdida.
• Prioridade: Média
• Atores: Team Manager
• H1: Dado o rastreio de chamadas ativado no Google Business Profile, Quando uma chamada é perdida, Então o sistema registra a chamada rastreada e envia automaticamente uma mensagem de texto de retorno ao contato, E deixa o registro disponível no histórico.
• Notas: Dependência externa da API Google Business Profile e do provedor de telefonia/SMS.

Apêndices

Apêndice A, Catálogo de campos personalizados padrão. Referência dos campos personalizados de base que uma empresa recebe ao ser criada (dados de identificação, endereço, empresa, fuso), espelhando o conjunto padrão do GHL. Ficha completa no Inventário de Artefatos.

Apêndice B, Matriz de canais por provedor. Referência de quais canais existem e por qual provedor operam (WhatsApp por Evolution ou Meta Cloud, Messenger e Instagram pela Meta, e-mail por IMAP/SMTP, SMS por Twilio, webchat por widget próprio). Ficha completa no Inventário de Artefatos.

Apêndice C, Estrutura de navegação em paridade com o GHL. Mapa da barra da agência e da barra da subconta, base do RF-UX-001.