Atualizado 2026-08-01 · 4 min de leitura
É uma das perguntas mais razoáveis que nos fazem, e costuma vir de uma clínica que tem as coisas em ordem: tenho o meu programa há anos, a minha equipa sabe-o, o meu processo clínico está lá. Não posso pôr-lhe a IA por cima e pronto?
A resposta honesta: às vezes sim, quase nunca é tão simples, e há uma terceira via que é a que quase toda a gente acaba por usar.
Porque «pôr a IA por cima» soa mais fácil do que é
Para que um assistente feche uma consulta — não recolha o recado: a feche — precisa de quatro coisas contra o seu programa atual: ler tratamentos, durações e médicos; consultar o que está livre neste momento; escrever a consulta; e saber se alguém a muda ou cancela a partir do programa.
As quatro exigem que o seu software tenha uma API aberta a terceiros. E aí está o problema: boa parte dos programas de gestão dentária não a oferece, ou reserva-a para acordos comerciais com parceiros concretos. Não é má-fé: é o modelo de negócio deles.
Quando não há API, o que lhe vão oferecer é um assistente que conversa muito bem e acaba com «vou passar à clínica». Isso não automatiza nada: muda o trabalho de sítio, porque a receção continua a ter de escrever a consulta.
Se um fornecedor lhe promete integrar-se com o seu programa, faça-lhe uma só pergunta: a consulta fica escrita sozinha na minha agenda, ou alguém a tem de passar? Tudo o resto é secundário.
As três vias reais
Cada uma tem o seu lugar, e a primeira é perfeitamente legítima se adora o seu programa e ele tem API.
| Conector à medida | Assistente que recolhe recado | Sistema integrado | |
|---|---|---|---|
| Requisito | Que o seu programa tenha API | Nenhum | Nenhum |
| Fecha a consulta sozinho? | Sim, se a API o permitir | Não: alguém a passa à mão | Sim |
| Custo inicial | Desenvolvimento (milhares de €) | Baixo | Nenhum |
| Custo contínuo | Mantê-lo sempre que a API mudar | Mensalidade + tempo da sua equipa | Mensalidade fixa |
| Quem o arranja se falhar | Quem o desenvolveu | — | O fornecedor |
| Muda de programa? | Não | Não | Sim |
A terceira via: conviver, não migrar de uma vez
O que quase toda a gente faz não é nenhuma das duas anteriores. A sincronização com o Google Calendar funciona nos dois sentidos: o que o assistente marca aparece no calendário em segundos, e o que a sua equipa bloqueia lá é respeitado e não se oferece a ninguém. Se a sua clínica já vive no calendário do telemóvel, o dia a dia não muda.
Isso permite um período de convivência real: nas primeiras semanas o assistente atende só WhatsApp e Instagram enquanto o seu programa continua a ser o seu programa; depois ativa-se o telefone, e só para as chamadas que não conseguem atender. Se ao fim de um mês não trouxer nada, desliga-se e não aconteceu nada.
A base de pacientes importa-se por CSV: só acrescenta fichas novas, nunca pisa uma existente. O histórico de tratamentos do seu programa anterior não se pode trazer automaticamente — cada um exporta à sua maneira — e preferimos dizê-lo antes do que depois.
O que se perde ao integrar tudo num sítio
É mais um fornecedor de quem depender: se amanhã não o convencermos, leva os seus dados exportáveis mas muda de ferramenta outra vez, e isso é um custo real.
E a nossa forma de organizar a agenda é a nossa. Adapta-se a bastante, mas se a sua clínica vive de uma regra muito própria que nenhum software de catálogo respeita, um desenvolvimento à medida dar-lhe-á mais liberdade: mais caro, mais lento a arrancar e mais seu.
Como decidir em cinco minutos
Pergunte ao seu fornecedor atual, por escrito, duas coisas: têm API pública para consultar disponibilidade e criar consultas a partir de outra ferramenta? E está documentada e posso dá-la a quem eu quiser?
Se a resposta for sim às duas, tem uma via que muitas clínicas não têm: fique com o seu programa e monte a camada de IA por cima. Se for não — e costuma ser não —, a escolha real não é integrar ou mudar, é continuar a responder vocês ou mudar.