Como integrar CRM e agenda quando cada unidade da rede usa um sistema diferente?

"Como automatizar CRM e agenda numa rede em que cada unidade herdou um sistema diferente, por aquisição ou por expansão?"

Você não tem um problema de software. Tem um problema de arquitetura.

Cada unidade que entrou na rede chegou com um sistema de gestão, um jeito próprio de cadastrar paciente, um imaging separado e uma agenda que só a recepção daquele endereço enxerga.

A conta aparece no fechamento do mês: planilha paralela para consolidar, o mesmo paciente existindo três vezes na rede, lead que entra pela marca e cai na unidade errada.

E a saída quase nunca é obrigar todo mundo a trocar de sistema no mesmo dia.

A saída é decidir o que precisa ser único na rede, o que pode continuar local, e ligar as pontas por um padrão em vez de por remendo. Esse padrão já existe e é nacional: segundo o guia oficial de integração da RNDS, do Ministério da Saúde, o FHIR é o padrão adotado pelo Brasil para transferir e obter informações em saúde no território nacional, e a Portaria 1.434, de 28/05/2020, do Ministério da Saúde, faz pela interoperabilidade em saúde o que a norma técnica de tomadas fez pela rede elétrica do país.

Neste guia você vai ver:

• O inventário por unidade que precisa existir antes de qualquer decisão de sistema
• As três rotas de arquitetura (unificada, federada, híbrida) e quando cada uma cabe
• Como resolver a identidade do paciente entre bases diferentes, o problema mais caro da rede
• Em que ordem migrar, com piloto, e por que comprimir prazo é o erro clássico
• O que a LGPD exige quando o cadastro atravessa unidades e CNPJs
• Quais indicadores provam que a integração funcionou (e quando não unificar)

Por que quase toda rede que cresce por aquisição acaba com um sistema por unidade

Esse cenário é o padrão, não a exceção. Vale registrar isso porque muito dono chega achando que fez alguma coisa errada.

Quando você compra uma clínica que já operava, você compra junto o contrato de software dela, o histórico dentro daquele banco, a equipe treinada naquela tela e o imaging já instalado nas salas.

Trocar tudo no dia seguinte à assinatura significa parar de faturar enquanto a equipe reaprende a trabalhar, no momento em que a unidade ainda está se estabilizando.

Então ninguém troca. E aí a rede vai somando sistemas na mesma proporção em que soma endereços.

O erro não é ter herdado sistemas diferentes. O erro é deixar isso sem arquitetura por anos, até a conciliação manual virar um cargo dentro da rede.

Passo zero: o inventário por unidade que decide tudo depois

Antes de escolher rota, você precisa saber o que existe. E existe mais do que o software de gestão.

Monte uma tabela com uma linha por unidade e cinco colunas de sistema em uso ativo:

Camada	O que mapear	Por que importa na integração
Gestão	Nome do software e a versão exata em uso	Duas unidades no "mesmo sistema" em versões diferentes não integram igual
Imaging	Software de imagem, raio-X e tomografia	É a camada que mais trava go-live e a que menos gente lembra de mapear
Comunicação com paciente	WhatsApp, lembrete, confirmação, quem opera	Define se a régua de comparecimento é da rede ou de cada recepção
Faturamento e convênio	Sistema, tabelas, quem fecha guia	Impacto de receita imediato se falhar
Aplicações clínicas	Periodontia, ortodontia, CAD e o que mais estiver rodando	São os satélites que ninguém cita na reunião e aparecem no corte

Duas colunas extras valem ouro: quem é o dono do contrato em cada unidade e quando ele vence. Data de renovação é alavanca de negociação e janela natural de migração.

Lembre: inventário incompleto é a origem da maior parte dos go-lives que atrasam. O sistema que ninguém mapeou é exatamente o que aparece na véspera do corte.

As três rotas de arquitetura: unificada, federada ou híbrida

Com o inventário na mão, a decisão fica objetiva. São três rotas, e não existe uma certa para toda rede.

Rota unificada: todas as unidades passam a rodar o mesmo sistema de gestão. Dado nasce único, relatório sai pronto, treinamento é um só.

