Gestão de chamados no GLPI: help desk, SLA e escalonamento

Toda área de TI vive a mesma pressão: responder rápido, cumprir prazos e provar que o atendimento funciona. A gestão de chamados no GLPI organiza esse esforço em um fluxo único, do registro do ticket até o fechamento com SLA medido.

No entanto, instalar a ferramenta não basta. A diferença entre um help desk reativo e um service desk maduro está em como você estrutura categorias, níveis de serviço e regras de negócio dentro do sistema.

Neste guia prático você vai ver como desenhar o ciclo de vida do chamado, configurar SLA e OLA, automatizar o escalonamento e acompanhar os indicadores que revelam a saúde do atendimento. O foco aqui é o processo: a ferramenta a serviço do ITIL, não o contrário.

O help desk do GLPI: incidente, requisição e estrutura

O GLPI é uma plataforma open source de ITSM que centraliza chamados, ativos e base de conhecimento. Se você ainda avalia a adoção, vale entender primeiro o que é o GLPI antes de mergulhar no módulo de atendimento.

Antes de tudo, o sistema separa dois tipos de demanda. Essa distinção define prazos, fluxos e relatórios, portanto merece atenção logo na modelagem do serviço.

Um incidente é a interrupção ou a queda de qualidade de um serviço, como um e-mail fora do ar. Já uma requisição é um pedido padrão previsto no catálogo, como criar um usuário ou liberar um acesso.

 
Essa separação conversa diretamente com a gestão de incidentes e com a disciplina de atendimento. Para revisar os fundamentos, vale conferir também o que é service desk e onde ele difere do help desk.

Vale destacar que a distinção entre incidente e requisição nasce do framework ITIL, hoje a referência mais usada para gestão de serviços de TI.

Na prática, classificar bem o chamado define todo o resto. Um incidente rotulado por engano como requisição perde a prioridade correta, atrasa a solução e contamina os relatórios de SLA no fim do mês.

Por isso, dedique tempo à árvore de categorias antes de abrir o atendimento ao público. Uma taxonomia enxuta, com poucos níveis e nomes claros, facilita a vida do solicitante e melhora a qualidade dos dados.

Entidades, perfis e portal do usuário

Além da classificação, o GLPI organiza o atendimento em três camadas. As entidades representam áreas, filiais ou clientes distintos, com dados isolados entre si.

Os perfis definem o que cada papel enxerga e executa: um técnico de N1, um supervisor e um solicitante têm telas e permissões diferentes. Dessa forma, cada pessoa acessa apenas o que precisa.

Por fim, o portal do usuário é a porta de entrada do solicitante. Por ali ele abre o chamado, anexa evidências e acompanha o andamento sem depender de telefone ou e-mail informal.

Essa estrutura em camadas é o que permite atender várias empresas ou filiais no mesmo GLPI. Cada entidade enxerga apenas os próprios chamados, enquanto a matriz consolida os números de todas em um relatório único.

O ciclo de vida do chamado no GLPI

Todo chamado percorre etapas previsíveis. Quando você mapeia esse ciclo na ferramenta, o atendimento ganha consistência e os relatórios passam a refletir a operação real.

Os canais de abertura

O solicitante registra a demanda pelo portal, por e-mail ou por um formulário específico. Cada canal alimenta a mesma fila central, o que evita pedidos perdidos em caixas pessoais.

Na prática, padronizar a abertura já melhora a qualidade do atendimento. Quanto mais completo o registro inicial, menos idas e vindas o técnico enfrenta depois.

Além disso, modelos de formulário aceleram o preenchimento. O GLPI permite criar campos obrigatórios por categoria, o que garante informações mínimas como patrimônio afetado, ramal ou print da tela com erro.

Da atribuição ao fechamento

Logo após a abertura, as regras de negócio direcionam o ticket para o técnico ou grupo certo, conforme categoria, entidade ou urgência. Em seguida, o relógio do SLA começa a contar.

Durante o acompanhamento, técnico e solicitante trocam mensagens em notas públicas, enquanto observações internas ficam restritas à equipe. Assim, o histórico completo permanece registrado no próprio chamado.

Entre uma etapa e outra, o chamado assume status claros: novo, em atendimento, pendente, solucionado e fechado. O status pendente, por exemplo, congela o relógio do SLA enquanto a equipe aguarda um retorno do solicitante.

Na etapa final, o técnico descreve a solução, o sistema registra o prazo de resolução e encerra o ticket. Por fim, uma pesquisa de satisfação coleta a percepção de quem abriu o pedido.

Em paralelo, o registro de tempo em cada tarefa alimenta os relatórios de esforço. Esse dado revela quais categorias de chamado consomem mais horas da equipe, o que ajuda no planejamento de capacidade.

SLA e SLT no GLPI: do calendário ao nível de serviço

Aqui mora o coração do atendimento profissional. Para que o SLA funcione no GLPI, você precisa configurar peças que trabalham juntas.

As três peças que fazem o SLA funcionar

Os calendários e feriados definem o horário útil de atendimento. Sem eles, o sistema conta prazo em finais de semana ou de madrugada, o que distorce qualquer métrica.

Os Níveis de Serviço, acessados em Configurar > Níveis de Serviço, guardam o tempo para atender e o tempo para solucionar. São relógios diferentes, com metas próprias.

As regras de negócio para chamados vinculam de forma automática o SLA correto a cada ticket, conforme categoria ou prioridade. Dessa forma, ninguém precisa lembrar de aplicar o acordo na mão.

Essas regras aceitam combinações poderosas de critérios. Você pode, por exemplo, aplicar um SLA mais curto para chamados de um cliente prioritário ou para uma categoria crítica como indisponibilidade de rede.

