Gestão de pedidos de serviço
Processo end-to-end com workflow, actividades, RACI e métricas
Descarregar pack completoÂmbito e objectivos
Garantir o tratamento eficiente e padronizado de todos os pedidos de serviço, mantendo a satisfação do utilizador e a qualidade do serviço prestado pela organização de TI.
Utilizador submete um pedido de serviço através do portal de auto-serviço, por telefone ou por email ao service desk.
Desde a submissão do pedido até ao fulfillment e encerramento. Inclui pedidos com e sem aprovação prévia, bem como pedidos executados de forma automática ou manual.
Interrupções de serviço (gestão de incidentes). Alterações que requerem avaliação de risco e aprovação formal (change enablement).
Pedido realizado conforme solicitado, utilizador informado do resultado, registo encerrado na ferramenta ITSM e questionário de satisfação enviado.
Modelos de fulfillment
A gestão de pedidos de serviço distingue-se da gestão de incidentes por trabalhar com pedidos pré-definidos e, na maioria dos casos, pré-aprovados. O catálogo de serviços define qual o modelo de fulfillment aplicável a cada tipo de pedido.
Automático (self-service)
O pedido é executado automaticamente por scripts ou integração com sistemas. Sem intervenção humana. Tempo de fulfillment inferior a minutos.
Service desk
O service desk executa o pedido directamente, sem necessidade de envolver equipas técnicas especializadas. Adequado para pedidos simples com procedimento documentado.
Equipa técnica
O pedido requer intervenção de uma equipa especializada (infraestrutura, segurança, aplicações). O service desk coordena e acompanha o progresso.
Com aprovação necessária
O pedido requer aprovação de gestor ou aprovador designado antes de iniciar o fulfillment. A aprovação pode ser manual ou automatizada por workflow.
Diagrama do processo
Diagrama BPMN simplificado do processo de gestão de pedidos de serviço (3 swimlanes). Percorra horizontalmente em dispositivos móveis.
Actividades macro
| # | Actividade | Responsável | Input | Output |
|---|---|---|---|---|
| 1 | Submissão do pedido | Utilizador | Necessidade de serviço | Pedido submetido (portal, telefone, email) |
| 2 | Validação e categorização | Service desk | Pedido submetido | Pedido categorizado, modelo de fulfillment identificado |
| 3 | Aprovação (se necessária) | Gestor / Aprovador designado | Pedido categorizado | Pedido aprovado ou rejeitado |
| 4 | Atribuição ao fulfillment team | Service desk | Pedido aprovado | Pedido atribuído à equipa ou processo automático |
| 5 | Fulfillment | Fulfillment team / Automação | Pedido atribuído | Serviço prestado ou recurso disponibilizado |
| 6 | Verificação com o utilizador | Service desk | Fulfillment concluído | Confirmação do utilizador |
| 7 | Encerramento | Service desk | Confirmação positiva | Pedido encerrado, questionário de satisfação enviado |
| 8 | Monitorização e melhoria | Service desk manager | Dados de pedidos | Relatório de tendências, propostas de automação |
Descrição detalhada das actividades
O processo inicia quando um utilizador identifica uma necessidade de serviço pré-definida no catálogo. O canal preferencial é o portal de auto-serviço, que apresenta os serviços disponíveis, os respectivos SLAs e os campos necessários para submissão. Canais alternativos como telefone ou email ao service desk são também aceites, embora com maior esforço de registo manual.
Passos chave
- Aceder ao portal de auto-serviço e localizar o serviço no catálogo
- Preencher os campos obrigatórios do formulário de pedido
- Indicar justificação de negócio quando exigida pelo catálogo
- Confirmar a submissão e anotar o número de referência do pedido
O service desk verifica se o pedido corresponde a um item do catálogo de serviços e se a informação submetida é suficiente para iniciar o fulfillment. Nesta fase identifica-se o modelo de fulfillment adequado, o SLA aplicável e se é necessária aprovação prévia.
Passos chave
- Confirmar que o serviço solicitado existe no catálogo de serviços
- Verificar que o utilizador tem direito ao serviço (elegibilidade)
- Identificar o modelo de fulfillment: automático, service desk, equipa técnica ou com aprovação
- Atribuir categoria e subcategoria ao pedido na ferramenta ITSM
- Solicitar informação adicional ao utilizador se necessário
Quando o catálogo define que um serviço requer aprovação prévia, o pedido é encaminhado ao aprovador designado antes de avançar para fulfillment. O aprovador pode ser o gestor directo do utilizador, um responsável de área ou um aprovador técnico. A aprovação deve ocorrer dentro do prazo definido no catálogo para não impactar o SLA total do pedido.
Passos chave
- Enviar notificação automática ao aprovador com detalhes do pedido
- O aprovador analisa a justificação e verifica conformidade com políticas
- Aprovação ou rejeição registada na ferramenta ITSM com motivo
- Utilizador notificado do resultado da aprovação
- Em caso de rejeição, pedido encerrado com estado "rejeitado" e motivo documentado
Após validação (e aprovação quando necessária), o pedido é atribuído à equipa ou processo responsável pelo fulfillment. Para pedidos automáticos, esta atribuição é feita por integração com ferramentas de automação. Para pedidos manuais, a atribuição pode ser automática com base na categoria ou manual pelo service desk.
Passos chave
- Verificar a disponibilidade do fulfillment team (carga de trabalho)
- Atribuir o pedido com base na categoria e nas regras de routing definidas
- Para pedidos automáticos, acionar o script ou workflow de automação
- Notificar a equipa receptora com os detalhes e prazo do pedido
- Actualizar o estado do pedido para "em execução"
A execução do pedido segue o procedimento de fulfillment documentado no catálogo de serviços. Cada tipo de pedido tem um modelo de fulfillment próprio com passos sequenciais, verificações e critérios de conclusão. A equipa de fulfillment actualiza o ticket ao longo da execução, garantindo rastreabilidade.
Passos chave
- Consultar o modelo de fulfillment documentado para o tipo de pedido
- Executar cada passo do procedimento pela ordem definida
- Registar a execução de cada passo no ticket
- Verificar o resultado de cada passo antes de avançar
- Documentar qualquer desvio ao procedimento standard
- Atualizar o ticket com estado "fulfillment concluído" ao terminar
Após o fulfillment, o service desk informa o utilizador que o serviço foi prestado e solicita confirmação. Para pedidos simples, a verificação pode ser feita por notificação automática; para pedidos mais complexos, é preferível contacto directo. O utilizador deve confirmar que o serviço está acessível e corresponde ao solicitado.
Passos chave
- Notificar o utilizador que o fulfillment foi concluído
- Fornecer instruções de acesso ou utilização se necessário
- Solicitar confirmação explícita ou definir prazo para resposta
- Se o utilizador reportar problema, reabrir o pedido e escalar para fulfillment team
O pedido é formalmente encerrado após confirmação positiva do utilizador. O registo é actualizado com a cronologia completa, os passos de fulfillment executados e o tempo total de processamento. Um questionário de satisfação é enviado para recolha de feedback sobre a qualidade do serviço prestado.
Passos chave
- Actualizar o ticket com data e hora de encerramento
- Registar o tempo total de fulfillment para cálculo de métricas
- Enviar questionário de satisfação ao utilizador
- Actualizar o CMDB se o pedido envolveu provisionamento de activos ou CIs
- Identificar oportunidades de automação com base no tipo de pedido
O service desk manager analisa periodicamente os dados de pedidos para identificar tendências, padrões de volume por categoria e oportunidades de automação. Pedidos repetitivos com alto volume são candidatos prioritários para automação no portal de auto-serviço, reduzindo esforço manual e melhorando o tempo de fulfillment.
Passos chave
- Compilar relatório de pedidos por categoria, volume e tempo de fulfillment
- Identificar os tipos de pedido com maior frequência e maior tempo de resolução
- Propor novos serviços para automação ou self-service
- Rever e actualizar os modelos de fulfillment existentes
- Partilhar resultados com stakeholders em reunião de revisão mensal
Modelo RACI
| Actividade | Utilizador (UT) |
Service desk (SD) |
Fulfillment team (FT) |
Aprovador (AP) |
SD Manager (SM) |
|---|---|---|---|---|---|
| Submissão do pedido | R | I | - | - | A |
| Validação e categorização | I | R | - | - | A |
| Aprovação | I | I | - | R | A |
| Atribuição ao fulfillment team | - | R | I | - | A |
| Fulfillment | - | C | R | - | A |
| Verificação com o utilizador | R | R | - | - | A |
| Encerramento | I | R | - | - | A |
| Monitorização e melhoria | - | R | - | - | A |
Métricas e KPIs
| Métrica | Descrição | Target sugerido |
|---|---|---|
| Tempo médio de fulfillment | Tempo médio desde a submissão do pedido até à conclusão do fulfillment | < 24h (standard) < 4h (urgente) |
| Taxa de automação | Percentagem de pedidos executados automaticamente sem intervenção humana | > 40% |
| Satisfação do utilizador | Classificação média dada pelo utilizador no questionário pós-fulfillment | > 4,2 / 5,0 |
| Pedidos por categoria | Distribuição do volume de pedidos por tipo, para identificação de tendências e priorização de automação | Análise de tendências |
| Taxa de rejeição | Percentagem de pedidos rejeitados na fase de aprovação | < 10% |
| Pedidos reabertos | Percentagem de pedidos reabertos após encerramento por insatisfação do utilizador | < 3% |
| Cumprimento de SLA | Percentagem de pedidos concluídos dentro do tempo de fulfillment acordado em SLA | > 95% |
Interfaces com outros processos
Gestão de incidentes
Quando a execução de um pedido revela uma interrupção de serviço subjacente, é criado um incidente para tratamento separado.
Change enablement
Pedidos complexos que impliquem alterações ao ambiente de produção são encaminhados para o processo de change enablement.
Catálogo de serviços
Define os serviços disponíveis para pedido, os SLAs associados, o modelo de fulfillment e se é necessária aprovação prévia.
Gestão do conhecimento
Artigos de auto-serviço e FAQs na base de conhecimento reduzem o volume de pedidos ao service desk, aumentando a taxa de self-service.
CMDB
Utilizada para identificar recursos e CIs associados ao pedido, como utilizadores, dispositivos, licenças e direitos de acesso.
Descarregar o pack completo
Inclui o processo documentado, formulário de pedido, catálogo de serviços, modelo RACI em Excel, métricas e modelo de fulfillment.