Rota federada: cada unidade mantém o sistema dela, e uma camada de integração normaliza os dados para alimentar o CRM, a agenda consolidada e o relatório da rede.

Rota híbrida: você define um stack preferencial, todas as aquisições novas entram nele, e o legado das unidades antigas é tolerado por um prazo que tem data.

Critério	Unificada	Federada	Híbrida
Disrupção na operação	Alta no corte	Baixa	Média, diluída no tempo
Custo inicial	Concentrado	Diluído, mas recorrente	Médio
Relatório consolidado	Nativo	Depende da camada de integração	Parcial até o legado sair
Risco de parada de receita	Concentrado na janela	Menor	Menor
Dependência de fornecedor	Alta, de um só	Distribuída	Média
Encaixa bem quando	A rede tem poucos endereços e muito atrito entre eles	As unidades são maduras e o dado em tempo real não é crítico	A rede segue comprando unidades

Repare no que a tabela não resolve: nenhuma rota dispensa você de padronizar como a equipe digita o dado. Voltaremos a isso.

O custo escondido de não integrar (a conta que ninguém coloca no papel)

Antes de decidir quanto investir na integração, coloque no papel o que a falta dela já custa hoje. Esse número costuma estar espalhado e por isso passa despercebido.

Ele aparece em quatro lugares:

1. Retrabalho de conciliação. Alguém do seu time gasta dias do mês reconciliando planilha de unidade com planilha de unidade para você fechar a rede.
2. Planilha paralela como fonte da verdade. Quando a planilha manda mais que o sistema, a informação de gestão da rede passa a depender de uma pessoa, não de um processo.
3. WhatsApp como sistema de gestão informal. Encaixe, transferência entre unidades e confirmação combinados por mensagem não viram registro, não viram relatório e somem quando a pessoa sai.
4. Decisão atrasada. Você descobre que uma unidade caiu de ocupação quando o fechamento sai, não quando a queda começa.

Esse custo não some sozinho. Ele cresce com o número de endereços, porque cada unidade nova multiplica os pontos de conciliação.

O problema mais caro não é o software: é a identidade do paciente

Aqui mora o custo real da rede com sistemas diferentes. E quase ninguém trata isso como projeto separado.

O mesmo paciente pode existir três vezes na rede: uma vez na base da unidade A, outra na B, outra no CRM que a agência ou o comercial alimentou. Três históricos parciais, nenhum completo.

Isso quebra coisas concretas:

• O dentista da unidade B não vê o tratamento iniciado na A.
• O follow-up dispara para quem já fechou em outro endereço.
• O relatório conta o mesmo paciente como dois, e a sua taxa de conversão fica errada.

A solução tem três peças, nessa ordem:

1. Defina a chave de identificação. O identificador principal (CPF costuma ser o mais estável no Brasil), com data de nascimento e telefone como apoio quando o principal falta.
2. Rode o pareamento entre as bases. Não é conferência manual: é uma rotina que aproxima registros parecidos e devolve uma lista de candidatos a duplicidade.
3. Escreva a regra de sobrevivência. Qual cadastro vence quando há conflito, quem decide o caso duvidoso, e o que acontece com o histórico do cadastro descartado.

Sem isso, qualquer integração que você construir vai apenas transportar o mesmo erro mais rápido entre os sistemas.

Padronizar como o dado é digitado custa pouco e resolve muito

Essa é a alavanca mais barata da lista inteira, e a mais ignorada. Ela não exige trocar o software de ninguém.

Boa parte da duplicidade não nasce de falha técnica. Nasce de gente digitando o mesmo paciente de jeitos diferentes: apelido no lugar do nome legal, endereço em formato livre, nome provisório improvisado.

Existe evidência documentada de que padronizar a digitação move o ponteiro. No relatório GAO-19-197, do US Government Accountability Office, publicado em janeiro de 2019, consta que em 2017 vinte e três prestadores de saúde no Texas acordaram e implementaram padrões de como a equipe deve registrar nome, endereço e outros dados dos pacientes, para melhorar o pareamento de registros e facilitar a troca de informação em saúde.

