O que preciso auditar antes de comprar a integração CRM-agenda 'pronta' que o fornecedor promete, para não virar outro sistema que não conversa?

"O que preciso auditar antes de comprar a integração CRM-agenda 'pronta' que o fornecedor promete, para não virar outro sistema que não conversa?"

Você já ouviu essa frase na reunião: "com a sua agenda a integração é nativa, já está pronta".

Três meses depois a recepção está redigitando paciente de um sistema no outro.

O problema quase nunca é má-fé do vendedor. É que "pronto" não é um estado, é uma palavra guarda-chuva que cobre quatro realidades muito diferentes de risco, custo e prazo. E a auditoria que separa uma da outra cabe em uma reunião, se você levar as perguntas certas.

O tamanho do buraco é medível. Na Pesquisa TIC Saúde 2025, do Cetic.br/CGI.br, 90% dos estabelecimentos de saúde privados brasileiros já têm os dados cadastrais do paciente disponíveis eletronicamente (92% no total) e 76% já têm histórico ou anotações clínicas em meio eletrônico (82% no total). O dado já está digital.

Só que ele não anda. Na mesma pesquisa, apenas 27% dos estabelecimentos declararam ter sistema eletrônico com interoperabilidade, e no recorte privado o índice cai para 14%.

Ou seja: comprar software digitalizado é o padrão do mercado. Comprar software que conversa ainda é exceção.

Neste guia você vai ver:

• Os 4 níveis que se escondem atrás da palavra "pronto" (e como identificar o seu)
• As perguntas técnicas que derrubam metade das promessas em uma reunião
• O que auditar campo a campo, direção a direção, antes de assinar
• O teste de aceite e o piloto que substituem o contrato anual no escuro
• As cláusulas de contrato (SLA, LGPD, saída) que decidem o seu risco em 12 meses

O que "integração pronta" significa na prática: os 4 níveis

Antes de discutir campo, latência ou preço, force o fornecedor a classificar a própria oferta. Peça por escrito, no e-mail mesmo.

Nível 1. Conector nativo, mantido e versionado pelo fornecedor

O próprio fabricante do software escreveu o conector, publica changelog, testa contra as versões do outro sistema e assume o conserto quando quebra. É o único nível em que "pronto" quer dizer produto.

Sinal de verdade: existe página pública de documentação, número de versão do conector e um canal de suporte que responde por ele especificamente.

Nível 2. Conector via plataforma intermediária

O fluxo passa por uma camada de automação no meio. Funciona, e às vezes é a decisão certa, mas o conector não é do fornecedor: é da plataforma. Se ela mudar preço, política ou descontinuar o app, você fica sem integração e o seu fornecedor não tem o que fazer.

Sinal de verdade: pergunte quem paga a assinatura da plataforma, o que acontece com o custo quando o volume dobra, e quem conserta se o app do meio parar.

Nível 3. Projeto sob demanda, faturado à parte

Não existe conector. Existe um time capaz de construir um para você, com escopo, horas e prazo. É legítimo, mas é outro produto e outro contrato.

Sinal de verdade: aparece a palavra "levantamento", "escopo" ou "análise técnica" antes de qualquer data.

Nível 4. Promessa de roadmap

A integração está no plano. Não existe hoje, não tem cliente rodando, não tem data contratual.

Sinal de verdade: futuro do verbo. "Vai ter", "está previsto", "no próximo trimestre".

Nível	Quem mantém	Quem paga a manutenção	Risco principal	O que exigir por escrito
1. Nativo	O fornecedor do software	Está na mensalidade	Baixo, mas depende do roadmap dele	Doc pública, changelog, referências de cliente
2. Via plataforma intermediária	A plataforma do meio	Assinatura extra que escala com volume	Descontinuação e custo por chamada	Quem é o dono da conta, teto de custo, plano B
3. Projeto sob demanda	Quem construiu	Contrato de manutenção separado	Vira legado sem dono	Escopo fechado, garantia, código e credenciais suas
4. Roadmap	Ninguém ainda	Não existe	Você paga hoje por algo que pode não sair	Data contratual com penalidade, ou não assine

Lembre: você não está comprando a integração. Está comprando a manutenção dela pelos próximos anos. O nível define quem acorda de madrugada quando ela para.

Nativa ou terceirizada: quem mantém o conector quando o fornecedor sair

Integração nativa e integração terceirizada podem entregar exatamente o mesmo resultado no dia 1. A diferença aparece no dia 400.

Na nativa, o fabricante versiona o conector junto com o produto. Quando ele muda a API, o conector muda junto, porque é o mesmo time.

Na terceirizada, o conector é mantido por um intermediário que não controla nenhum dos dois lados. Ele reage a mudanças que não escolheu, no ritmo dele, e pode simplesmente decidir que aquele par de sistemas não vale mais o esforço.

Faça três perguntas de propriedade:

