ITSM Maturity: How to Assess and Evolve Your Operation

How to assess your operation's ITSM maturity with objective signals pulled from GLPI (diagnostic SQL, a level-by-level matrix and cron in CLI) and evolve one level at a time, without skipping stages.

In this article7 sections

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:

LevelObservable signal in GLPINext technical actionTarget metric
1 - Ad-hocNo tool, or tickets without category/SLADeploy GLPI, create entity and profiles100% of tickets in the tool
2 - RepeatableTickets opened, but "Other" category dominatesLean category tree + initial SLA>70% categorized
3 - DefinedCategories and SLA in use; manual assignmentBusiness rules (assignment), knowledge baseSLA attached >90%
4 - ManagedMetrics collected; cron in CLIProblem and change management, dashboardsSLA met >90%
5 - OptimizedDecisions from data; mature automationRecurrence analysis, business integrationYear-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

  1. Is there an ITSM tool with all tickets inside it? (yes = level 2+)
  2. Are more than 70% of tickets in a specific category, not "Other"? (yes = level 3+)
  3. Is the SLA attached and the cron running in validated CLI? (yes = level 3+)
  4. Are metrics collected and reviewed in a fixed meeting? (yes = level 4+)
  5. Do decisions come from data, not perception? (yes = level 4+)
  6. 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.

Frequently Asked Questions

Under Setup > Automatic actions, the run-mode column shows CLI or GLPI for each task. Also check the last execution date: if it only advances when someone accesses the system, the cron is in web mode. The correct setup is to schedule front/cron.php in the operating system's cron and set each critical action to CLI.

Above 70% of tickets in specific categories (not "Other" or blank) is the minimum to sustain problem management. Below that, grouping by cause becomes weak and recurrence analysis loses reliability.

Dashboards help, but they depend on well-filled data and a reliable cron. If categorization is low or the cron runs in web mode, the dashboard shows optimistic numbers. That is why it pays to cross-check with read-only SQL queries directly against the database.

No. Start with the practices that solve the most urgent pain (incidents and requests), with a lean category set and an attached SLA. Problem and change management come later, once the base data is already reliable.

Buying a new feature (automation, AI) before cleaning up the basics. Without consistent categorization, an attached SLA and cron in CLI, any advanced layer inherits bad data and produces reports that do not reflect the real operation.

Need help?