E o efeito relatado foi grande. Ainda no GAO-19-197, representantes dos três hospitais entrevistados que participaram daquele acordo no Texas estimaram que o volume de revisão manual para resolver problemas de pareamento e ligar registros recebidos ao paciente certo caiu cerca de 90%. É estimativa dos entrevistados, não medição auditada, e o contexto é de hospitais norte-americanos trocando informação entre si em 2017.

O que dá para levar para uma rede odontológica brasileira é o princípio, não o número: o mesmo relatório descreve que o acordo incluiu registrar o nome legal do paciente e lançar apelido apenas como nome alternativo, adotar um padrão para nomes temporários de recém-nascido e usar um padrão único de endereço, no caso o dos Correios americanos.

Traduzindo para a sua recepção, vire isso um documento de uma página:

• Nome legal no campo de nome, apelido só no campo de nome alternativo.
• Formato único de endereço, telefone e data.
• Regra escrita para cadastro incompleto, em vez de cada uma inventando o seu.
• Conferência de compliance depois, para ver se a regra pegou de verdade.

Integração por padrão nacional: FHIR, RNDS e API em vez de ponte por unidade

Com o dado entrando padronizado, o próximo passo é como os sistemas conversam. E aqui a escolha errada é a mais comum: mandar construir uma integração ponto a ponto para cada par de sistemas.

Integração ponto a ponto cresce em complexidade a cada unidade nova, e cada uma vira um contrato e um ponto de falha.

O caminho estruturado é integrar por padrão e por API. Segundo o guia oficial de integração da RNDS, do Ministério da Saúde, usar o padrão adotado pelo Brasil significa empregar uma API e esquemas de dados bem estabelecidos para transferir e obter informações em saúde no território nacional, e a norma que ocupa esse lugar é a Portaria 1.434, de 28/05/2020, do Ministério da Saúde.

O mesmo guia registra uma condição importante para quem vai cobrar isso do fornecedor: a integração entre um Sistema de Informação em Saúde e a RNDS é assegurada se ambos estão conectados à internet e obedecem o contrato ou personalização nacional.

Na prática, isso muda a pergunta que você faz na renovação do contrato. Em vez de "esse sistema é bom?", passa a ser:

• Ele expõe API REST documentada?
• Ele trabalha com o padrão adotado nacionalmente?
• O que exatamente eu consigo ler e escrever por essa API (paciente, agenda, procedimento, financeiro)?
• Existe ambiente de teste antes de ligar em produção?

Fornecedor que não responde essas quatro perguntas por escrito está te dizendo qual vai ser o custo da sua próxima aquisição.

E quando a unidade roda um sistema fechado, sem API?

Acontece, principalmente em sistema antigo de unidade comprada. Não inviabiliza a rede, mas muda o nível de risco.

As saídas que sobram, em ordem de preferência:

1. Exportação agendada. O sistema gera um arquivo periódico que a camada de integração lê. Funciona bem para relatório consolidado e para CRM, mal para tempo real.
2. Integração via banco de dados, com aval do fornecedor. Leitura direta, documentada em contrato. Sem aval, você assume risco de suporte e de atualização.
3. Captura assistida na interface. Último recurso, frágil, quebra a cada atualização de tela.

Trate qualquer uma das três como ponte temporária, com data para sair, e não como arquitetura. O detalhamento está em o que fazer quando o sistema de prontuário não tem API aberta.

Sequenciamento de migração por risco: o que vai primeiro e o que vai por último

Decidida a rota, vem a pergunta que decide se o projeto vai bem: por onde começar. Sequencie por risco, não por facilidade.

1. Faturamento e convênio primeiro. O impacto de receita é imediato e visível em dias. Se a guia não sai, você descobre rápido e corrige rápido, em vez de acumular perda silenciosa por meses.

2. Sistema de gestão depois. É onde mora a maior complexidade de dados: cadastro, agenda, histórico, financeiro e as regras que cada unidade criou por conta própria.

3. Clínico e imagem por último. É o que mais atrapalha o fluxo do dentista se der errado, e o que mais depende de equipamento físico instalado na sala.

