O que precisamos entender da operação de vocês

A leitura disso é que vocês registram o trabalho, e registram bem — o histórico de cada negócio está escrito ali. O que não acontece é marcar o campo de situação depois.

O que precisamos confirmar

• É isso mesmo? O feedback escrito é onde tudo mora, e o status não é usado?
• Existe outro lugar onde o fechamento fica registrado de forma estruturada — planilha, sistema da seguradora, controle à parte?
• Se marcar "Ganhar" ou "Perder" na oportunidade passasse a fazer parte da rotina, isso seria viável para a equipe? É um clique a mais por negócio.

Por que insistimos nisso

Um número confiável precisa vir de um campo, não de interpretação de texto. Dá para contar quantos feedbacks dizem "fechado", mas "vamos fechar semana que vem", "não fechou" e "fechado" contam igual. Um painel que apresentasse isso como taxa de conversão estaria errando com aparência de precisão, que é o pior tipo de erro num relatório.

O que já dá para fazer de qualquer jeito

Mesmo sem status, os feedbacks sustentam informação útil: quando foi a última interação de cada contato, há quantos dias um negócio está parado, e quanto cada vendedor registrou no período. Isso o painel consegue mostrar com precisão. O que depende da resposta é conversão e venda.

O que precisamos

• O endereço da conta de vocês, no formato https://______.callix.com.br
• Um token de API, criado em Configurações > APIs > Acesso às APIs > Criar Token
• A documentação que fica em Configurações > APIs > Documentação — exportada em PDF, ou um acesso para consultarmos

Por que a documentação, e não só o token

Diferente do NectarCRM, o Callix não publica a referência da API em lugar nenhum. Ela só existe dentro da conta de cada cliente. Sem ela não há como saber quais endereços chamar, como uma ligação é representada, qual campo identifica o operador, nem como o contato aparece do lado de lá.

O que está parado esperando isso

O módulo Discador inteiro: volume de ligações, produtividade por operador, resultado das chamadas, campanhas. E também o cruzamento entre os dois sistemas — saber que o contato para quem o discador ligou é o mesmo lead que está no CRM.

Adiantamos o que foi possível: como 100% dos contatos do Nectar têm telefone, o telefone já está padronizado no nosso banco para servir de chave desse cruzamento assim que o Callix entrar.

O que precisamos

A lista de quem vai acessar o painel, com nome, e-mail e papel. E, para cada pessoa, qual usuário do Nectar corresponde a ela.

Por que isso importa

Essa separação não é só de tela: está no banco de dados. Um vendedor logado não consegue puxar a carteira de outro nem tentando, porque a regra é aplicada antes da consulta chegar. Isso já foi testado.

Mas ela depende de saber quem é quem. Enquanto uma pessoa não estiver vinculada ao vendedor correspondente no Nectar, ela simplesmente não vê carteira nenhuma — que é o comportamento seguro, e não o útil.

Também ajuda saber

Dos 13 usuários do Nectar, quais são de fato vendedores e quais são administrativo ou marketing? E quem responde pela equipe?

O que nos chamou atenção

A esmagadora maioria está em "suspect", e só 22 contatos estão marcados como "lead". Isso sugere que o estágio não é atualizado conforme o contato avança, ou que vocês usam esses nomes com um sentido diferente do padrão do Nectar.

O que queremos entender

Quando um contato entra, ele nasce como quê? O que faz ele mudar de estágio — alguém troca na mão, ou é automático? E o que vocês chamam de "lead" no dia a dia corresponde a qual desses?

Por que importa

É o que define o que o painel chama de lead e como o funil é desenhado. Se hoje mostrássemos "22 leads" no painel, estaria tecnicamente correto e seria completamente inútil para quem olha.

O que queremos entender

Vocês sabem de onde vem cada lead — Instagram, Google, indicação, site, lista fria? Isso fica registrado em algum lugar, mesmo que fora do CRM? E existe disposição de passar a preencher esse campo?

Por que importa, e esse é o ponto principal

Sem origem por canal, o painel não consegue dizer qual canal traz mais lead, qual traz lead melhor, nem qual traz cliente.

E, mais adiante, é exatamente aqui que o módulo de tráfego pago se conecta. A conta que interessa é esta: investi tanto no Meta → vieram tantos leads → viraram tantos clientes → deu tanto de receita. Essa cadeia inteira se apoia no campo de origem. Sem ele preenchido, o módulo mostra quanto foi gasto e não consegue ligar isso a venda nenhuma.

O banco já está preparado para receber essa informação. O que falta é processo, não programação.

Encontramos estes funis, com as etapas exatamente nesta ordem:

O que queremos entender

• "Administrativo" parece pós-venda, não venda. Ele deve entrar na conta do funil comercial?
• Existe um funil chamado "Moriah" com 2 oportunidades que a API não lista — provavelmente foi desativado. Podemos ignorar?
• Nenhum dos funis tem etapa de "fechado" ou "ganho". Depois de "Reunião Realizada", o que acontece? — conecta com a P1.

Por que importa

Define quais oportunidades entram no funil comercial do painel. Misturar pós-venda com venda distorce qualquer leitura.

O que queremos entender

Esse valor mensal é o prêmio que o cliente paga ou a comissão que a Moriah recebe? Existe diferença entre o valor mensal e o valor total — o total é o mensal vezes doze, ou outra coisa?

E como vocês acompanham número de vidas? Fica em algum campo do CRM ou fora dele?

Por que importa

Muda o rótulo e a leitura de tudo que envolve dinheiro no painel. Chamar comissão de receita, ou o contrário, faz o gestor tomar decisão com base num número que entendeu errado.

