NexTool Solutions

A maioria dos Service Desks opera no modo reativo: espera o chamado chegar e corre para resolver. O funil de atendimento inverte essa lógica - cada camada filtra a demanda 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 precisa ser medido e ajustado. Este guia mostra como montar cada camada com o que o GLPI já traz, e as armadilhas que já vimos derrubar funis inteiros na sustentação de ambientes de clientes.

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

O erro mais comum é montar o funil de trás para frente: criar dezenas de artigos e formulários genéricos torcendo para que reduzam chamados. Na sustentação fazemos o oposto - primeiro descobrir quais categorias concentram o volume, porque é ali que cada camada tem retorno real. A consulta abaixo, rodada com um usuário somente-leitura, lista as categorias que mais geram demanda nos últimos 90 dias e separa incidente de requisição, a distinção que decide se a demanda 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 usuário somente-leitura.
-- type: 1 = incidente, 2 = requisição
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;

Duas leituras saem daí. Categorias de requisição repetitiva (reset de senha, liberação de acesso, instalação padrão) são candidatas a autoatendimento e automação: o usuário não deveria precisar de um técnico. Categorias de incidente com alto volume apontam falhas recorrentes que a camada de prevenção deveria capturar antes de o usuário perceber. E se "(sem categoria)" aparece no topo, o problema é anterior ao funil: a triagem está solta e nenhuma regra consegue rotear o que não foi classificado.

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

Funil não é hierarquia de pessoas, é roteamento de demanda. Cada tipo de demanda 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 do monitoramento

A meta desta camada é o chamado que a equipe (ou o próprio sistema) abre antes de o usuário perceber o problema. Na prática:

• Monitoramento cria o chamado: Zabbix, GLPI Agent ou outro coletor dispara um chamado via e-mail (collector) ou API quando um limite é cruzado - disco em 90%, serviço parado, certificado a vencer. 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á fora do ar?".
• Correção de causa-raiz: incidentes que se repetem viram um Problema (Problem) no GLPI, tratado uma vez em vez de N chamados iguais.

O ganho é medível: a taxa de prevenção é o percentual de incidentes cujo primeiro registro veio do monitoramento, não do usuário. A integração do Zabbix com o GLPI é o caminho mais direto para essa camada.

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

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

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 definido que inclua o perfil self-service (ou "todos") - sem alvo, o artigo fica visível apenas para quem o criou.

Falte uma das três e o artigo existe no banco, 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, então o usuário nem chega a se autoatender por ali. Além dos artigos, esta camada inclui formulários guiados (reset de senha, solicitações padronizadas) que resolvem ou roteiam sem intervenção. Comece a base de conhecimento pelas categorias que o SQL acima apontou no topo, não pelo manual do produto de A a Z.

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

O que não foi prevenido nem autoatendido precisa chegar rápido a quem resolve - e chegar certo. O motor aqui são as Regras de negócio para chamados (RuleTicket): elas atribuem grupo, categoria, prioridade e SLA com base em critérios (categoria, origem, palavra no título, requerente). Roteamento por regra é auditável e reproduzível; roteamento por "encaminha o e-mail para o fulano" não escala e some quando o fulano entra de férias. A consulta abaixo lista as regras de chamado ativas na ordem em que o GLPI as executa:

-- Regras de negócio de chamado (RuleTicket) ativas, na ordem de execução.
-- O GLPI processa por `ranking`; uma ação "parar de processar" numa
-- regra anterior impede as seguintes de rodar. Usar usuário somente-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 esperando que ela ajuste a prioridade, sem perceber que uma regra anterior, com "parar de processar" ligado, já encerrou o roteamento - a nova nunca roda. Os níveis N1/N2/N3 são grupos; o escalonamento entre eles é regra mais SLA por prioridade, não decisão manual caso a caso.

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

Você pode montar as três camadas com capricho e ainda assim nada acontecer sozinho. Escalonamento de SLA, envio de notificações, fechamento automático de chamados solucionados, alertas - tudo isso no GLPI depende das Ações Automáticas (CronTask), e elas só rodam de forma confiável quando há um cron externo do sistema operacional chamando o GLPI. No modo padrão "GLPI" (disparo pela navegação web), as ações rodam de forma irregular, dependem de alguém acessar a interface e travam sob carga. O sintoma clássico que atendemos: "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 usuário do PHP):

# GLPI - ação automática EXTERNA, a cada 1 minuto, como usuário do PHP.
# Sem isto, SLA/escalonamento, notificações e fechamento automático NÃO rodam.
# 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, troque o modo das tarefas de "GLPI" para "CLI". Sem esse passo, boa parte do funil fica decorativa.

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

Ao assumir a sustentação de um ambiente que já rodava, encontramos 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 salvos como rascunho, nenhum marcado como FAQ nem com público-alvo, então o portal self-service aparecia vazio para o usuário. As regras de atribuição existiam, mas a terceira delas tinha "parar de processar" ligado e engolia metade dos chamados no grupo errado. E o cron externo nunca fora configurado, então o SLA não escalava e o fechamento automático estava parado - o backlog inflava com chamados solucionados que ninguém confirmava. Rodamos o SQL de volume por categoria antes de tocar em qualquer coisa: reset de senha e VPN respondiam por boa parte do total. Publicamos e marcamos como FAQ meia dúzia de artigos dessas duas categorias, corrigimos a ordem das regras e ligamos o cron externo. Em poucas semanas o volume dessas categorias caiu de forma visível no mesmo relatório - não porque o problema sumiu, mas porque parou de virar chamado. O funil não era novo; ele só nunca tinha saído do papel.

Montar o funil no GLPI é menos sobre plugins e mais sobre ordem: medir o volume, rotear por regra, publicar o autoatendimento de verdade e garantir que a automação dispara. A sustentação de GLPI da NexTool inclui exatamente esse desenho - da matriz de categorias às regras e ao cron - e o acompanhamento mensal que mostra cada camada reduzindo a demanda que chega ao técnico.

Revisado pela equipe NexTool Solutions.