O que é desvio de chamados (ticket deflection) e como melhorá-lo

Toda equipe de suporte de TI deseja resolver mais solicitações sem precisar contratar mais agentes. Uma das maneiras mais eficazes de fazer isso é o desvio de tickets: ajudar os funcionários a encontrar respostas ou realizar tarefas comuns antes de abrirem um ticket de suporte.

Quando bem feita, a redução de chamados diminui o volume de solicitações sem prejudicar a experiência do funcionário. Os usuários obtêm respostas mais rapidamente, os agentes gastam menos tempo com tarefas repetitivas e a central de atendimento pode se concentrar nas solicitações que exigem conhecimento especializado. O desafio é criar um sistema que as pessoas realmente utilizem.

Neste guia, você aprenderá o que é o desvio de tickets, como ele funciona, quais estratégias produzem os melhores resultados e como medir seu impacto. Também mostraremos como você pode implementar o desvio de tickets com o InvGate Service Management, combinando suporte baseado em IA, uma base de conhecimento e recursos de autoatendimento.

• O desvio de tickets reduz o número de chamados que chegam a um agente, resolvendo os problemas por meio do autoatendimento antes mesmo que eles sejam criados.
• A taxa de desvio é calculada da seguinte forma: (interações desviadas / total de interações potenciais) × 100.
• A base de conhecimento, o catálogo de serviços e os chatbots ou agentes virtuais são os três principais mecanismos de desvio em uma plataforma de ITSM.
• Uma alta taxa de desvio baseada em atrito (usuários desistindo, sem resolver o problema) é pior do que uma baixa: a qualidade da medição é importante.

O que é desvio de tickets no ITSM?

O desvio de tickets é o processo de resolver uma solicitação ou dúvida por meio de recursos de autoatendimento antes que um ticket formal seja criado na central de atendimento. O usuário encontra uma resposta, realiza uma ação ou recebe ajuda de um agente automatizado, e o ticket nunca chega a existir. Sem intervenção de agente, sem entrada na fila, sem tempo de atendimento.

Essa distinção é importante. O desvio de tickets não é o mesmo que fechar tickets mais rapidamente ou atingir uma alta taxa de resolução no primeiro contato (FCR). A FCR mede a rapidez com que um ticket existente é resolvido sem escalonamento. O desvio ocorre a montante, antes que o ticket seja registrado. Confundir os dois leva a programas que se otimizam para o objetivo errado.

Uma observação sobre o desvio por atrito: nem toda interação que termina sem um ticket é um desvio bem-sucedido. Se o usuário pesquisar na base de conhecimento, não encontrar nada útil e abandonar o autoatendimento para criar um chamado por meio de um canal diferente, seja e-mail, telefone ou visita ao departamento de TI, isso não é desvio. Isso é atrito. O volume de tickets pode parecer menor em um canal enquanto aumenta em outro, e a métrica de desvio parece melhor do que realmente é. A forma como você mede é tão importante quanto o que você mede.

Como funciona o desvio de tickets: os principais mecanismos

No ITSM, o desvio de tickets pode ocorrer por meio de vários mecanismos, dependendo da plataforma. Alguns dos mais comuns incluem:

• Base de conhecimento: o usuário procura uma resposta antes de abrir um ticket, encontra um artigo relevante e resolve o problema por conta própria.
• Portal de autoatendimento: o usuário encontra o serviço de que precisa, preenche um formulário ou segue um fluxo de trabalho guiado para atender a uma solicitação sem o envolvimento da central de atendimento. Em plataformas mais avançadas, o catálogo de serviços e a automação atendem à solicitação automaticamente.
• Agentes virtuais ou chatbots: uma interface conversacional que ajuda a responder perguntas, recomendar artigos da base de conhecimento, coletar informações ou iniciar solicitações de serviço. Dependendo da plataforma, ela pode se basear em fluxos de trabalho predefinidos, IA ou uma combinação de ambos.
• Automação para solicitações comuns: algumas plataformas executam tarefas repetitivas sem intervenção humana após o usuário iniciar uma solicitação, como redefinir uma senha, provisionar acesso ou criar uma conta. Nesses casos, um ticket pode nem ser criado ou pode ser encerrado automaticamente assim que o fluxo de trabalho for concluído.
• Recomendações contextuais ou pesquisa inteligente: enquanto os usuários digitam uma pergunta ou preenchem um formulário, a plataforma sugere artigos de conhecimento, respostas ou serviços relevantes que possam resolver o problema antes que a solicitação seja enviada.