1. De quem é o código do conector? Se um dos dois fornecedores sumir, você fica com o quê?
2. De quem é a conta na plataforma do meio? Se estiver no CNPJ do fornecedor, a integração sai junto com ele.
3. De quem são as credenciais de API? Chave emitida no seu ambiente, sob o seu controle, é patrimônio. Chave que só o fornecedor enxerga é dependência.

A pergunta que derruba metade das promessas

Existe uma pergunta única, de fato e não de opinião, que separa produto de intenção:

"Existe cliente rodando esse conector hoje, no mesmo par de sistemas e no mesmo volume que o meu?"

Repare nos três qualificadores. Cada um derruba um tipo de resposta evasiva:

• Hoje. Não "já rodou", não "está em homologação". Em produção, agora.
• Mesmo par de sistemas. Integrar com o software A não prova nada sobre o software B. O conector é específico do par.
• Mesmo volume. Um fluxo que funciona com dezenas de leads por mês pode desabar com centenas, e isso é problema de arquitetura, não de configuração.

Peça o passo seguinte: uma referência que você possa contatar. Não precisa ser cliente da sua cidade, e o fornecedor pode intermediar. Se ele não consegue produzir uma única clínica rodando o mesmo par, trate a proposta como nível 3 ou 4, e negocie preço, prazo e garantia como projeto.

O mercado sustenta o ceticismo. Na TIC Saúde 2025 (Cetic.br/CGI.br), entre os estabelecimentos de saúde privados, 27% declararam estar integrados à RNDS, 40% declararam não estar e 26% responderam não saber. Mais de um quarto dos estabelecimentos privados não sabe afirmar se o próprio sistema integra.

Se boa parte do mercado não sabe o que tem, a chance de você comprar uma promessa sem perceber não é pequena.

Audite a DIREÇÃO do fluxo: quase toda integração pronta é de mão única

Aqui mora a decepção mais comum. O fornecedor demonstra o conector, o agendamento aparece na agenda, todo mundo aplaude.

E a volta?

A maior parte das integrações vendidas como prontas é unidirecional: o CRM empurra para a agenda. O que a agenda sabe e o comercial precisa (compareceu, cancelou, remarcou, fechou quanto) fica preso do outro lado.

Sem a volta, a sua campanha continua sendo otimizada por lead, não por paciente na cadeira. É o mesmo problema que trava a automação quando os dois sistemas não conversam, detalhado em CRM e agenda não conversam: onde a automação quebra.

Monte a tabela de direção antes de assinar. Uma linha por evento:

Evento	Ida (CRM para agenda)	Volta (agenda para CRM)	Tem hoje?
Novo lead vira cadastro	Sim	Não se aplica	Perguntar
Agendamento criado	Sim	Sim (se marcarem na recepção)	Perguntar
Cancelamento	Perguntar	Crítico	Perguntar
Remarcação	Perguntar	Crítico	Perguntar
Comparecimento	Não se aplica	Crítico	Perguntar
Valor do orçamento fechado	Não se aplica	Crítico	Perguntar
Horário liberado (cadeira vaga)	Não se aplica	Alto valor	Perguntar

Preencha a coluna "Tem hoje?" com o fornecedor na sala. Os quatro itens marcados como críticos são os que transformam a integração em decisão de gestão em vez de conveniência de digitação.

Mapa campo a campo: exija a lista antes de assinar

"Integra" não é resposta. Quais campos exatamente atravessam é resposta.

Peça uma planilha com quatro colunas: campo de origem, campo de destino, direção e regra de transformação. Sem essa planilha você está comprando no escuro, e o descobrimento vai acontecer na operação.

Preste atenção especial em três categorias problemáticas:

• Campo customizado. Aquele campo que a sua clínica criou (origem da campanha, especialidade de interesse, score de qualificação) costuma ser o primeiro a não atravessar. Pergunte explicitamente se campo customizado é suportado ou se só o conjunto padrão anda.
• Campo com domínio fechado. Status de lead, tipo de procedimento e motivo de cancelamento são listas. Se as duas listas não forem equivalentes, alguém escolheu um "de-para" e você precisa aprovar esse mapa.
• Campo obrigatório em um lado e opcional no outro. É a causa clássica de registro rejeitado silenciosamente. Pergunte o que acontece quando o campo obrigatório do destino chega vazio: erro visível, valor padrão, ou descarte sem aviso.

Descarte sem aviso é o pior cenário possível. Você acredita que o dado está lá e ele nunca chegou.

Audite a API dos DOIS lados, não só a de quem está vendendo

O fornecedor que está te vendendo controla um lado. O outro lado é onde a integração costuma morrer, e ele não tem poder nenhum sobre ele.

Audite os dois com o mesmo questionário:

