Função ITSM Alinhado com ITIL

Service desk

Ponto único de contacto (SPOC) entre os serviços de TI e os utilizadores: workflow, canais, modelos operacionais, RACI e métricas

Descarregar pack completo

Âmbito e objectivos

O service desk não é um processo, mas uma função (ou prática, na linguagem ITIL 4) que actua como ponto único de contacto entre os serviços de TI e os utilizadores. Gere simultaneamente incidentes, pedidos de serviço, esclarecimentos e reclamações, garantindo que cada contacto é registado, triado e tratado ou encaminhado de forma adequada.

Objectivo

Ser o ponto único de contacto entre os serviços de TI e os utilizadores, garantindo que todas as solicitações são registadas, triadas e encaminhadas adequadamente, com comunicação proactiva em todo o ciclo de vida.

Trigger

Qualquer contacto de um utilizador com os serviços de TI: incidente, pedido de serviço, dúvida, reclamação ou alerta de monitorização automática.

Âmbito

Desde a recepção do contacto até ao encaminhamento, resolução L1 ou encerramento. Inclui todos os canais de contacto disponibilizados pela organização.

Fora do âmbito

Investigação aprofundada de causa raiz (gestão de problemas). Resolução técnica L2/L3 (equipas especializadas). Aprovação formal de mudanças.

Output

Contacto registado, triado e resolvido ou encaminhado. Utilizador informado do estado e prazo esperado. Dados operacionais disponíveis para reporting e melhoria contínua.

Canais de contacto

Um service desk moderno opera em modo omnichannel: o utilizador escolhe o canal mais conveniente e a experiência mantém-se consistente. Cada canal tem vantagens e limitações que devem ser ponderadas na estratégia de atendimento.

💻
Portal self-service
Pro Disponível 24/7, registo estruturado, menor custo por contacto, promove autonomia do utilizador
Con Requer adopção activa, menos adequado para situações urgentes ou utilizadores menos digitais
📞
Telefone
Pro Contacto imediato, adequado para situações críticas, permite recolha rápida de contexto
Con Custo mais elevado, filas de espera em picos, registo manual mais propenso a erros
💌
Email
Pro Rastreabilidade natural, permite anexar evidências, familiar para todos os utilizadores
Con Tempo de resposta mais lento, sem estrutura definida, difícil de priorizar automaticamente
💬
Chat
Pro Resposta rápida, um agente pode gerir múltiplos chats em simultâneo, registo automático
Con Requer cobertura em tempo real, qualidade depende da capacidade de escrita do utilizador
👤
Walk-in
Pro Contacto presencial, adequado para problemas de hardware ou situações que exigem intervenção física
Con Requer presença física, não escalável, pouco adequado para organizações distribuídas
🔌
Monitorização automática
Pro Detecção proactiva, reduz tempo de resposta, cria tickets antes do impacto no utilizador
Con Pode gerar ruído (falsos positivos), requer afinação contínua das regras de alerta

Modelos de service desk

A escolha do modelo operacional depende da dimensão da organização, distribuição geográfica, requisitos de cobertura horária e maturidade da função TI.

Modelo Descrição Adequado para Considerações
Local Equipa de suporte fisicamente no mesmo local que os utilizadores servidos. Organizações pequenas, locais únicos, sectores com forte componente presencial (manufacturing, saúde). Elevado conhecimento do contexto local; difícil de escalar; duplicação de recursos em múltiplos sites.
Centralizado Equipa única que presta suporte a toda a organização, independentemente da localização dos utilizadores. Organizações médias e grandes com múltiplos sites; permite uniformidade de processos e métricas. Economias de escala; pode perder contexto local; exige boa cobertura de canais remotos.
Virtual Equipa distribuída geograficamente mas com ferramenta ITSM unificada, criando a ilusão de um service desk único. Organizações com equipas remotas ou híbridas; permite flexibilidade de recrutamento. Requer forte disciplina de processo e ferramenta centralizada; gestão de equipa distribuída mais exigente.
Follow-the-sun Equipas em fusos horários diferentes que cobrem o atendimento sequencialmente para garantir cobertura 24/7. Multinacionais, organizações com SLAs de suporte contínuo, serviços críticos globais. Exige processos de handover rigorosos, linguagem comum e ferramentas partilhadas; custo operacional elevado.

Diagrama do processo

Diagrama BPMN simplificado do processo de service desk (2 swimlanes). Percorra horizontalmente em dispositivos móveis.

Actividades macro

