Você assumiu a responsabilidade pelos processos de TI e descobriu que a Gestão de Incidentes é basicamente um caos documentado em planilhas sem padrão? Ou pior: nem planilha tem — cada analista resolve do seu jeito e ninguém sabe o que aconteceu com aquele incidente crítico da semana passada.

Se isso soa familiar, este post é para você. Vamos montar um processo de Gestão de Incidentes funcional, baseado em ITIL, em 30 dias. Sem precisar comprar ferramenta nova, sem reescrever 200 páginas de documentação e sem a equipe te olhando como se você fosse implantar mais uma burocracia inútil.

E tem mais: ao final, você encontra o link para baixar o template completo de Gestão de Incidentes pronto para adaptar à sua realidade.

Veja também no Youtube

O que é Gestão de Incidentes (e o que ela não é)

Antes de sair desenhando fluxogramas, vale alinhar o básico, porque muita confusão começa aqui.

No ITIL 4, um incidente é qualquer interrupção não planejada ou redução na qualidade de um serviço de TI. Isso inclui desde o sistema que caiu até o usuário que tem dificuldade para cessar o e-mail porque está exibindo uma mensagem “estranha”.

A Gestão de Incidentes é o processo que garante que esses incidentes sejam registrados, classificados, priorizados, tratados e encerrados de forma consistente, com o menor impacto possível no negócio.

O que ela não é:

  • Não é investigar a causa raiz (isso é Gestão de Problemas)
  • Não é aprovar mudanças no ambiente (isso é Gestão de Mudanças)
  • Não é uma central de reclamações sem retorno

Entendida a diferença, vamos ao trabalho.

Antes de começar: o diagnóstico rápido

Antes de montar qualquer processo, você precisa saber onde está pisando. Reserve um tempo para responder honestamente a estas perguntas:

  1. Existe algum registro formal de incidentes hoje? Onde?
  2. Como os usuários reportam problemas? (telefone, e-mail, WhatsApp, sistema?)
  3. Quem resolve os incidentes? Existe separação de N1, N2, N3?
  4. Existe algum SLA definido? Ele é cumprido?
  5. Qual foi o incidente mais crítico dos últimos 3 meses? Quanto durou?
  6. Existe comunicação com o usuário durante o incidente?

As respostas a essas perguntas vão definir o quanto você precisa construir do zero versus o quanto precisa apenas organizar o que já existe. Em ambos os casos, o plano de 30 dias funciona, você só vai ajustar o ritmo.

Semana 1: Entender e mapear o terreno

Objetivo: saber o que está acontecendo antes de propor qualquer mudança

O erro mais comum de quem chega para estruturar processos é apresentar a solução antes de entender o problema. A equipe rejeita na primeira reunião e você perde credibilidade antes mesmo de começar.

Na primeira semana, seu único trabalho é observar e perguntar:

  • Dia 1-2: Converse com os analistas de N1. Como eles registram hoje? O que funciona? O que os irrita? Ouça sem julgamentos.
  • Dia 3: Converse com o gestor da área. Quais são as reclamações da liderança? Quais incidentes têm gerado mais pressão?
  • Dia 4: Levante os dados que existem. Quantos incidentes por mês? Quais são os mais recorrentes? Quanto tempo médio de resolução?
  • Dia 5: Monte um rascunho do fluxo atual, não o que deveria ser, mas o que realmente acontece hoje.

Entrega da semana 1: Um mapa simples do fluxo atual de incidentes e uma lista dos 5 principais problemas identificados.

Semana 2: Definir o processo mínimo viável

Objetivo: desenhar o processo que vai funcionar, não o processo perfeito

Processo mínimo viável significa: o menor conjunto de etapas e definições que resolve o caos atual. Você vai evoluir depois. Por agora, foque no essencial.

As 6 etapas que todo processo de Gestão de Incidentes precisa ter:

  1. Registro: Todo incidente precisa ser registrado em algum lugar, sistema, planilha, qualquer coisa. Sem registro, não existe processo.
  2. Classificação: Defina categorias simples (infraestrutura, aplicação, acesso, comunicação). Isso vai te ajudar a identificar padrões depois.
  3. Priorização: Use a matriz urgência x impacto. Defina claramente o que é P1 (crítico), P2 (alto), P3 (médio) e P4 (baixo).
  4. Diagnóstico e resolução: Defina quem faz o quê em cada nível de suporte. Quando escala? Para quem? Em quanto tempo?
  5. Comunicação: Estabeleça um padrão mínimo de comunicação com o usuário: confirmação de abertura, atualização em caso de demora, confirmação de encerramento.
  6. Encerramento: Defina quando um incidente pode ser encerrado. O usuário precisa confirmar a resolução? Após quanto tempo sem resposta o incidente é fechado automaticamente?

Definindo a matriz de prioridade

Este é um dos pontos que mais geram discussão, e que mais fazem diferença na prática. A tabela abaixo é um ponto de partida. Adapte conforme a realidade da sua empresa:

PrioridadeDefiniçãoExemploSLA sugerido
P1 – CríticoSistema ou serviço indisponível afetando múltiplos usuários ou área críticaERP fora do ar, e-mail corporativo indisponívelResposta: 15 min / Resolução: 4h
P2 – AltoImpacto significativo, mas workaround existeImpressora do financeiro não funciona no fechamento do mêsResposta: 1h / Resolução: 8h
P3 – MédioImpacto moderado, não interrompe o trabalhoLentidão no sistema que não impede o usoResposta: 4h / Resolução: 24h
P4 – BaixoImpacto mínimo ou estéticoAtalho do desktop sumiu, fonte errada no relatórioResposta: 8h / Resolução: 72h

Entrega da semana 2: Fluxo do novo processo desenhado (rascunho), matriz de prioridade definida e lista de papéis e responsabilidades (quem faz o quê).

Semana 3: Documentar e comunicar

Objetivo: transformar o rascunho em documento e apresentar para a equipe

Documentação não precisa ser um livro. Para começar, você precisa de três coisas:

  • Fluxo do processo: Uma representação visual das etapas, com os atores e decisões. Pode ser feito no Lucidchart, Draw.io ou até no PowerPoint.
  • Política de incidentes: Um documento curto (3-5 páginas) que estabelece as regras: o que é um incidente, como é priorizado, quais os SLA`s e quem é responsável pelo quê.
  • Procedimento operacional: O passo a passo para o analista de N1. Como registrar, como classificar, quando escalar. Algo que um analista novo consiga seguir no primeiro dia.

Como apresentar para a equipe sem gerar rejeição

A apresentação do processo é tão importante quanto o processo em si. Algumas dicas práticas:

  • Mostre que você ouviu os analistas, cite o que eles disseram na semana 1 e como isso influenciou o processo
  • Não apresente como “implantação”. Apresente como “o que vamos testar por 30 dias”. Um piloto
  • Peça feedback explicitamente. A equipe que ajuda a construir não sabota a execução
  • Foque nos benefícios para eles: menos retrabalho, mais clareza sobre o que fazer, menos pressão da liderança

Entrega da semana 3: Fluxo documentado, política de incidentes rascunhada e processo apresentado para a equipe com ajustes incorporados.

Semana 4: Medir e ajustar

Objetivo: colocar o processo em operação e definir os primeiros KPIs

O processo só existe de verdade quando está sendo executado e medido. Na semana 4, você vai:

  • Colocar o processo em operação (mesmo que ainda não seja 100% perfeito)
  • Definir e começar a coletar os primeiros indicadores
  • Fazer check-ins rápidos com a equipe (15 minutos, duas vezes na semana)
  • Documentar os desvios e ajustar

Os 5 KPIs essenciais para começar

Não tente medir tudo de uma vez. Comece com estes cinco indicadores e vá adicionando conforme o processo amadurece:

  1. Volume de incidentes por período: Quantos incidentes por semana/mês. A base de tudo.
  2. MTTR (Mean Time to Resolve): Tempo médio de resolução. Divide o total de horas de resolução pelo número de incidentes.
  3. Cumprimento de SLA: % de incidentes resolvidos dentro do prazo acordado por prioridade.
  4. Taxa de reabertura: % de incidentes que foram encerrados mas voltaram. Alto índice = incidentes sendo fechados sem resolução real.
  5. Incidentes por categoria: Quais categorias concentram mais volume. Isso vai alimentar a Gestão de Problemas depois.

Entrega da semana 4: Processo em operação, primeiro relatório de indicadores (mesmo que com poucos dados) e lista de pontos de melhoria para o próximo ciclo.

Baixe o template gratuito de Gestão de Incidentes

Para facilitar sua jornada, criei um template completo que inclui:

  • ✅ Formulário de registro de incidentes
  • ✅ Matriz de prioridade (urgência x impacto)
  • ✅ Matriz RACI (papéis e responsabilidades)
  • ✅ Modelo de política de incidentes
  • ✅ Fluxo do processo em diagrama
  • ✅ Dashboard de KPIs com fórmulas prontas

O template foi criado para ser adaptado à realidade de qualquer área de TI, desde times enxutos de 3 pessoas até operações maiores com múltiplos níveis de suporte.

👉 Clique aqui para baixar o Template de Gestão de Incidentes

Conclusão: processo bom é processo que funciona

30 dias é tempo suficiente para sair do caos e ter um processo funcionando. Não será perfeito, e não precisa ser. O objetivo é criar uma base estruturada que pode evoluir.

Recapitulando o plano:

  • Semana 1: Diagnóstico — entenda o que existe antes de propor mudanças
  • Semana 2: Definição — processo mínimo viável, matriz de prioridade e SLAs
  • Semana 3: Documentação e comunicação com a equipe
  • Semana 4: Operação e primeiros KPIs

Se você está passando por esse processo agora e quer um acompanhamento mais próximo, com alguém para revisar seu fluxo, ajudar a documentar e preparar a apresentação para a liderança, conheça a mentoria do ITIL Data Master. É exatamente para isso que ela existe.

Dúvidas? Deixe nos comentários ou me encontre no LinkedIn.