NexTool Solutions

A maioria dos Service Desks opera em modo reativo: espera o chamado chegar e corre para o resolver. O funil de atendimento inverte essa lógica - cada camada filtra a procura antes de ela chegar ao técnico. No GLPI, o funil não é um botão que se liga: é um arranjo de categorias, regras de negócio, base de conhecimento e cron que é preciso medir e afinar. Este guia mostra como construir cada camada com o que o GLPI já traz, e as armadilhas que já vimos deitar abaixo funis inteiros na manutenção de ambientes de clientes.

Antes de construir o funil, meça de onde vem o volume

O erro mais comum é montar o funil ao contrário: escrever dezenas de artigos e formulários genéricos na esperança de que reduzam chamados. Na manutenção fazemos o oposto - primeiro descobrir que categorias concentram o volume, porque é aí que cada camada tem retorno real. A consulta abaixo, executada com um utilizador só de leitura, lista as categorias que mais procura geram nos últimos 90 dias e separa incidente de pedido, a distinção que decide se a procura vai para autoatendimento ou para o N1:

-- Top categorias por volume (últimos 90 dias): onde as camadas de
-- prevenção e autoatendimento têm o maior retorno. Usar utilizador só de leitura.
-- type: 1 = incidente, 2 = pedido
SELECT
    COALESCE(c.completename, '(sem categoria)') AS categoria,
    COUNT(*)        AS chamados,
    SUM(t.type = 1) AS incidentes,
    SUM(t.type = 2) AS requisicoes
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.date >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
GROUP BY t.itilcategories_id
ORDER BY chamados DESC
LIMIT 15;

Daí saem duas leituras. As categorias de pedido repetitivo (reposição de palavra-passe, concessão de acesso, instalação padrão) são candidatas a autoatendimento e automação: o utilizador não devia precisar de um técnico. As categorias de incidente com volume alto apontam falhas recorrentes que a camada de prevenção devia captar antes de o utilizador as notar. E se "(sem categoria)" aparece no topo, o problema é anterior ao funil: a triagem está solta e nenhuma regra consegue encaminhar o que não foi classificado.

A matriz de decisão: cada procura na sua camada

Funil não é hierarquia de pessoas, é encaminhamento de procura. Cada tipo de procura tem uma camada certa e um mecanismo nativo do GLPI que a sustenta. A matriz abaixo é o ponto de partida que usamos ao desenhar o funil de um cliente:

Camada 1 - Prevenção: o chamado que nasce da monitorização

A meta desta camada é o chamado que a equipa (ou o próprio sistema) abre antes de o utilizador notar o problema. Na prática:

• A monitorização cria o chamado: Zabbix, GLPI Agent ou outro coletor dispara um chamado por e-mail (collector) ou API quando um limite é cruzado - disco a 90%, serviço parado, certificado a expirar. O chamado chega já categorizado e no grupo de infra.
• Manutenção programada comunicada: antes de uma janela, um anúncio no portal e uma notificação evitam a enxurrada de "está em baixo?".
• Correção da causa raiz: os incidentes que se repetem tornam-se um Problema (Problem) no GLPI, tratado uma vez em vez de N chamados iguais.

O ganho é mensurável: a taxa de prevenção é a percentagem de incidentes cujo primeiro registo veio da monitorização, não do utilizador. A integração do Zabbix com o GLPI é o caminho mais direto para esta camada.

Camada 2 - Autoatendimento: publicar não é o mesmo que aparecer

Aqui mora a armadilha que mais vimos matar a camada de autoatendimento: a equipa escreve dezenas de artigos e, ainda assim, o portal self-service não mostra nada ao utilizador. No GLPI, um artigo só aparece na FAQ pública quando coincidem três condições:

1. o artigo está publicado (com data de início de validade, não em rascunho);
2. está marcado como visível na FAQ (o campo is_faq);
3. tem público-alvo que inclua o perfil self-service (ou "todos") - sem destinatário, o artigo fica visível apenas para quem o criou.

Falte uma das três e o artigo existe na base, mas é invisível para quem precisa. Some a isso a visibilidade da categoria: uma categoria que não está marcada como visível no helpdesk não aparece no formulário de abertura, por isso o utilizador nem sequer chega a autoatender-se por ali. Além dos artigos, esta camada inclui formulários guiados (reposição de palavra-passe, pedidos padronizados) que resolvem ou encaminham sem intervenção. Comece a base de conhecimento pelas categorias que o SQL acima colocou no topo, não pelo manual do produto de A a Z.