1. Existe documentação pública da API? Link aberto, não PDF sob acordo de confidencialidade. Documentação pública é sinal de que a API é produto, não favor.
2. Como é a autenticação? OAuth com token renovável e escopo definido é padrão maduro. Chave estática única, compartilhada e sem escopo é risco de segurança e de auditoria.
3. Existe ambiente de sandbox? Sem sandbox, todo teste acontece na sua base real, com paciente real. Isso muda completamente o risco do go-live.
4. Qual o limite de chamadas? Peça o número: quantas chamadas por minuto, por hora e por dia, e o que acontece ao estourar (fila, erro, bloqueio temporário).
5. Como é o versionamento? Existe versão na URL da API? Qual a política de aviso prévio para mudança que quebra compatibilidade?
6. Quais eventos a API publica para fora? Ou seja, quais webhooks existem. É essa lista que define o que a integração consegue fazer em tempo real.

Se o software da agenda não expõe API pública, o caminho muda inteiro, e existe um roteiro específico para isso em sistema de prontuário sem API aberta: como integrar CRM e agenda.

Webhook ou polling: a diferença entre segundos e blocos

Essa é a pergunta técnica com maior impacto direto na sua operação comercial.

Webhook é o sistema avisando no instante em que o evento acontece. Cancelou às 9h05, a notificação sai às 9h05.

Polling é a integração perguntando de tempos em tempos se mudou alguma coisa. Se a varredura roda em blocos (digamos, a cada 15 minutos), o cancelamento das 9h05 só vira informação útil na próxima passada.

Para dado de cadastro, polling resolve. Para dado que dispara ação, não.

Pense na cadeira que vagou. O valor daquele buraco cai a cada minuto que passa sem alguém oferecer o horário para a lista de espera. Uma integração em blocos entrega o aviso quando o encaixe já não é mais viável, e é por isso que a liberação de horário é o evento que mais justifica webhook numa clínica.

Pergunte na reunião: quais eventos são webhook e quais são polling? Um fornecedor sério responde item a item. Um vendedor responde "é tudo em tempo real".

Latência prometida x latência medida: peça o número, não o adjetivo

"Em tempo real" não é especificação. É adjetivo.

Especificação é assim: "o evento de cancelamento chega ao CRM em até X segundos no percentil 95, medido em produção". Peça o X. Peça também como ele é medido e onde você pode ver esse número depois de contratado.

Se o fornecedor não tem o número, ele não mede. Se ele não mede, ninguém vai perceber quando piorar.

Latência importa porque a janela de decisão do paciente é curta. Nas clínicas atendidas pela Odonto Results, a IA responde o lead em mediana 4,4 segundos e a mediana entre a primeira mensagem e o agendamento é de 2h57 (base de 5.205 leads, dados internos da Odonto Results). Uma integração que empurra dado em blocos de vários minutos entra atrasada dentro de uma janela que se mede em horas. Janela: 25 de março a 14 de junho de 2026.

Dica: exija que o número de latência entre no contrato como parâmetro de aceite, não como frase de proposta comercial.

Rate limit e volume: a integração que aguenta a média e cai no pico

Toda API tem teto. A pergunta é se o teto dela cabe no seu pico, não na sua média.

O erro clássico é dimensionar pela média mensal. A integração não quebra na média: quebra na segunda-feira depois de uma campanha forte, quando três meses de volume normal chegam em duas horas.

Faça a conta de pico com o fornecedor:

• Quantas chamadas a integração dispara por lead (criar cadastro, checar duplicidade, criar agendamento, atualizar status)?
• Qual o seu volume de pico por hora, não por mês?
• O produto dessas duas coisas cabe no rate limit?
• O que acontece quando estoura: enfileira e reprocessa, ou perde?

Enfileirar e reprocessar é aceitável. Perder não é. Peça essa resposta por escrito, com a palavra "fila" ou "retentativa" dentro dela.

Chave única do paciente: sem regra de identidade, a integração duplica

Essa é a falha que mais estraga base, e ela nunca aparece na demo.

Os dois sistemas precisam concordar sobre o que define que dois registros são a mesma pessoa. Sem essa regra, a integração cria cadastro novo toda vez que o mesmo paciente volta por outro canal, e o histórico se parte em pedaços.

Decida antes de assinar:

1. Qual é a chave? CPF, telefone, e-mail, ou uma combinação. Cada uma tem furo: CPF nem sempre é coletado no primeiro contato, telefone muda e é compartilhado em família, e-mail é opcional.
2. O que acontece no empate? Se o telefone bate mas o nome não, a integração une, cria novo ou marca para revisão humana?
3. Existe fila de revisão? Duplicata suspeita precisa de um lugar onde alguém decide, com nome e responsável.
4. Qual sistema guarda o identificador do outro? O registro do CRM precisa carregar o id do paciente na agenda, e vice-versa. Sem esse par gravado, a próxima sincronização vai adivinhar de novo.

Fonte da verdade por campo: quem manda no horário, no cadastro e no status

Duas máquinas escrevendo o mesmo dado sem hierarquia definida produzem o pior dos mundos: a última que escreveu vence, e ninguém sabe qual foi.

Escreva a tabela de autoridade antes da primeira linha de código:

Dado	Fonte da verdade	Quem só lê
Horário disponível e ocupação da cadeira	Agenda / software clínico	CRM
Cadastro e contato do paciente	Definir uma, nunca as duas	A outra
Status comercial do lead	CRM	Agenda
Comparecimento	Agenda / recepção	CRM
Valor de orçamento aprovado	Sistema clínico ou financeiro	CRM
Origem da campanha	CRM	Sistema clínico

