Qualidade de dados e prontidão de registros
Entenda o que bloqueia análises confiáveis e defina quando um registro está pronto para um processo.
O Blocchi separa três perguntas que costumam se misturar:
| Conceito | Pergunta |
|---|---|
| Qualidade de dados | Os dados estão corretos, completos, consistentes, atualizados e confiáveis? |
| Prontidão de métrica | O Blocchi tem evidência mapeada suficiente para calcular esta métrica? |
| Prontidão de registro | Este registro específico está apto a avançar em um processo de negócio? |
Qualidade de dados (/app/data/quality)
A página responde a uma pergunta: dá para confiar nos seus números de Receita agora? Ela lê as mesmas verificações que decidem se as páginas de Receita mostram um número ou um aviso, então as duas sempre concordam.
- Contando — qual CRM o Blocchi está contando. O Blocchi nunca mistura registros de dois CRMs. Se o Blocchi CRM e um CRM externo estiverem conectados, um admin escolhe um em Modelo comercial (
/app/commercial-model); até lá, os números de Receita ficam vazios. - Última sincronização — quando o CRM contado sincronizou. O Blocchi CRM é gravado no próprio Blocchi, então está sempre ao vivo.
- Métrica por métrica — se cada número de Receita está completo e, se não estiver, o que falta (campos sem mapeamento, sincronização atrasada, limite de tamanho), com um link para a correção.
- Corrija na origem — Mapeamento, Prontidão de registros, Fontes e, com Data+, Resolução de qualidade.
Quando o CRM contado é externo, a página também leva às verificações de higiene dele (atividade, datas de fechamento, contatos). Elas mostram como o CRM é mantido, não se os números estão completos; a página de Revenue Dá para confiar nos dados do CRM? trata delas.
Prontidão de registros (/app/data/readiness)
Defina o que significa um registro estar pronto — por exemplo prontidão para qualificação de oportunidade ou prontidão para onboarding de cliente.
- Crie zero, um ou vários checklists por entidade semântica. Os checklists se ligam a entidades do Blocchi, não a objetos do provedor, então continuam portáveis.
- Cada verificação tem uma condição, critérios opcionais de aplicabilidade, uma gravidade (bloqueante, obrigatória ou recomendada), um peso, orientação de correção e uma ordem.
- Comece por um modelo sugerido; aplicá-lo cria uma cópia sua que você pode personalizar.
Cada registro é avaliado em um de quatro estados:
| Status | Significado |
|---|---|
| Pronto | Nenhuma verificação aplicável falhou e nenhuma evidência obrigatória ou bloqueante é desconhecida. |
| Precisa de atenção | Uma verificação não bloqueante falhou, ou falta evidência obrigatória. |
| Bloqueado | Pelo menos uma verificação bloqueante falhou. |
| Não se aplica | Nenhuma verificação se aplica ao registro. |
A nota percentual é secundária: uma falha bloqueante nunca fica escondida atrás de uma nota alta. A prontidão é usada, por exemplo, ao mover uma oportunidade de etapa no Pipeline.
Relacionados
Última atualização em