CRM com Power BI: decidir se precisa, tirar os dados do DataCrazy e montar o modelo certo

Muita empresa pede Power BI antes de ter o funil limpo. O resultado é um painel bonito com número errado, porque o vendedor não preencheu a origem e o card ganho não tem valor. Esta página começa pela pergunta que evita esse gasto: o que você quer saber que o painel do CRM não mostra?

Você precisa mesmo levar o CRM para o Power BI?

Só se a pergunta de negócio exigir dados de fora do CRM ou um histórico que o painel não guarda do jeito que você precisa. O DataCrazy tem BI interno com LTV, CAC, tempo por etapa e conversão por origem, vendedor e produto, segundo o site oficial.

Se as suas perguntas estão nas três primeiras linhas, gaste o esforço em limpar o funil e usar o painel que já existe. O que cada painel do DataCrazy mostra está em DataCrazy dashboard, e os indicadores que um painel comercial precisa ter, em dashboard de vendas.

Como os dados saem do DataCrazy para o Power BI?

Por dois caminhos, que podem ser usados juntos. A API REST, que a página de planos do DataCrazy lista a partir do Essential, permite que um processo agendado leia os dados. Os webhooks permitem que cada mudança importante seja registrada no momento em que acontece.

O Power BI não precisa falar direto com o CRM. Ler de uma base intermediária deixa o relatório mais rápido e evita depender da API em cada atualização. O conceito de webhook está explicado em o que é webhook, e o que a API do DataCrazy oferece por plano, em DataCrazy API.

Qual modelo de tabelas usar para o CRM no Power BI?

Um modelo em estrela: duas tabelas de fatos (negócios e mudanças de etapa) cercadas por tabelas de apoio (vendedor, origem, produto, data). Esse desenho evita a planilha única com cem colunas, que fica lenta e duplica valores.

FATO_NEGOCIOS (uma linha por negócio)
id_negocio | id_contato | id_vendedor | id_origem | id_produto | pipeline | etapa_atual | status (aberto/ganho/perdido) | valor | data_criacao | data_fechamento | motivo_perda

FATO_ETAPAS (uma linha por mudança de etapa, vinda do webhook)
id_evento | id_negocio | etapa_anterior | etapa_nova | data_hora | id_vendedor

DIM_VENDEDOR
id_vendedor | nome | equipe | unidade | ativo (sim/não)

DIM_ORIGEM
id_origem | canal (WhatsApp, Instagram, Facebook, site, indicação) | campanha | anúncio

DIM_PRODUTO
id_produto | nome | linha | preço de tabela | custo (vem do ERP, não do CRM)

DIM_DATA
data | dia_semana | semana | mês | trimestre | ano

Relacionamentos: cada DIM liga à FATO pelo id. DIM_DATA liga a data_criacao (ativa) e a data_fechamento (inativa, usada nas medidas de fechamento).

Medidas de partida (DAX):
Negocios criados = COUNTROWS(FATO_NEGOCIOS)
Negocios ganhos = CALCULATE([Negocios criados], FATO_NEGOCIOS[status] = "ganho")
Taxa de conversao = DIVIDE([Negocios ganhos], [Negocios criados])
Receita ganha = CALCULATE(SUM(FATO_NEGOCIOS[valor]), FATO_NEGOCIOS[status] = "ganho")
Ticket medio = DIVIDE([Receita ganha], [Negocios ganhos])

A FATO_ETAPAS é a tabela que mais faz falta depois. Ela só existe se o registro por evento for ligado no início do projeto. Como a taxa de conversão deve ser lida, sem misturar períodos, está em taxa de conversão de vendas.

De quanto em quanto tempo o Power BI atualiza os dados?

Não é em tempo real. Pela documentação da Microsoft, modelos em capacidade compartilhada aceitam até 8 atualizações agendadas por dia; em Premium, PPU ou Fabric, até 48. Por isso o acompanhamento do dia a dia do vendedor continua no painel do CRM, e o Power BI fica para análise semanal e mensal.

• Fonte em nuvem dispensa gateway quando o Power BI consegue se conectar direto a ela, segundo a mesma documentação. Uma planilha on-line ou um banco em nuvem costuma cair nesse caso.
• Cuidado com a consulta montada na mão. A Microsoft avisa que fontes dinâmicas com Web.Content, na maioria dos casos, não atualizam no serviço do Power BI; a exceção é usar as opções RelativePath e Query. Isso afeta quem monta a chamada à API direto dentro do Power BI.
• Base intermediária resolve as duas coisas: o n8n fala com a API do CRM, e o Power BI lê uma fonte simples e estável.

Power BI ou Looker Studio para o CRM: qual escolher?

Escolha pelo ecossistema que a empresa já usa. Quem trabalha com Microsoft 365 e Excel costuma estar mais à vontade no Power BI. Quem vive no Google Workspace pode usar o Looker Studio, que se liga a fontes como o Planilhas Google por meio de conectores.

Para o caminho mais curto, com planilha no meio, veja integrar Google Sheets com CRM.

Quanto custa levar o CRM para o Power BI?

Depende de quantas fontes entram e de quem monta os relatórios. Do lado do CRM, a API REST aparece a partir do DataCrazy Essential, de R$ 460 por mês (valores do site oficial, conferidos em 12/11/2026, em datacrazy.io/planos). A licença do Power BI é contratada com a Microsoft.

Todos os itens estão nos planos da AD PRO e o escopo de uma implantação completa, em implementação de CRM. Quando a outra ponta é um ERP, veja também integração CRM com ERP.

O que conferir no CRM antes de ligar o Power BI?

Seis regras de preenchimento. Elas valem mais para a qualidade do relatório do que qualquer gráfico, e todas são configuradas no próprio CRM.

1. Origem obrigatória em todo lead, com a mesma lista de valores para todo mundo.
2. Valor preenchido antes de o card ir para Ganho.
3. Motivo de perda obrigatório, com lista fechada.
4. Um dono por negócio; nada de card sem vendedor.
5. Etapas com nome estável. Renomear etapa no meio do mês quebra a série histórica.
6. Registro de mudança de etapa ligado (a FATO_ETAPAS do modelo acima).

Sem esses seis pontos, o Power BI só mostra mais rápido um número em que ninguém confia. Para a reunião semanal, um relatório de vendas semanal feito no próprio CRM costuma bastar até a empresa crescer.