Ticket de suporte: como aprender a priorizar por impacto real, não por urgência percebida
Fila de chamados com 30 tickets. Todo mundo diz que o dele é urgente. Como separar urgência real de percebida — e o que isso ensina sobre triagem em qualquer contexto técnico.
Todo ticket de suporte que chegava era urgente para quem abriu.
Usuário sem acesso à impressora: urgente. Servidor de email lento: urgente. Computador travando: urgente. Sem internet no celular corporativo: urgente.
Com 30 tickets na fila e dois atendentes, precisávamos decidir o que fazer primeiro. E a decisão não podia ser baseada em quem gritou mais alto.
Urgência percebida é o quanto a pessoa que abriu o ticket sente que o problema é crítico. Urgência real é o quanto o problema está bloqueando operação do negócio.
Essas duas coisas raramente são a mesma.
Computador do CEO travando parece urgente — é CEO. Mas se o CEO tem reunião em uma hora e o problema é lentidão, isso pode esperar 40 minutos. Servidor de email fora do ar para 50 funcionários parece menos urgente — mais silencioso no chamado. Mas paralisa operação de 50 pessoas.
Critério de prioridade que desenvolvi:
Quantas pessoas estão bloqueadas? Um usuário sem impressora versus o servidor de email que paralisa um time inteiro. Escala importa.
O problema está bloqueando completamente ou apenas degradando? Sem acesso ao sistema é diferente de acesso lento. Bloqueio total tem prioridade.
Tem workaround disponível? Se tem workaround que resolve parcialmente enquanto o problema não é corrigido, a urgência cai. Se não tem nenhuma alternativa, a urgência sobe.
O tempo de resolução é proporcional ao impacto? Problema que leva 5 minutos e resolve bloqueio de 10 pessoas tem prioridade maior que problema que leva 2 horas e afeta 1 pessoa.
A parte mais difícil não era priorizar — era comunicar a priorização.
Quando você decide que o ticket do usuário vai ser atendido depois, essa pessoa está esperando e não sabe por quê. Se não comunicar, a percepção é abandono ou desorganização.
Aprendi a confirmar o recebimento de todo ticket com previsão realista: "Recebi seu chamado. Estamos priorizando dois incidentes que estão bloqueando operação de times. Seu problema será atendido em aproximadamente X horas." Essa comunicação sozinha reduzia o volume de follow-up.
Triagem de tickets de suporte foi treinamento para algo que aparece em todo nível de engenharia: fila de trabalho com múltiplas urgências simultâneas.
Como arquiteto ou staff engineer, a fila não é de tickets de suporte — é de decisões arquiteturais, incidentes, débito técnico, features novas. O princípio é idêntico: urgência percebida não é urgência real. Impacto de negócio é o que determina ordem.
A habilidade de separar ruído de sinal na fila de trabalho é uma das mais valiosas em qualquer nível de senioridade. E é treinável desde o primeiro emprego.
Essa semana: na sua fila de trabalho atual, o que você está priorizando porque alguém gritou mais alto — e o que você está adiando que deveria ser primeiro?