# Actividade Responsável Input Output
1 Recepção do contacto Service desk Contacto via qualquer canal Contacto recebido e identificado
2 Identificação e registo Service desk Contacto recebido Registo criado (incidente / pedido / dúvida / reclamação)
3 Triagem e classificação Service desk Registo criado Tipo, categoria e prioridade atribuídos
4 Resolução L1 Service desk Registo classificado, base de conhecimento Resolução aplicada ou decisão de escalação documentada
5 Escalação Service desk Contacto não resolvido em L1 Contacto atribuído a equipa L2/L3 ou processo adequado
6 Acompanhamento e comunicação Service desk Contacto escalado ou em curso Utilizador informado periodicamente do estado
7 Encerramento Service desk / Utilizador Resolução confirmada Registo encerrado, satisfação recolhida
8 Reporting e melhoria SD manager Dados operacionais Relatórios de actividade, propostas de melhoria

Descrição detalhada das actividades

O service desk recebe o contacto independentemente do canal utilizado pelo utilizador: portal, telefone, email, chat, walk-in ou alerta de monitorização. A estratégia omnichannel garante que a experiência é consistente e que nenhum contacto se perde sem registo formal.

Passos chave

  • Atender ou receber o contacto dentro dos tempos de resposta acordados (SLA)
  • Identificar o utilizador e verificar os seus dados no sistema
  • Determinar o canal de origem para contexto de triagem
  • Para contactos por monitorização: validar que o alerta não é um falso positivo
Critério de saída: utilizador identificado e contacto recebido; processo de registo iniciado.

Todo o contacto deve ser registado na ferramenta ITSM com informação suficiente para suportar a triagem e o tratamento posterior. O registo é o ponto de partida de toda a rastreabilidade do contacto.

Passos chave

  • Criar registo com referência única, data/hora e canal de origem
  • Registar a descrição do contacto com as palavras do utilizador
  • Associar o utilizador e, quando possível, o CI (activo de configuração) afectado
  • Classificar o tipo de contacto: incidente, pedido de serviço, dúvida ou reclamação
  • Notificar o utilizador do número de registo e tempo de resposta esperado
Critério de saída: registo criado na ferramenta ITSM com tipo, utilizador e descrição; utilizador notificado com número de ticket.

A triagem determina o encaminhamento correcto do contacto: resolução imediata em L1, encaminhamento para gestão de incidentes, gestão de pedidos, ou outro processo. A classificação correcta é determinante para que o SLA certo seja aplicado e os recursos adequados mobilizados.

Passos chave

  • Confirmar e refinar a classificação do tipo de contacto
  • Atribuir categoria (serviço afectado, componente, tipo de problema)
  • Determinar prioridade com base em impacto e urgência
  • Verificar se existe incidente activo relacionado (major incident)
  • Encaminhar para o fluxo adequado: incidente, pedido, FAQ, reclamação
Critério de saída: tipo, categoria e prioridade definidos; contacto encaminhado para o fluxo correcto.

O service desk tenta resolver o contacto no primeiro nível, utilizando a base de conhecimento, scripts de diagnóstico e acesso remoto. O objectivo é atingir uma taxa de resolução L1 acima de 70%, reduzindo o volume de escalações e o tempo de resolução global.

Passos chave

  • Pesquisar artigos relevantes na base de conhecimento
  • Aplicar script de diagnóstico ou resolução documentada
  • Utilizar acesso remoto quando necessário e autorizado
  • Documentar todos os passos executados no registo
  • Se resolvido: informar o utilizador e preparar encerramento
  • Se não resolvido: documentar diagnóstico e decidir escalação
Critério de saída: resolução aplicada com sucesso (avança para encerramento) ou decisão de escalação documentada (avança para escalação).

Quando a resolução L1 não é possível, o service desk escala o contacto para a equipa técnica adequada ou activa o processo correspondente (gestão de incidentes L2/L3, gestão de pedidos especiais). A escalação deve ser feita com toda a informação de diagnóstico registada para evitar repetição de perguntas ao utilizador.

Passos chave

  • Seleccionar equipa ou especialista com base na categoria e tipo de contacto
  • Actualizar o registo com toda a informação de diagnóstico disponível
  • Notificar a equipa receptora com contexto completo e urgência
  • Informar o utilizador da escalação, nova equipa responsável e prazo estimado
  • Manter o registo em acompanhamento pelo service desk (ownership)
Critério de saída: contacto atribuído à equipa correcta com informação completa; utilizador informado da escalação.