Cada etapa fecha com uma auditoria antes da seguinte: contagem de registros na origem e no destino, amostra conferida a olho, e uma lista escrita do que não migrou e por quê.

Se você está migrando a unidade inteira de sistema, o passo a passo completo está em como trocar o software de gestão sem perder o histórico.

Imagem e raio-X: a causa clássica de go-live que trava

Vale uma seção só para isso, porque é o item que mais aparece atrasando go-live em rede multiunidade.

Imagem não é só um arquivo. É software proprietário, driver de sensor, calibração por sala e histórico pesado que precisa continuar abrindo depois do corte.

Os pontos que você confere antes de marcar data:

• O sensor e o equipamento de cada sala funcionam com o sistema novo, testados na própria sala, não no papel.
• O histórico de imagem abre no sistema novo, ou fica acessível de forma confiável no antigo.
• Quem dá suporte quando a imagem não abre com o paciente na cadeira, e em quanto tempo.

Teste isso na unidade piloto, em atendimento real, antes de escalar. Imagem que só foi validada em sala de reunião costuma falhar no primeiro dia cheio.

Cronograma: piloto em uma unidade antes de cravar data para as outras

O erro mais caro de cronograma é comprimir prazo: rodar todas as unidades ao mesmo tempo, numa janela curta, para "resolver de uma vez".

Quando tudo corta junto, você perde as duas coisas que salvam projeto: aprendizado entre ondas e time disponível para apagar incêndio.

Faça diferente:

1. Escolha uma unidade piloto. Nem a maior nem a mais problemática. Uma com volume representativo e equipe disposta.
2. Rode o piloto até o ciclo fechar. Um mês inteiro, com fechamento de faturamento feito no sistema novo, não só uma semana de uso.
3. Só então marque a data das outras. Com a lista de surpresas do piloto virando checklist das próximas.

O relatório GAO-19-197 registra, entre as lições daquele esforço de padronização no Texas em 2017, justamente dar tempo suficiente para conseguir adesão da equipe e para testar efeitos colaterais em outros sistemas de TI, além de comunicar os benefícios da mudança para o pessoal clínico e administrativo.

É o oposto de comprimir prazo.

O que fazer com o sistema antigo depois do corte

Muita rede desliga o sistema antigo no dia do go-live para economizar a mensalidade. É uma economia que costuma sair cara.

Mantenha o sistema antigo acessível, ao menos em modo leitura, por um período definido no plano. Ele serve para três coisas:

• Trilha de auditoria. Conferir no original quando algum dado migrado parecer estranho.
• Recuperação. Resgatar o que não migrou, que sempre existe.
• Defesa. Prontuário e registro clínico têm obrigação de guarda, e a cópia viva é a prova mais fácil.

Combine isso com uma auditoria pós-migração com data marcada: uma semana depois, um mês depois. Sem data, ninguém audita.

Agenda centralizada ou agenda local: o que precisa ser da rede

Essa é a decisão que a recepção sente todo dia. E ela não é oito ou oitenta.

O que ganha em ser da rede:

• Visibilidade de ocupação entre unidades. Se a unidade A está lotada e a B tem buraco no mesmo horário, alguém precisa enxergar as duas.
• Profissional que atende em mais de um endereço. Sem agenda única, você cria conflito de horário do mesmo dentista em dois lugares.
• Transferência de paciente entre unidades. Passa a ser um encaixe registrado, não um combinado por mensagem.

O que costuma continuar local:

• Bloqueio operacional da sala e manutenção de equipamento.
• Regra de encaixe de emergência, que depende de quem está fisicamente lá.

O teste é simples: se a informação muda a decisão de outra unidade, ela é da rede. Se só afeta o dia de quem está naquele endereço, é local.

CRM e captação: o lead da rede tem que cair na unidade certa

Aqui a integração deixa de ser assunto de TI e vira faturamento. O lead entra pela marca, não pela unidade.

Se o roteamento não existe, o lead vai para quem responder primeiro, ou fica parado enquanto duas recepções acham que a outra está cuidando.

Um roteamento que funciona define três coisas por escrito:

