Skip to main content

Atribuição de Incidente/Problema

1. Objetivo

Esta página ensina o agente de triagem a classificar tickets entre Incidente e RequisiçãoProblema no sistema de suporte.

A classificação correta permite:

  • priorizarseparar falhas operacionais
  • separar atendimento reativo de solicitaçõescausas planejadasestruturais
  • restaurar serviços com mais rapidez
  • identificar recorrências
  • encaminhar corretamente para as equipes
  • melhorar métricas de atendimento
  • apoiar análise de causa raiz

2. Definições

Incidente

Um Incidente é qualquer evento que interrompe ou degrada um serviço que deveria estar funcionando.funcionando.

Características:

  • algo parou de funcionar
  • algo está funcionando errado
  • há impacto na operação
  • háexiste urgência parade restaurar restauração
  • o serviçofoco é voltar ao normal rapidamente

Objetivo do incidente: 

  • restaurar o funcionamento normal o mais rápido possível.

    vel

Exemplos de incidentesincidentes:

  • Não consigo acessar o e-mail
  • Sistema ERP não abre
  • Impressora parou de funcionar
  • VPN caiu
  • Sistema está muito lento
  • Erro ao salvar dados
  • Usuário bloqueado no sistema
  • Site fora do ar
  • Integração parou de funcionar
  • VM não conecta ao servidor

Requisição

Problema

UmaUm RequisiçãoProblema é uma pedidocausa raiz conhecida ou suspeita de algo novoum ou adicional,mais nãoincidentes, relacionado aou uma falha.condição recorrente que exige investigação estrutural.

Características:

  • serviço estámesmo funcionandoincidente acontece repetidamente
  • usuárioexistem solicitavários algoincidentes com a mesma origem provável
  • a causa raiz não existeestá interrupçclara
  • há necessidade de investigação
  • geralmenteo foco não é planejávelapenas restaurar, mas eliminar a origem

Objetivo dado requisição:problema:

  • identificar fornecere algotratar solicitadoa pelocausa usuário.

    raiz

  • reduzir reincidência
  • evitar novos incidentes

Exemplos de requisiçõesproblemas:

  • CriarQuedas usuáriorecorrentes de VPN sem causa definida
  • Impressora que falha toda semana
  • Lentidão frequente no sistemaERP após atualizações
  • ConcederErro acesso a uma pasta
  • Instalar software
  • Solicitar equipamento
  • Criar e-mail
  • Criar grupo no sistema
  • Solicitar relatório
  • Alterar permissãorecorrente de acesso
  • Instalar impressora
  • Criar integração entre sistemas
  • Instabilidade frequente em servidor
  • Vários usuários relatando a mesma falha em períodos próximos
  • Falha intermitente em backup sem causa confirmada

3. Regras de decisão

A IA deve aplicar as seguintes regras:

Regra 1

Se algo estava funcionando e parou,parou, classificar como:


INCIDENTE

Regra 2

Se há erro, falha, lentidão, indisponibilidade ou interrupção usuário está pedindo algo novo,atual, classificar como:


REQUISIÇÃOINCIDENTE

Regra 3

Se o usuáriofoco relatado erro,ticket falhaé ourestaurar indisponibilidade,rapidamente o serviço, classificar como:


INCIDENTE

Regra 4

Se o usuárioticket solicitadescreve acesso,recorrência, criação, instalaçrepetição ou configuraçinvestigação, de causa, classificar como:


REQUISIÇÃOPROBLEMA

Regra 5

Se existem vários incidentes parecidos e o objetivo é entender a origem comum, classificar como:
PROBLEMA

Regra 6

Se o serviço já foi restabelecido, mas a causa raiz precisa ser analisada, classificar como:
PROBLEMA

4. Regra principal

Use esta lógica:

  • Incidente trata o efeito imediato
  • Problema trata a causa estrutural

Se existe impacto atual no usuário ou operação, a classificação inicial tende a ser Incidente.

Se a situação aponta para recorrência, causa raiz ou investigação estruturada, a classificação tende a ser Problema.

5. Casos comuns

Caso: acessosistema bloqueado

não abre

Exemplo

"MinhaExemplo:
“O contaERP não está bloqueada"abrindo”

Classificação:


Incidente

Motivo:
há falha atual no serviço acesso deveria funcionar.

Caso: solicitar acesso

Exemplo

"Preciso de acesso ao sistema financeiro"

Classificação:

Requisição

Motivo: é um novo acesso.

Caso: sistema lento

 com impacto hoje

Exemplo

"Exemplo:
“O sistema está muito lento hoje"desde a manhã”

Classificação:


Incidente

Motivo:
há degradação deatual do serviço.o

Caso: instalação

Exemplo

"Instalarerro o AutoCADrecorrente no meusistema

Exemplo:
“Esse computador"erro acontece toda semana no fechamento”

Classificação:


RequisiçãoProblema

Motivo:
há solicitaçrecorrência e indício de causa raiz não tratada

Caso: falha isolada de impressora

