A IA ajuda nas passagens de turno do suporte de duas maneiras, e a segunda importa mais. A óbvia é escrever notas de passagem melhores: resumir cada ticket aberto e sinalizar os que têm um SLA ou uma atualização prometida vencendo. A que a maioria das equipes deixa passar é que um agente de IA que trabalha a fila entre os turnos nunca troca de turno ele mesmo, então menos tickets atravessam a linha, e todo ticket que ele passa para uma pessoa chega com uma nota escrita no momento do escalonamento, não às 17h55 de memória.
O que realmente se perde na troca de turno raramente é o contexto. É o compromisso: "Eu disse a ela que atualizaríamos até as 14h UTC", o responsável pelo próximo passo e as correções já tentadas. Uma boa nota de passagem carrega cinco coisas (o que o cliente quer, o que foi tentado, o que foi prometido e até quando, quem é o próximo responsável, que evidências foram encontradas), e os resumos nativos dos helpdesks no Zendesk, Freshdesk e Help Scout cobrem bem as duas primeiras e o resto só se um agente digitar.
Um colega de IA como a eesel faz isso dentro do seu helpdesk atual. Na SE Ranking, uma equipe de Zendesk espalhada por 16 países e por todos os fusos horários, ela passou cerca de 1.260 chats para pessoas em um mês, cada um com o nome e o e-mail do cliente, e deixou cerca de 2.600 notas internas em tickets. Os planos começam em US$ 299 por mês por 500 créditos.
Por que as coisas escapam pelas frestas na troca de turno?
Porque a passagem é o único momento em que um ticket não tem dono. O agente que sai já está mentalmente fora, o que entra ainda não se atualizou, e tudo o que vivia apenas na cabeça do agente que sai simplesmente some. Trabalho na fila de suporte da eesel todos os dias, e os tickets que machucam quase nunca são os difíceis. São os fáceis, em que alguém fez uma pequena promessa e depois ninguém anotou.
Isto é o que costuma escapar, mais ou menos na ordem do estrago que cada item causa:
- A promessa. "Vou confirmar com o financeiro e te respondo até o fim do dia." O ticket parece qualquer outro ticket pendente, mas agora há um cliente esperando por um horário específico.
- O que já foi tentado. Sem isso, o próximo agente pede ao cliente que limpe o cache de novo, e o cliente percebe.
- Quem é responsável pelo próximo passo. Escalado para a engenharia? Aguardando o cliente? Com um colega que já foi para casa?
- O relógio do SLA. Um ticket que estoura às 9h15 pertence ao topo da lista do próximo turno, não a algum ponto do meio.
- O humor do cliente. O terceiro contato de um cliente irritado se lê de forma muito diferente de um primeiro contato.
Os clientes também sentem isso de fora. Um engenheiro no Hacker News descreveu como era o suporte de um fornecedor de nuvem quando um ticket ficava quicando entre regiões:
"...instead they keep sending tickets back for "more info", inevitably followed by a hand-off to another team in a different time zone. We have spent days trying to convince them there was an issue before, which just seems unacceptable."
Esse é o custo de uma passagem rasa: a próxima equipe começa o diagnóstico do zero. E não é um problema de nicho; outro comentarista descreveu o modelo follow-the-sun em termos bem diretos:
"It can absolutely work, given the right async workflows, but it can also absolutely fail. I'm inclined to believe failure is the default mode of operation."
"Os fluxos assíncronos certos" são basicamente o jogo inteiro. A maioria das equipes tenta resolver com um documento compartilhado ou uma thread no Slack no fim de cada turno. Isso funciona por mais ou menos uma semana, depois o documento fica desatualizado, porque escrevê-lo é a última coisa que um agente cansado faz antes de sair.
Como a IA pode ajudar nas passagens de turno do suporte?
A IA pode fazer quatro trabalhos aqui, e só o primeiro é o que a maioria dos artigos descreve. Esta é a ordem em que eu os ativaria.
Os números de tickets neste esboço são ilustrativos. Coloque seus próprios números na calculadora mais abaixo.
1. Resumir os tickets abertos. É a versão que o ChatGPT e a maioria dos fornecedores vendem: a IA lê cada ticket e escreve um resumo, para que o agente que entra não precise rolar por 20 respostas. Ajuda, e a maioria dos helpdesks já tem isso (mais sobre isso abaixo). Meu guia de resumo de tickets aprofunda o quão bons são esses resumos.
2. Sinalizar os tickets de risco. Ordene a passagem por risco e não por antiguidade: SLA vencendo na próxima hora, um retorno prometido, um contato repetido ou um relato de indisponibilidade. Uma lista de resumos de 40 tickets em ordem de data esconde os poucos que realmente importam.
3. Reduzir o que atravessa a linha. Este é o trabalho que muda a conta. Um agente de IA de helpdesk que responde e resolve tickets não sai às 18h. Status de pedido, perguntas de como fazer, links de devolução: se a IA os fecha enquanto o turno que sai está encerrando e antes de o que entra chegar, eles nunca viram itens de passagem. A passagem mais barata é aquela que nunca precisa acontecer.
4. Escrever a nota no momento do escalonamento. Quando a IA não consegue fechar um ticket, ela o entrega a uma pessoa. Essa entrega já é uma passagem por si só, e acontece em cada ticket no momento em que o contexto está mais fresco, em vez de uma vez por turno. Assim a passagem deixa de ser uma tarefa de fim de turno e passa a ser uma propriedade do ticket.
Os trabalhos 3 e 4 são o motivo pelo qual acho que "a IA escreve um documento de passagem melhor" subestima o assunto. Um documento melhor ainda pressupõe que a mesma pilha de tickets passa de uma mesa para a outra. Um agente que trabalha a fila entre os turnos deixa a pilha menor, e as notas sobre o que sobra foram escritas por algo que nunca se cansa no fim de um turno.
O que uma boa nota de passagem deve conter?
Cinco campos por ticket. Se uma nota os tem, a próxima pessoa consegue agir no ticket sem ler a conversa. Se falta algum, ela lerá a conversa de qualquer jeito, e então a nota não economizou nada.
| Campo | Exemplo | Quem deve preencher |
|---|---|---|
| O que o cliente quer | Reembolso do pedido 4417 | IA, a partir da conversa |
| O que já foi tentado | Link de redefinição enviado duas vezes, falhou | IA, a partir das respostas e das notas internas |
| O que foi prometido e até quando | "Atualização até as 14h UTC" | A IA rascunha a partir das respostas, uma pessoa confirma |
| Quem é responsável pelo próximo passo | Equipe de cobrança | Uma pessoa, ou uma regra de roteamento que a IA aplica |
| Evidências já encontradas | Pedido pago, não enviado | IA, a partir de uma consulta no Shopify, no CRM ou na ferramenta de cobrança |
O padrão na última coluna é o que vale notar. A IA é muito boa nos dois primeiros campos e no último, já que são fatos que estão no ticket ou em um sistema conectado. A promessa e o responsável são onde uma pessoa ainda deve dar o aval, porque são compromissos, e um compromisso errado em uma nota de passagem é pior que nenhum. Meu guia de passagem para humano no chat cobre o lado voltado ao cliente do mesmo momento.
Duas regras tornam essas notas confiáveis entre fusos horários:
- Faça link para a fonte. Toda afirmação da nota deve poder ser verificada no ticket. "O cliente está irritado" é uma opinião; "terceiro contato em 48 horas" é um fato que o próximo agente pode verificar.
- Separe o que foi encontrado do que foi suposto. "Pedido enviado em 28 de out." (do Shopify) e "provavelmente atraso da transportadora" (uma suposição) nunca devem soar iguais.
O que Zendesk, Freshdesk, Help Scout e Gorgias já fazem?
A maioria dos helpdesks já consegue resumir um ticket sob demanda, e isso cobre a parte do "o que aconteceu" de uma passagem. Nenhum deles mantém, de fábrica, uma lista contínua do que foi prometido e de quem é o responsável. Veja o que cada um faz, segundo a documentação dos próprios fornecedores, consultada em 30 de outubro de 2026.
| Helpdesk | IA nativa ligada à passagem | O que cobre | Plano e limites |
|---|---|---|---|
| Zendesk | Resumos de tickets no Agent Workspace | Recapitula comentários públicos; notas internas só se um administrador ativar | Suite e Support Professional ou superior, com cota de uso mensal; parte do complemento Copilot |
| Freshdesk | Freddy AI Summarize | Issue, Steps Taken e Outcome, incluindo notas privadas | Em Ticket content assist do Freddy AI Copilot, o administrador precisa ativar |
| Help Scout | AI Summarize | Resumo da conversa com um clique | Planos Plus e Pro; o resumo é sempre em inglês |
| Gorgias | AI Agent configurações de passagem | Tópicos de passagem e mensagens separadas para quando o chat está online ou offline | Parte do Gorgias AI Agent |
Resumos de tickets do Zendesk
A versão do Zendesk aparece como um banner abaixo do cabeçalho do ticket. A documentação diz que ele recapitula "the public comments that have been added to a ticket so far", e as notas internas só entram se o seu administrador ativar. Para uma passagem, essa configuração importa muito, porque é nas notas internas que o agente que sai costuma registrar o que tentou. Os resumos podem ser atualizados manualmente a cada cinco minutos para captar novos comentários. Mais detalhes no meu post sobre os resumos de tickets do Zendesk Copilot.
Freddy AI Summarize no Freshdesk
O resumo do Freshdesk é o mais próximo de uma nota de passagem de fábrica, porque vem estruturado: uma seção Issue, uma seção Steps Taken que inclui notas privadas e um Outcome. Os agentes podem editá-lo e salvá-lo, e a Freshworks sugere adicionar os resumos a notas privadas para referência da equipe. Ele não se atualiza quando chegam novas respostas; você o gera de novo. Meu passo a passo dos resumos do Freddy traz a configuração.
Quem usa descreve mais ou menos o benefício de passagem que você esperaria:
"Freddy makes our tickets easy to understand for all agents. The need for explanation has decreased, as agents can find the Freddy summary at the top of the ticket."
Help Scout AI Summarize e as passagens do Gorgias
O Help Scout é o único fornecedor cuja documentação cita diretamente o caso de uso de passagem: o AI Summarize é "useful for handing off a conversation to another teammate." Dois limites merecem atenção para uma equipe em vários fusos: o resumo é sempre escrito em inglês, seja qual for o idioma da conversa, e não se atualiza sozinho; você clica em Update Summary quando entram novas respostas. Mais na minha visão geral do Help Scout AI.
O Gorgias aborda o tema pelo outro lado. As configurações de passagem do AI Agent permitem escrever instruções de passagem separadas para quando o chat está online e offline, informar o horário comercial na mensagem offline e coletar o e-mail do cliente para que o próximo turno possa dar seguimento. É uma passagem da IA para a equipe, e não de turno para turno, mas é o mesmo momento. Tratei disso no meu post sobre a orientação de passagem do Gorgias.
A lacuna comum aos quatro: os resumos são puxados sob demanda e descrevem o passado. Eles não ordenam a fila por quem deve o quê, e só existem nos tickets que alguém pensou em abrir. Para uma fila tranquila, tudo bem. Para uma equipe com duas ou três trocas de turno por dia, a nota de passagem precisa já estar lá quando a próxima pessoa chegar.
Como isso fica em produção?
Aqui estão três clientes da eesel cujas configurações resolvem o problema da passagem cada uma de um jeito. Todos os números vêm dos casos publicados deles e cobrem de 8 de agosto a 8 de setembro de 2026.
SE Ranking: as regras de passagem por escrito. A SE Ranking atende o suporte de três produtos no Zendesk, com uma equipe de 16 países cobrindo todos os fusos horários. Esse é o formato de uma equipe follow-the-sun, e as regras de passagem estão escritas. Quando um chat precisa de uma pessoa (um reembolso, uma extensão de teste, a mesma pergunta feita duas vezes ou um cliente dizendo que a tela dele não corresponde), a eesel passa com o nome e o e-mail do cliente. Se estava investigando um problema, passa com uma nota sobre o que já disse ao cliente. Problemas de nível 2 viram um ticket com as evidências anexadas primeiro: o domínio, o link da auditoria ou uma captura do conector. E ela nunca diz a um cliente que alguém está entrando agora; diz para esperar uma resposta em um ou dois dias úteis. Nesse mês passou cerca de 1.260 chats para a equipe e deixou cerca de 2.600 notas internas, a maioria rascunhos para uma pessoa enviar.
Essa última regra é a que eu copiaria em qualquer equipe com vários fusos horários. Um bot que promete um agente ao vivo às 3 da manhã cria exatamente o tipo de compromisso que morre na passagem.
Amagency: o formato de nota que poupa uma leitura prévia. A Amagency atende o suporte de quatro marcas de consumo a partir de uma conta do Gorgias. A eesel nunca responde aos clientes ali. Em vez disso, cada nota interna traz a resposta completa ao cliente no topo, pronta para copiar, e abaixo dela uma seção curta com os dados do pedido que encontrou e qualquer coisa que sinalizou. Isso é uma nota de passagem em tudo menos no nome: quem pega o ticket em seguida vê as evidências e a resposta proposta sem abrir a conversa. Ela deixou cerca de 900 notas internas e 460 rascunhos de resposta em cerca de 350 tickets no mês. Também faz toda manhã de dia útil, às 9h no horário de Sydney, uma revisão curta do workspace e envia uma nota por e-mail à equipe, o que funciona como um briefing de início de turno.
Swiftreg: o turno da noite que não é um turno. A Swiftreg, uma vendedora britânica de placas de veículo no Zendesk, recebe a maioria dos tickets durante o expediente, mas o caso observa que os que chegam de madrugada recebem o mesmo tratamento dos diurnos. De cerca de 2.100 tickets no mês, a eesel enviou 1.494 respostas públicas e deixou 1.055 notas internas onde o próximo passo cabia à equipe. Quem abre a fila de manhã encontra os tickets da noite ou respondidos ou com uma nota.
Uma regra da configuração de um cliente mostra por que regras escritas valem mais que documentos de passagem. Um administrador de suporte que configurava o agente colocou assim:
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
Regras como essa costumam viver na cabeça de um agente sênior e viajam de turno em turno boca a boca. Depois de escritas nas instruções do agente, elas se aplicam do mesmo jeito às 14h e às 2h, não importa quem esteja de plantão. É um benefício discreto da IA para equipes com vários turnos: a política deixa de depender de quem está trabalhando naquele dia.
Quanto tempo a sua passagem custa?
Coloque seus próprios números. Os valores padrão assumem duas trocas de turno por dia, 40 tickets abertos em cada uma e 6 minutos para o próximo agente se atualizar em um ticket sem nota, contra 1,5 minuto com uma boa nota. Marque o que a sua passagem atual captura de forma confiável e o verificador lista as lacunas.
O tempo de atualização hoje escala com quantos dos seis campos as suas notas já capturam. "Com um agente de IA" assume que o agente fecha a parcela que você definir antes da passagem e deixa uma nota completa em todo o resto.
Duas coisas costumam chamar a atenção. Primeiro, o tempo de atualização é maior do que as pessoas esperam, porque você o paga em cada troca de turno, todo dia: 80 tickets a 4,5 minutos cada são 6 horas do novo turno se atualizando, antes de alguém responder a um cliente. Segundo, a nota faz mais trabalho que o desvio. Mesmo com 0 % no controle deslizante, uma nota completa em cada ticket reduz o tempo de atualização em cerca de dois terços nos valores padrão. Se o número que te preocupa é o tamanho da fila em si e não o tempo de atualização, meus posts sobre zerar um backlog de tickets e reduzir o tempo de atendimento cobrem esse lado.
O que a IA deve passar adiante e o que deve ficar com uma pessoa?
A IA deve carregar os fatos e os tickets de rotina; as pessoas devem ser donas dos compromissos e das decisões de julgamento. Assim eu dividiria para uma equipe com dois ou três turnos:
| Na troca de turno | A IA cuida | Uma pessoa cuida |
|---|---|---|
| Tickets de rotina (status de pedido, como fazer, devoluções) | Responde e fecha antes e depois da passagem | Confere uma amostra no início do turno |
| Resumo de cada ticket aberto | Escreve em todo ticket em que atua | Lê e sinaliza o que estiver errado |
| Passos tentados e evidências encontradas | Extrai de respostas, notas e consultas | Acrescenta o que foi feito fora do ticket (uma ligação, uma thread no Slack) |
| Atualizações e prazos prometidos | Rascunha a partir das respostas, sinaliza os que vencem em breve | Confirma a promessa e a cumpre |
| Responsável por um escalonamento | Aplica suas regras de roteamento | Assume a responsabilidade, sobretudo em engenharia ou cobrança |
| Indisponibilidades e questões de segurança | Aciona quem está de plantão | É dono do incidente e das atualizações ao cliente |
| Clientes irritados ou recorrentes | Sinaliza no topo da passagem | Escreve a resposta |
As salvaguardas para deixar o lado da IA seguro são poucas. Ela nunca deve fechar ou reatribuir em silêncio um ticket que pertence a outro turno. Toda nota de passagem que ela escrever deve ter link para o ticket de origem. E ela nunca deve prometer uma pessoa ao vivo que a escala não consegue entregar, que é de novo a regra da SE Ranking. Para o desenho mais amplo, veja meu post sobre boas práticas de passagem com IA.
Como configurar passagens assistidas por IA no seu helpdesk?
Cinco passos. Os dois primeiros são organização do helpdesk de que qualquer processo de passagem precisa, com IA ou sem ela.
Passo 1: transforme os cinco campos em campos reais do ticket
Uma nota de passagem em texto livre é ignorada. Adicione campos personalizados ou tags para próximo responsável e prometido até (data e hora), e garanta que o horário de vencimento do SLA apareça na visualização do ticket. Quando viram campos, tanto pessoas quanto a IA podem preenchê-los, e você pode montar uma visualização ordenada por "prometido até".
Passo 2: defina o horário comercial por região
Seu helpdesk precisa saber quem está online e quando; caso contrário, os temporizadores de SLA e as mensagens de "o chat está offline" ficarão errados em toda troca de turno. O Zendesk oferece vários horários no Enterprise, o Freshdesk oferece vários horários comerciais do Pro em diante, o Gorgias tem horário comercial em todos os planos a partir do Basic, e o Help Scout tem horário da empresa com horários personalizados de caixa de entrada no Plus e no Pro. Percorri os caminhos de menu de cada um no meu guia de cobertura de fim de semana. Para o desenho do SLA em si, veja as boas práticas de SLA.
Passo 3: conecte um agente de IA e dê a ele um modelo de nota de passagem
Conecte o agente ao seu helpdesk, à central de ajuda e aos tickets anteriores, além dos sistemas de que ele precisa para consultas (Shopify, sua ferramenta de cobrança). Depois escreva a regra de passagem com palavras simples, como você orientaria um novo contratado: "Quando você passar um ticket para uma pessoa, deixe uma nota interna com o que o cliente quer, o que você tentou, qualquer coisa que tenha prometido e até quando, quem deve ser o responsável e o que você encontrou." Na eesel isso é apenas texto nas instruções do agente; vale para todo escalonamento, 24 horas por dia.
Passo 4: agende um briefing de início de turno
Peça que a IA poste um briefing curto quando cada turno começar: tickets com SLA vencendo nas próximas duas horas, tickets com atualização prometida para hoje, contatos repetidos, tudo o que foi escalado desde o último turno. Envie para onde a sua equipe já olha: Slack, Microsoft Teams ou e-mail. Na eesel isso é um job agendado: um prompt, um horário e um fuso horário, de modo que o briefing da APAC e o da Europa possam chegar cada um às 9h locais.
Passo 5: rode duas semanas só com rascunhos e depois amplie
Comece com a IA escrevendo notas e rascunhos, sem enviar respostas. Em cada troca de turno, faça uma pergunta ao agente que entra: dava para agir neste ticket só pela nota? Corrija o modelo onde a resposta for não. Depois deixe a IA fechar sozinha os seus dois ou três temas de rotina principais. Há anos vejo a eesel colocar agentes de IA em filas de suporte reais, e toda configuração nova roda primeiro contra tickets reais do passado, porque respostas que soam confiantes erram de formas que você só vê nos seus próprios dados. Minha lista de erros de implementação de IA cobre as armadilhas habituais.
Como saber se as suas passagens estão funcionando?
Meça a passagem em si e não só a fila. Quatro números dizem quase tudo de que você precisa:
- Compromissos perdidos. Tickets em que o horário de atualização prometido passou sem resposta. É o número que todo o exercício existe para levar a zero.
- Violações de SLA na primeira hora de um turno. Se as violações se concentram logo após a troca de turno, a passagem está perdendo o relógio.
- Tempo até a primeira ação após o início do turno. Quanto tempo até o turno que entra responder ao primeiro ticket herdado. Boas notas fazem isso levar minutos, não uma hora.
- Tickets que atravessam cada troca de turno. O número que a calculadora acima estima. Ele deve cair conforme a IA assume mais volume de rotina.
Marque com tag tudo o que a IA tocar para poder separar os tickets dela dos da equipe. A SE Ranking pediu uma tag ai_handled em todo ticket em que a eesel atua, além de tags de útil e não útil, para que a contenção seja contada no Zendesk em vez de estimada. Meus posts sobre métricas de atendimento com IA e qualidade de escalonamento vão além, e IA para relatórios de suporte cobre como montar o relatório em si.
Onde a eesel não é a escolha certa: se você tem um único turno com um ou dois agentes, um modelo de passagem de cinco linhas no helpdesk mais o botão de resumo nativo resolvem bem. E se o seu problema é que ninguém fica online por longos períodos, e não o momento entre turnos, leia meu guia de suporte fora do horário ou veja as opções de dimensionamento em IA para dimensionamento de suporte.
Experimente a eesel nas passagens de turno
Se a sua equipe de suporte trabalha em turnos e a manhã começa com uma pilha que ninguém documentou, a eesel funciona como um colega que nunca troca de turno. Ela entra na sua fila atual no Zendesk, Freshdesk, Gorgias ou Help Scout, responde o que a sua central de ajuda e os tickets anteriores já cobrem e deixa uma nota interna com os fatos, o rascunho e as evidências em cada ticket que passa para uma pessoa. Um briefing agendado pode chegar ao Slack ou ao Teams no início do turno de cada região.
É assim que a SE Ranking opera uma fila em 16 países, e é assim que a Amagency recebe uma resposta pronta para enviar nos tickets do Gorgias antes de a equipe abrir. Os planos são um lote mensal fixo de créditos: um ticket ou chat é um crédito, a partir de US$ 299 por mês por 500, e os 100 créditos do plano gratuito permitem ver as notas primeiro nos seus próprios tickets.
Experimente a eesel na passagem de hoje à noite, ou veja como ela se compara no meu panorama dos melhores agentes de IA para atendimento ao cliente.