Por que o desvio de tickets é importante para as equipes de TI (o custo de não desviar)

A maioria das filas de TI apresenta um problema estrutural: uma parcela significativa dos tickets recebidos consiste em solicitações repetitivas e de baixa complexidade que poderiam ser resolvidas sem a intervenção de um agente. Somente as redefinições de senha podem representar cerca de 30% dos tickets de TI nas organizações. Quando essas solicitações chegam à fila, triadas manualmente, atribuídas manualmente, resolvidas manualmente, elas consomem tempo que deveria ser dedicado a tarefas de maior prioridade.

As consequências operacionais se acumulam rapidamente.

• Esgotamento dos agentes. Técnicos seniores passam o dia lidando com solicitações de Nível 1 que poderiam ser resolvidas por um artigo da base de conhecimento ou um fluxo de trabalho do catálogo. O trabalho não é desafiador, mas é constante. Com o tempo, esse desequilíbrio contribui para o desengajamento e a rotatividade em equipes que já operam com recursos reduzidos.

• Custo por ticket. Os tickets tratados manualmente acarretam um custo real, estimativas de analistas do setor situam a média entre US$ 22 e mais de US$ 100, dependendo da complexidade e do tempo de tratamento. Em grande volume, os números se tornam difíceis de ignorar.

• Acúmulo permanente. Quando a fila fica cheia de solicitações de baixo valor, os incidentes de alta prioridade ficam enterrados. A triagem dos tickets se torna mais difícil de executar porque tudo está competindo pela mesma atenção limitada. Os tempos de resposta para problemas críticos são prejudicados, não porque a equipe não tenha capacidade, mas porque o sinal se perde no volume.

Nada disso é resolvido com a contratação de mais agentes. A solução está em impedir que os tickets que não deveriam existir entrem na fila.

Como medir a taxa de desvio de tickets

A taxa de desvio de tickets é a porcentagem de possíveis interações de suporte que foram resolvidas sem a criação de um ticket. É o indicador mais direto da eficácia do autoatendimento.

Fórmula:

Taxa de desvio (%) = (Interações desviadas ÷ Total de interações potenciais) × 100

Definição das variáveis:

• Interações desviadas: sessões de autoatendimento, conversas no VSA ou pesquisas na base de conhecimento que terminaram sem a criação de um ticket. O usuário resolveu o problema, ou, pelo menos, não enviou uma solicitação.
• Total de interações potenciais: todas as interações de suporte iniciadas, independentemente de terem sido desviadas ou de terem resultado em um ticket. Interações desviadas + tickets criados = total de interações potenciais.

Avisos sobre a medição (sem eles, a métrica pode induzir em erro):

Contagem dupla. A mesma solicitação pode ser registrada em dois canais, por exemplo, um usuário tenta usar o VSA, desiste e envia um e-mail. Se ambas as interações forem contadas, o denominador aumenta e a taxa cai artificialmente. Defina claramente a atribuição de canais antes de iniciar o acompanhamento.

Desvio por atrito. Conforme observado anteriormente: o usuário abandona o autoatendimento sem resolver o problema e cria um ticket em outro lugar. A sessão de autoatendimento é contabilizada como “desviada” em alguns sistemas de rastreamento, mas nenhum valor foi entregue. Uma medição precisa distingue entre sessões que terminaram com uma resolução confirmada e sessões que simplesmente não geraram um ticket naquele canal.

Desvio vazio. A base de conhecimento exibe um artigo que parece responder à pergunta, mas o artigo está desatualizado. O usuário o lê, não encontra a resposta de que precisa e cria um ticket mesmo assim. A sessão de busca ainda pode ser considerada desviada, dependendo de como o rastreamento estiver configurado.

Referências (nível do setor, não atribuíveis à InvGate):

