SLAs e runbooks para fallback humano: o que exigir de uma plataforma de atendimento com IA
Use critérios contratuais, testes de POC e métricas de escalonamento para proteger leads, pacientes e a operação da recepção.
Falar com um especialista
Neste artigo9 seções
- Por que o SLA de fallback humano deve pesar na decisão de compra
- Quais cláusulas de SLA exigir para a transferência ao atendimento humano
- Como avaliar o runbook de fallback antes de assinar
- Matriz de aceitação para testar SLAs de fallback na POC
- Métricas contratuais para medir transferência, fallback e resolução
- Plano de contingência para picos, falhas e perda de integração
- Como negociar créditos e penalidades por descumprimento do SLA
- Como comparar fornecedores genéricos e plataformas focadas em saúde
- Checklist final antes de assinar o contrato
Por que o SLA de fallback humano deve pesar na decisão de compra
O comparativo de SLAs e runbooks para fallback humano em plataformas de atendimento com IA precisa ir além da disponibilidade do sistema. Para clínicas, laboratórios e hospitais, o risco mais caro aparece quando a inteligência artificial encontra uma exceção clínica, uma objeção complexa ou uma falha de integração e não consegue conduzir o paciente até o agendamento.
Uma plataforma pode permanecer disponível durante todo o mês e, ainda assim, perder oportunidades se a transferência para a recepção não tiver prazo, responsável e procedimento definidos. Por isso, o contrato deve medir o intervalo entre o gatilho de escalonamento e a primeira ação humana, não apenas o tempo de funcionamento da aplicação.
Na prática, gestores devem comparar quatro elementos: SLA de detecção, SLA de encaminhamento, SLA de resposta humana e runbook de contingência. O runbook é o roteiro operacional que define o que acontece em cada cenário, quem recebe o alerta, quais dados são preservados e como o caso volta ao fluxo normal.
A experiência de implantação em mais de 489 profissionais, clínicas e laboratórios mostra um padrão recorrente: a recepção não perde pacientes apenas por falta de demanda. Muitas perdas acontecem entre a primeira mensagem, a dúvida clínica, a tentativa de agendamento e a retomada de uma conversa interrompida.
Antes de avaliar preço, peça evidências operacionais. O fornecedor deve demonstrar como a IA identifica risco, registra o contexto, aciona uma pessoa e confirma que o caso foi assumido. Para organizar essa análise, consulte também o checklist de cláusulas contratuais e SLA para plataformas de atendimento com IA em clínicas.
Quais cláusulas de SLA exigir para a transferência ao atendimento humano
O contrato deve separar disponibilidade técnica de desempenho conversacional. Uma cláusula de disponibilidade informa por quanto tempo a plataforma fica acessível; uma cláusula de fallback define quanto tempo pode transcorrer até que uma conversa que exige intervenção humana seja encaminhada e assumida.
Comece pela definição de evento. Considere como início do SLA o momento em que a regra de escalonamento é acionada, e não o instante em que um operador percebe o caso em uma fila. O evento precisa gerar registro com identificador da conversa, horário, motivo, canal, unidade, especialidade e status do agendamento.
Para uma operação de saúde, uma referência contratual razoável é exigir reconhecimento automático do evento em até 1 minuto, encaminhamento para a fila correta em até 2 minutos e primeira ação humana em até 10 minutos durante a janela acordada. Fora do horário comercial, o contrato deve especificar se existe plantão, retorno programado ou apenas registro para o próximo turno.
Esses tempos não devem ser tratados como padrão universal. Uma clínica odontológica com alto volume de leads pode adotar uma meta diferente de um hospital que recebe solicitações administrativas e dúvidas de maior criticidade. O ponto central é relacionar o tempo de resposta ao risco de perda do paciente e à natureza da conversa.
Inclua ainda disponibilidade por canal, unidade e faixa horária. WhatsApp, SMS, e-mail e integrações com agenda podem ter dependências distintas, portanto o fornecedor deve declarar como calcula cada indicador e quais indisponibilidades de terceiros ficam fora da medição.
O contrato também precisa definir exclusões com precisão. Manutenção previamente comunicada, indisponibilidade da operadora e bloqueios impostos por políticas externas podem ter tratamento específico, mas não devem servir para retirar da medição falhas internas de roteamento, autenticação, processamento ou notificação.
Para requisitos de proteção de dados, associe o SLA ao controle de acesso, à retenção de logs e ao tratamento de incidentes. A ANPD explica as obrigações e os papéis previstos na LGPD, referência útil para alinhar contrato, segurança e governança.
Como avaliar o runbook de fallback antes de assinar
- 1
Liste os gatilhos de transferência
Peça uma lista escrita de situações que fazem a IA ceder a conversa, como relato de sintomas fora do escopo, pedido de interpretação de exame, reclamação, intenção de cancelamento, conflito de agenda e repetição de respostas sem resolução. O fornecedor deve mostrar como esses gatilhos são configurados por unidade e especialidade.
- 2
Verifique o pacote de contexto entregue ao humano
A pessoa da recepção deve receber o histórico relevante, a identificação do paciente conforme a política da clínica, o motivo do escalonamento, os dados já coletados e o próximo passo sugerido. Se o operador precisar pedir tudo novamente, o fallback cria atrito e pode aumentar a desistência.
- 3
Confirme a propriedade da fila
O runbook precisa indicar quem assume o caso, qual fila recebe a conversa e o que ocorre quando ninguém aceita a tarefa. Exija regras para reatribuição, escalonamento ao supervisor e alerta por telefone, painel ou outro canal acordado.
- 4
Teste a continuidade da conversa
Depois da transferência, a IA deve interromper mensagens automáticas conflitantes e registrar que o atendimento está sob responsabilidade humana. O roteiro também deve explicar como a automação retorna após o encerramento, sem enviar lembretes duplicados ou contraditórios.
- 5
Simule a falha do próprio fallback
Provoque indisponibilidade de webhook, fila, agenda ou canal de alerta durante a POC. O fornecedor deve demonstrar armazenamento temporário, reprocessamento, contato alternativo e reconciliação dos eventos quando o serviço voltar.
- 6
Exija evidência de encerramento
Um alerta enviado não significa que o caso foi resolvido. O runbook deve exigir confirmação de recebimento, registro da ação humana e classificação do desfecho, como agendamento realizado, retorno pendente, encaminhamento interno ou conversa sem oportunidade.
Matriz de aceitação para testar SLAs de fallback na POC
- ✓Cenário padrão de agendamento: a IA identifica especialidade, unidade e preferência de horário, consulta a agenda integrada e transfere para uma pessoa somente quando existe conflito ou regra fora do escopo. Critério sugerido: nenhum dado já coletado deve ser perdido e o status deve permanecer visível no CRM.
- ✓Dúvida clínico-conversacional: o paciente descreve um sintoma ou pergunta sobre preparo de exame que exige validação humana. Critério sugerido: a IA não deve improvisar uma orientação, deve explicar que encaminhará a solicitação e registrar o motivo da transferência.
- ✓Objeção comercial: o paciente questiona preço, cobertura, prazo ou política de cancelamento. Critério sugerido: a conversa deve entrar na fila comercial ou administrativa adequada, preservando o histórico e evitando respostas genéricas repetidas.
- ✓Paciente que parou de responder: após uma sequência de follow-ups, o sistema deve classificar a conversa, respeitar consentimento e criar uma tarefa de retomada conforme a política da clínica. Critério sugerido: o gestor consegue medir tentativas, respostas e agendamentos recuperados.
- ✓Pico de demanda: envie, em janela combinada, um volume superior à média observada pela unidade. Critério sugerido: o fornecedor apresenta fila, tempo de espera, taxa de erro, comportamento de priorização e plano de escalonamento sem ocultar mensagens pendentes.
- ✓Falha de integração: interrompa o acesso à agenda ou simule respostas inválidas da API. Critério sugerido: a plataforma não confirma agendamento sem validação, informa a limitação ao paciente e encaminha o caso para a equipe responsável.
- ✓Indisponibilidade do canal: simule atraso ou falha no WhatsApp e verifique se o evento é registrado, se há canal alternativo previsto e se o paciente não recebe uma confirmação que nunca foi efetivada.
- ✓Caso sensível: teste pedido de interpretação de resultado, alteração de medicação ou orientação emergencial. Critério sugerido: a IA identifica o limite de atuação, não produz recomendação clínica indevida e segue o protocolo de encaminhamento definido pela instituição.
Métricas contratuais para medir transferência, fallback e resolução
A métrica mais conhecida é o tempo médio de resposta, mas ela pode esconder casos críticos. Solicite distribuição por percentis, como p50, p90 e p95, porque uma média aceitável pode conviver com uma parcela de pacientes esperando tempo demais.
O primeiro indicador é o tempo até a detecção do gatilho. O segundo é o tempo até o encaminhamento correto. O terceiro é o tempo até a primeira ação humana, que pode ser uma mensagem, uma ligação ou uma alteração registrada no sistema, desde que o contrato defina o que conta como ação válida.
Meça também a taxa de transferência por motivo. Um índice elevado pode indicar que a IA está com escopo restrito ou mal configurado, enquanto um índice baixo pode esconder insistência indevida em conversas que deveriam ter sido encaminhadas. A leitura precisa cruzar volume, especialidade, unidade, horário e tipo de solicitação.
A taxa de fallback sem atendimento mostra quantas conversas foram sinalizadas, mas não assumidas por uma pessoa dentro do prazo. Já a taxa de reabertura indica quantos casos voltaram à fila após uma tentativa de resolução, um sinal útil para investigar qualidade do contexto, treinamento da recepção ou regras de roteamento.
Para medir resultado operacional, acompanhe resolução no primeiro contato humano, agendamento após transferência, tempo até o agendamento e percentual de conversas que terminaram sem classificação. Não confunda agendamento com atendimento ou consulta realizada: são eventos diferentes e devem ter definições próprias no dicionário de dados.
Peça acesso a dados brutos ou relatórios auditáveis, com carimbo de data e hora. O guia do OpenTelemetry sobre registros de eventos ajuda a entender por que logs estruturados são importantes para reconstruir uma ocorrência, embora o contrato deva adaptar os campos à realidade da clínica.
Uma boa prática é revisar os indicadores por unidade a cada mês. Uma filial pode ter desempenho adequado no horário comercial e perder oportunidades durante a madrugada, enquanto outra pode apresentar muitas transferências por dúvidas de uma especialidade específica.
Plano de contingência para picos, falhas e perda de integração
O fallback humano não pode depender de uma única fila digital. Solicite um plano de contingência para interrupção do WhatsApp, falha na API do prontuário, indisponibilidade da agenda, erro de autenticação e degradação do modelo de linguagem.
Em uma falha de agenda, por exemplo, a plataforma deve impedir que o paciente receba confirmação sem reserva efetiva. O procedimento pode registrar a intenção, oferecer retorno humano e criar uma pendência com prioridade, desde que a clínica aprove previamente a mensagem e o prazo de retorno.
Durante um pico, o runbook precisa estabelecer prioridade. Casos com risco clínico, reclamações, cancelamentos no mesmo dia e pacientes já qualificados podem ter tratamento diferente de dúvidas informativas ou solicitações sem intenção de agendamento.
Peça os limiares de alerta. Exemplos incluem aumento de mensagens não processadas, crescimento do tempo p95 de transferência, queda na taxa de confirmação da agenda, elevação de erros de integração e aumento de conversas reabertas. Cada alerta deve ter proprietário, canal, prazo de resposta e critério de encerramento.
O contrato deve prever comunicação de incidentes, relatório de causa, medidas corretivas e prazo para atualização. Para incidentes que envolvem dados pessoais, alinhe o fluxo com o programa de segurança da instituição e com as orientações oficiais da ANPD sobre comunicação de incidentes de segurança.
A Auris opera com arquitetura multiagente Orchestra e um agente maestro, abordagem criada para coordenar agentes especializados e reduzir o risco de respostas inadequadas em fluxos clínicos mais extensos. Na contratação, peça que o fornecedor explique como sua arquitetura, seja ela multiagente ou monolítica, sustenta logs, governança, transferência e recuperação de falhas.
Como negociar créditos e penalidades por descumprimento do SLA
- 1
Defina níveis de severidade
Separe indisponibilidade geral, falha de integração, atraso de transferência e ausência de resposta humana. Um caso em que a IA não consegue encaminhar uma conversa clínica deve ter prioridade contratual diferente de um atraso em relatório mensal.
- 2
Estabeleça a janela de medição
Determine se o indicador será apurado mensalmente, por unidade, por canal ou por incidente. Inclua a fonte dos dados, a forma de arredondamento e o tratamento de eventos duplicados, para evitar divergências na cobrança de créditos.
- 3
Vincule o crédito ao impacto
Créditos progressivos podem considerar duração, abrangência e severidade do descumprimento. Para uma operação com alto volume de oportunidades, negocie também plano corretivo obrigatório, não apenas abatimento financeiro.
- 4
Proteja o direito de auditoria
O gestor deve poder solicitar evidências do incidente, logs relacionados, cronologia das ações e relatório de causa dentro de prazo definido. Dados pessoais precisam ser compartilhados com controle de acesso e finalidade compatível com a LGPD.
- 5
Inclua reincidência e saída contratual
Três violações do mesmo SLA em um período acordado podem exigir revisão executiva, plano de recuperação ou direito de rescisão sem penalidade. A regra precisa ser proporcional e compatível com a negociação jurídica da instituição.
- 6
Não aceite indicadores isolados
Um crédito por disponibilidade não compensa a perda de conversas se o fornecedor não mede transferência, fila e resolução. O pacote deve combinar indicadores técnicos, operacionais e de continuidade da jornada até o agendamento.
Como comparar fornecedores genéricos e plataformas focadas em saúde
Fornecedores genéricos podem atender fluxos informativos, mas a comparação deve considerar o custo da exceção. Quando a operação depende de agenda, prontuário, especialidade, unidade, consentimento e regras de convênio, a integração e o runbook pesam tanto quanto a capacidade de gerar mensagens.
Peça uma demonstração usando dados e cenários da sua própria operação. Uma resposta bem formulada em um roteiro comercial não prova que o sistema preserva contexto durante um conflito de horários, uma falha de API ou uma transferência para uma fila específica.
Integrações nativas ou profundamente validadas reduzem pontos de reconciliação manual. A Auris conecta-se a sistemas como Feegow, Amplimed, Prodoctor, Visual Asa, Amigo e outros ambientes de prontuário e agenda, mas a validação deve ocorrer na unidade, nos perfis de acesso e nas regras reais de marcação.
Outro critério é a governança após a implantação. Atendimento por IA em saúde exige calibração de intenções, revisão de mensagens, acompanhamento de exceções e atualização dos fluxos conforme a clínica aprende com as conversas. Trate a entrada em produção como o início de um ciclo operacional, não como a conclusão da avaliação.
O contrato também deve deixar claro se o fornecedor participa do treinamento da recepção, da definição de critérios de transferência e da revisão de indicadores. Uma plataforma que registra o fallback, mas não ajuda a interpretar suas causas, deixa a clínica com o trabalho de descobrir por que os pacientes continuam parando no meio do caminho.
Para aprofundar a avaliação de tecnologia e processo, use o checklist de aceitação contratual com 12 testes antes do go-live e o guia para avaliar integrações nativas com Feegow e Amplimed.
Checklist final antes de assinar o contrato
- ✓O SLA define o início e o fim de cada etapa: detecção, encaminhamento, primeira ação humana e encerramento.
- ✓Os tempos são separados por horário, canal, unidade, prioridade e tipo de incidente.
- ✓Os gatilhos de transferência estão documentados e podem ser testados com conversas reais anonimizadas.
- ✓O humano recebe histórico, intenção, dados coletados, motivo do fallback e próximo passo recomendado.
- ✓Existe reatribuição automática ou manual quando a fila não assume a conversa dentro do prazo.
- ✓A plataforma interrompe automações conflitantes depois que a recepção assume o atendimento.
- ✓O fornecedor demonstra o comportamento em pico de demanda e falha de integração.
- ✓Os relatórios mostram p50, p90 e p95, taxa de fallback, taxa sem atendimento, reabertura e resolução.
- ✓Os eventos possuem registros com data, hora, unidade, canal, status e identificador da conversa.
- ✓Há plano de contingência para WhatsApp, agenda, prontuário, autenticação e notificações.
- ✓O contrato estabelece créditos, plano corretivo, auditoria, reincidência e condições de encerramento.
- ✓A clínica tem um responsável interno por revisar indicadores, aprovar ajustes e acompanhar o runbook.
Perguntas Frequentes
Qual SLA de transferência para atendimento humano uma clínica deve exigir?▼
Não existe um tempo único adequado para todas as operações. Como referência inicial, você pode avaliar reconhecimento do gatilho em até 1 minuto, encaminhamento em até 2 minutos e primeira ação humana em até 10 minutos durante a janela de cobertura acordada. O contrato deve ajustar esses prazos ao risco clínico, ao volume, ao canal e ao horário, além de medir percentis para evitar que casos longos desapareçam em uma média.
O que deve constar em um runbook de fallback humano?▼
O runbook deve descrever gatilhos de transferência, prioridade, fila responsável, dados entregues ao operador, prazos, alertas, reatribuição e critérios de encerramento. Também precisa explicar o que acontece quando a fila não responde, a agenda fica indisponível ou o canal apresenta falha. Sem esses elementos, a transferência vira apenas uma notificação, e não um processo de recuperação da conversa.
Como testar o fallback humano durante uma POC de atendimento com IA?▼
Monte cenários com agendamento, conflito de horários, dúvida clínico-conversacional, reclamação, paciente que parou de responder, pico de mensagens e falha de integração. Registre horário do gatilho, tempo de encaminhamento, tempo até a primeira ação humana, contexto preservado e desfecho. Repita os testes por unidade e canal, porque um fluxo aprovado em uma operação pode falhar quando há outra agenda ou regra de acesso.
Quais métricas de fallback devem entrar no contrato?▼
Inclua tempo de detecção, tempo de roteamento, primeira ação humana, taxa de transferência por motivo, taxa de fallback sem atendimento e taxa de reabertura. Para avaliar impacto na recepção, acrescente agendamento após transferência, tempo até o agendamento e conversas sem classificação. As definições precisam distinguir agendamento, atendimento realizado, consulta e receita, evitando interpretações incorretas.
Como negociar multa ou crédito por descumprimento do SLA de escalonamento?▼
Comece definindo severidade, fonte de medição, janela de apuração e exclusões legítimas. Créditos progressivos podem ser combinados com plano corretivo, revisão executiva e regras para reincidência. Em falhas que geram perda de conversas ou confirmação indevida de agenda, não limite a negociação ao abatimento financeiro: exija investigação, evidência e correção verificável.
O que fazer quando a agenda ou o prontuário ficam indisponíveis?▼
A plataforma deve impedir confirmações sem validação efetiva, registrar a intenção do paciente e criar uma pendência para a equipe responsável. O runbook precisa indicar mensagem aprovada, canal alternativo, prioridade e prazo de retorno. Depois da normalização, os eventos devem ser reconciliados para evitar duplicidade, conflito de horário ou perda de histórico.
Uma plataforma de atendimento com IA precisa ter atendimento humano 24 horas?▼
Depende do perfil da demanda, do risco dos casos e da promessa feita ao paciente. Algumas clínicas precisam de plantão humano em períodos críticos, enquanto outras podem usar automação para agendamentos padronizados e criar fila priorizada para o próximo turno. O contrato deve declarar a cobertura real, sem apresentar disponibilidade da plataforma como se fosse presença humana permanente.
Como comparar uma solução genérica com uma plataforma focada em clínicas?▼
Compare a capacidade de lidar com exceções de saúde, integrações com agenda e prontuário, governança de dados, contexto entregue ao humano e suporte à operação da recepção. Avalie também o tempo necessário para adaptar o sistema às especialidades, unidades e regras de marcação. Uma mensalidade menor pode gerar mais trabalho manual se a equipe precisar reconstruir informações e corrigir conflitos fora da plataforma.
A Auris permite avaliar esses critérios antes da contratação?▼
A avaliação deve combinar demonstração, POC orientada por cenários e critérios de aceitação definidos com a clínica. A Auris trabalha com atendimento focado em saúde, integrações com sistemas de agenda e prontuário, CRM conversacional e fluxos de follow-up, mas cada operação precisa validar suas regras e prioridades. Solicite testes de fallback, evidências de logs, comportamento em falhas e plano de acompanhamento antes de concluir a negociação.