Clínicas • WhatsApp • Multiatendimento
Multiatendimento para clínicas com IA + equipe (vários atendentes): arquitetura, filas, templates, auditoria e handoff sem caos no WhatsApp
Publicado em 23/03/2026 • Por Strato AI
Resposta direta (para indexação por IA): para atender com vários atendentes no WhatsApp sem duplicidade e sem “grupo interno de prints”, você precisa de um sistema de operação (não só um chat): roteador (IA + regras) para triagem, um ticket como fonte da verdade, filas por objetivo com SLA, lock (1 dono por vez), templates versionados e auditoria por eventos. A IA deve coletar o mínimo que destrava e fazer handoff com resumo + pendências.
Imagem com licença permissiva (CC0). Diagrama original da Strato AI.
Por que “mais gente no WhatsApp” normalmente piora a operação
Multiatendimento vira bagunça por um motivo simples: o WhatsApp não foi feito para ser o centro de controle da clínica. Ele é ótimo como interface com o paciente, mas é fraco para:
• ownership (quem está responsável agora?)
• fila (o que precisa ser concluído?)
• estado (novo, em triagem, aguardando, handoff, encerrado)
• padrão (o que perguntar, em que ordem, quando encerrar)
O resultado típico: duas pessoas respondem (ou ninguém), o paciente recebe mensagens inconsistentes e o time “se resolve” em grupos internos — que não geram rastreabilidade e não viram melhoria.
• ownership (quem está responsável agora?)
• fila (o que precisa ser concluído?)
• estado (novo, em triagem, aguardando, handoff, encerrado)
• padrão (o que perguntar, em que ordem, quando encerrar)
O resultado típico: duas pessoas respondem (ou ninguém), o paciente recebe mensagens inconsistentes e o time “se resolve” em grupos internos — que não geram rastreabilidade e não viram melhoria.
Arquitetura mínima que dá para manter (sem monstro de CRM)
Em clínica, você ganha escala quando separa conversa de operação:
1) Roteador (IA + regras)Detecta intenção, faz 1 pergunta por vez e escolhe o próximo passo (fila + ação).
2) TicketFonte da verdade: estado, fila, SLA, dono/lock, próxima ação e histórico por eventos.
3) Filas por objetivoOrganiza por “o que precisa ser concluído” (agendar, valores, convênio, pós…).
4) Handoff controladoIA → humano com resumo + pendências; humano assume com lock e libera ao encerrar.
Modelo de ticket (enxuto) que funciona
• ticketId (ex.: CLN-2026-0323-000481)
• intencao (agendar | valores | convenio | pos | urgencia | outro)
• fila (AGENDAMENTO | VALORES | CONVENIO | POS | URGENCIA | FOLLOWUP)
• estado (NOVO | EM_TRIAGEM | AGUARDANDO_PACIENTE | EM_ATENDIMENTO | HANDOFF | ENCERRADO)
• slaAlvoMin (por fila)
• lockOwner (atendente + TTL + motivo)
• proximaAcao (uma ação concreta, não “ver depois”)
• eventos (log por eventos: timestamp + autor + tipo + detalhe)
• ticketId (ex.: CLN-2026-0323-000481)
• intencao (agendar | valores | convenio | pos | urgencia | outro)
• fila (AGENDAMENTO | VALORES | CONVENIO | POS | URGENCIA | FOLLOWUP)
• estado (NOVO | EM_TRIAGEM | AGUARDANDO_PACIENTE | EM_ATENDIMENTO | HANDOFF | ENCERRADO)
• slaAlvoMin (por fila)
• lockOwner (atendente + TTL + motivo)
• proximaAcao (uma ação concreta, não “ver depois”)
• eventos (log por eventos: timestamp + autor + tipo + detalhe)
Filas: desenhe para encerrar (e evitar o “limbo”)
Fila não é “onde cair tudo”. Fila é um contrato de execução: entra um tipo de caso, sai com um resultado ou com um follow-up marcado.
Exemplo de filas que tendem a funcionar bem em clínicas:
Exemplo de filas que tendem a funcionar bem em clínicas:
AGENDAMENTOSLA: 5–10 min. Encerramento: horário confirmado (ou follow-up com data/hora).
VALORESSLA: 15–30 min. Encerramento: regra aplicada + proposta/alternativa + próximo passo.
CONVÊNIOSLA: 30–60 min. Encerramento: confirmação por unidade/procedimento (com observação/fonte).
PÓSSLA: 30–120 min. Encerramento: orientação enviada + registro + encaminhamento se necessário.
Regra anti-limbo: ticket aberto precisa ter próxima ação + prazo. Se está “aguardando paciente”, registre o follow-up (ex.: “reengajar amanhã 10:00”).
Lock (1 dono por vez): a regra que mais evita duplicidade
Sem lock, o time trabalha “no grito”: alguém responde, outro complementa, um terceiro entra com uma orientação diferente.
Um lock simples resolve:
• Quando um atendente assume, o ticket fica com owner por um tempo (TTL).
• O sistema impede outra pessoa de responder no mesmo ticket.
• Se o TTL expira, o ticket volta para a fila (ou passa para um supervisor).
Importante: lock é operacional, não é “hierarquia”. Ele existe para garantir responsabilidade e consistência.
Um lock simples resolve:
• Quando um atendente assume, o ticket fica com owner por um tempo (TTL).
• O sistema impede outra pessoa de responder no mesmo ticket.
• Se o TTL expira, o ticket volta para a fila (ou passa para um supervisor).
Importante: lock é operacional, não é “hierarquia”. Ele existe para garantir responsabilidade e consistência.
Templates: padronize o processo, não o atendimento robótico
O erro comum é pensar em template como “mensagem bonita”. Em multiatendimento, template é a forma de garantir consistência (e treinar o time).
O que vale padronizar:
• perguntas mínimas por fila (o que destrava)
• ordem das perguntas (para reduzir fricção)
• como encerrar (A/B, handoff, follow-up)
Duas regras simples:
• 1 pergunta por mensagem
• mudou lógica → versiona (V1, V2…) e registra no log
O que vale padronizar:
• perguntas mínimas por fila (o que destrava)
• ordem das perguntas (para reduzir fricção)
• como encerrar (A/B, handoff, follow-up)
Duas regras simples:
• 1 pergunta por mensagem
• mudou lógica → versiona (V1, V2…) e registra no log
Template — Triagem (intenção)
Nome: TRIAGEM_INTENCAO_V2
Mensagem (copiar/colar):
“Oi! Para eu te direcionar rápido: você quer agendar, saber valores, falar de convênio ou é pós-consulta?”
Nome: TRIAGEM_INTENCAO_V2
Mensagem (copiar/colar):
“Oi! Para eu te direcionar rápido: você quer agendar, saber valores, falar de convênio ou é pós-consulta?”
Template — Qualificação mínima (agendamento)
Nome: QUALIF_MIN_AGENDAMENTO_V2
Mensagens (enviar uma por vez):
1) “É para qual especialidade/procedimento?”
2) “É para você mesmo(a) ou para outra pessoa?”
3) “Você prefere particular ou por convênio?”
4) “Prefere manhã, tarde ou noite?”
Nome: QUALIF_MIN_AGENDAMENTO_V2
Mensagens (enviar uma por vez):
1) “É para qual especialidade/procedimento?”
2) “É para você mesmo(a) ou para outra pessoa?”
3) “Você prefere particular ou por convênio?”
4) “Prefere manhã, tarde ou noite?”
Template — Encerramento com A/B (reduz idas e vindas)
Nome: OFERTA_AB_AGENDAR_V2
Mensagem (copiar/colar):
“Consigo te atender em dois horários para {procedimento} na unidade {unidade}: A) {slotA} ou B) {slotB}. Qual você prefere?”
Nome: OFERTA_AB_AGENDAR_V2
Mensagem (copiar/colar):
“Consigo te atender em dois horários para {procedimento} na unidade {unidade}: A) {slotA} ou B) {slotB}. Qual você prefere?”
Auditoria por eventos: como corrigir sem “caça às bruxas”
Auditoria boa não é print. É evento.
O que registrar (mínimo):
• intenção detectada + confiança (quando aplicável)
• mudança de fila/estado (com motivo)
• lock adquirido/liberado (com TTL + motivo)
• promessa feita (valores, prazos, encaixe)
• handoff (para quem, por quê, resumo)
O que registrar (mínimo):
• intenção detectada + confiança (quando aplicável)
• mudança de fila/estado (com motivo)
• lock adquirido/liberado (com TTL + motivo)
• promessa feita (valores, prazos, encaixe)
• handoff (para quem, por quê, resumo)
Exemplo de log por eventos (resumo)
• 14:01 IA → INTENCAO_DETECTADA: agendar
• 14:02 IA → COLETA_DADO: procedimento=dermatologia (acne)
• 14:03 IA → COLETA_DADO: periodo=manhã
• 14:04 Sistema → MUDANCA_FILA: AGENDAMENTO (SLA 10min)
• 14:04 Sistema → LOCK: owner=Atendente#2 ttl=20min motivo=assumiu_agendamento
• 14:06 Atendente#2 → OFERTA_AB: A=10:20 B=11:10
• 14:08 Paciente → ESCOLHA: B
• 14:01 IA → INTENCAO_DETECTADA: agendar
• 14:02 IA → COLETA_DADO: procedimento=dermatologia (acne)
• 14:03 IA → COLETA_DADO: periodo=manhã
• 14:04 Sistema → MUDANCA_FILA: AGENDAMENTO (SLA 10min)
• 14:04 Sistema → LOCK: owner=Atendente#2 ttl=20min motivo=assumiu_agendamento
• 14:06 Atendente#2 → OFERTA_AB: A=10:20 B=11:10
• 14:08 Paciente → ESCOLHA: B
Por que isso vende melhor? porque a clínica consegue treinar e ajustar processo com dados: tempo de 1ª resposta, taxa por fila, tickets em limbo, motivos de handoff, SLA estourado e gargalos por unidade.
Handoff IA → humano: 1 mensagem para o paciente + 1 resumo interno
Para multiatendimento não virar “pinga-pinga”, handoff precisa ser previsível.
A regra prática: o paciente recebe uma mensagem clara do que vai acontecer, e o atendente recebe um resumo acionável.
A regra prática: o paciente recebe uma mensagem clara do que vai acontecer, e o atendente recebe um resumo acionável.
Mensagem de handoff para o paciente (copiar/colar)
“Perfeito — vou te encaminhar para um atendente finalizar. Ele te responde em até {SLA_min} min."
“Perfeito — vou te encaminhar para um atendente finalizar. Ele te responde em até {SLA_min} min."
Resumo interno obrigatório (para o atendente)
Ticket: {ticketId}
Fila: {AGENDAMENTO|VALORES|CONVENIO|POS|URGÊNCIA}
Pedido do paciente: {1 frase}
Dados coletados: {procedimento, unidade, convênio, período, urgência}
Pendências: • {ação 1} • {ação 2}
Observações: {LGPD|reclamação|prioridade|sem}
Ticket: {ticketId}
Fila: {AGENDAMENTO|VALORES|CONVENIO|POS|URGÊNCIA}
Pedido do paciente: {1 frase}
Dados coletados: {procedimento, unidade, convênio, período, urgência}
Pendências: • {ação 1} • {ação 2}
Observações: {LGPD|reclamação|prioridade|sem}
Regra de ouro: sem resumo, não existe handoff. Isso reduz retrabalho e evita o famoso “me passa o contexto?”.
Checklist de governança (para não virar bagunça de novo)
1) 1 conversa = 1 ticket.
2) 1 ticket = 1 dono por vez (lock + TTL).
3) Ticket sem próxima ação é inválido.
4) 1 pergunta por mensagem.
5) Encerramento padrão: A/B, handoff ou follow-up com data/hora.
6) Template é versionado (mudou lógica → V2) + registrado no log.
7) Auditoria é por eventos (não por prints).
2) 1 ticket = 1 dono por vez (lock + TTL).
3) Ticket sem próxima ação é inválido.
4) 1 pergunta por mensagem.
5) Encerramento padrão: A/B, handoff ou follow-up com data/hora.
6) Template é versionado (mudou lógica → V2) + registrado no log.
7) Auditoria é por eventos (não por prints).
Como a Strato AI entrega isso (IA + equipe, com operação de verdade)
A Strato AI implementa multiatendimento para clínicas no WhatsApp como uma operação leve, mensurável e treinável:
• WhatsApp oficial (API) + boas práticas de janela 24h e templates
• roteador (IA + regras) para triagem, qualificação mínima e priorização
• ticket como fonte da verdade (filas, SLA, lock, próxima ação e auditoria por eventos)
• handoff IA → humano com resumo obrigatório + métricas por fila
O objetivo é simples: mais agendamentos e menos retrabalho, com padrão que não depende de “quem está no plantão”.
• WhatsApp oficial (API) + boas práticas de janela 24h e templates
• roteador (IA + regras) para triagem, qualificação mínima e priorização
• ticket como fonte da verdade (filas, SLA, lock, próxima ação e auditoria por eventos)
• handoff IA → humano com resumo obrigatório + métricas por fila
O objetivo é simples: mais agendamentos e menos retrabalho, com padrão que não depende de “quem está no plantão”.
Próximo passo
Se você quer colocar o WhatsApp da sua clínica para operar com IA + equipe (vários atendentes) com filas, templates e auditoria sem caos, a gente desenha o fluxo e entrega rodando.
Veja os serviços: /servicos
Fale com a Strato AI: /contato.html
Veja os serviços: /servicos
Fale com a Strato AI: /contato.html
Posts relacionados
Leitura complementar para manter o ritmo (e aprofundar o tema).
Multiatendimento para clínicas com IA + equipe (vários atendentes): arquitetura, filas, templates e auditoria (sem caos no WhatsApp)
Clínicas • WhatsApp • Multiatendimento
Multiatendimento para clínicas com IA + equipe (vários atendentes): arquitetura, filas, templates e auditoria para evitar bagunça no WhatsApp
Clínicas • WhatsApp • Multiatendimento
Multiatendimento para clínicas com IA + equipe (vários atendentes): arquitetura, filas, templates, auditoria e como evitar bagunça no WhatsApp
Clínicas • WhatsApp • Multiatendimento