O que é a gestão de pedidos de serviço
A gestão de pedidos de serviço é uma das práticas do ITIL 4 que trata pedidos pré-definidos dos utilizadores como parte normal e esperada da entrega do serviço. Ao contrário dos incidentes, que representam interrupções inesperadas, os service requests são pedidos planeados com procedimentos de fulfillment conhecidos antecipadamente.
"Service request management é a prática que trata pedidos pré-definidos e acordados dos utilizadores, iniciados como parte normal da entrega do serviço."
Service request vs incidente: qual a diferença?
A distinção entre service request e incidente é fundamental para encaminhar correctamente os contactos para o service desk e definir os fluxos adequados. Um incidente é uma interrupção não planeada ou uma redução da qualidade de um serviço. Um service request é um pedido planeado, esperado e com procedimento de resposta normalizado.
| Característica | Service request | Incidente |
|---|---|---|
| Natureza | Pedido planeado e esperado | Interrupção não planeada |
| Urgência | Normal (SLA definido por tipo) | Alta (restaurar serviço rapidamente) |
| Procedimento | Fluxo pré-definido e normalizado | Diagnóstico e resolução ad hoc |
| Exemplos | Reset de password, novo equipamento | Servidor em baixo, aplicação indisponível |
| Aprovação | Pode ser necessária para alguns pedidos | Não aplicável - acção imediata |
| Automatização | Alta possibilidade de automatizar | Depende do tipo de incidente |
Exemplos concretos de service requests incluem: reset de password, pedido de acesso a uma aplicação, requisição de novo equipamento (portátil, monitor, teclado), pedido de informação sobre um serviço, instalação de software standard, criação de conta num sistema, e pedido de alteração de dados pessoais.
Tipos de pedidos de serviço
Os service requests podem ser classificados em diferentes categorias consoante a sua natureza. Esta classificação facilita a automatização, a definição de SLAs e o encaminhamento para as equipas correctas.
| Tipo | Descrição | Exemplos | Automatizável? |
|---|---|---|---|
| Acesso | Pedidos de permissões e contas | Acesso a pasta partilhada, nova conta de utilizador, permissões em aplicação | Parcialmente |
| Informação | Perguntas e consultas sobre serviços | Como utilizar o VPN, onde encontrar o formulário X, qual o prazo do serviço Y | Sim (chatbot/FAQ) |
| Provisão | Pedidos de novo equipamento ou software | Requisição de portátil, instalação de software standard, novo telemóvel corporativo | Parcialmente |
| Alteração | Mudanças de configuração standard | Reset de password, alteração de limites de caixa de correio, mudança de grupo | Sim (totalmente) |
| Reclamação/Feedback | Comentários e reclamações sobre serviços | Reclamação sobre qualidade do serviço, sugestão de melhoria, elogio | Registo automático |
A categorização correcta no momento do registo é essencial para o encaminhamento automático e para a recolha de métricas úteis. Um portal self-service bem desenhado guia o utilizador na escolha da categoria correcta através de formulários intuitivos e linguagem simples, evitando a necessidade de recategorização posterior pela equipa do service desk.
"Nem todos os contactos para o service desk são incidentes. Uma parte significativa, frequentemente entre 30% e 50% do volume total, são service requests. Distinguir correctamente estes dois tipos de contacto melhora a eficiência do service desk e a satisfação do utilizador."
O processo de gestão de pedidos de serviço
O fluxo de um service request segue etapas bem definidas desde a submissão até ao fecho. Este fluxo normalizado é precisamente o que distingue a gestão de pedidos da gestão de incidentes: o caminho é conhecido com antecedência e pode ser optimizado ao longo do tempo.
Submissão do pedido
O utilizador submete o pedido através do portal self-service, e-mail, telefone ou chat. O portal self-service é o canal preferencial por permitir automatização e tracking. O pedido é registado com os dados necessários para o fulfillment.
Categorização automática
O sistema categoriza o pedido com base no tipo seleccionado ou na análise do texto. A categorização correcta determina o SLA aplicável, o fluxo de aprovação necessário e a equipa responsável pelo fulfillment.
Aprovação (se necessária)
Alguns pedidos requerem aprovação de um gestor ou de uma equipa especializada antes de avançar. As aprovações devem ser limitadas ao mínimo necessário - pedidos de baixo risco e custo standard não devem requerer aprovação manual.
Fulfillment
A equipa ou o sistema executa o pedido. Pedidos simples como resets de password podem ser executados automaticamente em segundos. Pedidos mais complexos, como provisão de equipamento, envolvem múltiplas equipas e prazos mais longos.
Verificação
O pedido é verificado para confirmar que foi executado correctamente e que o utilizador tem acesso ao que solicitou. Em pedidos automatizados, a verificação pode ser feita por testes automáticos. Em pedidos manuais, o utilizador é contactado para confirmação.
Fecho e avaliação
O pedido é fechado no sistema e o utilizador recebe notificação. É enviado um questionário de satisfação (CSAT) para medir a qualidade do serviço prestado. Os dados recolhidos alimentam o processo de melhoria contínua.
Modelos de fluxo de trabalho
Cada tipo de service request deve ter o seu próprio modelo de fluxo de trabalho (workflow model) documentado no catálogo de serviços. Este modelo define os passos exactos, os responsáveis por cada passo, os SLAs aplicáveis e as condições de escalada. A padronização dos workflows é o que permite medir, optimizar e automatizar a gestão de pedidos ao longo do tempo.
Automatização na gestão de pedidos de serviço
A automatização é um dos maiores benefícios da gestão de pedidos de serviço. Ao contrário da gestão de incidentes, onde cada situação pode ser única, os service requests seguem padrões repetitivos que são ideais para automatizar. Uma estratégia de automatização bem implementada reduz custos, melhora a satisfação e liberta a equipa do service desk para tarefas de maior valor.
Ferramentas e técnicas de automatização
Benefícios da automatização
Pedidos automatizados não consomem tempo da equipa. Um reset de password automatizado liberta entre 5 e 10 minutos de trabalho do técnico para cada pedido, e este tipo de pedido pode representar 20% a 30% do volume total.
Um reset de password que demora 30 segundos em vez de 2 horas muda radicalmente a percepção do utilizador sobre o serviço de TI. A disponibilidade 24/7 para pedidos simples é um factor diferenciador significativo.
A automatização elimina variações no processo de fulfillment. O mesmo pedido é executado da mesma forma todas as vezes, reduzindo erros humanos e garantindo conformidade com políticas de segurança.
Cada pedido automatizado gera dados que permitem medir o volume, o tempo de fulfillment e os padrões de utilização. Esta informação é essencial para optimizar o catálogo de serviços e dimensionar recursos.
Relação com o catálogo de serviços
A gestão de pedidos de serviço e o catálogo de serviços são práticas complementares e interdependentes. O catálogo define os serviços disponíveis e as condições em que são prestados; os service requests são o mecanismo pelo qual os utilizadores acedem a esses serviços.
"O catálogo de serviços é a fonte de verdade sobre o que está disponível. Cada entrada no catálogo deve ter um procedimento de service request correspondente, com formulário, SLA, workflow de aprovação e instruções de fulfillment claramente definidos."
O que o catálogo deve incluir para suportar os service requests
| Elemento do catálogo | Impacto na gestão de pedidos |
|---|---|
| Descrição do serviço em linguagem de utilizador | Facilita a escolha correcta no portal self-service |
| Critérios de elegibilidade | Permite validar automaticamente se o utilizador pode solicitar o serviço |
| SLA de fulfillment | Define expectativas claras e permite medir o desempenho |
| Processo de aprovação | Especifica se é necessária aprovação e de quem |
| Informação necessária para o pedido | Orienta o formulário do portal para recolher os dados correctos |
| Custo do serviço (se aplicável) | Permite ao utilizador tomar decisões informadas e facilita a aprovação |
Um catálogo de serviços bem mantido reduz significativamente o número de pedidos mal submetidos, que exigem clarificação antes do fulfillment. Quando os utilizadores encontram rapidamente o que procuram e percebem o que vão receber e quando, a satisfação aumenta e o volume de contactos desnecessários para o service desk diminui.
Boas práticas na gestão de pedidos de serviço
6 boas práticas para uma gestão de pedidos eficaz
Simplificar os formulários de pedido
Pedir apenas os dados estritamente necessários para o fulfillment. Formulários longos e complexos desencorajam a utilização do portal self-service e levam os utilizadores a recorrer ao telefone. Cada campo desnecessário é um obstáculo à adopção.
Automatizar o que for possível
Identificar os tipos de pedido com maior volume e menor complexidade para automatizar primeiro. Resets de password e criação de contas são candidatos ideais. O objectivo é que o fulfillment aconteça sem intervenção humana sempre que seja seguro fazê-lo.
Definir SLAs por tipo de pedido
Não usar um SLA genérico para todos os service requests. Um reset de password tem um SLA diferente de uma requisição de equipamento. SLAs específicos por tipo permitem medir o desempenho de forma significativa e gerir expectativas correctamente.
Medir o CSAT sistematicamente
Enviar um questionário de satisfação curto após o fecho de cada pedido. O CSAT (Customer Satisfaction Score) é a métrica mais directa da percepção do utilizador sobre o serviço. Analisar regularmente os comentários negativos para identificar padrões de melhoria.
Eliminar aprovações desnecessárias
Rever periodicamente os fluxos de aprovação e questionar se cada aprovação acrescenta valor real. Aprovações desnecessárias atrasam o fulfillment, frustram os utilizadores e consomem tempo dos aprovadores. A maioria dos pedidos de baixo risco não precisa de aprovação manual.
Tornar o portal self-service o canal mais rápido
Os utilizadores adoptam o self-service quando é genuinamente mais rápido do que o telefone ou o e-mail. Se submeter um pedido pelo portal demorar mais do que ligar para o service desk, a adopção não acontece. O design da experiência do utilizador é crítico para o sucesso.
Métricas relevantes para acompanhar
As métricas e KPIs mais relevantes para a gestão de pedidos de serviço são: volume de pedidos por tipo e canal, tempo médio de fulfillment por tipo, taxa de cumprimento de SLA, taxa de adopção do self-service, CSAT médio, percentagem de pedidos automatizados e custo por pedido. Estas métricas, analisadas em conjunto, fornecem uma visão completa da eficiência e da qualidade da prática.
Perguntas frequentes
Um incidente é uma interrupção não planeada de um serviço ou uma redução da sua qualidade. Um service request é um pedido planeado, pré-definido e esperado, como um reset de password ou acesso a uma aplicação. Os incidentes requerem resposta urgente para restaurar o serviço; os service requests seguem um fluxo normalizado de aprovação e fulfillment sem a mesma pressão de tempo.
Podem ser automatizados o reset de passwords (sem intervenção humana), o provisionamento de contas em sistemas, a atribuição de licenças de software, a criação de caixas de correio e a notificação ao utilizador sobre o estado do pedido. Portais self-service e chatbots permitem ainda que o utilizador submeta e acompanhe pedidos sem contactar o service desk, reduzindo a carga operacional e melhorando a satisfação.
Os SLAs para service requests devem ser definidos por tipo de pedido, não de forma genérica. Um reset de password pode ter um SLA de 15 minutos se for automatizado, enquanto o provisionamento de um novo equipamento pode ter um SLA de 5 dias úteis. Os SLAs devem reflectir o impacto no negócio, a complexidade do fulfillment e as expectativas do utilizador, e devem ser publicados no catálogo de serviços.
As aprovações devem ser limitadas aos pedidos que envolvem custos significativos, acessos privilegiados ou implicações de segurança ou compliance. Pedidos rotineiros de baixo risco, como resets de password ou software standard, não devem requerer aprovação manual. A regra geral é: se a aprovação não acrescenta valor, elimina-se. Demasiadas aprovações atrasam o fulfillment e frustram os utilizadores.
A adopção do self-service aumenta quando o portal é simples, rápido e resolve o pedido mais depressa do que o telefone ou o e-mail. Factores críticos: formulários curtos e intuitivos, categorias claras no catálogo de serviços, feedback imediato sobre o estado do pedido, e fulfillment mais rápido pelo portal do que pelos canais tradicionais. A comunicação interna sobre os benefícios e um tutorial inicial também ajudam.
As principais métricas são: volume de pedidos por tipo e canal, tempo médio de fulfillment por tipo de pedido, taxa de cumprimento de SLA, CSAT (Customer Satisfaction Score) pós-resolução, taxa de adopção do self-service, percentagem de pedidos resolvidos sem escalada e custo por pedido. O CSAT é particularmente importante porque a satisfação com a gestão de pedidos influencia directamente a percepção global do departamento de TI.
Quer optimizar os seus pedidos de serviço?
Aprenda a implementar a gestão de pedidos de serviço e todas as práticas ITIL 4 com formação certificada.
Ver formação ITIL