Essa tabela vale mais que o conector. Ela é a que resolve discussão seis meses depois, quando dois dados divergem e a equipe pergunta em qual acreditar.

Conflito e double-booking: quando os dois lados escrevem na mesma agenda

Se o CRM cria agendamento e a recepção também cria, existe um instante em que os dois ocupam o mesmo horário.

Pergunte, com essas palavras: "como o conector trata conflito de escrita concorrente?"

Respostas aceitáveis envolvem reserva do horário antes da confirmação, verificação de disponibilidade no momento da gravação, ou bloqueio otimista com erro visível. Resposta inaceitável é silêncio, ou "isso não acontece".

Acontece. E o custo é o pior possível: dois pacientes no mesmo horário, na frente da sua recepção.

Peça também a regra de precedência: quando o conflito ocorre, quem ganha o horário e quem é avisado.

O passado: a integração migra o histórico ou só liga o futuro?

Quase toda integração pronta liga o fluxo do dia da virada em diante. O que já existe nos dois sistemas continua onde está.

Isso pode ser aceitável, desde que seja uma decisão sua e não uma descoberta.

Pergunte três coisas:

1. A carga inicial está incluída? Ou é serviço à parte, com preço à parte?
2. O que exatamente vem no passado? Cadastro, histórico de agendamentos, histórico de conversas, valores? Cada um é um esforço diferente.
3. Como fica a deduplicação na carga? Importar a base inteira sem regra de identidade é a forma mais rápida de duplicar tudo de uma vez.

Se a decisão for migrar de verdade, trate a carga inicial como projeto separado, com congelamento de cadastro, reconciliação e critério de aceite próprios.

Teste de aceite ANTES de assinar: o roteiro do paciente-fantasma

Esse é o item que mais economiza dinheiro, e ele é gratuito.

Antes da assinatura, defina por escrito um roteiro de aceite com um paciente de teste percorrendo os dois sistemas ponta a ponta. Uma pessoa da sua equipe executa, com cronômetro na mão.

O roteiro mínimo tem oito passos:

1. Criar o lead no CRM e conferir se o cadastro aparece na agenda, com os campos certos.
2. Agendar pelo CRM e conferir o horário reservado na agenda, com dentista e sala corretos.
3. Remarcar pela recepção, direto na agenda, e conferir se o CRM soube.
4. Cancelar pela agenda e conferir se o CRM soube, com o motivo.
5. Marcar comparecimento na recepção e conferir se o CRM recebeu.
6. Registrar valor de orçamento aprovado e conferir o que atravessa (e o que não deve atravessar).
7. Repetir o cadastro do mesmo paciente por outro canal e conferir se duplicou.
8. Rodar os passos 1 e 4 fora do horário comercial e conferir se atravessam igual.

Anote o atraso de cada salto. O que nunca atravessa recebe a marca de infinito, não de lento.

O resultado desse roteiro é o seu critério de aceite contratual: a integração é considerada entregue quando os oito passos passam, medidos, no seu ambiente. Não quando o fornecedor declara que subiu.

Audite a demo: ambiente controlado x o seu próprio dado

Demo é peça de vendas. Isso não é problema, desde que você saiba ler os sinais.

Sinais de demo montada em ambiente controlado:

• Base pequena, limpa e com nomes fictícios óbvios.
• Nenhum campo customizado à vista.
• Nenhum erro, nenhuma latência perceptível, nenhuma tela de retentativa.
• O apresentador conduz a ordem e desvia de qualquer pedido fora do roteiro.
• Nada acontece "para trás": só o fluxo de ida é demonstrado.

O contra-teste é simples e educado: peça para executar dois passos do seu roteiro, escolhidos por você na hora, dentro da demo. Um deles deve ser um evento de volta (cancelamento ou comparecimento).

Se a resposta for "isso a gente mostra na implantação", você já tem a informação que precisava.

Piloto pago curto, em vez de contrato anual no escuro

O contrato anual assinado antes da primeira integração real transfere todo o risco para você.

A alternativa que funciona é um piloto pago, com escopo pequeno e prazo curto (exemplo: uma unidade, uma especialidade, 30 dias), com três condições escritas:

1. Critério de aceite objetivo, que é o roteiro do paciente-fantasma com os números medidos.
2. Conversão automática em contrato maior se o aceite passar, com preço já acordado (para o fornecedor não ficar refém do seu sim).
3. Saída limpa se o aceite falhar, com devolução ou crédito definido, e exportação dos dados que já entraram.

O piloto custa mais caro por mês que o anual. Ele compra informação, e informação sobre integração é a coisa mais barata que você pode comprar antes de assinar.

Versionamento e breaking change: o que acontece quando um dos dois atualiza

Integração não quebra sozinha. Ela quebra quando um dos dois lados muda.

E os dois lados vão mudar, porque software vivo atualiza.