1. Critério de destino. Geografia (endereço mais próximo) combinada com especialidade (a unidade que faz aquele tratamento).
2. Dono do follow-up. Uma pessoa por lead, nomeada, com prazo. Rede sem dono nomeado é onde o lead morre.
3. O que acontece no empate. Paciente equidistante ou que já foi atendido em outra unidade tem regra própria, decidida antes.

E tem um dado que muda a urgência disso. Segundo dados internos da Odonto Results, 46,0% dos leads de clínica odontológica chegam fora do horário comercial. Base: 16.719 leads. Janela: 25 de março a 25 de agosto de 2026.

Ou seja: quase metade do fluxo chega quando nenhuma recepção da rede está aberta. Roteamento que depende de gente de plantão perde esse pedaço inteiro. Veja como a IA atende e direciona o paciente para a unidade certa.

Confirmação e lembrete: uma régua só para a rede inteira

Quando cada unidade confirma do seu jeito, o comparecimento da rede vira loteria, e você não consegue nem comparar as unidades entre si.

Uma unidade confirma por ligação na véspera. Outra manda mensagem na hora que der. A terceira confia que o paciente lembra.

Padronize quatro elementos, iguais em todos os endereços:

• Quando o contato sai (quantas horas antes, quantas tentativas).
• Por qual canal e em que ordem.
• Qual texto, com a variação mínima de marca da unidade.
• O que fazer quando o paciente não responde e quando ele desmarca.

A velocidade da resposta entra na mesma régua. Segundo dados internos da Odonto Results, a IA de Agendamento responde o primeiro lead em 5,7 segundos na mediana. Base: IA de Agendamento da Odonto Results no WhatsApp. Janela: 25 de março a 25 de agosto de 2026.

Régua única também é o que torna o relatório comparável. Sem ela, a diferença de comparecimento entre unidades pode ser só diferença de processo de confirmação.

Relatório consolidado: a rede inteira na mesma régua

O objetivo final da integração não é "ter tudo num sistema". É você conseguir olhar a rede e decidir.

Para isso, cinco indicadores precisam sair por unidade, com a mesma definição em todas:

Indicador	O que precisa estar igual entre unidades
Produção	O que conta como produção e em que momento entra
Faturamento	Regime de competência ou caixa, e como convênio entra
Ocupação de agenda	O que é hora disponível e o que é bloqueio
Absenteísmo	O que conta como falta, como remarcação e como cancelamento
Margem por unidade	Quais custos são rateados e por qual critério

Repare que a maior parte desse trabalho é de definição, não de tecnologia. Dois sistemas idênticos produzem relatórios incomparáveis se cada unidade chamar falta de uma coisa diferente.

Por isso o dicionário de indicadores vem antes do painel. Primeiro a definição escrita, depois a ferramenta que consolida.

LGPD quando o cadastro atravessa unidades e CNPJs

Assim que o cadastro do paciente passa a circular entre unidades, você saiu do campo de TI e entrou no campo jurídico. Vale tratar isso antes de ligar a integração, não depois.

Pela Lei 13.709/2018 (LGPD), dado referente à saúde é dado pessoal sensível (art. 5º, II). Isso eleva o cuidado exigido em todo o trajeto do dado.

Dois deveres aparecem direto no texto e valem para a sua rede:

• Registro das operações de tratamento. O art. 37 estabelece que o controlador e o operador devem manter registro das operações de tratamento de dados pessoais que realizarem, especialmente quando baseado no legítimo interesse.
• Medidas de segurança. O art. 46 determina que 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.

Na prática da integração, isso vira três entregas: base legal definida para o compartilhamento entre unidades, registro de quem acessou o quê, e controle técnico de acesso em vez de confiança informal. O detalhamento para clínica está em LGPD na clínica odontológica.

Quem é controlador e quem é operador na sua rede

Essa pergunta parece burocrática e é a que mais gera confusão em rede com CNPJs diferentes. Ela define quem responde pelo quê.

A própria LGPD define os dois papéis no art. 5º: controlador é a pessoa natural ou jurídica a quem competem as decisões referentes ao tratamento de dados pessoais (inciso VI), e operador é quem realiza o tratamento em nome do controlador (inciso VII).

