Service request e incidente chegam pelo mesmo canal: o service desk. Os dois viram tickets. Os dois precisam de resposta.
Daí a confusão é compreensível. Mas são coisas completamente diferentes e tratá-los da mesma forma quebra a operação.
A definição de cada um
Incidente: interrupção não planejada de um serviço ou redução na qualidade de um serviço que estava funcionando.
Service request: solicitação formal de um usuário por algo que ele precisa para trabalhar, seguindo um processo padrão e pré-aprovado.
O incidente é algo que quebrou. O service request é algo que o usuário quer ou precisa, sem que nada tenha quebrado.
O teste de dois segundos
Duas perguntas resolvem qualquer caso ambíguo:
Estava funcionando antes? Se sim e não está funcionando agora: é incidente.
Existe um procedimento aprovado para entregar isso? Se sim e nada está quebrado: é service request.
Exemplos práticos
Service requests:
- Criação de conta de usuário para novo funcionário
- Reset de senha (quando o serviço de autenticação está funcionando)
- Instalação de software homologado
- Solicitação de acesso a um sistema
- Pedido de novo notebook
- Criação de caixa de e-mail
Incidentes:
- Sistema de e-mail fora do ar
- VPN não conecta para nenhum usuário
- Impressora da rede não responde
- Reset de senha falhando para todos os usuários (o serviço de autenticação quebrou)
- Internet lenta ou indisponível
Daí o reset de senha pode ser service request ou incidente dependendo do contexto. Se o usuário esqueceu a senha e o sistema está funcionando: service request. Se o sistema de autenticação está rejeitando senhas válidas de múltiplos usuários: incidente.
Por que a diferença importa na prática
SLA diferente. Incidentes críticos precisam de resolução em 1 a 4 horas. Service requests podem levar dias dependendo do tipo e complexidade. Tratar um service request como incidente critica inflação de urgência. Tratar um incidente como service request atrasa a resolução de algo que está quebrando o negócio.
Fluxo de trabalho diferente. Incidentes vão para a fila de suporte com escalada por impacto e urgência. Service requests vão para a fila de fulfillment com processo padrão documentado.
Métricas diferentes. Incidentes medem MTTR (Mean Time to Resolve). Service requests medem tempo de fulfillment e conformidade com o processo.
Relatórios diferentes. Se tudo entra como incidente, os relatórios mostram uma explosão de "incidentes" que são na verdade demandas normais de serviço. A gestão perde visibilidade do que está realmente quebrando.
O catálogo de serviços
O catálogo de serviços é onde os service requests vivem. É a lista de todos os serviços que a TI oferece aos usuários, com o processo para solicitar cada um.
Um catálogo bem estruturado define para cada serviço: o que é entregue, quem pode solicitar, como solicitar, qual o SLA e quais as aprovações necessárias.
Daí o service request não começa do zero toda vez. O usuário escolhe o que precisa no catálogo e segue o processo definido. O time de TI executa o que está documentado.
Gestão de service request no ITIL 4
O ITIL 4 chama essa prática de Service Request Management. Os princípios centrais:
Service requests devem ser simples de fazer e rápidos de cumprir. Se é complicado demais solicitar, os usuários vão criar workarounds ou abrir incidentes para tudo.
Service requests de baixo risco devem ser automatizados ou delegados. Reset de senha, por exemplo, pode ser self-service sem envolver o service desk.
A aprovação deve ser proporcional ao risco. Uma solicitação de acesso a sistema financeiro precisa de aprovação formal. Uma solicitação de headset para home office não precisa.
O que a prova ITIL 4 Foundation cobra
Os pontos mais frequentes:
A definição de service request e a diferença para incidente. Os dois testes para classificar um ticket (estava funcionando? existe procedimento?). O papel do catálogo de serviços. Por que a distinção importa para SLA e métricas. Exemplos de cada um — especialmente os casos ambíguos como reset de senha.
FAQ
Password reset é sempre service request? Não. Se o usuário esqueceu a senha e o sistema funciona: service request. Se o sistema de autenticação está com problema e resets estão falhando para múltiplos usuários: incidente.
Service request precisa de aprovação? Depende do risco e da política da organização. Solicitações de baixo risco e pré-aprovadas pelo catálogo não precisam de aprovação adicional. Solicitações de acesso a sistemas sensíveis geralmente precisam.
Um service request pode virar incidente? Sim. Se durante o fulfillment de um service request a TI descobre que algo está quebrado, abre um incidente separado. Os dois registros coexistem.
▌ Service request e incidente são temas da prova ITIL 4 Foundation. O simulado do PacketPass cobre todos os domínios com questões calibradas para o exame atual.
Informações baseadas no ITIL 4 Foundation oficial (Axelos/PeopleCert), CustomerExperience.io (julho 2026) e RekallTech (2026).