Pergunte, dos dois fornecedores:

• Qual a política de aviso prévio para mudança que quebra compatibilidade?
• Por quanto tempo a versão anterior da API continua funcionando depois de uma nova?
• Existe ambiente de homologação onde a nova versão aparece antes da produção?
• Quem testa o conector contra a versão nova, e em que prazo?

Nota: esse é o ponto onde o nível 2 (plataforma intermediária) cobra o preço. O intermediário depende do aviso dos dois lados e reage depois de todo mundo.

Monitoramento e alerta: quem descobre que a integração parou

A pergunta certa não é "e se parar". É "quanto tempo passa entre parar e alguém saber".

Em clínica sem monitoramento, quem descobre é a recepcionista, quando um paciente aparece para uma consulta que não está na agenda. Isso costuma acontecer dias depois da falha.

Exija três coisas:

1. Alerta ativo de falha, que sai por e-mail ou mensagem para uma pessoa nomeada da sua equipe, não só para um painel do fornecedor.
2. Painel de fila e erro que você consegue abrir sozinho, com o que ficou parado e por quê.
3. Reprocessamento, para que o que falhou entre depois sem redigitação manual.

E instale a conferência de números que não depende do fornecedor: agendamentos, cancelamentos e comparecimentos precisam bater entre os dois sistemas, com tolerância definida antes e um dono para investigar divergência.

SLA de correção: canal, prazo, escalonamento e penalidade

SLA sem penalidade é intenção. Escreva os quatro elementos:

• Canal de abertura do chamado, com registro rastreável. Grupo de WhatsApp não é canal de SLA, porque não gera protocolo.
• Prazo de primeira resposta e prazo de correção, separados, em horas úteis definidas no contrato.
• Escalonamento nominal: quem é acionado se o prazo estourar, e quem é acionado depois dele.
• Penalidade proporcional: desconto na mensalidade, crédito, ou gatilho de rescisão sem multa após N ocorrências no mesmo período.

Sem penalidade, o incentivo do fornecedor é fechar o chamado, não resolver a causa.

A armadilha do "é do outro lado"

Você tem dois fornecedores. A integração falha. O fornecedor A diz que o problema está na API do B, o fornecedor B diz que o A está chamando errado.

Enquanto isso, a sua recepção redigita.

Essa é a falha mais previsível de toda integração multi-fornecedor, e ela se resolve no contrato, antes de acontecer:

1. Nomeie um responsável único pela integração (prime contractor). Preferencialmente quem vendeu o conector. Ele responde por ponta a ponta e aciona o outro lado sozinho.
2. Exija autorização cruzada de contato, para que os dois times possam falar diretamente sem passar pela clínica como intermediária.
3. Escreva a regra de triagem: quem produz o log, em quanto tempo, e o que serve como evidência para dizer de que lado está o erro.
4. Marque uma reunião conjunta na implantação, com os dois times na mesma chamada. Se um dos dois se recusa, você acabou de descobrir como vai ser o suporte.

LGPD: quem é controlador, quem é operador, e o que precisa estar no contrato

Dado de paciente é dado pessoal sensível. Isso muda a régua contratual.

Na prática, a clínica costuma ser controladora (decide a finalidade e os meios do tratamento) e o fornecedor de software costuma ser operador (trata em nome dela). Mas isso não pode ficar implícito: precisa estar escrito, com as obrigações que decorrem de cada papel.

Cheque no contrato:

• Definição explícita dos papéis de controlador e operador, por sistema e por fluxo.
• Finalidade e escopo do tratamento: o fornecedor pode usar o dado para quê, e o que ele está proibido de fazer (treinar modelo, agregar, revender, usar como base de estudo).
• Subcontratação: se o fornecedor usa outro fornecedor (nuvem, plataforma intermediária, serviço de mensagem), você precisa saber quem são e ter direito de ser avisado quando mudar.
• Eliminação ao fim do contrato: prazo, comprovação e o que fica retido por obrigação legal.

O mesmo raciocínio aplicado ao atendimento e ao registro de conversas está em LGPD na clínica odontológica: dados de leads e pacientes.

Comunicação de incidente de segurança

O contrato precisa dizer em quanto tempo o fornecedor avisa você de um incidente, e o que ele entrega junto: escopo, dados afetados, medidas tomadas.

Isso não é burocracia: como controladora, é a clínica que responde pela comunicação ao titular e à ANPD, dentro do prazo definido pela regulamentação. Se o fornecedor demora a te avisar, o prazo que corre é o seu.

Escreva prazo em horas, canal de aviso e pessoa nomeada dos dois lados.

Responsabilidade solidária na cadeia

Na cadeia de tratamento de dados, o dano causado por um elo não é automaticamente problema só dele. A clínica pode ser acionada por falha que aconteceu dentro do fornecedor.

Por isso o contrato precisa de cláusula de responsabilidade e de ressarcimento definida: quem indeniza o quê, e com que limite. Contrato de software genérico costuma limitar a responsabilidade do fornecedor ao valor de alguns meses de mensalidade, o que é desproporcional ao risco de um vazamento de base de pacientes.