Traduzindo para os arranjos comuns de rede:

• Holding com unidades próprias. Se as decisões sobre o tratamento são tomadas centralmente, o papel de controlador tende a ficar lá, e isso precisa estar escrito.
• Unidade franqueada com CNPJ próprio. Ela costuma tomar decisões próprias sobre o tratamento dos dados dos pacientes dela. Nesse caso o arranjo é diferente do de uma filial, e o contrato entre as partes tem que dizer quem decide o quê.
• Software house e fornecedores. Quem trata dado em nome da rede, seguindo instrução dela, está no papel de operador, e isso entra em contrato, não em confiança.

Defina isso por escrito antes do primeiro compartilhamento entre unidades. Depois do incidente, a discussão é outra.

Governança de acesso: quem pode abrir o prontuário de outra unidade

Integração sem governança cria um efeito colateral silencioso: todo mundo passa a poder ver tudo, e ninguém percebe até acontecer alguma coisa.

Escreva a matriz de acesso antes de ligar a camada de integração. Ela responde quatro perguntas:

1. Quem vê o cadastro básico do paciente de outra unidade (nome, contato, histórico de agendamento).
2. Quem vê o prontuário clínico de outra unidade, e sob qual justificativa.
3. O que fica registrado quando alguém acessa (quem, quando, qual registro).
4. Quem revisa esse registro e com qual periodicidade.

Recepção que precisa remarcar um paciente não precisa ver evolução clínica. Dentista que vai atender o caso, precisa. A diferença entre os dois é uma linha de configuração, e é ela que você audita depois.

Due diligence de sistemas antes de assinar a aquisição

Essa é a seção que economiza mais dinheiro, porque age antes do problema existir. A hora de olhar o sistema da unidade é antes de comprá-la, não no primeiro dia de integração.

Coloque quatro itens na sua due diligence, junto com o financeiro e o jurídico:

1. Exportabilidade comprovada. Peça um export de teste real, com prontuário, agenda, financeiro e imagem, no formato que o seu time consegue ler. Promessa de que "exporta" não vale; arquivo aberto e conferido, vale.
2. Contrato de saída. Prazo para entrega dos dados, formato, custo e o que acontece se o fornecedor não cumprir.
3. Existência de API. Documentada, com ambiente de teste, com a lista do que dá para ler e escrever.
4. Passivo de licença. Versão em uso, licenças pagas, quantos usuários, quando vence.

Sistema sem export testado e sem cláusula de saída não é detalhe técnico. É custo escondido que aparece depois da assinatura, quando você já perdeu o poder de barganha.

Lock-in de fornecedor e a cláusula de portabilidade

A seção anterior olhou para a unidade que você ainda vai comprar. Esta olha para os contratos que já estão rodando nas unidades que você tem hoje.

O lock-in raramente é declarado. Ele aparece como formato de export que ninguém consegue importar, prazo indefinido para entrega e cobrança extra por algo que deveria ser seu.

O ponto a fixar: o dado do paciente é da clínica e do titular, não do software. O contrato precisa refletir isso.

Coloque na renovação de cada contrato de sistema que já está em uso na rede:

• Formato de export especificado (estruturado e legível, incluindo imagem).
• Prazo máximo de entrega após a rescisão.
• Custo da extração definido em contrato, não cotado na hora da saída.
• Direito de fazer um export de teste durante a vigência, sem justificar.

Essa última linha é a mais útil e a mais esquecida. Export que nunca foi testado é export que não existe.

Treinamento e a queda de produtividade que você precisa orçar

Toda migração tem uma curva de produtividade, e fingir que ela não existe é o que transforma um projeto bom em crise interna.

Nos primeiros dias no sistema novo, a equipe atende menos, erra mais no cadastro e pergunta mais. Isso é esperado e temporário, desde que você planeje para ele.

Três medidas cortam a curva:

