NexTool Solutions

AI will not replace the support analyst, but the analyst who uses it well will replace the one who ignores it. In GLPI this is not a slogan: it is a workflow you configure, measure and tune. Maintaining client GLPI service desks, we have seen AI fail in two ways - bolted on with no measurement (nobody knows if it helped) and used on autopilot (a wrong suggestion pasted straight into the solution). This guide shows how to operationalise AI in day-to-day ticket work, with the queries and the configuration we actually run in the field.

Start by measuring where AI pays off, not where it impresses

The common mistake is to point AI at the complex, rare ticket - the one that shines in a demo - instead of the high-volume repetitive one, which is where it gives real time back. Before plugging anything in, find out where the volume is and what it costs. This query lists the categories with the most tickets over the last 90 days and the average time to resolution, the highest-return candidates for AI-assisted replies, knowledge base articles and automatic triage:

-- Highest-volume categories and average resolution time (90 days).
-- solve_delay_stat is in seconds; /3600 converts to hours.
SELECT c.completename            AS category,
       COUNT(t.id)               AS tickets,
       ROUND(AVG(t.solve_delay_stat)/3600, 1) AS hours_to_resolve
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
  AND t.is_deleted = 0
  AND t.solvedate IS NOT NULL
GROUP BY t.itilcategories_id, c.completename
HAVING tickets >= 10
ORDER BY tickets DESC
LIMIT 15;

The top of that list is your map: these are the subjects where an automatic summary, a draft reply or a KB article pay off most. A high-volume category with high resolution time is where AI as an assistant relieves the queue the most; a low-volume, high-complexity category stays human work - and trying to automate it is a waste.

Deterministic triage first, AI second

The costliest confusion we see is asking AI to do what GLPI business rules already do better. Classifying category, setting priority and assigning the group by patterns on subject, requester or entity is the job of ticket business rules (RuleTicket): deterministic, auditable and reproducible. Generative AI belongs to what is fuzzy and does not need to be reproducible: summarising a 50-message thread, drafting a reply from history, gauging the requester's tone. Mixing the two roles is the source of SLA reports nobody can explain. The matrix we use to decide who does what:

Never call AI synchronously in the ticket lifecycle

This is the trap that cost us the most hours in sustaining work. When the AI integration - or any external webhook - fires an HTTP call inside the ticket create or update hook synchronously, the analyst's save gets stuck waiting for the external API to answer. We have seen the save button hang for 30 to 60 seconds because a hook made the request on the spot, and the analyst swore "GLPI is slow". AI enrichment must be asynchronous: queue it and process it outside the request, through GLPI's external cron. And that cron must be real (CLI/external mode), not the page-visit trigger:

# GLPI external cron (MODE_EXTERNAL) - runs queued tasks,
# including notifications and asynchronous enrichment.
# Run as the web server user (www-data / apache), every minute:
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

The common error is to leave the automatic tasks in internal mode, triggered by whoever loads a page. With no visit, nothing runs; under load, one long task locks the state and the rest do not execute. Set the tasks to CLI mode in GLPI and make sure the crontab above is in place - otherwise the automation "works sometimes", which is the same as not working.

What stays human work

AI drafts; the human decides and signs off. Diagnosing a problem with undocumented variables, negotiating with a frustrated user, the judgement to escalate or work around, the organisational context that sets the real priority - none of that is AI's to solve. And there is a detail only an operator notices: the ticket's solution field feeds the knowledge base, which in turn feeds AI's next suggestion. Pasting a generated reply without review is not just a one-off error - it enters the archive and comes back amplified in the next suggestion. The analyst of the AI era is the reviewer who stops that loop from degrading service quality.

The technical skills that now matter

1. Prompt with ticket context: citing the item, the history and the exact error yields a useful reply; a generic prompt yields generic text.
2. Read and tune RuleTicket: understanding the deterministic triage that underpins the SLA is worth more than any AI trick.
3. Measure with SQL: the queries above prove, with numbers, where AI paid off and where it just added work.
4. Curate the knowledge base: AI's suggestion is only as good as the KB feeding it; a stale article becomes a wrong suggestion.
5. Review before pasting: you sign the solution, not the AI. That is the line that defines the analyst who adds value.

Want to put AI to work inside GLPI in a measurable way, with the AI Assist module integrating OpenAI GPT and Google Gemini right in the ticket? Discover NexTool's GLPI sustaining service and make AI deliver without breaking what already works.

Reviewed by the NexTool Solutions team.