O que é um sistema de registro?

Um sistema de registro é o sistema autorizado a criar e manter dados confiáveis de um domínio ou processo. Um CRM pode ser o sistema de registro de clientes, um ERP de transações, um HCM de funcionários, billing de faturas e um MES do estado de produção.

Ser autorizado não significa que uma aplicação contém todos os fatos. O CRM pode ser owner da etapa e do histórico, billing dos pagamentos e produto dos entitlements.

Também é diferente de uma fonte única de verdade. Essa visão pode combinar vários sistemas. O sistema de registro mantém a criação, correção e o ciclo de vida oficial dentro do domínio.

O primeiro requisito de um sistema de registro é um mapa acordado de ground truth. O negócio deve definir quais entidades existem, qual sistema é owner de cada campo e como Objects, Record Types, campos e relações expressam essa realidade.

Em um CRM, People, Companies, Deals e Tickets podem ser Objects padrão. Um Record Type diferencia Lead de Contact sem criar outra pessoa. Campos tipados tornam email, telefone, moeda, data e relações machine-readable.

Agentes aumentam o custo da ambiguidade. Se dois sistemas reivindicam ownership ou a ontologia é confusa, eles propagam duplicatas e estado incorreto em velocidade de máquina.

Comece por ground truth e ontologia antes de escolher sync. Nomeie substantivos, lifecycle, Objects, Record Types, campos, cardinalidade e um owner para cada dado importante.

Depois conecte fontes. WhatsApp, Gmail e Outlook fornecem identidade e atividade. Imports, APIs e aplicações operacionais fornecem registros. ETL, reverse ETL, warehouses e data lakes distribuem ou enriquecem, mas não ganham autoridade de escrita por padrão.

Cada sync mapeia IDs para registros canônicos, valida tipos, aplica conflitos e registra provenance. Correções retornam ao owner.

Um cliente avisa ao suporte que mudou o endereço da empresa e pede correção de uma fatura. O CRM é owner do perfil; billing é owner das faturas e do tratamento fiscal.

O agente atualiza o endereço verificado no CRM e chama o workflow aprovado em billing. Ele não altera uma cópia da fatura e presume que o registro financeiro mudou.

Os dois sistemas emitem eventos com identificadores compartilhados. O suporte vê a correção no timeline, enquanto billing continua autoritativo para a fatura.

Mantenha uma matriz por campo com Object, Record Type, tipo, relação, source, writers, matching key, frescor, retenção e conflito.

Use Object para um substantivo com lifecycle, Record Type para uma variante real, campo para um fato, relação para conexão e tabela ou warehouse para apoio analítico.

Teste identidade cross-source, conversão Lead para Contact, duplicatas de email e telefone, null versus false, fusos, exclusão de relações, batches atrasados e correções humanas.