Leia esse limite. Negocie ele.

Prontuário é registro legal: o que a integração não pode espelhar no CRM

Existe uma linha que a integração não deve atravessar, e ela não é técnica: é jurídica e ética.

O prontuário é registro clínico, com regras próprias de guarda, acesso e sigilo. O CRM comercial é ferramenta de venda, acessada por equipe comercial, com histórico de conversa e campos livres.

Espelhar conteúdo clínico no CRM amplia o acesso a informação sensível para pessoas que não precisam dela. Isso é risco desnecessário, e nenhuma eficiência de digitação compensa.

O que deve atravessar para o comercial:

• Existência do agendamento, data, hora, profissional e sala.
• Status: agendado, confirmado, cancelado, compareceu, faltou.
• Especialidade ou tipo de procedimento em nível de categoria comercial.
• Valor de orçamento apresentado e valor aprovado.

O que não deve atravessar:

• Evolução clínica, anamnese, diagnóstico e conduta.
• Imagem, laudo e exame.
• Prescrição.
• Qualquer campo de texto livre do prontuário.

Pergunte ao fornecedor qual é o comportamento padrão do conector nesse ponto, e exija a possibilidade de desligar campos clínicos, mesmo que a integração os suporte.

Certificação do sistema de prontuário e o que isso limita

Sistema de registro eletrônico em saúde no Brasil está sujeito a requisitos formais de certificação e a exigências de assinatura digital para o registro clínico. Isso não é detalhe de compliance: é o que explica por que certos dados não saem do sistema clínico por API, mesmo quando tecnicamente seria possível.

Na hora da compra, pergunte ao fornecedor do sistema clínico:

1. O sistema é certificado, e em qual nível?
2. Quais registros exigem assinatura digital e como isso afeta o que a API pode gravar de fora?
3. A integração escreve no prontuário ou só na agenda? (A resposta desejável, na maior parte dos casos, é só na agenda.)

Se o fornecedor do CRM promete gravar dentro do prontuário sem falar de assinatura e trilha de auditoria, desconfie. Ou ele não entende a regra, ou está prometendo o que não vai entregar.

Padrão aberto (HL7 FHIR / RNDS) ou conector proprietário

Conector proprietário resolve um par de sistemas. Padrão aberto resolve o próximo par também.

Essa distinção decide o seu custo de integração daqui a três anos, quando você trocar um dos dois lados, abrir unidade nova ou adotar mais uma ferramenta.

Perguntas de compra:

• O sistema fala algum padrão de interoperabilidade em saúde? Pergunte pelo nome (HL7 FHIR) e peça a lista de recursos suportados, não só o "sim".
• Está integrado à RNDS? Peça evidência, não declaração. Vale lembrar o dado da TIC Saúde 2025 (Cetic.br/CGI.br): entre os estabelecimentos privados, 26% responderam não saber se estão integrados à RNDS.
• O que é padrão e o que é extensão proprietária? Extensão não é problema, desde que identificada, porque é ela que não viaja para o próximo fornecedor.

Padrão aberto não é requisito absoluto para clínica odontológica hoje. Mas ele é um critério de desempate poderoso entre dois fornecedores parecidos, porque reduz o custo da sua próxima decisão.

Onde o dado fica hospedado e quem tem acesso

Auditoria de integração é também auditoria de hospedagem, porque a integração multiplica as cópias do dado.

Levante, por sistema e pela plataforma intermediária, se houver:

Item	O que perguntar
Local de hospedagem	Nuvem de qual provedor, em qual país
Trânsito	O dado atravessa fronteira? Passa por servidor de terceiro?
Criptografia	Em trânsito e em repouso, com qual escopo
Acesso interno	Quantas pessoas do fornecedor conseguem ver dado de paciente, e sob qual controle
Backup	Frequência, retenção e teste de restauração já executado
Log de acesso	Existe trilha de quem viu o quê, e você consegue solicitar

Nota: a plataforma intermediária é o ponto mais esquecido dessa lista. Ela costuma armazenar o histórico das execuções, e esse histórico contém dado de paciente.

Cláusula de saída: exportação completa, formato, prazo e custo

A hora de negociar a saída é antes de entrar. Depois, você não tem alavanca nenhuma.

Escreva quatro itens:

1. O que você leva. Base completa de cadastros, agendamentos, histórico e anexos. Especifique que inclui o histórico gerado pela integração, não só o que você digitou.
2. Em qual formato. Formato aberto e legível por máquina (CSV, JSON ou exportação estruturada equivalente), com dicionário de campos. Exportação em PDF de relatório não é exportação de dados.
3. Em quanto tempo. Prazo em dias contados do pedido, não "assim que possível".
4. Por quanto. Custo de desligamento definido no contrato de entrada. Se não estiver escrito, ele será decidido no momento em que você já quer sair.

Acrescente uma quinta: acesso somente leitura por um período após o encerramento, para a transição não coincidir com o corte.

