NexTool Solutions

Most service desks run in reactive mode: they wait for the ticket to arrive and rush to solve it. The support funnel flips that logic - each layer filters demand before it reaches the technician. In GLPI the funnel is not a button you switch on: it is an arrangement of categories, business rules, knowledge base and cron that has to be measured and tuned. This guide shows how to build each layer with what GLPI already ships, and the traps we have seen bring down entire funnels while maintaining client environments.

Before building the funnel, measure where the volume comes from

The most common mistake is building the funnel backwards: writing dozens of generic articles and forms hoping they cut tickets. In maintenance we do the opposite - first find out which categories concentrate the volume, because that is where each layer pays off. The query below, run with a read-only user, lists the categories that generate the most demand in the last 90 days and splits incident from request, the distinction that decides whether the demand goes to self-service or to L1:

-- Top categories by volume (last 90 days): where the prevention and
-- self-service layers pay off the most. Use a read-only user.
-- type: 1 = incident, 2 = request
SELECT
    COALESCE(c.completename, '(no category)') 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;

Two readings come out of it. Repetitive request categories (password reset, access grants, standard installs) are candidates for self-service and automation: the user should not need a technician. High-volume incident categories point to recurring failures that the prevention layer should catch before the user notices. And if "(no category)" shows up at the top, the problem is upstream of the funnel: triage is loose and no rule can route what was never classified.

The decision matrix: each demand in its layer

A funnel is not a hierarchy of people, it is demand routing. Each type of demand has a right layer and a native GLPI mechanism that backs it. The matrix below is the starting point we use when designing a client funnel:

Layer 1 - Prevention: the ticket born from monitoring

The goal of this layer is the ticket the team (or the system itself) opens before the user notices the problem. In practice:

• Monitoring creates the ticket: Zabbix, GLPI Agent or another collector fires a ticket via email (collector) or API when a threshold is crossed - disk at 90%, service down, certificate about to expire. The ticket arrives already categorized and in the infra group.
• Planned maintenance communicated: before a window, a portal announcement and a notification prevent the flood of "is it down?".
• Root-cause fix: incidents that keep recurring become a Problem in GLPI, handled once instead of N identical tickets.

The gain is measurable: the prevention rate is the share of incidents whose first record came from monitoring, not from the user. The Zabbix-GLPI integration is the most direct path to this layer.

Layer 2 - Self-service: publishing is not the same as appearing

Here lives the trap we have seen kill the self-service layer most often: the team writes dozens of articles and yet the self-service portal shows the user nothing. In GLPI an article only appears in the public FAQ when three conditions line up:

1. the article is published (with a validity start date, not a draft);
2. it is flagged as visible in the FAQ (the is_faq field);
3. it has a target audience that includes the self-service profile (or "everyone") - with no target, the article is visible only to whoever created it.

Miss one of the three and the article exists in the database but is invisible to whoever needs it. Add category visibility to that: a category not flagged as visible in the helpdesk does not show up in the opening form, so the user never even gets to self-serve there. Beyond articles, this layer includes guided forms (password reset, standardized requests) that solve or route without intervention. Start the knowledge base with the categories the SQL above flagged at the top, not with the product manual from A to Z.

Layer 3 - Resolution: routing by rule, not by email

What was neither prevented nor self-served must reach whoever resolves it fast - and reach the right place. The engine here is the ticket business rules (RuleTicket): they assign group, category, priority and SLA based on criteria (category, source, word in the title, requester). Routing by rule is auditable and reproducible; routing by "forward the email to so-and-so" does not scale and vanishes when so-and-so goes on holiday. The query below lists the active ticket rules in the order GLPI runs them:

-- Active ticket business rules (RuleTicket), in execution order.
-- GLPI processes by `ranking`; a "stop processing" action on an
-- earlier rule prevents the following ones from running. Use a read-only user.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
  AND is_active = 1
ORDER BY ranking;

The order (ranking column) matters because a "stop processing" action interrupts the following rules. The common mistake is to create a new rule at the end of the queue expecting it to adjust priority, without noticing that an earlier rule, with "stop processing" enabled, has already ended the routing - the new one never runs. The L1/L2/L3 levels are groups; escalation between them is rule plus SLA by priority, not a manual case-by-case decision.

The mistake that brings down any funnel: the automation that never fires

You can build the three layers with care and still have nothing happen on its own. SLA escalation, sending notifications, auto-closing solved tickets, alerts - all of it in GLPI depends on the Automatic Actions (CronTask), and they only run reliably when an external OS cron calls GLPI. In the default "GLPI" mode (triggered by web browsing), the actions run irregularly, depend on someone opening the interface and stall under load. The classic symptom we get called about: "the SLA does not escalate", "the notification does not arrive", "the ticket does not close on its own" - and the cause is almost always the same. The line below fixes it (adjust the path to your GLPI root and the PHP user):

# GLPI - EXTERNAL automatic action, every 1 minute, as the PHP user.
# Without this, SLA/escalation, notifications and auto-close do NOT run.
# Adjust the path to your GLPI root (GLPI 10 and 11 use front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Then, under Setup > Automatic actions, switch the tasks mode from "GLPI" to "CLI". Without that step, much of the funnel is just decoration.

From the field: the funnel that existed only on paper

Taking over the maintenance of an already-running environment, we found the most common scenario of all: the funnel was drawn on the slide but not in the system. The knowledge base had over a hundred articles - all saved as drafts, none flagged as FAQ nor with a target audience, so the self-service portal came up empty for the user. The assignment rules existed, but the third one had "stop processing" enabled and swallowed half the tickets into the wrong group. And the external cron had never been configured, so the SLA did not escalate and auto-close was stalled - the backlog swelled with solved tickets nobody confirmed. We ran the volume-by-category SQL before touching anything: password reset and VPN accounted for a large share of the total. We published and flagged as FAQ half a dozen articles from those two categories, fixed the rule order and turned on the external cron. Within a few weeks the volume of those categories dropped visibly in the same report - not because the problem vanished, but because it stopped becoming a ticket. The funnel was not new; it had simply never left the paper.

Building the funnel in GLPI is less about plugins and more about order: measure the volume, route by rule, publish self-service for real and make sure the automation fires. NexTool GLPI maintenance includes exactly this design - from the category matrix to the rules and the cron - and the monthly follow-up that shows each layer cutting the demand reaching the technician.

Reviewed by the NexTool Solutions team.