ITSM · Service Desk · Ticketing · ITIL · GLPI · osTicket · Documentação · SLA

Duarte Spínola · 26 de Junho de 2026

Registar e Documentar Tickets: Por Que o Registo Correcto Resolve Mais Rápido

Em qualquer PME com mais de 20 utilizadores, o service desk é o ponto de contacto entre o IT e o negócio. Mas o valor de uma ferramenta de ticketing — seja GLPI, osTicket ou Jira Service Management — não está na ferramenta em si, está na qualidade do registo. Um ticket com a descrição “não funciona a net” obriga o técnico de 2ª linha a recomeçar o diagnóstico do zero; um ticket bem registado permite resolver em minutos. Este guia explica como documentar incidentes e pedidos correctamente seguindo as práticas do framework ITIL 4 e as recomendações de ITSM da Atlassian: campos obrigatórios, categorização, prioridades, escalamento e como transformar tickets numa base de conhecimento reutilizável. Embora não seja um artigo de firewall ou networking como os outros da série, a qualidade do registo é transversal — um administrador de sistemas que domina o DrayTek (DrayTek Vigor: Configuração Completa do Router) ou o FortiGate (FortiGate: Firewall Policies, NAT e VPN IPsec) mas não documenta os tickets perde metade do valor do seu trabalho.

Neste artigo

• 1. Por Que o Registo Importa
• 2. Campos Obrigatórios num Ticket
• 3. Categorização e Subcategorização
• 4. Prioridade: Impacto × Urgência
• 5. Descrição do Problema: O Que Escrever
• 6. Registar Passos de Resolução
• 7. Escalamento: Quando e Como
• 8. Erros Comuns no Registo
• 9. Do Ticket à Base de Conhecimento
• 10. Ferramentas de Ticketing
• 11. Métricas que Dependem do Registo
• 12. Checklist de Qualidade do Ticket

1. Por Que o Registo Importa

Um ticket mal registado custa tempo a toda a equipa. Quando o técnico de 2ª linha recebe um ticket com a descrição “não funciona a net”, precisa de começar do zero: perguntar que máquina, que rede, que erro, desde quando. Se o ticket tivesse sido registado correctamente — “utilizador João Silva, sala 2, não consegue aceder a internet desde 09:15, IP 192.168.1.45, ping para gateway falha, erro no browser ERR_NAME_NOT_RESOLVED” — o diagnóstico seria imediato.

O registo correcto de tickets não é burocracia — é a base de três processos fundamentais do ITIL 4:

• Gestão de Incidentes: restaurar serviço o mais rápido possível
• Gestão de Problemas: identificar causa raiz de incidentes recorrentes
• Gestão de Conhecimento: transformar resoluções em artigos reutilizáveis

Quando os tickets são bem documentados, a equipa de suporte consegue identificar padrões (“já tivemos 5 tickets de impressora HP na sala 3 este mês”), proactively resolver problemas antes que escalonem e reduzir o tempo médio de resolução (MTTR — Mean Time to Resolution).

ℹ️ Nota: Segundo o framework ITSM da Atlassian, um incidente deve ter sempre um identificador único, categoria, prioridade e estado. Sem estes campos, não é possível reportar métricas de SLA nem identificar tendências.

2. Campos Obrigatórios num Ticket

Independentemente da ferramenta (GLPI, osTicket, Jira Service Management, Freshservice), estes campos devem ser sempre preenchidos:

⚠️ Atenção: Nunca fechar um ticket sem preencher a resolução. Um ticket “Resolvido” sem descrição da solução é inútil para a base de conhecimento e para auditorias. Se a resolução foi “reiniciar serviço X”, registar esse passo — não assumir que é óbvio.

3. Categorização e Subcategorização

A categorização é o que permite extrair relatórios úteis da ferramenta de ticketing. Sem categorias consistentes, os relatórios mostram “120 tickets este mês” sem indicar se são problemas de rede, software, hardware ou pedidos de acesso.

Estrutura recomendada para PME

ℹ️ Nota: Definir as categorias antes de começar a usar a ferramenta. Mudar categorias a meio do ano invalida os relatórios históricos. Revisitar a lista anualmente, não mais frequentemente.

4. Prioridade: Impacto × Urgência

A prioridade não é um palpite — é o produto de dois factores:

Definições

• Impacto: quantas pessoas/serviços são afectados
• Alto: empresa inteira ou serviço crítico (email, ERP, internet)
• Médio: um departamento ou serviço importante (impressora partilhada, pasta de rede)
• Baixo: um utilizador individual

• Urgência: quão rápido precisa de ser resolvido
• Crítica: serviço interrompido, produção parada
• Alta: trabalho seriamente afectado, sem workaround
• Média: trabalho afectado mas existe workaround
• Baixa: inconveniente, não impede trabalho

Matriz de SLA recomendada para PME