Camada 3 - Resolução: encaminhamento por regra, não por e-mail

O que não foi prevenido nem autoatendido tem de chegar depressa a quem resolve - e chegar ao sítio certo. O motor aqui são as Regras de negócio para chamados (RuleTicket): atribuem grupo, categoria, prioridade e SLA com base em critérios (categoria, origem, palavra no título, requerente). O encaminhamento por regra é auditável e reproduzível; o encaminhamento por "reencaminha o e-mail para o fulano" não escala e desaparece quando o fulano vai de férias. A consulta abaixo lista as regras de chamado ativas pela ordem em que o GLPI as executa:

-- Regras de negócio de chamado (RuleTicket) ativas, pela ordem de execução.
-- O GLPI processa por `ranking`; uma ação "parar de processar" numa
-- regra anterior impede as seguintes de serem executadas. Usar utilizador só de leitura.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
  AND is_active = 1
ORDER BY ranking;

A ordem (coluna ranking) importa porque uma ação de "parar de processar" interrompe as regras seguintes. O erro comum é criar uma regra nova no fim da fila à espera de que ajuste a prioridade, sem reparar que uma regra anterior, com "parar de processar" ligado, já encerrou o encaminhamento - a nova nunca é executada. Os níveis N1/N2/N3 são grupos; o escalonamento entre eles é regra mais SLA por prioridade, não uma decisão manual caso a caso.

O erro que deita abaixo qualquer funil: a automação que nunca dispara

Pode construir as três camadas com cuidado e ainda assim nada acontecer sozinho. Escalonamento de SLA, envio de notificações, fecho automático de chamados resolvidos, alertas - tudo isso no GLPI depende das Ações Automáticas (CronTask), e só são executadas de forma fiável quando há um cron externo do sistema operativo a chamar o GLPI. No modo predefinido "GLPI" (disparo pela navegação web), as ações correm de forma irregular, dependem de alguém aceder à interface e bloqueiam sob carga. O sintoma clássico que nos chamam a resolver: "o SLA não escala", "a notificação não chega", "o chamado não fecha sozinho" - e a causa é quase sempre a mesma. A linha abaixo resolve (ajuste o caminho para a raiz do seu GLPI e o utilizador do PHP):

# GLPI - ação automática EXTERNA, a cada 1 minuto, como utilizador do PHP.
# Sem isto, SLA/escalonamento, notificações e fecho automático NÃO são executados.
# Ajuste o caminho para a raiz do seu GLPI (GLPI 10 e 11 usam front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Depois, em Configurar > Ações automáticas, mude o modo das tarefas de "GLPI" para "CLI". Sem esse passo, boa parte do funil fica decorativa.

Da manutenção: o funil que existia só no papel

Ao assumir a manutenção de um ambiente que já estava a funcionar, encontrámos o cenário mais comum de todos: o funil estava desenhado no slide, mas não no sistema. A base de conhecimento tinha mais de cem artigos - todos guardados como rascunho, nenhum marcado como FAQ nem com público-alvo, por isso o portal self-service aparecia vazio para o utilizador. As regras de atribuição existiam, mas a terceira tinha "parar de processar" ligado e engolia metade dos chamados no grupo errado. E o cron externo nunca fora configurado, por isso o SLA não escalava e o fecho automático estava parado - o backlog inchava com chamados resolvidos que ninguém confirmava. Executámos o SQL de volume por categoria antes de tocar em fosse o que fosse: reposição de palavra-passe e VPN respondiam por boa parte do total. Publicámos e marcámos como FAQ meia dúzia de artigos dessas duas categorias, corrigimos a ordem das regras e ligámos o cron externo. Em poucas semanas o volume dessas categorias caiu de forma visível no mesmo relatório - não porque o problema desapareceu, mas porque deixou de virar chamado. O funil não era novo; só nunca tinha saído do papel.

Construir o funil no GLPI é menos sobre plugins e mais sobre ordem: medir o volume, encaminhar por regra, publicar o autoatendimento a sério e garantir que a automação dispara. A manutenção de GLPI da NexTool inclui exatamente este desenho - da matriz de categorias às regras e ao cron - e o acompanhamento mensal que mostra cada camada a reduzir a procura que chega ao técnico.

Revisto pela equipa NexTool Solutions.