O service desk mantém o ownership do contacto após escalação, garantindo que o utilizador é mantido informado do progresso. A comunicação proactiva é um dos principais factores de satisfação do utilizador, independentemente do tempo de resolução.

Passos chave

  • Monitorizar o progresso dos contactos escalados
  • Comunicar actualizações ao utilizador nos intervalos definidos pelo SLA
  • Alertar o incident/request manager se os prazos estiverem em risco
  • Registar todas as actualizações no histórico do ticket
Critério de saída: utilizador informado com a frequência acordada; histórico de comunicações registado no ticket.

O contacto é encerrado após confirmação da resolução pelo utilizador ou decorrido o período de confirmação automática. O encerramento inclui a recolha de feedback de satisfação e, quando relevante, a criação ou actualização de artigo na base de conhecimento.

Passos chave

  • Contactar o utilizador para confirmar que o assunto está resolvido
  • Actualizar o registo com causa e solução final
  • Enviar inquérito de satisfação (CSAT)
  • Criar ou actualizar artigo na base de conhecimento se a solução for reutilizável
  • Encerrar o ticket formalmente
Critério de saída: ticket encerrado com estado "resolvido"; satisfação recolhida; base de conhecimento actualizada quando aplicável.

O SD manager analisa os dados operacionais semanalmente e mensalmente para identificar tendências, problemas sistémicos e oportunidades de melhoria. O reporting alimenta as decisões de formação, dimensionamento de equipa e investimento em self-service.

Passos chave

  • Compilar métricas operacionais: volume, FCR, tempo médio, satisfação
  • Identificar categorias de contacto com maior volume e tendência crescente
  • Propor artigos de conhecimento para os contactos mais frequentes
  • Reportar ao IT management e aos process owners relevantes
  • Definir acções de melhoria e monitorizar os seus resultados
Critério de saída: relatório de actividade distribuído; acções de melhoria identificadas e comunicadas.

Modelo RACI

Actividade Utilizador
(UT)
Service desk
(SD)
Equipa L2/L3
(L2)
SD manager
(SDM)
Knowledge mgr
(KM)
Recepção do contacto R A - I -
Identificação e registo I R - A -
Triagem e classificação - R C A -
Resolução L1 C R C A C
Escalação I R I A -
Acompanhamento e comunicação I R C A -
Encerramento C R - A I
Reporting e melhoria - C I R A
R Responsible - executa a actividade A Accountable - responde pelo resultado C Consulted - é consultado I Informed - é informado

Métricas e KPIs

Métrica Descrição Target sugerido
First contact resolution (FCR) Percentagem de contactos resolvidos no primeiro contacto, sem escalação > 70%
Tempo médio de atendimento Tempo desde a chegada do contacto até ao agente atender (telefone/chat) < 30 seg (tel.) < 2 min (chat)
Taxa de abandono Percentagem de utilizadores que desistiram antes de ser atendidos < 5%
Satisfação do utilizador Classificação média dada pelo utilizador no inquérito pós-contacto (CSAT) > 4,2 / 5,0
Tickets por agente por dia Volume médio de contactos tratados por agente em dia normal de operação 15-25 (referência)
Taxa de escalação Percentagem de contactos que não foram resolvidos em L1 e foram escalados < 30%
Tempo médio de resolução L1 Tempo médio desde o registo até à resolução para contactos tratados em L1 < 30 minutos
Utilização do portal self-service Percentagem de contactos que chegam via portal em vez de canais assistidos > 40%

Interfaces com outros processos

Saida

Gestão de incidentes

O service desk cria e encaminha incidentes para as equipas L2/L3, mantendo o ownership e comunicando com o utilizador.

Saida

Gestão de pedidos de serviço

Pedidos de acesso, aprovisionamento e outros pedidos standard são criados pelo service desk e encaminhados para cumprimento.

Saida

Gestão de problemas

O service desk reporta tendências de incidentes recorrentes para análise de causa raiz pela gestão de problemas.

Entrada

Gestão do conhecimento

O service desk consulta artigos da base de conhecimento para suportar a resolução L1 e manter a qualidade e consistência do atendimento.

Entrada

CMDB

O service desk consulta a CMDB para identificar CIs afectados, utilizadores associados e relações de dependência entre serviços.

Saida

Change enablement

O service desk reporta mudanças falhadas que originaram incidentes, contribuindo para a análise pós-implementação.

Descarregar o pack completo

Inclui manual do processo, scripts de atendimento, RACI, métricas KPI, checklist de qualidade, plano de formação e relatório de actividade.