⚠️ Atenção: Prioridade Crítica deve ser usada com moderação. Se tudo é crítico, nada é crítico. O objectivo é que 5-10% dos tickets sejam críticos, 20-30% altos, e a maioria médios/baixos. Se 80% dos tickets são “críticos”, a prioridade perde significado.

5. Descrição do Problema: O Que Escrever

A descrição é a parte mais importante do ticket. Deve permitir que qualquer técnico da equipa entenda o problema sem precisar de falar com o requerente.

Estrutura de uma boa descrição

O que NÃO escrever

ℹ️ Nota: Usar a técnica 5W1H na descrição: Who (quem), What (o quê), When (desde quando), Where (onde), Why (contexto), How (como se manifesta). Se a descrição responde a estas 6 perguntas, está completa.

6. Registar Passos de Resolução

A resolução deve ser registada como uma sequência de passos, não como um parágrafo vago. Isto serve dois propósitos:

1. Auditoria: qualquer pessoa pode ver o que foi feito e quando
2. Base de conhecimento: os passos podem ser convertidos num artigo reutilizável

Exemplo de registo correcto

Exemplo de registo incorrecto

O segundo exemplo não diz o que foi diagnosticado, que passos foram tentados, nem porque é que o problema ocorreu. Se o mesmo problema acontecer noutra impressora, a equipa não tem histórico para consultar.

⚠️ Atenção: Mesmo quando a resolução é simples (“reiniciar serviço X”), registar o que levou a essa conclusão. “Reiniciado serviço Spooler porque fila tinha 47 documentos presos após crash do driver HP” é útil. “Reiniciado spooler” não é.

7. Escalamento: Quando e Como

O escalamento não é uma admissão de falha — é um processo estruturado para garantir que o ticket chega à pessoa certa.

Níveis de suporte

O que escrever ao escalar

Ao escalar um ticket, incluir:

1. Resumo do problema (1-2 frases)
2. O que já foi testado (para não repetir trabalho)
3. Resultados dos testes (logs, screenshots, outputs)
4. Impacto actual (quanto é que está parado)
5. Urgência (prazo para resolução)

8. Erros Comuns no Registo

9. Do Ticket à Base de Conhecimento

Cada ticket resolvido é um candidato a artigo na base de conhecimento. O processo é simples:

1. Identificar tickets recorrentes: se o mesmo problema aparece 3+ vezes, criar artigo
2. Generalizar a solução: remover detalhes específicos (IPs, nomes de utilizadores)
3. Escrever em formato passo-a-passo: alguém sem conhecimento do caso específico deve conseguir seguir
4. Publicar na base de conhecimento: GLPI, Confluence, ou sistema integrado
5. Referenciar no próximo ticket: quando o problema aparece novamente, linkar o artigo

Exemplo de transformação

Ticket original (específico):

Artigo na base de conhecimento (generalizado):

ℹ️ Nota: Segundo as práticas de Gestão de Conhecimento ITSM, a base de conhecimento deve ser o primeiro lugar onde um técnico procura antes de abrir um ticket. Se a solução já está documentada, o ticket pode ser resolvido em 1ª linha em minutos.

10. Ferramentas de Ticketing

⚠️ Atenção: A ferramenta não resolve o problema do registo — o processo sim. Uma ferramenta gratuita como o GLPI com bons processos de registo é mais valiosa do que o Jira Service Management sem processo definido. Começar pelo processo, depois escolher a ferramenta que melhor o suporta.

11. Métricas que Dependem do Registo

As métricas de service desk só são fiáveis se os tickets estiverem bem registados:

Se os tickets não têm categoria, não é possível calcular “top categorias”. Se a prioridade está errada, o SLA compliance não significa nada. Se o estado não é actualizado, o backlog é fictício.

12. Checklist de Qualidade do Ticket

Antes de fechar um ticket, confirmar:

• [ ] Título é específico e pesquisável (sistema + sintoma + localização)
• [ ] Categoria e subcategoria preenchidas
• [ ] Prioridade foi definida com matriz Impacto × Urgência
• [ ] Descrição responde às 6 perguntas (5W1H)
• [ ] Cada passo de diagnóstico tem timestamp
• [ ] Acções testadas estão documentadas com resultados
• [ ] Resolução final está descrita passo-a-passo
• [ ] Screenshots de erros estão anexados
• [ ] Requerente foi notificado da resolução
• [ ] Requerente confirmou que o problema está resolvido
• [ ] Se problema recorrente (3+ tickets), artigo na base de conhecimento criado
• [ ] Se escalado, informações de escalamento completas (resumo + testes + impacto)

Artigos Relacionados

• DrayTek Vigor: Configuração de Router e Firewall
• FortiGate: Firewall, NAT e VPN IPsec
• Palo Alto Firewall: Configuração 2026
• Sophos Firewall: Configuração de Firewall, NAT e VPN
• DrayTek Vigor: Diagnóstico Técnico Avançado