O que é e como funciona na prática
O criterio rebote assistencia é aquele mecanismo que as equipes de suporte usam pra decidir se um chamado deve ser encaminhado, devolvido ou reaberto quando o técnico responsável não consegue resolver dentro do prazo ou da competência esperada. Não é coisa muito complicada, mas muita gente erra na configuração e acaba gerando um loop infinito de tickets voando de um nível pra outro sem resolução. No dia a dia, o fluxo mais comum funciona assim: o usuário abre o chamado, o sistema aplica regras automáticas de categorização, joga na fila do nível 1. Se o técnico não conseguir resolver dentro do tempo estabelecido, o criterio rebote assistencia entra em ação e o chamado vai para o nível 2. Se o nível 2 também não resolver, há possibilidades: o ticket volta pro nível 1 com observações, sobe pro nível 3, ou fica retido em uma fila de supervisão. O problema é que cada empresa configura isso de um jeito, e muita configuração de cabo armado que eu já vi por aí.
Como montar um criterio rebote assistencia que não gera sofrimento
Eu comecei a brincar com isso há alguns anos atrás, quando ainda estava montando a estrutura de helpdesk de uma empresa de médio porte. Na época, a gente tinha um ticket que ficava dando voltas entre o nível 1 e o nível 2 por quase duas semanas antes de ser resolvido. Duas semanas. Era insuportável e o índice de satisfação despencou. O que a gente fez foi criar um critério bem simples baseado em três variáveis: tempo de resposta, complexidade detectada automaticamente pelo campo de descrição do chamado, e histórico do solicitante. A parte do tempo era a mais importante. Se um técnico do nível 1 não dava andamento no chamado em 4 horas úteis, o sistema enviava um alerta pro responsável. Se passava de 8 horas sem atualização substantiva, o ticket ia automaticamente pro nível 2. Sem precisar de alguém analisando manualmente.
Um detalhe que todo mundo esquece: o criterio rebote assistencia precisa ter um limite de rebotes. De nada adianta configurar o sistema pra subir chamado se não houver um teto. Nós colocamos um máximo de dois rebotes. Se o ticket fosse reaberto pela segunda vez sem resolução, ele ia direto pra uma fila de escalonamento com um supervisor responsável. Isso cortou o tempo médio de resolução de chamado em cerca de 60%, porque eliminou aqueles tickets que ficavam viajando sem rumo. Tem um edge case que vale a pena mencionar. A gente tinha um problema recorrente com chamados de acessos e permissões que o nível 1 resolviam rápido, mas o sistema de categorização automática às vezes classificava errado como problema técnico complexo. O resultado era que o ticket subia pro nível 2 por engano, o técnico do nível 2 perdia tempo analisando, detectava o erro, mandava de volta pro nível 1, e o ciclo começava de novo. Resolvemos isso adicionando uma regra específica: chamados com palavras-chave como "senha", "acesso", "permissão" iam direto pro nível 1 com prioridade normal e tinham um SLA diferenciado de 2 horas. Se não resolvessem nesse prazo, aí sim sobriam. Isso reduziu os rebotes inúteis pela metade.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pegadinhas comuns e onde a maioria erra
A primeira armadilha é configurar o criterio rebote assistencia só com base no tempo. Parece lógico, mas tempo não significa complexidade. Um chamado pode ficar aberto por 3 dias sem movimento porque o técnico está esperando uma resposta do fornecedor, não porque não sabe resolver. Se o sistema subir esse ticket automaticamente, você está apenas redistribuindo trabalho sem resolver nada. O ideal é combinar tempo com indicadores de atividade real: atualizações no campo de observações, anexos adicionados, interações com o usuário. A segunda pegadinha é não definir critérios claros de o que conta como "resolução". Sem isso, o técnico do nível 1 pode marcar o chamado como concluído dizendo que "o usuário disse que funcionou", mas na verdade só deu uma solucao paliativa. Quando o problema reaparece e o ticket é reaberto, o criterio rebote assistencia entra em ação sem nenhum benefício real. Eu recomendo exigir que o técnico preencha um campo obrigatório de "causa raiz" antes de poder fechar qualquer chamado, senão o sistema vai te dar uma taxa de reincidência altíssima e você não vai saber se o problema é no ticket ou na qualidade do atendimento.
Outro ponto importante: o criterio rebote assistencia não funciona bem se você não tiver métricas de acompanhamento. Sem saber quantos rebotes estão acontecendo, qual o tempo médio por tipo de chamada, e quais técnicos estão gerando mais devoluções, você tá voando cego. Configure relatórios semanais simples e reveja com a equipe. Os números costumam mostrar problemas que a gente não percebe no dia a dia.
Quando o criterio rebote assistencia simplesmente não resolve
Existem cenários onde essa abordagem é ineficaz ou até prejudicial. Se sua equipe é pequena, com menos de cinco técnicos, o rebote automático pode criar mais atrito do que resolver. Nesses casos, um fluxo mais manual com supervisão direta costuma funcionar melhor. Também não recomendo depender exclusivamente de regras automáticas se seu sistema de helpdesk não permite personalização avançada dos critérios. Algumas plataformas mais básicas simplesmente não oferecem as opções de combinação de regras que fazem o sistema funcionar direito, e nesse caso o melhor é investir em uma ferramenta mais robusta ou criar um processo manual bem documentado. Se você quer algo prático pra começar, a maioria dos sistemas de helpdesk modernos — GLPI, Zendesk, Jira Service Management — já vêm com recursos de encadeamento e rebote configuráveis. A configuração básica leva de 30 minutos a 1 hora, dependendo da complexidade das suas regras. Não tem mistério, mas a diferença entre uma configuração mediana e uma boa configuração é o tempo que você investe entendendo como seus chamados realmente se comportam antes de definir as regras.
O criterio rebote assistencia bem feito economiza horas da sua equipe e reduz drasticamente a frustração tanto dos técnicos quanto dos usuários finais. Mal feito, é apenas mais uma fonte de caos no seu suporte. A escolha é sua, mas a diferença está nos detalhes da configuração e no acompanhamento constante dos resultados.
