GLPI stores every ticket, every asset change, every SLA breach. But raw data sitting in a database is not a report. The gap between "we have the data" and "we can answer the question" is where most GLPI installations stall.
Building useful reports requires knowing what questions to ask, which data points answer them, and how to present the result so someone acts on it.
The built-in reporting engine
GLPI ships with a reporting module that covers the basics: ticket statistics, asset counts, SLA compliance summaries. These predefined reports work out of the box — open, filter by date or entity, export to PDF. For monthly management summaries, they’re often sufficient.
Where the built-in module falls short is customization. You can filter and sort, but you can’t build a report that cross-references ticket volume with asset age, or one that shows cost per incident by department. For that, you need the dashboard system or an external tool.
Dashboards in GLPI 10+
Since version 10, GLPI has a native dashboard builder. You place cards — counters, bar charts, pie charts, tables — on a grid and configure each card’s data source. A few practical dashboards:
- Helpdesk overview — open tickets by priority, average resolution time this week vs. last, SLA compliance percentage
- Asset health — devices by status (in use / repair / stock / disposed), warranty expirations in the next 90 days
- Team workload — tickets assigned per agent, average time to first response, backlog trend
Dashboards can be scoped per entity — a branch office manager sees their numbers, the CIO sees the aggregate. The key is designing dashboards around decisions, not data. "How many tickets did we close?" is data. "Are we meeting our SLA and where are we failing?" is a decision.
Reports that management actually reads
The most common failure in IT reporting is producing 15-page documents that nobody opens. Management wants three things:
- A headline number — are we up or down? (e.g., "SLA compliance: 94%, down from 97%")
- The reason — what caused the change? (e.g., "P2 incidents in the network category spiked after the office move")
- The action — what are we doing about it? (e.g., "Temporary resource reassignment until backlog clears")
Structure your GLPI reports around this pattern and they’ll get read. One page, three sections, sent monthly. Everything else is available on demand in the dashboard for anyone who wants to drill deeper.
Common reporting mistakes
- Reporting everything — 50 charts with no narrative. Nobody knows what to look at.
- No baseline — "We resolved 340 tickets" means nothing without comparison. Is that good? Bad? Trending up?
- Dirty data — if agents skip categories or don’t close tickets properly, every report built on that data is unreliable. Fix the process before trusting the numbers.
Start with one dashboard for the helpdesk manager and one monthly report for the CIO. Get those right before building anything else.