Pense nessas três peças como engrenagens conectadas. Se uma falha, o cálculo do prazo quebra: um calendário sem horário correto, um nível de serviço sem meta ou uma regra que não dispara deixam o SLA apenas decorativo.

A documentação oficial detalha cada campo dessas telas. Para se aprofundar na configuração, consulte a documentação oficial do projeto antes de levar para produção.

SLA x OLA e o tempo de atender x solucionar

Dois conceitos costumam gerar confusão. O SLA é o acordo entre a central e o cliente, enquanto o OLA é o acordo interno entre as equipes que sustentam aquele serviço.

Da mesma forma, atender e solucionar não são a mesma coisa. O tempo de atender mede a primeira resposta ao usuário, ao passo que o tempo de solucionar mede a entrega definitiva da correção.

Separar esses relógios evita uma armadilha comum. Uma equipe pode responder rápido e, ainda assim, demorar para resolver, então medir apenas a primeira resposta esconde o gargalo real.

O OLA tem um papel silencioso, porém decisivo, nessa cadeia. Quando um time interno descumpre o prazo combinado, o gestor enxerga onde o fluxo emperrou, mesmo que o acordo com o cliente continue dentro da meta.

Escalonamento e regras de negócio

Mesmo com SLA bem definido, alguns chamados travam. O escalonamento garante que eles não fiquem parados quando o prazo aperta ou quando o nível atual não resolve.

Existem dois caminhos. O escalonamento funcional move o chamado para um time mais especializado, enquanto o hierárquico aciona um gestor para decisões que exigem alçada.

No GLPI, você modela isso com níveis de escalação dentro do SLA e com regras que disparam ações por tempo decorrido. Por exemplo, um ticket sem resposta em 30 minutos sobe do N1 para o N2 sem intervenção humana.

Antes de escalar, o sistema calcula a prioridade do chamado pelo cruzamento entre impacto e urgência. Essa matriz define quais tickets furam a fila, o que evita o vício de tratar toda demanda como emergência.

O GLPI ainda dispara notificações automáticas a cada evento relevante. Quando um prazo se aproxima do limite, o sistema avisa técnico e supervisor por e-mail, o que dá tempo de agir antes do descumprimento.

É justamente aqui que o atendimento dá um salto de maturidade. Com regras de negócio bem desenhadas, você pode automatizar a triagem de chamados e reduzir o trabalho manual da equipe.

Para ir além, dá para aplicar classificação automática com IA, que lê o texto do chamado e sugere categoria, prioridade e grupo responsável já na abertura.

Base de conhecimento e catálogo de serviços

Reduzir o volume de chamados é tão importante quanto resolvê-los rápido. O GLPI ajuda nisso com dois recursos que atuam na origem da demanda.

A base de conhecimento publica artigos e soluções recorrentes para o autoatendimento. Quando o usuário encontra a resposta sozinho, o chamado nem chega à fila do time.

Já o catálogo de serviços de TI padroniza o que a área oferece, com formulários próprios por tipo de pedido. Assim, o solicitante já informa tudo que o técnico precisa para começar a trabalhar.

Outro ganho aparece quando o catálogo se conecta ao inventário. Ao vincular o ativo afetado ao chamado, o técnico consulta histórico, garantia e configuração do equipamento sem sair da tela do ticket.

Cada serviço do catálogo também pode ter o seu próprio SLA. Dessa forma, um pedido simples de acesso e uma falha crítica de rede recebem prazos coerentes com o impacto de cada caso.

No fim, esses recursos mudam a natureza do atendimento. Em vez de só reagir a problemas, a equipe passa a oferecer serviços organizados, com prazos claros e caminhos de autoatendimento bem sinalizados.

Indicadores de service desk no GLPI

De nada adianta operar sem medir. O GLPI gera relatórios nativos e amplia a análise com plugins de mercado, o que sustenta decisões de capacidade e de qualidade.

Os indicadores abaixo resumem o que acompanhar e por que cada número importa para o service desk.

 
Para um panorama completo das métricas de service desk, combine esses números com metas claras. Times maduros revisam os indicadores em reuniões semanais e ajustam as regras conforme a tendência aparece.

Painéis de gestão à vista deixam esses dados visíveis para toda a equipe. Um quadro com o SLA do dia, o backlog e os chamados por técnico mantém o time focado no que precisa de ação imediata.

Vale lembrar que indicador sem dono não vira ação. Cada métrica precisa de um responsável e de uma meta acordada, caso contrário o relatório bonito não muda a operação no dia a dia.

Esses indicadores também conversam com referências de mercado. Vale comparar a sua operação com a definição de service desk consolidada no mercado de ITSM.

Quando a operação integra esses dados ao monitoramento de infraestrutura, o ganho cresce ainda mais. A OpServices apoia a implementação do help desk com GLPI, conectando chamados, ativos e indicadores em um fluxo só.

Conclusão

A gestão de chamados no GLPI deixa de ser um quebra-cabeça quando você trata a ferramenta como apoio ao processo. Categorias bem definidas, SLA realista e regras de escalonamento transformam uma fila confusa em um service desk previsível.

O caminho começa pela distinção entre incidente e requisição, passa pela configuração de calendários e níveis de serviço e se consolida com indicadores acompanhados de perto. Cada etapa aproxima a operação de um modelo proativo, alinhado ao ITIL.

Se a sua equipe ainda apaga incêndios em planilhas ou em e-mails soltos, o momento de estruturar é agora. Fale com os especialistas da OpServices para desenhar um help desk que cumpre SLA do primeiro chamado ao relatório final.