--- id: imobiliario/funil-crm-por-pipeline industria: Imobiliário uso: muito usado esforco: médio grao: Negócio (deal) com pipeline, etapa e campos decodificados; passagem de etapa para a jornada --- # Funil do CRM imobiliário por pipeline Negócios em andamento, ganhos e perdidos de cada pipeline com os campos do CRM legíveis, o VGV por corretor sem dobrar parcerias e o tempo real em cada etapa. ## Resumo executivo **Para quem:** Imobiliárias de venda de terceiros, lançamentos e locação que usam Bitrix24, Vista, Imobzi ou Moskit. **O que resolve** - O gestor vê negócios em andamento, ganhos e perdidos de cada pipeline sem abrir o CRM. - Campos customizados viram texto legível e o empreendimento de cada negócio para de ser subcontado. - VGV, VGC e vendas por corretor e equipe batem com o número real, mesmo com vendas em parceria. **Por que importa:** O CRM imobiliário guarda quase toda regra de negócio em códigos: ids de campo, ids de opção e letras de semântica. Sem um de-para, cada dashboard reinventa a regra e os números divergem entre diretoria e equipes. É a base da meta por corretor, da comissão e do funil de mídia até a venda. **Perguntas de negócio que responde** - Quantos negócios estão em andamento, ganhos e perdidos em cada pipeline neste mês? - Quanto VGV e VGC cada corretor e cada equipe fizeram contra a meta? - Em qual etapa cada equipe mais perde clientes? - Quanto tempo um lead leva até a visita, a proposta e o contrato assinado? - Quais negócios acima de um valor estão parados há mais de N dias? - Quantas captações de proprietário entraram por corretor no trimestre? **O que você precisa** - CRM conectado na Nekt, com as tabelas de metadados de campos e a lista de status - O mapa dos pipelines do CRM (comprador, proprietário, lançamentos, locação, fechamento) - A planilha de metas por equipe e período, se houver meta **O que você recebe** - Uma tabela por negócio com pipeline, grupo de fase e campos legíveis - Uma tabela de vendas por corretor com participação, para ranking e comissão - Uma tabela de passagens de etapa com o tempo em cada uma - Um agente de IA que responde sobre o funil com as definições da casa ## Detalhado ### O problema O CRM guarda pipeline, etapa e campos customizados em códigos: category_id numérico, UF_CRM_* com ids de opção e uma letra de semântica por etapa. Cada imobiliária usa ids diferentes, e campos legados com rótulo parecido convivem com os novos. Quem filtra pelo nome do negócio ou soma vendas em parceria por corretor entrega VGV dobrado e empreendimentos subcontados. ### Regras de negócio 1. **Grupo de fase vem da semântica da etapa.** No Bitrix, stage_semantic_id do negócio diz P (em andamento), S (ganho) ou F (perdido). Para leads, use semantics da status_list (S ganho, F perdido, vazio em andamento). O nome da etapa muda por pipeline e serve só para o detalhe. (Evite: Classificar ganho e perdido pelo nome da etapa.) 2. **Um pipeline por linha de negócio.** category_id (Bitrix) ou o grupo de pipeline (Imobzi) separa comprador, captação de proprietário, lançamentos, locação e o pipeline administrativo de fechamento. Os ids são números que mudam por empresa: mantenha uma tabela de-para pipeline para tipo e conte cada tipo separado. (Evite: Somar captações de proprietário com leads de comprador num total de leads.) 3. **Decodifique campos pelo dicionário.** Campos UF_CRM_* do tipo enumeration guardam o id da opção. O texto vem de items em bitrix_deal_fields, que a Nekt grava como array> com chaves em maiúsculas. A fonte do negócio sai de source_id cruzado com status_list onde entity_id = 'SOURCE'. Monte um dicionário único com o rótulo em português de cada campo e use em todas as tabelas. (Evite: Mostrar o id da opção ou decodificar campo a campo em cada query.) 4. **Campo múltiplo usa o primeiro valor.** Campo com ismultiple = true chega como array mesmo quando o time preenche um valor só. Use o primeiro elemento como valor principal e registre a cobertura: num caso real, um campo obrigatório ainda veio vazio em cerca de 20% dos negócios. (Evite: Explodir o array e contar o negócio várias vezes.) 5. **Escolha o campo vigente, não o legado.** Campos com rótulo quase igual convivem ('Tipo do Imóvel' obrigatório e 'Tipo de imóvel' legado quase vazio). Use o obrigatório. Quando a regra mudou de campo, como motivo de perda, consolide com o campo novo na frente e o legado como reserva, e uma categoria que cubra as duas taxonomias. (Evite: Pegar o primeiro campo que aparece na busca pelo rótulo.) 6. **Empreendimento só pelo campo canônico.** O empreendimento do negócio vem do campo customizado definido para isso (por exemplo, produto de origem ou lista de empreendimentos). Tag, etiqueta e nome do negócio subcontam muito: num caso real, tag e nome acharam pouco mais da metade dos negócios que o campo canônico achou. (Evite: Filtrar empreendimento por nome do negócio ou por tag.) 7. **Venda em parceria é uma venda.** Explode a venda por corretor: uma linha quando solo, duas quando parceria, cada uma com a participação. Ranking e comissão usam o VGV atribuído. Quantidade de vendas é sempre a contagem distinta do negócio. (Evite: Somar o VGV inteiro para cada corretor da parceria.) 8. **Equipe tem uma regra única.** A equipe pode vir do responsável pela venda, do agenciador ou do departamento do usuário. Defina a equipe contabilizada por uma regra fixa de prioridade. O departamento vem de bitrix_users.uf_department (array) cruzado com bitrix_departments, com o nome da equipe antes do ' - '. Corretor que cai em duas equipes distintas vai para um grupo de múltiplas equipes, não para as duas. (Evite: Contar a venda na equipe de cada campo preenchido.) 9. **Data oficial da venda é declarada.** Lançamentos costumam contar pela assinatura do contrato (CCV) e terceiros pela criação quando não há CCV. Se a regra mudou no tempo, guarde as duas: até um ano, a primeira entrada em ganho depois de uma etapa não ganha; depois, o campo de data criado para isso. Converta os horários do Bitrix para America/Sao_Paulo antes de cortar o mês. (Evite: Usar closedate ou date_modify como data da venda.) 10. **Tempo por etapa vem do histórico.** O negócio só guarda a etapa atual. Use bitrix_deal_stage_history e bitrix_lead_stage_history: cada linha é uma passagem com data. Tempo na etapa = próxima passagem menos a entrada. Etapa ainda aberta é medida até hoje, por isso a média dela cresce. Sem histórico nativo, grave snapshot diário. (Evite: Calcular tempo por etapa com date_modify do negócio.) ### Como ler pipeline e etapa Semântica da etapa e tipo de pipeline, no Bitrix24. - **stage_semantic_id = P** → Negócio em andamento (`P`) - **stage_semantic_id = S** → Negócio ganho (`S`) - **stage_semantic_id = F** → Negócio perdido (`F`) - **Lead: semantics vazio na status_list** → Lead em andamento (`entity_id = 'STATUS'`) - **Pipeline de comprador** → Demanda: lead que quer comprar (`category_id = `) - **Pipeline de proprietário** → Captação: imóvel para a carteira (`category_id = `) - **Pipeline de lançamentos** → Venda de unidade na planta (`category_id = `) - **Pipeline de locação** → Locação (`category_id = `) - **Pipeline de fechamento ou ADM** → Venda fechada e pós-venda (`category_id = `) - **Motivo de perda 'duplicado ou com erro'** → Fora de todas as contagens (`motivo de perda`) ### Definições | Métrica | Definição | |---|---| | Leads captados | negócios distintos criados no pipeline no período, por tipo de pipeline (comprador, proprietário, lançamentos, locação) | | Leads ativos | negócios distintos com grupo de fase em andamento na data de corte, por pipeline | | Ganhos e perdidos | negócios distintos com semântica S ou F, pela data de entrada nessa semântica | | Vendas | contagem distinta de negócios ganhos no pipeline de fechamento, pela data oficial da venda, sem desistências | | VGV | soma do valor de venda do imóvel das vendas do período; para ranking por corretor, soma do VGV atribuído pela participação | | VGC | soma da comissão da imobiliária nas vendas do período; comissão do corretor e do agenciador ficam em colunas próprias | | Tempo na etapa | dias entre a entrada na etapa e a próxima passagem; etapa aberta medida até hoje e sinalizada | | Dias até a assinatura | dias entre a criação do lead e a entrada no contrato assinado, por lead convertido | | Atingimento de meta | VGV ou VGC realizado / meta da equipe no mesmo ano, mês e vertical | ### Armadilhas - **Etapas somem do funil.** Etapa sem negócio no período não aparece numa contagem simples, e o gráfico de funil fica com buracos. Como evitar: Cruze todas as etapas de cada pipeline com a contagem e mostre zero. - **Dois CRMs ao mesmo tempo.** Depois de uma migração, o CRM antigo e o novo convivem com listas de status e ids próprios. Como evitar: Decodifique cada um com a própria status_list e una só depois, com a origem marcada. - **Duplicados no total de leads.** Negócios perdidos com motivo 'duplicado ou com erro' inflavam leads e derrubavam a conversão. Como evitar: Tire esse motivo de todas as contagens. - **Usuário institucional no ranking.** Usuários como 'Lançamentos', 'Administrativo' ou o nome da imobiliária apareciam como corretores com vendas. Como evitar: Mantenha uma lista de usuários institucionais fora do ranking. - **Mês errado na virada.** O Bitrix grava em fuso do servidor e vendas assinadas à noite do último dia caíam no mês seguinte. Como evitar: Converta para America/Sao_Paulo antes de cortar o mês. - **Correção manual some.** A diretoria corrige a data de uma venda específica por fora e a correção fica escondida no código da transformação, sem ninguém saber por quê. Como evitar: Guarde correções numa tabela de exceções por negócio, com o motivo. ### Teste de aceitação - [ ] Para um pipeline e um mês fechado, ganhos, perdidos e em andamento batem com o filtro do próprio CRM (diferença zero). - [ ] A soma do VGV atribuído por corretor é igual ao VGV total do mês, e o número de vendas é a contagem distinta de negócios. - [ ] Nenhum campo de opção aparece como id numérico na tabela final. - [ ] Todas as etapas de cada pipeline aparecem no funil, inclusive as com zero. - [ ] A soma do tempo das etapas de um negócio fechado é igual aos dias entre criação e fechamento. ### Context document ```text Funil do CRM imobiliário - Grupo de fase vem da semântica: stage_semantic_id P = em andamento, S = ganho, F = perdido. Nome da etapa é só detalhe. - Cada pipeline (category_id) tem um tipo: comprador, proprietário (captação), lançamentos, locação, fechamento. Nunca some tipos diferentes em um total de leads. - Campos UF_CRM_* de opção são decodificados pelo dicionário de campos (items de bitrix_deal_fields). Campo múltiplo: o primeiro valor é o principal. - Fonte do negócio: source_id cruzado com status_list onde entity_id = 'SOURCE'. - Empreendimento só pelo campo canônico. Nunca por tag ou nome do negócio. - Negócios perdidos com motivo 'duplicado ou com erro' ficam fora de todas as contagens. - Vendas = contagem distinta de negócios. Ranking por corretor usa VGV atribuído pela participação; parceria não duplica. - Equipe contabilizada segue uma regra de prioridade única por venda. - Data oficial da venda: assinatura do CCV para lançamentos; para terceiros, conforme a regra declarada. Horários convertidos para America/Sao_Paulo. - Tempo por etapa vem do histórico de etapas. Etapa aberta é medida até hoje e aumenta a média: avise quando a resposta incluir etapas abertas. Exceções por cliente: - : pipelines , , , , . - : campo de empreendimento = ; campo de corretor = . - : data oficial da venda até = primeira entrada em ganho; depois = . - : usuários institucionais fora do ranking: . ``` ### Variações - **Vista, Imobzi e Moskit:** Vista: etapa e pipeline em vista_crm_negocios e visitas na agenda (visita concluída). Imobzi: grupos de pipeline e dias de estagnação nativos. Moskit: opções em custom_field_options. - **Visitas por corretor:** Visitas reais = atividades do tipo visita marcadas como concluídas, por corretor e mês, com clientes distintos ao lado. - **Pós-venda e SLA:** Mesmo método no pipeline administrativo: tempo entre validação de dados, minuta, assinatura do CCV e emissão da nota de comissão.