Uniformizar tickets no GLPI sem depender da disciplina de quem os abre

Categoria ITIL que já define prioridade, SLA, grupo e técnico; e obrigatoriedades validadas no servidor para o ticket não fechar a meio. O módulo Regras de Ticket resolve os dois lados por configuração.

A uniformização não se pede, configura-se. Todo o service desk tenta uniformizar o atendimento com formação e boa vontade — e todo o service desk descobre que, em volume, isso não se sustenta.

O problema

Uniformizar tickets no GLPI costuma custar de dois lados. Na entrada, prioridade, SLA, grupo e técnico dependem de quem abriu escolher bem — e cada pessoa escolhe à sua maneira. Na saída, o ticket fecha com uma resolução de três palavras, sem localização preenchida e sem responsável claro.

A alternativa habitual é montar uma teia de regras de negócio no GLPI. Funciona no início e torna-se dívida técnica depois: dezenas de regras com ordens de execução interdependentes que ninguém se atreve a mexer.

Como funcionam as Regras de Ticket

O módulo ataca os dois lados com configuração declarativa, em vez de regras encadeadas.

  • Categorização automática por categoria ITIL — cada categoria transporta prioridade, SLA, grupo, técnicos e observadores. Escolher a categoria certa preenche o resto.
  • Obrigatoriedades ao resolver ou fechar — validação no servidor, não apenas no formulário: não dá para contornar pela API nem por um campo escondido.
  • Mínimo de caracteres — em seguimentos, tarefas e resoluções — acabou o "ok" como registo de resolução.
  • Um técnico ou grupo por ticket — evita a atribuição acumulada, em que meia equipa é formalmente responsável e ninguém o é de facto.
  • Regras à la carte — cada obrigatoriedade é um interruptor independente: ative apenas o que faz sentido na sua operação.

Como ativar

  1. Instale o NexTool no seu GLPI 11.
  2. Aceda a NexTool > Módulos e ative as Regras de Ticket.
  3. Em Parâmetros por categoria, defina prioridade, SLA, grupo e técnicos de cada categoria ITIL.
  4. Em Regras de atendimento, ligue as obrigatoriedades pretendidas e o mínimo de caracteres.

A quem se destina

Operações que precisam de indicadores fiáveis — e descobriram que o indicador só é fiável se o dado de entrada também for. Também para quem tem auditoria ou contrato a exigir registo mínimo por atendimento e hoje depende de revisão manual para o garantir.

Uma ressalva honesta: a obrigatoriedade gera atrito com a equipa. Comece pelas duas ou três que resolvem a sua dor real, não por todas de uma vez.

Compatibilidade

  • GLPI: 11.0+
  • Plano: Licenciado
  • Plugin: NexTool 6.x+

Próximo passo

As Regras de Ticket fazem parte do NexTool, ecossistema de módulos que expande o GLPI sem personalização de código. Conheça a página do módulo ou marque uma conversa para o ver a funcionar no seu ambiente.


Revisto pela equipa NexTool Solutions.

Perguntas Frequentes

Por categoria ITIL, o módulo pode definir tipo, urgência, impacto, prioridade, SLA de atendimento e resolução, localização, técnicos, grupos, observadores, ativos e modelos. A prioridade também pode ficar para recálculo pelo GLPI.

Cada categoria pode aplicar os seus parâmetros na abertura do pedido, na mudança de categoria ou nos dois momentos. Na criação, também pode escolher se a categorização é executada antes ou depois das regras de negócio; na mudança de categoria é executada antes devido aos pontos de extensão disponíveis no GLPI.

A validação é feita no servidor, pelo que uma integração por API não ignora as regras aplicáveis. Para proteger a experiência do requerente, as regras de campos e categoria obrigatórios nunca bloqueiam a interface simplificada; a categorização automática por categoria continua a funcionar nela.

Não. A funcionalidade de categorização começa ativa, mas cada categoria tem de ser configurada e ativada separadamente. As regras de atendimento também são independentes, permitindo começar apenas pelas validações necessárias.

Sim, mas devem evitar-se funcionalidades sobrepostas. Não ative também técnico ou grupo único no Behaviors; a opção do Escalade para remover técnicos ao adicionar um grupo pode alterar o resultado esperado. O Smart Assign substitui atribuições antes de adicionar o técnico e normalmente coexiste com as regras de unicidade.

Precisa de ajuda?