Custos escondidos: as seis linhas que não aparecem na proposta

A proposta mostra a mensalidade. O custo total tem mais linhas, e algumas só aparecem depois.

Linha de custo	Onde costuma aparecer	Pergunta de auditoria
Setup e implantação	Cobrança única no início	Está incluso no valor apresentado? Cobre a carga inicial?
Licença por usuário	Cresce quando a equipe cresce	O que conta como usuário? Recepção de outra unidade conta?
Cobrança por chamada de API ou por operação	Fatura da plataforma intermediária	Qual o custo por mil operações? Existe teto?
Manutenção do conector	Contrato separado, no modelo de projeto	Quem paga o conserto quando um dos lados atualiza?
Reprocessamento e correção de dado	Serviço avulso, cobrado por hora	Falha do conector gera custo para mim?
Ambiente de homologação	Quase nunca aparece	Tem sandbox incluso ou é módulo pago?

A conta que importa não é a mensalidade: é o custo total de propriedade nos próximos 12 meses, com um cenário de volume dobrado. Peça a simulação nesse cenário, por escrito.

Se você quer a estrutura de custo do projeto de integração em si, a decomposição está em quanto custa integrar CRM com agenda sem parar a operação.

Dependência de plataforma intermediária: custo que escala e ponto único de falha

Plataforma intermediária é uma boa ferramenta e uma péssima surpresa.

Boa ferramenta porque conecta o que não tem conector nativo, rápido e sem projeto.

Péssima surpresa quando você descobre, um ano depois, que ela virou:

• Custo variável que escala com volume. Quanto mais a clínica cresce, mais caro fica exatamente a peça que você não controla.
• Ponto único de falha fora do seu perímetro. Se ela cai, os dois sistemas continuam de pé e a comunicação entre eles morre.
• Caixa-preta de lógica de negócio. As regras de de-para, filtro e transformação moram lá, muitas vezes sem documentação e sem versionamento.
• Dependência de uma pessoa. Quem montou o cenário costuma ser a única que entende, e frequentemente é do fornecedor.

Se a decisão for por esse caminho, imponha três condições: conta no seu CNPJ, documentação escrita dos cenários entregue a você, e teto de custo definido com gatilho de renegociação.

Checklist documental: o que exigir por escrito antes de assinar

Se você levar só uma coisa desta página para a próxima reunião, leve esta lista. Nada aqui é abusivo, e tudo isso existe quando o produto existe.

1. Classificação do nível da integração (1 a 4), declarada pelo fornecedor.
2. Documentação da API dos dois lados, com link público ou arquivo.
3. Lista de campos que atravessam, com direção e regra de transformação.
4. Lista de eventos com a marcação de webhook ou polling para cada um.
5. Número de latência medido, com o percentil e o método.
6. Política de rate limit e comportamento no estouro (fila ou perda).
7. Regra de identidade do paciente e tratamento de duplicata.
8. Tabela de fonte da verdade por campo, aprovada por você.
9. Escopo da carga inicial de histórico, com preço.
10. Roteiro de aceite assinado como critério de entrega.
11. SLA com canal, prazo, escalonamento e penalidade.
12. Papéis de LGPD, cláusula de incidente e limite de responsabilidade.
13. Plano de rollback: como voltar ao estado anterior se o go-live falhar.
14. Cláusula de saída com formato, prazo e custo.
15. Duas referências de cliente no mesmo par de sistemas.

Faltando os itens 1, 3, 10 e 15, você não tem informação suficiente para decidir. Não é pessimismo, é aritmética de risco.

Red flags na proposta e no discurso do vendedor

Alguns sinais aparecem antes de qualquer documento. Anote quando ouvir:

• "É nativo" sem nome de versão, changelog ou documentação.
• "É tudo em tempo real" sem número de latência.
• "A gente já fez isso" sem cliente atual que você possa contatar.
• "Isso a gente resolve na implantação" aplicado a duas ou mais perguntas seguidas.
• "Esse campo dá para colocar depois" sobre um campo que é central no seu processo.
• Desconto grande atrelado a contrato longo apresentado antes do teste de aceite.
• Recusa a colocar o critério de aceite no contrato, mesmo com o critério pronto e simples.
• Culpa preventiva do outro fornecedor, dita já na venda ("se o sistema deles atrapalhar, aí não é conosco").
• Nenhuma pergunta sobre o seu volume, processo e campos. Fornecedor que não pergunta nada não está dimensionando nada.

Um sinal isolado não condena ninguém. Três juntos mudam o nível da negociação, e devem mudar o preço, o prazo e a garantia.

A integração precisa funcionar quando a clínica está fechada

Esse é o teste que quase ninguém coloca no roteiro, e é onde a integração comercial mais rende.

O paciente não escolhe o seu horário comercial para decidir. Nas clínicas atendidas pela Odonto Results, 43,8% dos leads chegam fora do horário comercial e 19,8% chegam no fim de semana (base de 5.205 leads, dados internos da Odonto Results). Janela: 25 de março a 14 de junho de 2026.

