A resposta em uma frase: o que muda na passagem do robô para a pessoa
O Decreto nº 13.135/2026 não proíbe inteligência artificial no SAC. Ele proíbe que a automação vire um labirinto sem saída humana. Para diretores e gestores de atendimento, CX e operações de empresas com SAC, a dúvida sobre o que o novo decreto exige e o medo de que a IA tenha sido banida precisam dar lugar a um entendimento operacional claro: a regra central é que, se o cliente já informou, o sistema não pode pedir de novo. O risco real está na jornada sem continuidade. O art. 7º exige que o atendimento prossiga até a conclusão, e o art. 18 §1º determina que o atendente receba o histórico do mesmo fato gerador — resumo da demanda, dados já informados e protocolo — antes da primeira interação humana. Os gatilhos de transferência previstos incluem pedido do cliente, cancelamento, urgência e falha da IA. Um handoff bem feito segue uma sequência tela a tela: o chatbot registra o contexto, sinaliza a transferência, enfileira o caso com prioridade correta e entrega ao humano uma tela preenchida com o histórico. Erros comuns são transferir sem protocolo, exigir repetição de CPF ou relato e deixar o atendente sem visão do que a IA já resolveu. O Chatbot Omnismart, para WhatsApp e outros canais, trata esse repasse como parte do fluxo, não como exceção, acionando o atendente com o histórico do fato gerador já preenchido. Consulte a íntegra do Decreto 13.135 e a página de handoff da OmniSmart para validar a sequência operacional.
Quando o assunto é transferir chatbot para atendente, o que está em jogo não é apenas trocar o remetente da mensagem, mas garantir que a passagem preserve contexto, protocolo e histórico. O Decreto nº 13.135/2026 não proíbe inteligência artificial no SAC: ele proíbe que a automação vire um labirinto sem saída humana. Para diretores e gestores de atendimento, CX e operações de empresas com SAC, a dúvida sobre o que o novo decreto exige e o medo de que a IA tenha sido banida precisam dar lugar a um entendimento operacional claro: a regra central é que, se o cliente já informou, o sistema não pode pedir de novo. O risco real está na jornada sem continuidade. O art. 7º exige que o atendimento prossiga até a conclusão, e o art. 18 §1º determina que o atendente receba o histórico do mesmo fato gerador — resumo da demanda, dados já informados e protocolo — antes da primeira interação humana. Os gatilhos de transferência previstos incluem pedido do cliente, cancelamento, urgência e falha da IA. Um handoff bem feito segue uma sequência tela a tela: o chatbot registra o contexto, sinaliza a transferência, enfileira o caso com prioridade correta e entrega ao humano uma tela preenchida com o histórico. Erros comuns são transferir sem protocolo, exigir repetição de CPF ou relato e deixar o atendente sem visão do que a IA já resolveu. O Chatbot Omnismart, para WhatsApp e outros canais, trata esse repasse como parte do fluxo, não como exceção, acionando o atendente com o histórico do fato gerador já preenchido. Consulte a íntegra do Decreto 13.135 e a página de handoff da OmniSmart para validar a sequência operacional. Vale também revisar os recursos obrigatórios da plataforma e o guia completo do Decreto 13.135 antes de redesenhar o fluxo.
O que a pessoa precisa receber no instante em que assume o caso
Para gestores de operação e CX, a transferência do chatbot para o atendente é o ponto mais sensível da jornada. É nesse instante que se define se o cliente continuará em um fluxo resolutivo ou cairá em uma jornada sem saída, repetindo dados e refazendo o caminho do zero. O Decreto nº 13.135/2026 não trata a passagem de bastão como um simples aviso: ele exige que o humano receba um pacote mínimo de contexto para assumir o caso com continuidade real.
| Elemento que o atendente recebe | O que o decreto determina | Risco operacional se faltar | Como garantir na prática |
|---|---|---|---|
| Resumo da demanda | Art. 6º, II — registrar o relato do consumidor antes da transferência | Atendente pergunta “como posso ajudar?” e o cliente percebe que o bot não serviu para nada | Gravar a intenção principal e a última resposta do cliente antes do handoff |
| Dados já informados | Art. 6º, II — preservar informações fornecidas durante o atendimento automatizado | Cliente repete CPF, número de pedido e endereço, gerando atrito e alongando o tempo de atendimento | Espelhar campos estruturados do bot no CRM do agente em tempo real |
| Protocolo por demanda | Art. 18 — fornecer número de protocolo para acompanhamento | Sem protocolo, o cliente não consegue rastrear o caso e a operação perde a rastreabilidade | Gerar protocolo automático no início do atendimento e exibi-lo no painel do agente |
| Histórico unificado entre canais | Art. 18, §1º — acesso ao histórico de demandas ativas ou do mesmo fato gerador | Atendente não vê o que já foi tratado por telefone, e-mail ou outro canal sobre o mesmo pedido | Integrar chatbot, CRM e canais anteriores em um único histórico associado ao mesmo identificador de contratação |
| Continuidade sem repetição | Art. |
Transferir chatbot para atendente exige que o humano receba resumo da demanda, dados já informados e protocolo antes da primeira interação. É esse pacote mínimo que separa uma passagem de bastão real de um simples aviso de "aguarde, você será atendido". O art. 18 §1º do Decreto 13.135/2026 determina que o atendente receba o histórico do mesmo fato gerador antes de assumir o caso. Sem esse contexto, o cliente volta a repetir CPF, relato e caminho já percorrido — exatamente o que a norma busca evitar. Um handoff bem feito registra o contexto no chatbot, sinaliza a transferência, enfileira o caso com prioridade correta e entrega ao humano uma tela preenchida. Para quem opera WhatsApp, entender os status de enviado, entregue e lido ajuda a confirmar que a mensagem de transferência chegou antes de o atendente assumir. E vale alinhar o repasse com a adequação do WhatsApp de atendimento à Lei do SAC.
Para times que já operam com automação em outros pontos da jornada, o mesmo cuidado de continuidade aparece em formulário no site ou no WhatsApp com Flow e na estratégia para evitar mensagens duplicadas entre PWA e WhatsApp. Depois da transferência, o ganho de contexto se completa com práticas de redução do tempo pós-chamada sem perder qualidade nos registros.
Quais gatilhos devem disparar a transferência para um humano?
O Decreto nº 13.135/2026 fixa situações em que a automação deve ceder lugar ao atendente. São gatilhos com base normativa, não escolhas discricionárias da operação. Gestores de atendimento e operações precisam desenhar fluxos em que o cliente não encontre saída humana apenas depois de esgotar tentativas frustradas: a opção de falar com uma pessoa deve existir em todos os níveis do menu, inclusive no primeiro contato.
- Pedido explícito do cliente. O art. 13 garante atendimento humano em todos os níveis do menu. Detecte frases como "quero falar com uma pessoa" e transfira imediatamente, anexando histórico da conversa e protocolo.
- Intenção de cancelamento. O art. 13 §1º e o art. 20 determinam que o pedido de rescisão seja recebido pela mesma equipe ou menu que contrata. Transfira no mesmo fluxo, sem desvio para retenção separada, anexando contrato e dados do titular.
- Urgência com risco relevante. O art. 17 trata de situações urgentes, distintas da prioridade legal dos arts. 10 e 11, que cobre idosos, gestantes e pessoas com deficiência. Urgência é risco concreto; prioridade é perfil do consumidor.
- Falha da IA. Resposta inconclusiva, repetição de loop ou pergunta fora do escopo configuram falha. Encaminhe ao atendente com a transcrição do trecho em que o agente não resolveu.
- Reclamação de cobrança indevida. O art. 21 exige tratamento específico para contestação de valores. Transfira com número da fatura, valor contestado e data da primeira manifestação.
Transferir chatbot para atendente faz sentido quando o caso exige julgamento, exceção contratual ou risco jurídico. Não faz sentido quando a automação conclui a solicitação sem perda para o cliente. A OmniSmart oferece agente de IA com detecção de intenção e regras de escalonamento configuráveis. A plataforma não identifica cancelamento automaticamente: a regra precisa ser desenhada pela operação.
Como desenhar a passagem tela a tela sem quebrar a continuidade
Para diretores de operações e TI, o medo central é duplo: achar que a IA foi proibida pelo novo decreto e descobrir tarde que o handoff piorou o tempo de atendimento. Nenhum dos dois precisa se confirmar. O Decreto nº 13.135/2026 não proíbe chatbot — ele exige que a passagem para humano preserve contexto, protocolo e histórico. A sequência abaixo mostra como desenhar isso tela a tela.
- Cliente pede pessoa e a IA confirma com prazo. A automação reconhece o pedido e informa tempo estimado de espera, conforme o art. 13 do decreto. Trade-off: prometer prazo exige fila calibrada; estimativa errada derruba a confiança. Próximo passo: configurar cálculo de espera por fila.
- IA gera resumo estruturado e anexa ao protocolo. Motivo, dados já informados e tentativas de resolução seguem juntos, atendendo ao art. 6º, II. Trade-off: resumo rico melhora a retomada, mas consome tempo de geração. Próximo passo: definir campos obrigatórios do resumo.
- Sistema cria ou reaproveita o protocolo. O número é vinculado ao histórico do mesmo fato gerador, como pede o art. 18, §1º. Trade-off: reaproveitar reduz retrabalho, mas exige deduplicação confiável. Próximo passo: mapear regra de vínculo por fato gerador.
- Fila correta por competência e prioridade legal. O roteamento respeita arts. 10, 11 e 17, incluindo prioridade quando aplicável. Trade-off: fila por competência reduz transferências internas, mas exige matriz de skills atualizada. Próximo passo: revisar a matriz de competências.
- Atendente abre a tela com tudo antes da primeira frase. Resumo, histórico e protocolo aparecem juntos, sem o cliente repetir informação. Trade-off: tela densa acelera, mas pede treino de leitura rápida. Próximo passo: padronizar o layout da tela de handoff.
- Encerramento com resposta conclusiva e registro. O atendente fecha com resposta clara e registra no histórico, conforme arts.
Quais erros comuns fazem o cliente repetir tudo depois da transferência?
O cliente repetir o problema após o handoff nasce de falhas operacionais específicas, não de falta de ferramenta. São erros que violam os arts. 6º II, 7º e 18 §1º do Decreto nº 13.135/2026 e que gestores de CX e operações podem corrigir com ajustes no fluxo de passagem entre IA e atendente.
- Transferir sem anexar resumo: o atendente assume o caso sem saber o que a IA já coletou. A correção é exigir resumo estruturado obrigatório no handoff, com motivo, tentativas e dados confirmados.
- Reaproveitar protocolo de outro fato gerador: vincular o número a uma ocorrência diferente quebra a rastreabilidade exigida pelo art. 18 §1º. Cada demanda precisa de protocolo próprio, gerado no momento da abertura do fato.
- Encerrar o caso na IA e abrir novo contato: reiniciar o atendimento apaga o histórico e força o cliente a recomeçar, o que viola o art. 7º. A continuidade deve ser mantida até a conclusão do mesmo fato gerador.
- Histórico fragmentado entre WhatsApp, chat e telefone: cada canal guarda um pedaço da conversa e nenhum atendente vê o todo. Unificar o histórico por cliente elimina a repetição de contexto na troca de canal.
- Transferir para fila errada e gerar nova triagem: o cliente cai em time sem competência para o caso e precisa explicar tudo de novo. Distribuir por competência, e não por disponibilidade, evita a segunda triagem.
Na prática, o histórico unificado e o protocolo por demanda resolvem a maior parte desses erros. A plataforma omnichannel da OmniSmart mantém a conversa contínua entre agente de IA, atendente humano, telefonia e CRM, sem reiniciar o caso. Ver os recursos obrigatórios da plataforma ajuda a checar o que precisa estar no fluxo antes de configurar a transferência.
O que avaliar na plataforma antes de 2 de novembro
Diretores de TI e operações enfrentam uma incerteza comum: a plataforma atual já cobre os requisitos do Decreto nº 13.135/2026 ou será preciso trocar de fornecedor? A resposta exige uma checagem objetiva, item por item, antes de qualquer decisão de contratação. A tabela abaixo converte cada exigência em sinal operacional verificável.
| Requisito do decreto | Capacidade necessária | Sinal operacional a verificar | Ação recomendada |
|---|---|---|---|
| Opção de atendente em todo nível (art. 13) | Menu e fluxo com saída humana sempre visível | Árvore de atendimento editável e teste de escape em cada etapa | Simular a jornada completa e confirmar a saída em todos os níveis |
| Handoff com resumo e histórico (arts. 6º II e 18 §1º) | Transição com contexto consolidado para o atendente | API de handoff e registro do resumo no ticket | Pedir demonstração do handoff e conferir o que chega na tela do atendente |
| Protocolo único por fato gerador (art. 18) | Identificador estável entre canais e reaberturas | Modelo de dados com protocolo vinculado ao fato gerador | Validar com a equipe como configurar a regra de protocolo |
| Histórico unificado entre canais (art. 18 §1º) | Visão única de WhatsApp, chat, telefonia e CRM | Integrações nativas e cobertura de canais documentada | Listar canais usados hoje e cruzar com a cobertura da plataforma |
| Filas com tempo estimado informado (art. 13) | Fila com posição e espera comunicadas ao cliente | Configuração de filas e mensagens automáticas de espera | Avaliar com a equipe como configurar a comunicação de espera |
| — | Retenção configurável e exportável | Política de retenção, logs e exportação de histórico | Confirmar com o fornecedor o prazo de guarda e o formato de exportação |
Por onde começar a revisar o handoff antes da vigência
Três prioridades concentram o esforço até 2 de novembro. A primeira é mapear cada ponto em que o chatbot passa o caso para uma pessoa. Em seguida, verifique se aquele ponto anexa resumo, dados já informados e protocolo antes de o atendente abrir a conversa.
A segunda prioridade é testar o fluxo como cliente, canal por canal. Cronometre quantas vezes você repete a mesma informação e anote onde a jornada trava. A terceira é confirmar se o histórico do mesmo fato gerador chega ao atendente antes da primeira resposta.
- Mapear pontos de transferência: cada saída do bot precisa carregar resumo, dados e protocolo.
- Testar como cliente: percorra WhatsApp, site e telefonia medindo repetições de informação.
- Validar histórico: o atendente deve ver o fato gerador antes de responder.
O diagnóstico gratuito dos canais visíveis no site funciona como porta de entrada para revisar essa jornada com a OmniSmart. Ele mostra onde a passagem do robô para o humano ainda deixa o cliente sem saída.
Empresas fora do escopo do art. 1º do Decreto nº 13.135/2026 podem adotar as mesmas regras como boa prática, sem obrigação direta. Para quem está no escopo, o texto não substitui parecer jurídico. Recomendamos validação com o jurídico e acompanhamento das regras complementares de Anatel, Banco Central, ANS, ANEEL, ANAC e demais reguladores.
Conheça a plataforma OmniSmart e fale com nosso time.
Fontes e referências
Segundo as referências institucionais abaixo, a validação técnica deve considerar a documentação primária de cada padrão e serviço.
- Visão geral da WhatsApp Cloud API — Meta for Developers
- Documentação da WhatsApp Business Platform — Meta for Developers
Perguntas frequentes
O Decreto nº 13.135/2026 proíbe o uso de chatbot no SAC ou apenas exige que exista transferência para atendente humano?
O decreto não proíbe inteligência artificial no SAC. Ele proíbe que a automação vire um labirinto sem saída humana. A regra central é que, se o cliente já informou algo, o sistema não pode pedir de novo, e a transferência para atendente deve preservar contexto, protocolo e histórico.
Quais requisitos do Decreto nº 13.135/2026 preciso verificar na plataforma antes de contratar uma solução de transferir chatbot para atendente?
Verifique se a plataforma oferece opção de atendente em todo nível do menu, conforme o art. 13, e se o handoff anexa resumo da demanda, dados já informados e protocolo do mesmo fato gerador, como exigem os arts. 6º II, 7º e 18 §1º.
Trocar de plataforma para garantir a transferência do chatbot para atendente conforme o novo SAC exige grande investimento?
Não necessariamente. Antes de decidir pela troca, faça uma checagem objetiva item por item: se a plataforma atual já tem árvore de atendimento editável, saída humana em todos os níveis e handoff com resumo e protocolo, o ajuste pode ser de fluxo, não de fornecedor.
Quanto tempo leva para revisar a transferência do chatbot para atendente antes da vigência do Decreto nº 13.135/2026 em 2 de novembro?
O artigo prioriza três frentes até 2 de novembro: mapear cada ponto de transferência do bot para humano, testar o fluxo como cliente canal por canal e confirmar se o histórico do mesmo fato gerador chega ao atendente antes da primeira resposta. O prazo depende de quantos canais e pontos existem.
Quais erros na transferência do chatbot para atendente violam o Decreto nº 13.135/2026 e geram risco de conformidade?
Transferir sem anexar resumo, reaproveitar protocolo de outro fato gerador e não garantir saída humana em todos os níveis do menu violam os arts. 6º II, 7º, 13 e 18 §1º. Esses erros quebram a rastreabilidade e a continuidade exigidas pelo decreto.
Quais gatilhos devem disparar a transferência do chatbot para um atendente humano segundo o novo decreto do SAC?
O principal gatilho é o pedido explícito do cliente, como 'quero falar com uma pessoa', garantido pelo art. 13 em todos os níveis do menu. A transferência deve ser imediata, anexando histórico da conversa e protocolo, sem exigir que o cliente esgote tentativas frustradas.