Exemplo:
“A impressora do setor fiscal parou de imprimir hoje”

Classificação:
Incidente

Motivo:
interrupção atual de serviço.o

5.

Caso: mesma impressora com falhas repetidas

Exemplo:
“A mesma impressora falha várias vezes por mês”

Classificação:
Problema

Motivo:
há recorrência e necessidade de investigação estrutural

Caso: VPN caiu agora

Exemplo:
“A VPN caiu e não consigo trabalhar”

Classificação:
Incidente

Motivo:
indisponibilidade atual

Caso: quedas frequentes de VPN

Exemplo:
“A VPN cai com frequência em vários usuários”

Classificação:
Problema

Motivo:
existe padrão recorrente e possível causa comum

Caso: VM não conecta ao servidor

Exemplo:
“Preciso conectar minha VM ao servidor para subir backups, mas não conecta”

Classificação:
Incidente

Motivo:
falha operacional atual

Caso: várias VMs perdem conexão em momentos diferentes

Exemplo:
“Nas últimas semanas várias VMs perderam conexão com o servidor”

Classificação:
Problema

Motivo:
há repetição e necessidade de análise de causa raiz

6. Casos ambíguos

Alteração

Falha deatual permissão

com recorrência conhecida

Se o usuário relata uma falha acontecendo agora, mas já possuíarecorrente:

  • classificar acessoo eticket perdeu:

    →atual como Incidente

    Se

  • sinalizar oque usuáriopode nunca teve acesso:

    →haver RequisiçãoProblema

    Troca derelacionado

Serviço senha

restaurado, mas causa desconhecida

Se a falha já passou, mas o usuárioticket esqueceufoi aaberto senha:para descobrir o motivo:

  • →classificar como RequisiçãoProblema

Muitos tickets com o mesmo sintoma

Se oexistem sistemavários nãotickets aceitasemelhantes em pouco tempo:

  • os tickets individuais tendem a senha correta:

    →ser IncidenteIncidentes

  • o ticket de investigação central tende a ser Problema

6.

7. Regra de desempate

Se houver dúvida:vida, a IA deve verificar:

  1. verificar se existe falha de sistemaatual?
  2. verificar se algo deixou de funcionarfuncionar?
  3. o usuário precisa voltar a operar agora?
  4. o foco é restauração ou investigação?

Aplicar o desempate assim:

  • se nãohá houverimpacto falha,atual, classificar como RequisiçãoIncidente
  • se o foco é causa raiz, classificar como Problema

7.

8. Sinais linguísticos úteis

Indícios de Incidente

Palavras e expressões comuns:

  • não funciona
  • parou
  • caiu
  • erro
  • lento
  • indisponível
  • travando
  • não conecta
  • fora do ar
  • não abre
  • não imprime
  • bloqueado

Indícios de Problema

Palavras e expressões comuns:

  • recorrente
  • acontece sempre
  • novamente
  • intermitente
  • causa
  • causa raiz
  • investigar
  • voltando a ocorrer
  • frequente
  • padrão
  • repetição

Esses sinais ajudam, mas não decidem sozinhos. A decisão final depende do contexto.

9. Saída esperada do classificador

A IA deve retornar:

tipo_ticket: incidente | requisicaoconfianca:problemaconfianca: 0-1justificativa: texto curto

Exemplo:Exemplo 1:

tipo_ticket: incidenteconfianca: 0.92justificativa:94justificativa: usuário relata queindisponibilidade atual do sistema

Exemplo nã2:

tipo_ticket: problemaconfianca: 0.89justificativa: relato indica recorrência e necessidade de investigação abrede causa raiz

8.

10. Erros comuns que a IA deve evitar

Classificar como requisiçãoProblema quando na verdade é incidente:Incidente

Evitar isso em casos como:

  • sistema fora do ar agora
  • erro de login atual
  • sistemaimpressora travandoque acabou de parar
  • servidor indisponível
  • falha atual de integração quebrada

Classificar como incidenteIncidente quando na verdade é requisição:Problema

Evitar isso em casos como:

  • pedidofalha derecorrente acessosem causa definida
  • criaçrepetição de usuárioerro em vários tickets
  • instalaçinvestigação técnica de softwareorigem comum
  • solicitaçinstabilidade frequente no mesmo serviço
  • análise de causa raiz após vários incidentes

11. Regra operacional complementar

Quando existir falha atual e também indício de recorrência:

  • o registro principal do atendimento deve ser Incidente
  • a análise estrutural deve gerar ou relacionar um Problema

Isso evita que a operação perca velocidade e garante tratamento da causa raiz.

12. Resumo final para a IA

Use esta lógica curta:

  • Se algo que deveria funcionar parou, falhou ou degradou, classifique como Incidente
  • Se o foco é recorrência, causa raiz ou investigação estrutural, classifique como Problema
  • Se houver dúvida e existir impacto atual, classifique primeiro como Incidente
  • Se o caso apontar repetição ou origem comum, sinalize necessidade de relatórioProblema relacionado


Back to top