1. Reduza agenda na janela de corte. Menos pacientes marcados na primeira semana, de propósito. Agenda cheia no dia do go-live é como um problema pequeno vira dia perdido.
2. Treine na tela e no dado da própria unidade. Treinamento genérico de fornecedor não cobre a regra que aquela recepção criou por conta própria.
3. Tenha alguém de referência dentro da unidade. Uma pessoa treinada antes, que responde a dúvida na hora, vale mais que suporte externo por chamado.

Vale uma quarta, que o GAO-19-197 lista entre as lições do esforço de padronização no Texas: treinar a equipe sobre como inserir os dados e, depois, avaliar a conformidade para identificar oportunidades de melhoria. Treinamento sem conferência posterior costuma durar duas semanas.

Backup e contingência na janela de corte

Antes de qualquer corte, monte o plano de volta. Ele não é pessimismo: é o que permite tentar sem medo.

O mínimo que precisa existir por escrito:

• Backup completo e testado da origem, com restauração verificada de verdade, não só o arquivo gerado.
• Critério de rollback. O que exatamente faz você voltar para o sistema antigo, decidido antes e por escrito.
• Quem decide o rollback e até que hora do dia.
• Plano de atendimento manual para as horas de indisponibilidade: como a recepção marca, confirma e registra quando o sistema não responde.

Combine o corte com o calendário da unidade: fora de pico, com equipe cheia no dia seguinte, longe de fechamento de convênio.

Como provar que a integração funcionou (os indicadores do antes e depois)

Sensação de organização não é resultado. Meça antes de começar, para poder comparar depois.

Registre a linha de base ainda na fase de inventário e repita a medição em prazo definido após o go-live:

Indicador	Como medir	O que a integração deveria fazer
Duplicidade de cadastro	Quantos registros aparecem como candidatos a duplicata no pareamento	Cair e parar de crescer
Horas de conciliação manual	Horas do time por mês fechando planilha da rede	Cair
Tempo até o relatório da rede	Dias entre o fim do mês e o número consolidado	Cair
Lead roteado para a unidade certa	Percentual de leads atendidos pela unidade de destino correto	Subir
Cadastro novo criado para paciente que já existia	Quantos cadastros novos batem com um registro anterior da rede	Cair
Encaixe entre unidades	Quantos pacientes foram realocados para outro endereço com horário livre	Subir, porque antes isso era invisível

Um alerta de leitura: nem toda melhora vem da integração. Se você mudou a régua de confirmação no mesmo mês, separe os efeitos antes de atribuir o ganho ao projeto de sistema.

Quando NÃO unificar

Nem toda unidade deve entrar na unificação, e forçar todas gera custo sem retorno. Três casos pedem exceção explícita:

1. Unidade em processo de venda. Migrar sistema de algo que vai sair da rede é investir em ativo de terceiro. Mantenha federada e integre só o relatório.
2. Unidade com especialidade muito diferente. Um endereço focado em um fluxo clínico distinto pode depender de um sistema específico que a plataforma da rede não cobre. Integre os dados, preserve a ferramenta.
3. Unidade recém-adquirida, ainda em estabilização. Enquanto a equipe, o faturamento e a agenda não estabilizaram, migração de sistema empilha risco sobre risco. Dê o tempo de estabilizar e migre depois, com data no plano.

Em todos os três, a decisão é a mesma: não unificar agora, mas integrar o suficiente para que a unidade apareça no relatório da rede, na mesma régua das outras. E toda exceção nasce com data de revisão, porque exceção sem data vira legado permanente.

Seu próximo passo

1. Feche o inventário em uma semana. Uma linha por unidade, cinco camadas de sistema, mais dono e vencimento de contrato. Sem isso, qualquer decisão de arquitetura é chute.
2. Escolha a rota e escreva o padrão de digitação. Defina unificada, federada ou híbrida, e publique a página única de como a equipe cadastra paciente em todos os endereços. É a entrega mais barata com maior efeito no pareamento.
3. Rode um piloto com data e indicadores. Uma unidade, um ciclo completo de faturamento, linha de base medida antes e conferida depois. Só então marque a data das outras.

Quer transformar uma rede com sistemas herdados em agenda, CRM e relatório que falam a mesma língua, com o paciente chegando na unidade certa? Agende uma apresentação.