Quase todo corretor de vida já tentou um CRM genérico. Quase todo corretor de vida abandonou.

A explicação usual é falta de disciplina. Não é. O problema é estrutural, e está no modelo de dados: um CRM genérico registra negócios que fecham uma vez, e seguro de vida é uma relação que continua rendendo depois do fechamento.

Este texto mostra onde a estrutura quebra, o que dá para contornar e o que não dá.

O que um CRM genérico entende do mundo

Todo CRM de uso geral organiza a informação em três níveis: contato, empresa e oportunidade. A oportunidade tem um valor, uma data prevista de fechamento e um estágio. Quando fecha, vira ganho e sai do funil.

Esse desenho descreve bem a venda de software, de consultoria, de máquina industrial. Vende-se uma vez, entrega-se, encerra-se.

Ele descreve mal a venda de seguro de vida.

Este texto integra o guia de CRM para corretor de seguro de vida, sobre o que a categoria precisa entregar.

Os termos que este texto usa

CRM é a sigla de gestão de relacionamento com o cliente. No contexto de vida, o termo designa o sistema que guarda cliente, apólice, cobertura e comissão em níveis separados.

Esteira de propostas é o nome que damos aqui ao percurso entre o aceite do cliente e a emissão da apólice: direcionamento, pendência de pagamento, pendência de documentação, análise de risco e emissão.

Por que a diferença importa agora

A Resolução CNSP nº 493, de 17 de julho de 2026, publicada no Diário Oficial da União de 21 de julho, entra em vigor em 17 de janeiro de 2027. O art. 21 estabelece que a comissão é restituída à seguradora, proporcionalmente, em caso de devolução de prêmio ou cancelamento de apólice — e que não são devidas comissões a corretor com registro suspenso.

Isso transforma controle de apólice e de comissão em requisito de conformidade, não em preferência de organização. Um sistema que não separa cobertura de apólice não consegue nem calcular o que seria restituído.

O que falta, na ordem em que dói

O que falta Consequência
Apólice não é oportunidade Um cliente pode ter três apólices, cada uma com vigência, status e forma de pagamento próprios. No CRM genérico, viram três oportunidades ganhas, sem hierarquia entre elas e sem vínculo com o que veio depois.
Cobertura não existe Dentro de uma apólice há coberturas distintas, com capital, prêmio e data de término próprios. É o nível em que a comissão é calculada e em que o cliente decide manter ou cancelar. Nenhum CRM genérico tem esse nível, e adaptá-lo com campos personalizados produz uma ficha ilegível.
A receita não acaba na venda Comissão de primeiro ano e renovação seguem lógicas diferentes, por anos. O CRM genérico registra o valor do negócio uma vez, no fechamento, e não sabe o que acontece nos 35 meses seguintes.
O estorno não cabe Quando uma apólice cancela, parte da comissão volta. Um sistema que só entende ganho e perda não tem onde registrar receita que já entrou e depois saiu.
As datas que importam não são as do funil Aniversário de apólice, fim de vigência, último ano sem DPS, revisão anual. São gatilhos que nascem da carteira, não da negociação, e o CRM genérico não tem de onde tirá-los.
A carteira não entra A seguradora entrega planilha com dezenas de colunas. Sem importação que entenda esse formato, alguém digita — e ninguém digita seiscentos clientes.

Há um requisito que nenhuma planilha atende e que costuma ficar de fora da comparação:

Art. 46. Os agentes de tratamento devem adotar medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito.

— Lei nº 13.709/2018, a LGPD.

A lei não lista as medidas. Ela exige que sejam aptas, o que desloca o critério para a adequação ao risco. E o risco de uma base de seguro de vida é maior que o de uma base comercial comum, porque ela contém dado de saúde — categoria sensível pelo art. 11, com restrição própria.

Planilha em nuvem pessoal, sem controle de acesso e sem registro de quem viu o quê, não sustenta essa exigência. Não é questão de conforto: é o critério legal aplicado ao dado que você guarda.

O calendário que o sistema precisa sustentar

Um sistema de carteira de vida precisa dar conta de um calendário que não é opcional. Vale ter os prazos em uma tabela só.

Obrigação Prazo Base
Comunicar incidente de segurança à ANPD e ao titular 3 dias úteis do conhecimento Res. CD/ANPD nº 15/2024, art. 6º
Responder sem modelo aprovado no WhatsApp 24 horas da última mensagem do cliente Política de Mensagens do WhatsApp Business, seção 2, versão de 1º de maio de 2026
Manter cadastro atualizado sob pena de suspensão contínuo; 180 dias de suspensão até o cancelamento Res. CNSP nº 493/2026, arts. 14, 18 e 20
Vigência da Resolução 493 17 de janeiro de 2027 publicada no DOU de 21/07/2026

Nenhum desses prazos é cumprido de memória. Três dias úteis para mapear o que vazou pressupõe saber onde os dados estão. Vinte e quatro horas para responder pressupõe ver a mensagem. Cadastro em dia pressupõe alguém lembrando — porque, pelo art. 21, registro suspenso não gera comissão.

O ponto exato em que o corretor desiste

O padrão se repete.

Primeiro mês: entusiasmo, cadastro manual dos clientes principais, funil montado com estágios adaptados.

Segundo mês: a planilha da seguradora chega com movimentação. Não há como importar sem retrabalho. O corretor atualiza o que dá.