• Organizações sem uma estratégia ativa de desvio geralmente apresentam taxas em torno de 23%.
• Equipes com uma base de conhecimento integrada e VSA relatam taxas entre 40% e 60%.
• Programas maduros com desvio assistido por IA podem ultrapassar 70% em categorias específicas de solicitações.

Esses números servem como orientação, não como metas. A meta correta não é a maior taxa de desvio possível , é a maior taxa em que os desvios representam resoluções reais. Uma taxa de 70% em que os usuários resolvem seus próprios problemas é um resultado excelente. Uma taxa de 70% em que os usuários abandonam o autoatendimento e reabrem tickets por outros canais não traz nenhum benefício operacional e corrói ativamente a confiança na função de suporte.

Como melhorar o desvio de tickets com o InvGate Service Management

Passo 1 - Alimente a base de conhecimento com as resoluções de tickets, não com um projeto de redação separado

Quando um agente encerra um ticket, o InvGate Service Management pode gerar um primeiro rascunho de um artigo da base de conhecimento a partir dessa resolução em menos de 30 segundos, usando os detalhes da solicitação do ticket e as etapas de resolução como material de origem. O agente revisa e edita antes de publicar, a IA produz um ponto de partida, não um artigo finalizado.

Separadamente, o Knowledge Discovery analisa os tickets encerrados de forma recorrente e extrai unidades menores chamadas “Knowledge Snippets”, ou Fragmentos de Conhecimento, padrões e soluções extraídos do histórico dos tickets que não exigem que ninguém escreva um artigo completo. Cada Snippet começa invisível e passa por uma fila de moderação; um revisor decide se ele é preciso o suficiente para alimentar as Recomendações de Solução voltadas para os agentes, as respostas do Agente Virtual de voltadas para o usuário final ou ambas.

Essa é a base de um ciclo de KCS (Serviço Centrado no Conhecimento): a base de conhecimento cresce como um subproduto da prestação de suporte, e não como um projeto de documentação separado que compete com o tempo dos agentes. O efeito prático é que os tipos de tickets mais comuns, aqueles que geram o maior volume, são também os que têm maior probabilidade de acumular uma boa cobertura na Base de Conhecimento ao longo do tempo.

Passo 2 - Construa o Catálogo de Serviços em torno das categorias de solicitações que os usuários reconhecem

O catálogo de serviços da InvGate permite que as equipes organizem as categorias de acordo com a forma como os usuários percebem suas necessidades, e não de acordo com a forma como a TI as classifica internamente. Cada categoria pode incluir os campos de dados específicos necessários para esse tipo de solicitação, a lógica de aprovação e as regras de encaminhamento configuradas sem a necessidade de código.

Quando o catálogo reflete a linguagem e a intenção do usuário, a adoção do portal aumenta e a criação de tickets desestruturados diminui. Os usuários encontram o caminho certo rapidamente, enviam informações completas na primeira tentativa e o fluxo de trabalho é executado automaticamente. Quando, ao contrário, o catálogo reflete o organograma interno de TI, os usuários ficam confusos, escolhem categorias erradas e criam tickets desestruturados que exigem retrabalho manual a cada etapa.

Reestruturar o catálogo costuma ser a mudança de maior impacto que uma equipe pode fazer para melhorar a taxa de desvio e isso não requer implementação técnica.

Passo 3 - Implantar o Agente Virtual de Serviço 

O Agente Virtual de Serviço opera nos três canais a partir de uma única configuração, sem necessidade de configuração separada para cada canal. Ele responde utilizando os artigos aprovados da Base de Conhecimento e os trechos descritos na Etapa 1; portanto, sua qualidade depende diretamente do nível de manutenção dessa camada, e não de um recurso de IA separado.

Quando ele não consegue resolver a solicitação, o encaminhamento para um nível superior transfere todo o contexto da conversa: o que foi perguntado e o que já foi tentado para o ticket, de modo que o agente não comece com um ticket em branco e o usuário não precise repetir sua explicação. Para equipes que já utilizam o Microsoft Teams, isso também significa que o suporte ocorre sem a necessidade de alternar para um portal separado.

Passo 4 - Acompanhe as métricas de desvio