O que queremos entender

• O que significam as 4 opções de "Classificação"? Serve para priorizar atendimento?
• "Categoria Atual" e "Seguradora Atual" são do plano que o cliente tem hoje, antes de migrar?
• Algum desses deveria virar filtro ou coluna no painel?

Uma decisão que já tomamos, e queremos confirmada

O CPF não está sendo copiado para o nosso banco. Ele existe no CRM de vocês e continua lá, intacto — apenas não entra no painel.

O motivo é o princípio de minimização da LGPD: dado pessoal sensível que nenhuma tela usa não deve ser duplicado, porque cada cópia é mais uma superfície para vazar. Se em algum momento o painel precisar do CPF para alguma coisa, reavaliamos — mas aí com um motivo declarado.

O que queremos entender

Existe meta hoje? Se sim, é por vendedor, por equipe ou da corretora inteira? É mensal? E medida em quê — número de contratos, de vidas, valor de prêmio, valor de comissão?

Por que importa

Meta é a única informação do painel que não vem de sistema nenhum — nem do Nectar, nem do Callix. Alguém precisa cadastrar. Então precisamos saber a unidade e a periodicidade para construir o cadastro certo, e quem tem permissão de definir.

Se não houver meta formalizada hoje, isso também é uma resposta válida: a tela continua como está até existir.

O que queremos entender

• Essas tarefas de ligação são criadas à mão, como lembrete de ligar?
• O Callix registra alguma coisa de volta no Nectar quando a ligação acontece, ou os dois sistemas não se falam hoje?
• Depois de ligar, alguém marca a tarefa como feita?

Por que importa

Se os dois sistemas já se falam, parte do trabalho de integração do Discador já existe e mudamos a abordagem. Se não se falam, é justamente o que o painel vai unir — e aí o valor de juntar os dois fica maior, porque hoje ninguém consegue cruzar "liguei" com "virou negócio".

O que queremos entender

"Vitória" é cidade, campanha, responsável, lote de importação, ou outra coisa? Existem outras etiquetas em uso? E elas são mantidas atualizadas ou ficaram de uma importação antiga?

Por que importa

Se essas etiquetas separam grupos que fazem sentido para vocês, elas viram filtro no painel — e possivelmente são a informação mais útil que existe hoje para segmentar a base, dado que o campo de origem está quase vazio (ver P5).

O que queremos entender

O painel é para olhar de manhã e ter a foto do dia, ou alguém vai usá-lo durante o atendimento e precisa ver o lead que entrou há cinco minutos?

Por que importa

Muda como a sincronização é feita. De hora em hora é simples e barato. Quase em tempo real exige que o Nectar avise a cada mudança, o que é possível mas é mais peça para manter.

Há um limite prático: a API do Nectar bloqueia quando recebe requisição demais. Já esbarramos nisso durante o desenvolvimento, então atualizar "o tempo todo" não é uma opção técnica.

Situação atual

O repositório e o banco estão em conta pessoal, em caráter temporário e declarado, para o desenvolvimento andar sem esperar burocracia.

O que precisamos, antes de produção

• Uma organização no GitHub em nome da Moriah
• Uma conta Supabase da empresa — é onde o banco vai viver
• Uma conta Cloudflare da empresa — é onde o painel vai rodar
• Definição do endereço — um subdomínio de vocês, tipo painel.moriahseguros.com.br

Por que importa

Sistema que guarda dado de segurado precisa pertencer à empresa, não a uma pessoa. Se tudo ficar em conta pessoal, a Moriah depende de um indivíduo para acessar o próprio sistema — e trocar isso depois de estar no ar é bem mais trabalhoso que começar certo.

Um caso concreto disso

O token de integração com o Nectar que estamos usando foi emitido em nome de um usuário específico, e expira em 24 de agosto de 2028. Se essa pessoa for desativada no CRM antes disso, a sincronização para. O ideal é criar um usuário de integração dedicado, que não dependa de ninguém em particular.

O que precisamos definir junto

• Base legal — sob qual justificativa a Moriah trata esses dados? Normalmente é execução de contrato para cliente e legítimo interesse para prospect, mas quem confirma isso é vocês ou o jurídico.
• Retenção — por quanto tempo faz sentido guardar um lead descartado? Há contato de 2022 na base.
• Pedido de exclusão — se um titular pedir para ser apagado, qual o caminho? O dado original fica no Nectar; o painel é uma cópia. Apagar nos dois precisa ser um procedimento, não improviso.
• Encarregado — existe alguém responsável por proteção de dados na Moriah?

O que já foi feito por padrão

• CPF não é copiado para o painel
• Cada usuário só enxerga o que o papel dele permite, com a regra aplicada no banco
• Contato marcado como sigiloso no Nectar continua sigiloso no painel
• Registro de erro nunca guarda dado pessoal nem senha
• O painel não altera nada no CRM de vocês — só lê, e isso é garantido no código, não apenas combinado

Contexto

Este módulo não está sendo construído agora, por decisão de escopo. A pergunta é para o desenho não fechar portas.

O que queremos saber

Vocês anunciam em Meta, Google, ou ambos? As contas de anúncio estão em nome da Moriah ou de uma agência? Se for agência, ela dá acesso de leitura?

Por que perguntar agora

Porque a resposta da P5 (origem do lead) é o que torna esse módulo útil. Se vocês começarem a registrar o canal de origem desde já, quando o módulo entrar já haverá histórico para comparar. Se começar depois, o módulo nasce sem passado.