Terceiro mês: os dados do CRM e os da planilha divergem. A planilha continua sendo a fonte de verdade, porque é ela que a seguradora manda.

Quarto mês: o CRM vira uma agenda cara.

O abandono não acontece por preguiça. Acontece quando manter dois sistemas passa a custar mais do que manter um.

O que dá para contornar com campos personalizados

Vale reconhecer o que funciona, porque parte das operações roda assim há anos.

Dá para criar campos personalizados para número de apólice, vigência e prêmio. Dá para montar um funil com os estágios da venda consultiva. Dá para usar automações de follow-up.

Isso resolve a fase comercial de forma razoável — do primeiro contato ao fechamento.

O que não se resolve com campo personalizado é a fase de carteira: hierarquia entre apólice e cobertura, comissão recorrente com estorno, alertas que nascem de datas da apólice e importação do arquivo da seguradora.

Se a sua operação é quase toda prospecção e você acompanha a carteira por fora, um CRM genérico serve. Dizer o contrário seria vender urgência que não existe.

O teste dos cinco minutos

Há uma forma rápida de descobrir a categoria de qualquer ferramenta, e ela não depende de conversar com vendedor.

Abra a demonstração e tente responder a cinco perguntas usando apenas as telas que existem, sem criar campo nenhum.

  1. Quais coberturas vencem nos próximos noventa dias?
  2. Qual foi a comissão de renovação deste mês, separada da comissão de primeiro ano?
  3. Quais clientes estão com prêmio em atraso, e há quantos dias?
  4. Qual o prêmio anual total da carteira?
  5. Quais clientes têm capital desatualizado?

CRM genérico não responde nenhuma das cinco, porque nenhuma delas nasce da negociação. Todas nascem da apólice.

Se o vendedor responder "dá para montar um relatório", pergunte a partir de qual campo. A resposta vai revelar que o dado precisaria ser digitado por você, cliente a cliente.

Por que o problema não é resolvido por integração

Uma objeção comum: "mas dá para integrar o CRM genérico com uma planilha ou com outro sistema."

Dá, e o resultado costuma durar pouco. Integração transfere dados entre dois modelos; ela não cria um nível que não existe no destino.

Se o CRM não tem cobertura como entidade, a integração vai despejar as coberturas em campos de texto ou criar um registro por linha da planilha — que é exatamente o problema original. E cada mudança no formato do relatório da seguradora quebra a integração.

Manter integração é trabalho recorrente. Corretor autônomo não tem quem faça esse trabalho.

A pergunta que resolve a escolha

Não é "qual CRM tem mais recursos". É esta:

A informação que você mais consulta está na negociação ou na apólice?

Se está na negociação — quem respondeu, quando é a próxima conversa, quantas propostas estão abertas — o CRM genérico dá conta.

Se está na apólice, nenhum campo personalizado resolve, porque falta o nível abaixo do cliente. Qual cobertura vence, qual comissão entrou este mês, qual cliente está com prêmio em atraso, qual capital está desatualizado.

Corretor de vida com carteira formada consulta a segunda.

Como nós resolvemos isso

O Insurance Pro é construído sobre a hierarquia real do negócio: cliente, apólice, cobertura. São três níveis distintos no banco, não campos personalizados dentro de um contato.

A carteira entra pela planilha da seguradora. O sistema reconhece as colunas do relatório por nome e por variação de nome, e consolida por três chaves: cliente pelo código, apólice pelo número, cobertura pela combinação de apólice e código de cobertura. Reimportar o mesmo arquivo não duplica nada.

A comissão tem tratamento próprio, com deduplicação por apólice, cobertura e mês, separação entre primeiro ano e renovação, e projeção do mês seguinte com destaque para a comissão em risco por atraso de prêmio.

E as datas da apólice viram fila de trabalho: revisão de carteira, fim de cobertura, aniversário.

O que não fazemos: integração com a API oficial do WhatsApp, com histórico de conversa dentro do sistema. Trabalhamos com modelos de mensagem e link. Está explicado em detalhe em outro artigo.

Antes de trocar

Três verificações que valem para qualquer fornecedor, inclusive para nós.

Teste O que observar
Peça para ver a importação com o seu arquivo Não com o arquivo de demonstração. É onde a maioria das ferramentas revela o limite.
Pergunte como o sistema trata reimportação Se duplicar registro, você vai limpar base manualmente todo mês.
Pergunte se existe o nível de cobertura Se a resposta for "dá para criar um campo", é um CRM genérico com outro nome.

Teste com a sua carteira. O Insurance Pro tem sete dias de avaliação e a importação é o primeiro passo — em vez de começar com o sistema vazio, você começa com os seus clientes, apólices e coberturas já dentro.

Perguntas frequentes

Um CRM genérico serve para corretor de seguros?

Serve para gerir contatos e oportunidades, e falha na estrutura do produto. CRM genérico trata apólice como negócio fechado, quando ela é um contrato vivo com coberturas, vigências e comissão recorrente.

Qual a diferença de um CRM para seguro de vida?

A hierarquia. Cliente, apólice e cobertura são três níveis distintos, e é no nível de cobertura que a comissão é paga e que a lacuna de proteção aparece.

O que um CRM genérico não faz?

Não separa primeiro ano de renovação, não consolida extrato de comissão por chave, não calcula projeção de receita e não reconhece aniversário de apólice como gatilho.

Fontes