Se a integração roda uma varredura só em horário comercial, ou se o webhook do lado da agenda depende de alguém logado no sistema, tudo o que acontece à noite entra na fila da manhã seguinte.

Pergunte três coisas ao fornecedor:

1. A consulta de disponibilidade funciona 24 horas, sem depender de sessão aberta?
2. O agendamento criado de madrugada aparece na agenda na hora ou no próximo expediente?
3. Existe janela de manutenção programada? Qual, com que aviso, e o que acontece com os eventos que chegam durante ela?

E rode o passo 8 do roteiro do paciente-fantasma em um domingo. É barato e revela muito.

Como medir, nos primeiros 30 dias, se a integração entregou o que foi vendido

Aceite não termina no go-live. Ele termina quando os números do primeiro mês batem.

Monte um painel simples, com cinco indicadores e uma meta escrita antes de ligar:

Indicador	Como medir	O que significa quando falha
Taxa de sincronização	Eventos que atravessaram / eventos que ocorreram	Perda silenciosa de dado
Latência efetiva	Tempo mediano e de percentil 95 por tipo de evento	Promessa comercial não bateu com produção
Duplicatas criadas	Cadastros novos do mesmo paciente por mês	Regra de identidade errada ou ausente
Divergência de agenda	Agendamentos no CRM x agendamentos na agenda	A conta que prova que a integração está viva
Redigitação restante	Contagem de casos que a equipe ainda digita duas vezes	O motivo real da compra não foi resolvido

Some um indicador de negócio, porque é ele que justifica o gasto: quantos agendamentos passaram a ter origem de campanha identificada e, na sequência, quantos viraram comparecimento com a origem preservada.

Se a integração não melhorou a atribuição do paciente na cadeira, ela resolveu digitação, não gestão. Pode valer o preço, mas é outra compra.

Quando a resposta certa é NÃO comprar

Nem todo problema de integração se resolve comprando integração. Três cenários em que o dinheiro rende mais em outro lugar:

1. A API de um dos lados não existe, ou é fechada por decisão comercial. Nenhum conector supera uma porta trancada de propósito. Aqui a conversa é sobre trocar o sistema, não sobre integrar.
2. O volume ainda não justifica. Se o número de eventos por dia é pequeno, um processo humano documentado, com responsável nomeado, checklist e conferência diária, entrega quase o mesmo resultado por muito menos, e não quebra quando alguém atualiza uma API.
3. O custo total escala sem teto com o seu crescimento. Integração que fica mais cara na mesma proporção do seu sucesso é imposto, não investimento.

Existe ainda um quarto caso, mais comum do que parece: o problema não é de sistema, é de processo. Antes de comprar, teste se dá para resolver sem trocar nada: padronize a rotina, nomeie o responsável, meça duas semanas e só então decida.

Lembre: integração é meio. O objetivo é paciente na cadeira com origem rastreada, não dois sistemas trocando mensagens bonitas entre si.

Governança interna: quem é dono da integração depois que o fornecedor vai embora

A implantação termina. O consultor sai. E aí?

Integração sem dono interno degrada em silêncio. Alguém muda um campo customizado, outra pessoa cria um status novo no CRM, a equipe adota uma convenção nova de nomes, e três meses depois metade dos registros para de atravessar sem que ninguém tenha "quebrado" nada.

Defina, por escrito, antes do go-live:

1. Um dono nomeado dentro da clínica, com nome e cargo. Normalmente é quem responde pelo CRC ou pela gestão, não o dentista.
2. Um substituto, porque dono único é ponto único de falha.
3. Uma rotina fixa de conferência, mensal no mínimo, com os cinco indicadores do painel e tolerância definida.
4. Uma regra de mudança: nenhum campo, status ou lista de domínio muda em qualquer um dos sistemas sem passar pelo dono da integração.
5. Um lugar único de documentação: onde ficam as credenciais, o mapa de campos, os contatos de suporte dos dois fornecedores e o histórico de incidentes.

Esse é o item mais barato da lista inteira e o que mais determina se a integração ainda estará funcionando daqui a um ano.

Seu próximo passo

1. Classifique a proposta que está na sua mesa hoje. Mande um e-mail curto pedindo, por escrito, em qual dos 4 níveis a integração está e duas referências de cliente rodando o mesmo par de sistemas. A resposta (ou a demora dela) já te diz muita coisa.
2. Escreva o roteiro do paciente-fantasma e transforme em cláusula de aceite. São os oito passos deste guia, com cronômetro. Enquanto o fornecedor não aceitar esse critério dentro do contrato, você não tem entrega definida, tem promessa.
3. Negocie piloto pago curto no lugar do anual, e instale o painel de cinco indicadores no dia 1. Meta escrita antes de ligar, conferência mensal e um dono nomeado dentro da clínica.

Quer que a sua captação seja medida até o paciente na cadeira, com a volta da agenda alimentando campanha e reativação em vez de planilha redigitada? Agende uma apresentação.