O InvGate Service Management inclui mais de 150 métricas integradas, painéis configuráveis e relatórios OLAP, sem módulos adicionais. Especificamente para o desvio, os indicadores relevantes são:

• Artigos da base de conhecimento que resolveram as dúvidas dos usuários (e quais não geraram um ticket de acompanhamento).
• Taxa de adoção do portal por categoria de serviço (quais categorias estão sendo utilizadas e quais estão sendo ignoradas).
• Volume de interações no VSA e a porcentagem que terminou sem a criação de um ticket.

Esses indicadores identificam onde a base de conhecimento apresenta lacunas, quais categorias do catálogo geram maior atrito e quais tipos de solicitações estão gerando volume de tickets, apesar da disponibilidade do autoatendimento. Esses dados orientam a próxima iteração: atualização da base de conhecimento, reestruturação das categorias do catálogo e ajuste dos fluxos de resposta do VSA.

Erros comuns que prejudicam os programas de redução de chamados

• Base de conhecimento desconectada do portal. Artigos que os usuários não conseguem encontrar no momento da intenção, quando estão prestes a abrir um ticket, não desviam nada. A integração com o fluxo de envio de tickets é imprescindível.

• Catálogo de serviços organizado com base na taxonomia de TI, e não na linguagem do usuário. Quando os usuários não conseguem identificar a categoria correta, eles ignoram o catálogo e abrem tickets desestruturados. A adesão ao sistema cai e a oportunidade de desvio de tickets desaparece.

• Métricas de desvio inflacionadas por atritos. Contar sessões de autoatendimento abandonadas como desvios bem-sucedidos produz um número que parece bom, mas não diz nada de útil. Meça as resoluções confirmadas, não as sessões que não geraram um ticket em um único canal.

• VSA operando com uma base de conhecimento desatualizada. Um agente conversacional que dá respostas erradas ensina os usuários a contornar o autoatendimento. O dano à adoção leva meses para ser reparado. A manutenção da base de conhecimento não é opcional depois que um VSA é implantado.

• Ausência de ciclo de melhoria a partir de tickets escalados. Cada ticket que chega a um agente é um sinal: algo no autoatendimento não funcionou. Equipes que não utilizam os tickets escalados para identificar lacunas na base de conhecimento e no catálogo estão perdendo a principal fonte de informação para melhorar o desvio ao longo do tempo.

Perguntas frequentes sobre desvio de chamados

Como se calcula a taxa de desvio de tickets?

Taxa de desvio (%) = (Interações desviadas ÷ Total de interações potenciais) × 100. Interações desviadas são sessões de autoatendimento, pesquisas na Base de Conhecimento ou conversas no VSA que terminaram sem a criação de um ticket. O total de interações potenciais é a soma das interações desviadas e dos tickets enviados. O resultado é a porcentagem da demanda de suporte que foi atendida sem o envolvimento de um agente.

O que é uma boa taxa de desvio de tickets?

Isso depende da maturidade do programa. Organizações sem uma estratégia ativa de desvio geralmente apresentam taxas em torno de 23%. Equipes com uma base de conhecimento conectada e um Agente Virtual de Serviço (VSA) relatam taxas entre 40% e 60%. Programas maduros assistidos por IA podem ultrapassar 70% em categorias específicas. A meta não é o número mais alto possível, é a taxa mais alta em que os desvios representam resoluções reais. Uma taxa baseada em usuários que abandonam o autoatendimento sem resolver o problema não agrega valor real, independentemente de quão alta a porcentagem pareça.

O desvio de tickets pode prejudicar a qualidade do atendimento?

Sim, se for baseada em atrito, em vez de resolução. Quando os usuários abandonam o autoatendimento porque não conseguem encontrar uma resposta e são forçados a criar um ticket por meio de um canal diferente, as métricas de desvio podem parecer saudáveis, enquanto a experiência real do usuário se deteriora. Uma base de conhecimento desatualizada, um catálogo de serviços confuso ou um VSA com cobertura insuficiente podem produzir “desvios” que, na verdade, são interações fracassadas. O desvio eficaz de tickets melhora a experiência do usuário; o desvio por abandono a prejudica e torna a métrica pouco confiável.