Vou gerenciar o backlog de chamados
Resposta rápida
Gerenciar backlog de chamados não é zerar fila — é ler o que a fila está dizendo. Estabeleça um ritual semanal de 60 a 90 minutos para triar, repriorizar e diagnosticar o backlog: separe os tickets em incidente (algo quebrou, urgente), requisição (pedido padrão) e problema (causa raiz por trás de incidentes recorrentes), aplique SLA por categoria, identifique os tickets vencidos e cobre quem está pendurado neles. Olhe o padrão: cinco chamados do mesmo sistema apontam para um problema estrutural, não para cinco incidentes. Use o backlog como termômetro da operação. Sem esse ritual, TI vira balcão reativo: atende o que grita mais alto, perde os SLAs silenciosos e nunca vê a causa real.
Na empresa pequena, o volume de chamados é baixo e o "ritual" cabe em 20 a 30 minutos por semana — muitas vezes conduzido pelo MSP ou pelo único ponto focal interno de TI. A ferramenta de chamados não precisa ser sofisticada: planilha compartilhada, formulário simples ou ferramenta gratuita já cobrem o essencial. O risco aqui é exatamente o oposto do volume: chamado chega por WhatsApp e nunca entra na fila formal, ninguém sabe quantos foram resolvidos no mês, e o termômetro da operação não existe. A disciplina mínima — todo pedido entra como ticket, mesmo o do fundador — vale mais do que qualquer SLA elaborado. Padrão por sistema raramente aparece com volume baixo; o que aparece é padrão por pessoa que sempre pede o mesmo tipo de coisa, e é por aí que vem a leitura.
Na empresa média, o backlog tem volume para mostrar padrão e o ritual semanal já exige time de suporte e coordenador conduzindo juntos. A ferramenta passa a importar — categorização decente, SLA por tipo, relatório básico de backlog idade e reabertura. O risco característico é a triagem virar exclusividade do coordenador: quando uma pessoa só classifica tudo, o ritual depende dela e o time não desenvolve critério próprio. É também o porte onde a separação incidente/requisição/problema deixa de ser teoria — sem ela, o time vira escudo emocional dos usuários que reclamam mais alto. Comitê mensal com áreas-cliente para discutir os padrões do backlog ajuda a transformar dado em decisão de priorização compartilhada, em vez de TI sempre na defensiva.
Na empresa grande, o backlog é processo industrializado: ITSM completo (geralmente ServiceNow, BMC, Jira Service Management ou equivalente), múltiplos níveis de suporte, SLA por contrato com áreas, governança formal. O risco não é falta de ritual, é ritual demais — comitês semanais cheios de gráfico que ninguém usa para decidir. O foco aqui é qualidade da categorização (sem ela, os relatórios mentem) e leitura cruzada de indicadores: SLA cumprido isolado engana; junto com reabertura, idade média e first-call resolution, dá diagnóstico. Backlog idade crescente em torre específica costuma indicar falta de braço ou de conhecimento naquela frente; problema recorrente em sistema específico vira projeto de remediação com prazo. Em escala, gestão de backlog é gestão de operação como um todo.
- O backlog cresce sem que ninguém saiba ao certo por quê
- Os mesmos chamados se repetem mês após mês e ninguém olhou a causa
- A priorização do dia depende de quem grita mais alto, não do SLA
- Há tickets parados há semanas em status de "aguardando"
- Você não consegue dizer com segurança o tempo médio de resolução
- Reuniões com áreas-cliente sempre voltam ao mesmo "TI demora demais"
O ritual semanal de triagem
O coração da gestão de backlog é um ritual fixo, semanal, de 60 a 90 minutos, com o time de suporte e o coordenador. Sem essa cadência, o backlog acumula em silêncio e vira crise. O ritual tem quatro blocos: rever os tickets abertos e seu status real (não o status formal), reclassificar o que está mal categorizado, repriorizar com base no SLA e no impacto, e identificar padrões — sinais de problema estrutural por trás de incidentes recorrentes.
O critério de priorização é simples: impacto (quantas pessoas ou processos afetados) versus urgência (quanto tempo até virar problema sério). Tickets de alto impacto e alta urgência vão para o topo, mesmo que tenham chegado depois. Tickets de baixo impacto e baixa urgência podem esperar — e precisam ser comunicados ao solicitante para não acumular ansiedade.
Separe incidente, requisição e problema
Misturar essas três categorias é o erro mais comum em help desk imaturo. Incidente é algo que quebrou e precisa voltar a funcionar — tem SLA agressivo. Requisição é pedido padrão (criar acesso, instalar software, trocar equipamento) — tem fila e prazo, mas não é urgência. Problema é a causa raiz por trás de incidentes recorrentes — não tem SLA de resolução individual, mas precisa de dono e acompanhamento. Tratar requisição como incidente esgota o time; tratar problema como incidente nunca chega à causa.
- Rode o relatório de backlog. Tickets abertos por categoria, status, prazo e responsável. Comece pelos vencidos e pelos sem dono claro.
- Reclassifique o que está errado. Incidente que virou requisição, requisição rotulada como urgente, ticket aberto há semanas em "aguardando" sem ninguém cobrar.
- Repriorize por impacto e urgência. Reordene a fila com critério explícito, não pela ordem de chegada nem pela pressão de quem reclamou último.
- Identifique padrões. Cinco tickets do mesmo sistema, do mesmo usuário, do mesmo tipo? Há um problema estrutural por trás — abra um ticket de problema e dê dono.
- Comunique o que vai e o que não vai. Avise solicitantes sobre tickets postergados. Silêncio gera reabertura e perda de confiança.
Indicadores que dão sinal real
Acompanhar backlog sem indicadores faz o ritual virar opinião. Quatro métricas dão o sinal mais útil: tempo médio de resolução por categoria (incidente, requisição), percentual de SLA cumprido, número de tickets reabertos no período e backlog idade média (quanto tempo, em média, um ticket aberto está esperando). Reabertura alta indica resolução superficial; backlog idade crescente indica gargalo no time ou priorização ruim; SLA caindo em uma categoria específica costuma esconder problema estrutural que merece virar ticket de problema.
Quando virar ticket de problema
O ITIL chama de "problema" a causa raiz por trás de incidentes recorrentes. Na prática, três sinais indicam que está na hora de abrir um ticket de problema: o mesmo tipo de incidente apareceu cinco ou mais vezes no mês; um sistema específico concentra desproporcionalmente os tickets; ou um incidente sério aconteceu e a equipe não tem certeza da causa. Problema tem dono, tem investigação técnica e tem prazo de conclusão — diferente do incidente, ele aceita semanas. Sem essa separação, o time apaga o mesmo incêndio toda semana e nunca corrige a fiação.
Confundir SLA com prioridade. SLA é prazo, prioridade é ordem de atendimento. Um ticket de SLA de 8 horas pode ser despriorizado por outro de impacto maior — desde que o time saiba e comunique.
Não fechar tickets por status formal. Tickets em "aguardando usuário" há um mês sem cobrança viram poluição. Defina prazo para fechamento automático após silêncio do solicitante.
Categoria genérica demais. Quando "Outros" é a maior categoria, você perdeu a leitura do backlog. Force categorização mínima — ainda que com lista curta.
Triagem só do coordenador. Quando uma pessoa só classifica e prioriza tudo, o ritual depende dela. Distribua a triagem com critério escrito para o time inteiro aplicar.
- Todos os tickets vencidos têm explicação e nova previsão
- Padrões repetidos viraram ou tickets de problema, ou estão em observação
- Os solicitantes de tickets postergados foram comunicados
- SLA, reabertura e idade média do backlog foram lidos juntos
- Tickets sem dono claro receberam responsável
- O backlog idade média da semana foi comparado com a anterior