Mudei a tabela de preços e entrou procedimento novo: a IA de triagem de orçamento continua priorizando certo?

"Mudei a tabela de preços e entrou procedimento novo: a IA de triagem de orçamento continua priorizando certo?"

A resposta honesta é: você não sabe. E o jeito de descobrir não é olhar a conversa de hoje.

Quase toda clínica trata reajuste de tabela como assunto do financeiro. Alguém abre a planilha, corrige os valores, avisa a recepção e o assunto morre ali.

Só que a sua IA de triagem não decide com a planilha. Ela decide com o que foi escrito para ela em algum momento do passado, e ela não avisa quando esse passado fica velho.

É por isso que o erro dessa mudança quase nunca aparece como bug. Ele aparece três semanas depois, no fechamento do mês, como um número de conversão que ninguém consegue explicar.

O guia Rules of Machine Learning do Google tem uma regra dedicada a isso (Regra #10, falhas silenciosas). Ela descreve exatamente o seu cenário: quando uma tabela usada pelo sistema deixa de ser atualizada, o sistema de machine learning se ajusta, o comportamento continua razoavelmente bom e decai de forma gradual.

Razoavelmente bom é o problema. Não é quebra. É erosão.

Neste guia você vai ver:

• Por que mexer na tabela é um deploy na IA, com data, responsável e plano de volta atrás
• O que de fato muda (a palavra "retreinar" descreve mal o trabalho real)
• O checklist das peças que se desatualizam juntas e quase nunca são atualizadas juntas
• Como validar com gabarito de regressão, execução em sombra e matriz de discordância
• O painel de vigia das duas primeiras semanas e os erros que invalidam a validação inteira

Mexer na tabela de preços é um deploy, não um ajuste administrativo

Comece pelo enquadramento, porque ele muda todo o resto.

Se a tabela é um documento vivo que a IA consulta para priorizar orçamento, então alterar essa tabela altera o comportamento de um sistema que fala com paciente e ordena a sua fila de dinheiro. Isso é deploy.

Deploy tem três coisas que ajuste administrativo não tem:

1. Data e hora exatas. Você precisa saber a partir de qual minuto o comportamento mudou, para separar o antes do depois em qualquer análise.
2. Responsável nomeado. Uma pessoa que assina a mudança e responde por ela. Não "o financeiro" nem "a agência".
3. Plano de volta atrás. A versão anterior guardada e pronta para voltar em minutos, sem depender de ninguém lembrar como era.

Sem essas três, você não consegue nem investigar. Quando o número do mês vier estranho, a pergunta "mudou alguma coisa na triagem?" não vai ter resposta.

Lembre: o custo de tratar a mudança como deploy é uma anotação curta. O custo de não tratar é passar um mês inteiro discutindo se a queda foi sazonalidade, campanha ou a IA.

O que de fato muda quando o preço muda (a palavra "retreinar" engana)

A pergunta que todo dono faz é "preciso retreinar a IA?". Na prática, quase nunca existe retreino de modelo. Existe atualização de cinco peças diferentes, e elas ficam em lugares diferentes.

1. A tabela-fonte que a IA consulta. O documento de valores que a IA lê na hora de responder. Se ele estiver versionado e for consultado em tempo real, a mudança é rápida.

2. O prompt ou a instrução de triagem. O texto que explica à IA o que é caso prioritário, o que escala e o que segue fluxo normal. Se houver preço escrito aqui dentro, ele virou código.

3. A régua de priorização. A lógica que ordena a fila: ticket estimado, urgência clínica, canal de origem, histórico do paciente. Reajuste mexe no peso do ticket dentro dessa régua, mesmo que ninguém tenha tocado nela.

4. O catálogo de procedimentos. A lista de nomes que a IA reconhece. Procedimento novo que não está no catálogo não existe para ela.

5. Os sinônimos que o paciente usa. O paciente não escreve "reabilitação oral com carga imediata". Ele escreve "dente fixo no mesmo dia", "arcada toda", "vou tirar tudo e colocar". Sem esses termos mapeados, a classificação erra na entrada.

Repare no que essa lista revela: quatro das cinco peças não têm nada a ver com modelo de IA. São dados de operação. Por isso "retreinar" descreve mal o trabalho. O trabalho é sincronizar fontes de verdade.

Se quiser aprofundar a parte de alimentar o sistema com a realidade da clínica, veja como treinar e alimentar a IA de atendimento com os dados da clínica.

Checklist: as peças que se desatualizam juntas e quase nunca são atualizadas juntas

Este é o ponto onde a maioria das clínicas perde dinheiro sem perceber. O financeiro atualiza o preço. Ninguém atualiza o resto.

Peça	O que ela decide	O que quebra se ficar velha	Quem costuma atualizar
Tabela de valores	Ticket estimado de cada caso	A fila inteira ordena por um valor que não existe mais	Financeiro
Catálogo de procedimentos	O que a IA reconhece como tratamento	Procedimento novo cai no balde mais parecido	Ninguém
Sinônimos e termos do paciente	Se a IA entende o pedido na entrada	Erro de classificação antes de qualquer régua rodar	Ninguém
Faixas de ticket	Quem é caso de alto valor	Casos médios viram "alto" em bloco depois do reajuste	Ninguém
Limite de escalonamento em reais	Quem sobe para o dono ou para a CRC sênior	Volume de escalonamento muda sozinho	Ninguém
Duração e cadeira por procedimento	Se o agendamento cabe na agenda	A IA agenda o que a clínica não consegue executar	Coordenação clínica
Cobertura de convênio	Se o caso é particular, convênio ou misto	Promessa errada de cobertura na primeira mensagem	Recepção
Scripts de follow-up	O que a IA fala ao retomar orçamento em aberto	Paciente recebe valor antigo semanas depois	Marketing

Oito peças. Uma dona. Sete órfãs.

Antes de continuar, pergunte-se: quando foi a última vez que alguém abriu a lista de sinônimos da sua IA?

Procedimento novo é uma classe que não existe no gabarito

Reajuste e lançamento são problemas diferentes, e confundir os dois custa caro.

Reajuste move casos dentro de classes que já existem. A IA continua sabendo o que é implante, o que é orto e o que é clareamento. Só o valor de cada um mudou.

Procedimento novo cria uma classe que não existe. A IA nunca viu aquilo. E o comportamento padrão de um classificador diante do desconhecido não é dizer "não sei". É empurrar o caso para o balde mais próximo.

Suponha que você lançou um protocolo de reabilitação com fluxo digital e ticket bem acima da média da casa. Se o catálogo não tem esse item, o paciente que pergunta por ele vira "implante" na cabeça da IA. Entra numa faixa de ticket errada, recebe o script errado e não aciona o escalonamento que um caso desse porte exigiria.

A clínica não descobre isso no dia. Descobre no fechamento do mês, quando alguém pergunta por que o procedimento que entrou em campanha não apareceu no fechamento na proporção esperada.

O sintoma tem nome e tem método de auditoria. Vale ler como auditar erro de classificação da IA de triagem entre particular e convênio, porque o mecanismo é o mesmo.

Dica: antes de o procedimento novo entrar em campanha, coloque no catálogo o nome técnico, os apelidos que o paciente usa, a faixa de ticket, a duração de cadeira, a cobertura de convênio e pelo menos um punhado de conversas rotuladas à mão. Sem exemplos, você não tem como testar nada.

Régua de escalonamento em reais: o reajuste que muda quem sobe para o dono

Aqui mora o efeito colateral mais silencioso de todos.

Quase toda clínica com IA de triagem tem uma régua de escalonamento denominada em reais: acima de um valor, o caso sobe para o dono ou para a CRC sênior. Suponha que a sua régua mande escalar todo orçamento estimado acima de R$ 5.000.

Agora suponha um reajuste linear de 8% na tabela inteira.

Você não tocou na régua. Mas a fatia de casos que cruza esse corte do exemplo aumentou, porque todos os valores subiram e o corte ficou parado. O dono passa a receber mais casos, muitos deles do mesmo perfil que antes seguia fluxo normal.

O inverso também acontece. Se você baixou preço para ganhar volume num procedimento, o corte deixa de ser cruzado por casos que antes subiam, e o dono para de ver o que precisava ver.

Nos dois cenários ninguém mexeu na IA. Mexeu no denominador.

A decisão de onde colocar esse corte merece atenção própria. Veja a partir de que valor a IA deve escalar o orçamento para o dono.

Faixa de ticket absoluta x relativa: o que recalibrar quando a tabela sobe

A régua em reais é fácil de escrever e fácil de quebrar. A régua relativa é mais chata de montar e resiste melhor ao reajuste.

Critério	Faixa absoluta (em reais)	Faixa relativa (percentil ou múltiplo do ticket médio)
Como é escrita	"Acima de um valor fixo em reais"	"Acima do ticket médio do período anterior" ou "no topo da distribuição"
O que acontece no reajuste	O corte fica parado e a fatia acima dele muda sozinha	O corte acompanha a tabela sem intervenção
Facilidade de explicar para a equipe	Alta, todo mundo entende	Média, exige um painel que mostre o corte vigente
Risco principal	Desatualizar em silêncio	Deriva devagar se a distribuição mudar de forma
Quando usar	Limite de alçada, aprovação de desconto, gatilho jurídico	Priorização de fila e definição de caso de alto valor
Manutenção exigida	Revisar a cada mudança de tabela	Revisar a cada mudança de mix de procedimento

A recomendação prática é misturar as duas. Use faixa relativa para ordenar a fila (porque ela se ajusta sozinha) e faixa absoluta só onde existe alçada de verdade, com a obrigação explícita de revisar o valor sempre que a tabela mudar.

O importante é que a escolha seja consciente. Régua em reais sem data de revisão é uma bomba com relógio.

Fonte única de verdade: preço consultado x preço memorizado no prompt

Esta seção decide se a sua próxima mudança de tabela leva dez minutos ou uma semana.

Existem dois jeitos de a IA saber o preço:

Preço consultado. A IA lê a tabela na hora de responder, em um documento ou sistema versionado. Você troca o documento, a IA passa a responder com o valor novo na conversa seguinte.

Preço memorizado. O valor está escrito dentro da instrução da IA, no meio do texto que define como ela se comporta. Trocar exige editar o prompt, reler tudo em volta, revalidar e republicar.

A segunda opção cria um problema que o próprio guia do Google aponta. A Regra #31 alerta que, quando o sistema cruza dados de uma tabela no treino e na hora de servir, os dados dessa tabela podem mudar entre um momento e outro. Traduzindo para a sua clínica: a versão do preço que a IA aprendeu e a versão que está valendo hoje podem ser duas coisas diferentes, e nada no sistema acusa a diferença.

Pensa assim: preço dentro do prompt é preço em fotocópia. Preço em tabela consultada é preço no original.

Se hoje o seu preço está no prompt, a migração para tabela consultada é o investimento de maior retorno desta lista inteira. Ela transforma toda mudança futura de tabela em operação de minutos, e derruba a chance de a IA falar um valor que a clínica não pratica mais.

Requisito de frescor: quanto tempo a triagem aguenta com a tabela velha

Frescor não é vaidade técnica. É uma decisão de negócio que você precisa tomar e escrever.

A Regra #8 do guia do Google coloca a pergunta na forma certa: quanto o desempenho degrada se você tem um modelo com um dia de idade? Uma semana? Um trimestre?

Faça a mesma pergunta com a sua tabela, procedimento por procedimento:

• Alto ticket com margem apertada. Um dia de valor errado já vira desconto involuntário em caso grande. Tolerância baixíssima.
• Procedimento em campanha. Se você está pagando mídia para gerar demanda daquilo, a tabela errada contamina o funil inteiro enquanto a campanha roda.
• Procedimento de baixo valor e alto volume. O erro unitário é pequeno, mas se acumula. Tolerância média.
• Procedimento raro. Tolerância alta em dinheiro, risco alto de constrangimento, porque quando acontece é com um paciente que pesquisou muito.

Escreva o número de dias aceitável para cada grupo e transforme isso em regra de operação: a tabela da IA não pode estar mais velha que esse prazo, e alguém confere.

Sem prazo escrito, o padrão vira "atualiza quando alguém lembrar". E ninguém lembra.

Falha silenciosa: por que ninguém percebe o erro a tempo

Já citei a Regra #10 lá em cima porque ela é o coração deste artigo. Vale destrinchar o mecanismo.

Sistema que quebra alto é fácil. A IA para de responder, o paciente reclama, alguém conserta em uma hora.

Sistema que degrada é o inimigo. A IA continua respondendo, continua educada, continua agendando. Só que ordena a fila com um critério que não vale mais e classifica o procedimento novo no balde errado.

O guia do Google descreve isso com precisão: o sistema de machine learning se ajusta e o comportamento continua razoavelmente bom, decaindo gradualmente.

Três sinais que aparecem antes do estrago virar número:

1. A equipe começa a corrigir a IA na mão com frequência maior do que o normal, sem ninguém registrar.
2. O dono recebe mais (ou menos) escalonamento do que costumava, e atribui isso a "mês fraco".
3. O procedimento novo não aparece na proporção que a campanha deveria produzir.

Nenhum desses três dispara alerta em sistema nenhum. Todos os três aparecem em conversa de corredor. Seu trabalho é transformá-los em indicador olhado toda semana.

Deriva de conceito: o mix de perguntas muda quando o procedimento entra em campanha

Tem um segundo movimento acontecendo ao mesmo tempo, e ele não vem da tabela. Vem da mídia.

Quando você lança um procedimento e coloca verba atrás dele, muda o perfil de quem chega. Muda o vocabulário das perguntas, muda a proporção entre curioso e paciente decidido, muda a distribuição de ticket na entrada.

Isso é deriva de conceito: a relação entre o que entra e o que deveria sair mudou, mesmo com a régua parada.

Efeito prático: uma régua que estava calibrada para um mix onde a maioria era caso médio começa a operar num mix com mais caso alto. Os limiares que funcionavam passam a classificar demais ou de menos.

Por isso a validação da mudança de tabela e a leitura da campanha nova precisam acontecer na mesma janela. Separar as duas produz a conclusão errada nas duas.

Lembre: se você mudou tabela e ligou campanha nova na mesma semana, aceite que não vai conseguir isolar as causas. Ou escalona as mudanças, ou mede as duas juntas sabendo que a atribuição vai ficar em aberto.

O gabarito de regressão: o teste que roda antes de a IA falar com paciente

Chega a parte prática. Como você prova que a versão nova prioriza certo?

Com um gabarito de regressão: um conjunto fixo de conversas reais, já rotuladas por você, com a classificação correta definida à mão.

Como montar:

1. Puxe conversas reais dos últimos meses, cobrindo todos os procedimentos que a clínica atende, incluindo os casos esquisitos (áudio, pergunta fora de ordem, paciente que muda de ideia no meio).
2. Rotule à mão com o dono ou a CRC sênior: qual deveria ser a classificação, a prioridade e o destino de cada caso.
3. Congele o conjunto. Ele não muda a cada rodada, senão você perde a comparabilidade entre versões.
4. Adicione os casos novos do procedimento recém-lançado. Se ainda não houver conversa real dele, use as conversas do procedimento mais próximo e rotule com a régua nova, deixando marcado que são casos de transição.
5. Rode a versão nova contra o gabarito inteiro antes de qualquer paciente falar com ela.

Um detalhe que parece pequeno e não é: guarde também o resultado da versão antiga no mesmo gabarito. Sem isso você não tem com o que comparar, e "a versão nova acertou quase tudo" não diz nada.

Casos inventados não servem. Eles são limpos demais, escritos como você escreveria, e passam em qualquer teste. O paciente real escreve com erro, manda áudio, pergunta preço antes de dizer o que quer e some no meio.

Execução em sombra e canário: rodar a versão nova sem risco

Gabarito valida o conhecido. Sombra valida o desconhecido.

Execução em sombra é rodar a versão nova em paralelo com a antiga, sobre as conversas reais que estão acontecendo, sem que a versão nova responda ninguém. Ela só registra o que teria decidido.

Durante alguns dias você acumula pares de decisão: o que a versão antiga fez, o que a versão nova teria feito. Nenhum paciente é cobaia.

Canário é o passo seguinte: promover a versão nova para uma fatia pequena do fluxo real (um canal, um turno, uma origem de lead), com a régua de volta atrás pronta.

A ordem que reduz risco:

1. Gabarito de regressão fechado e explicado
2. Sombra por alguns dias sobre tráfego real
3. Canário numa fatia pequena, com vigilância diária
4. Promoção total, com o painel de vigia ligado

Cada etapa responde uma pergunta diferente. Gabarito responde "acerta o que eu já sei?". Sombra responde "o que ela faria com o que chega hoje?". Canário responde "o que acontece de verdade quando ela decide?".

Matriz de discordância: separar a mudança desejada do efeito colateral

Com sombra ou gabarito rodando, você tem duas decisões por caso. Organize a comparação assim:

Versão antiga	Versão nova	Leitura	O que fazer
Prioridade alta	Prioridade alta	Estável	Nada
Prioridade baixa	Prioridade baixa	Estável	Nada
Prioridade baixa	Prioridade alta	Mudança pretendida (o reajuste elevou o ticket) ou efeito colateral	Ler uma amostra à mão e classificar qual dos dois é
Prioridade alta	Prioridade baixa	Quase sempre efeito colateral	Investigar caso a caso antes de promover
Classificada	Não reconhecida	Regressão no catálogo	Bloqueia a promoção
Não reconhecida	Classificada	Ganho do procedimento novo	Confirmar que a classe está certa, não só presente

A regra de ouro: toda célula fora da diagonal precisa de explicação escrita. Se você não consegue dizer por que aquele caso mudou de lado, você não entendeu a sua própria mudança.

E preste atenção no volume das discordâncias, não só na direção. Uma mudança de tabela que faz metade da fila trocar de prioridade não é reajuste. É régua nova disfarçada.

Precisão, recall e o paradoxo da acurácia no dia do reajuste

Aqui é onde a maioria das validações caseiras se engana. Elas olham acurácia global.

O Machine Learning Crash Course do Google mostra por que isso não serve: em conjuntos fortemente desbalanceados, onde uma classe aparece muito raramente (digamos, 1% das vezes), um modelo que responde negativo 100% das vezes marcaria 99% de acurácia, apesar de ser inútil.

Sua fila de orçamento é desbalanceada desse jeito. A maioria esmagadora dos casos cai numa classe só. Um classificador preguiçoso que chuta a classe majoritária sempre vai parecer excelente na acurácia e vai ser péssimo exatamente onde está o dinheiro.

Use os dois indicadores que o mesmo material define:

• Precisão é a proporção de todas as classificações positivas do modelo que são de fato positivas. Traduzindo: dos casos que a IA marcou como alto valor, quantos eram mesmo.
• Recall é a proporção de todos os positivos reais que foram classificados corretamente. Traduzindo: dos casos que eram de fato alto valor, quantos a IA pegou.

E o ponto que mais dói: o mesmo material aponta que precisão e recall costumam mostrar uma relação inversa, em que melhorar um piora o outro.

Na clínica isso vira uma decisão de dono, não de técnico:

• Perder caso bom (recall baixo) é margem que nunca aconteceu, e você nem fica sabendo. Custo invisível.
• Escalar caso ruim (precisão baixa) é tempo do dono e da CRC sênior gasto com quem não vai fechar. Custo visível.

Qual dos dois você prefere errar depende do seu gargalo. Se a agenda tem folga, erre para o lado do recall. Se o gargalo é tempo da equipe sênior, erre para o lado da precisão. O que não dá é fingir que existe ponto sem escolha.

O custo do lado invisível tem método de medição próprio, vale ver quanto custa o falso negativo da triagem de orçamento com IA.

Concordância com a régua humana: kappa, revisão por amostra e o desempate

Precisão e recall exigem gabarito. Mas quem define o gabarito?

Um humano. E humanos discordam entre si.

Por isso a validação séria mede também a concordância entre a IA e a régua humana, e entre os próprios humanos. O coeficiente kappa serve para isso: ele desconta a concordância que aconteceria por acaso, o que a simples contagem de "batemos em tanto por cento dos casos" não faz.

Três regras de operação que valem mais que a estatística:

1. Dois revisores independentes rotulam a mesma amostra sem ver a decisão um do outro.
2. Um desempatador nomeado (em geral o dono) resolve os casos em que os dois discordam, e a decisão dele vira regra escrita.
3. Toda discordância humana vira melhoria de instrução. Se dois membros da equipe discordam do que é prioridade, a IA não tinha como acertar: a régua estava ambígua.

Esse terceiro ponto é o mais valioso do processo inteiro. Validar IA de triagem costuma revelar que a clínica nunca tinha escrito com clareza o que é caso prioritário.

LLM como juiz: varrer a primeira semana inteira sem parar a operação

Revisão humana não escala. Ninguém vai ler todas as conversas da semana.

A saída prática é usar um modelo como juiz: um segundo sistema que lê cada conversa e classifica se a triagem decidiu certo, segundo a régua escrita. Isso permite varrer o volume inteiro da primeira semana pós-mudança em vez de uma amostra minúscula, sem parar a operação.

Como fazer isso sem se enganar:

• Escreva a régua de julgamento de forma explícita, com exemplos de certo e errado. Juiz sem régua reproduz o gosto pessoal do modelo.
• Calibre com amostra humana. Sorteie uma amostra aleatória das conversas julgadas e revise à mão. Compare. Se o juiz e o humano divergem muito, o problema é o juiz.
• Conheça os vieses do método. Modelo usado como juiz tende a favorecer resposta mais longa, tende a preferir texto com o próprio estilo e é sensível à ordem em que as opções aparecem. Neutralize o que der: embaralhe a ordem, padronize o tamanho, não deixe o juiz saber qual versão produziu qual resposta.
• Use o juiz para triar, não para absolver. O valor dele é apontar onde olhar. A decisão sobre caso duvidoso continua humana.

Dica: junte o julgamento da IA com um sorteio humano semanal fixo. A varredura pega o padrão, a amostra humana impede o juiz de derivar em silêncio.

Painel de vigia das duas primeiras semanas

Validação antes do deploy reduz risco. Não elimina. O que fecha o ciclo é vigiar o comportamento real logo depois.

Defina a janela antes de mexer (digamos, as duas primeiras semanas) e não mude o recorte no meio.

Indicador	O que ele pega	Sinal de que algo quebrou
Mix de classes de triagem	Redistribuição da fila	Uma classe engorda ou some sem relação com o que você mudou
Percentual escalado para o dono ou CRC sênior	Efeito do corte em reais	Volume de escalonamento muda sem você ter mexido na régua
Taxa de resposta do lead	Qualidade da primeira mensagem	Queda sustentada por vários dias seguidos
Lead para agendamento	Efeito final na conversão	Desvio que persiste e que você não consegue explicar pela mudança
Tempo até agendar	Atrito novo na conversa	Alongamento consistente, sinal de que a IA passou a pedir informação demais
Casos "não reconhecido"	Buraco no catálogo	Qualquer aparição do procedimento novo nessa fila
Correções manuais da equipe	Desconforto que não virou número	Aumento de vezes em que alguém reclassifica na mão

Cada linha só significa alguma coisa contra um baseline. Salve os números do mês anterior antes de mexer na tabela. Depois é tarde.

Para dar referência do que essas linhas costumam valer numa operação com IA no WhatsApp, três recortes nossos servem de régua de ordem de grandeza.

Segundo dados internos da Odonto Results (2026), 12% dos leads viram agendamento dentro do WhatsApp (faixa 9% a 15%), sem contar telefone. Base: 21.433 leads. Janela: 25 de março a 25 de agosto de 2026.

Segundo dados internos da Odonto Results (2026), entre os leads que respondem à clínica no WhatsApp, a mediana entre clínicas é de 21% que viram agendamento na conversa (faixa típica de 16% a 28%), sem contar telefone. Base: 21.433 leads. Janela: 25 de março a 25 de agosto de 2026.

Segundo dados internos da Odonto Results (2026), entre os leads que agendam, metade fecha em até 34 minutos e 53,6% em menos de 1 hora. Base: 3.148 agendamentos. Janela: 25 de março a 25 de agosto de 2026.

O uso correto desses números não é copiar a meta. É entender que o tempo até agendar é curto, então uma versão nova que introduz atrito aparece rápido no indicador, e não em três meses.

Convênio e capacidade: as duas perguntas que o procedimento novo cria

Procedimento novo não muda só preço. Muda o que a IA precisa perguntar e o que a agenda consegue absorver.

Cobertura de convênio e coparticipação

Se o procedimento tem cobertura parcial, cobertura por carência ou coparticipação, a triagem precisa de uma pergunta nova logo no início da conversa. Sem ela, a IA classifica como particular quem é convênio (ou o contrário) e a primeira mensagem já promete o que a clínica não vai cumprir.

O que precisa estar escrito antes de a campanha subir:

• Se o procedimento é coberto, por quais convênios e em que condição
• Se existe coparticipação e como ela é comunicada
• Se existe carência e quem confere isso
• Qual é a pergunta exata que a IA faz para separar os casos

Duração, cadeira e a fila que o procedimento novo fura

Todo procedimento novo consome cadeira. Se a duração e o profissional habilitado não estão no sistema, a IA agenda o que a clínica não consegue executar, e o problema aparece como remarcação na semana seguinte.

Coloque no catálogo, junto com o preço: duração real (não a otimista), quais profissionais executam, quais dias da semana e quantos casos por semana a estrutura aguenta. Priorização que ignora capacidade não é priorização, é lista de espera com nome bonito.

Governança: versão, changelog, assinatura e revisão

Nada disso sobrevive a três meses sem processo. O mínimo viável cabe em cinco itens:

1. Versionamento. Cada versão da tabela, do catálogo e da instrução tem número e data. Você consegue dizer qual versão estava no ar em qualquer dia do mês passado.
2. Changelog datado. Uma linha por mudança: o que mudou, por quê, quem pediu, quando entrou. Um punhado de linhas por trimestre resolve investigações que levariam dias.
3. Assinatura nomeada. Uma pessoa responde pela mudança. Mudança sem dono é mudança que ninguém revisa.
4. Supervisão humana com amostra fixa. Uma revisão semanal de amostra aleatória, com resultado registrado. A frequência importa menos que a constância.
5. Revisão dos resultados propostos. Para os casos de maior valor, a decisão da IA é sugestão, não comando. Alguém confirma antes de a fila se reorganizar.

Existe um efeito colateral bom nisso tudo. Quando a divergência de critério entre dentistas aparece no changelog, ela para de ser assunto de bastidor e vira decisão do dono, com data.

Cadência: reajuste programado x mudança de emergência

Nem toda mudança de tabela merece o mesmo ritual. Separar as duas evita que o processo vire burocracia e seja abandonado.

Dimensão	Mudança programada (reajuste anual, revisão de tabela)	Mudança de emergência (custo de insumo, convênio novo, erro de valor)
Aviso prévio	Semanas	Horas
Validação exigida	Gabarito completo, sombra e canário	Gabarito reduzido aos procedimentos afetados
Quem assina	Dono, com a coordenação clínica	Dono, sozinho se preciso
Janela de vigia	Duas semanas com painel completo	Vigilância diária até estabilizar
Volta atrás	Planejada e testada	Obrigatória e à mão
Risco principal	Efeito colateral amplo e silencioso	Erro pontual que vaza para o paciente rápido

A mudança programada é onde você faz o trabalho completo. A de emergência é onde você precisa do mínimo que não deixa vazar erro.

O erro clássico é inverter: fazer o ritual completo na emergência (e chegar tarde) e nenhum ritual no reajuste anual (que é justamente o que muda tudo de uma vez).

A pergunta de fundo: o reajuste corrigiu a margem ou só deslocou o problema?

Vale uma verificação de negócio antes de fechar, porque priorizar certo um preço errado não resolve nada.

Reajuste de tabela costuma ser uma resposta a pressão de custo. Mas custo variável e custo fixo se comportam de forma diferente quando o preço sobe.

• Custo variável (material, laboratório, descartáveis) acompanha o volume. Reajuste que só repassa aumento de insumo devolve a margem unitária ao patamar anterior, não melhora nada.
• Custo fixo diluído (aluguel, equipe, estrutura) se comporta como percentual do faturamento e cai quando o volume sobe. Reajuste que reduz volume pode piorar a margem final mesmo com ticket maior.

Ou seja: a conta só fecha se você olhar preço, mix e volume juntos, depois da mudança. A IA de triagem entra aqui como instrumento de medição, porque é ela que registra o mix real de pedidos que chega.

Se a revisão de tabela ainda está em aberto, feche a conta de margem por procedimento antes de programar o próximo reajuste. Priorizar bem um preço errado não recupera nada.

Os erros que invalidam a validação inteira

Seis erros comuns. Cada um deles transforma o trabalho de validação em teatro.

1. Testar com casos inventados. Conversa escrita por você passa em qualquer teste. Use conversa real, com a bagunça real.
2. Medir só acurácia global. Em fila desbalanceada, acurácia alta convive com erro total onde está o dinheiro.
3. Não guardar o baseline. Sem os números do mês anterior, qualquer variação depois vira opinião.
4. Mudar tabela e campanha na mesma semana. As duas causas se misturam e nenhuma análise separa depois.
5. Liberar sexta à noite. O erro roda o fim de semana inteiro sem ninguém olhando, e a segunda começa com fila bagunçada.
6. Não testar a volta atrás. Plano de rollback que nunca foi executado não é plano, é intenção.

Lembre: validação não é provar que a IA está certa. É descobrir onde ela está errada enquanto isso ainda é barato.

Seu próximo passo

1. Faça o inventário das oito peças. Abra hoje a tabela, o catálogo, os sinônimos, as faixas de ticket, o limite de escalonamento, a duração de cadeira, a cobertura de convênio e os scripts de follow-up. Anote a data da última atualização de cada uma. O resultado costuma ser desconfortável.
2. Monte o gabarito de regressão antes da próxima mudança. Puxe conversas reais, rotule com o dono e a CRC sênior, congele o conjunto e salve o baseline do mês anterior. Sem esses dois ativos, nenhuma validação futura vale nada.
3. Transforme a próxima mudança de tabela em deploy. Data, responsável, plano de volta atrás, sombra por alguns dias, canário e painel de vigia por duas semanas. Faça uma vez e vire rotina.

Quer que a triagem, o escalonamento e o painel de vigia da sua clínica sejam operados como sistema medido, e não como planilha que alguém lembra de atualizar? Agende uma apresentação.