Knowing where you stand is the first step to knowing where to go. This guide shows how to assess your operation's ITSM maturity level using objective signals pulled from GLPI itself - not perception - and how to prioritize the next steps of your evolution.
Maturity is not measured by opinion
The question "what level are we at?" almost always gets an emotional answer: whoever fights fires every day swears they are at level 1, and the manager who approved the tool purchase swears they are at level 4. Both are wrong, because both are measuring a feeling, not a process. ITSM maturity is the degree of formalization, automation and optimization of service management, and it leaves measurable traces in the tool's database. Before hiring consulting or buying more modules, it pays to extract those traces.
Objective diagnosis: ask GLPI itself
Three signals clearly separate a mature operation from an immature one: how many tickets are actually categorized, how many have an SLA attached, and how long they take to resolve. Run the query below directly against the database (read only) over the last 90 days:
-- Maturity signals over the last 90 days (GLPI 10/11)
SELECT
COUNT(*) AS total_tickets,
ROUND(100 * SUM(itilcategories_id > 0) / COUNT(*), 1) AS pct_categorized,
ROUND(100 * SUM(slas_id_ttr > 0) / COUNT(*), 1) AS pct_with_resolution_sla,
ROUND(AVG(TIMESTAMPDIFF(HOUR, date, solvedate)), 1) AS avg_hours_to_resolve
FROM glpi_tickets
WHERE date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND is_deleted = 0
AND solvedate IS NOT NULL;
Field reading: below 70% of tickets categorized, forget problem management - you have no basis to group recurrences. Below 50% with an SLA attached, your compliance reports only measure the fraction that has a deadline, not the whole operation. And if the average hours to resolve swings a lot from month to month, the process is still ad-hoc even if a tool exists.
Matrix: level x GLPI signal x action
Use the matrix to locate your level by what GLPI shows today, not by what you wish it showed:
| Level | Observable signal in GLPI | Next technical action | Target metric |
|---|---|---|---|
| 1 - Ad-hoc | No tool, or tickets without category/SLA | Deploy GLPI, create entity and profiles | 100% of tickets in the tool |
| 2 - Repeatable | Tickets opened, but "Other" category dominates | Lean category tree + initial SLA | >70% categorized |
| 3 - Defined | Categories and SLA in use; manual assignment | Business rules (assignment), knowledge base | SLA attached >90% |
| 4 - Managed | Metrics collected; cron in CLI | Problem and change management, dashboards | SLA met >90% |
| 5 - Optimized | Decisions from data; mature automation | Recurrence analysis, business integration | Year-over-year drop in recurrence |
The support detail that skews every metric
In supporting client environments, the most misleading indicator is "SLA met" when GLPI's automatic actions run in GLPI mode (triggered by the browser) instead of CLI. In that mode, deadline recalculation, escalations and notifications only happen when someone opens a page in the system. The result: at 3 a.m., with nobody logged in, no ticket is escalated, and the next day's report shows a green SLA that does not match reality. The common mistake is trusting the dashboard without checking, under Setup > Automatic actions, which execution mode is set. The fix is to standardize everything on CLI and schedule the system cron:
# /etc/cron.d/glpi - runs the automatic actions every minute
# Works for GLPI 10 and 11 (front/cron.php is portable; on 11 avoid depending on the console)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null
After moving to CLI, in Automatic actions switch the run mode of each critical task (queuednotification, slaticket, closeticket) to CLI. Without this, you may be at level 4 on paper and level 2 in practice.
The trap of the inherited category tree
Another recurring stumble: moving up a level thinking that "having many categories" is a sign of maturity. It is the opposite. We once took over an environment that had brought in around 400 categories imported from a legacy system, nested five levels deep. In practice, agents could not find the right category, picked the first one that appeared, and the field turned into noise. We recategorized the last few months of history, cut the tree down to a little over two dozen categories that reflected what the team actually handles, and only then did the by-cause reports start to make sense. The rule of thumb we use: if a category has received no ticket in 90 days, it is a candidate to disappear. Too many categories do not measure maturity; they get in the way of triage and skew any recurrence analysis.
Quick assessment checklist
- Is there an ITSM tool with all tickets inside it? (yes = level 2+)
- Are more than 70% of tickets in a specific category, not "Other"? (yes = level 3+)
- Is the SLA attached and the cron running in validated CLI? (yes = level 3+)
- Are metrics collected and reviewed in a fixed meeting? (yes = level 4+)
- Do decisions come from data, not perception? (yes = level 4+)
- Is there active problem management reducing recurrence? (yes = level 5)
Evolution plan: one level at a time
Do not try to skip stages - each level rests on the previous one. If the diagnosis showed low categorization, the next step is not to buy AI; it is to shrink the category tree to what the team actually uses (in practice, 15 to 25 categories cover most mid-sized operations) and to train triage. Only after categorization stabilizes does problem management make sense, because you can finally group incidents by cause. If you are at level 1-2, start with the GLPI deployment and basic configuration before any automation.
In our support experience, the fastest maturity gain does not come from a new feature, but from cleaning up what already exists: cron in CLI, lean categories, and an SLA attached to 100% of ticket types. These three adjustments move an operation from level 2 to level 3 in a few weeks, with no extra license cost.
If you want a maturity diagnosis with these indicators pulled from your own environment, NexTool assesses and supports GLPI for B2B operations - from basic configuration to the optimized level.
Reviewed by the NexTool Solutions team.