On 29 July 2026 the GLPI team published a case study of Econocom's Product Care operation. The figures are worth a look: 260,000 tickets a year, 2 million assets under management, 6,500 clients served daily, 650 platform users and a team of 40 — 20 on the front desk, 20 in the workshop — across 16 countries.
What makes it useful is not the reference value but the question it answers, the one that comes up in every tender and every internal review: will an open-source tool carry our volumes? The published numbers sit well above what a typical deployment in Slovakia handles.
What actually runs there
Requests arrive by phone, email and dynamic web forms built on Form Creator — which in the latest GLPI version is part of the core rather than a plugin. GLPI is not primarily a ticketing tool in that setup; it is the CMDB, the central repository the rest of the processes hang off. Task templates fire resolution steps automatically, from assignment through closure to the confirmation message sent to the client. Contract management and change enablement sit on top.
What the study does not publish is the architecture — no database sizes, no application server counts, no tuning parameters. You cannot derive sizing for your own environment from those numbers. You can derive something else.
What breaks first as you grow
In larger deployments the bottleneck is rarely server performance. It is the data model, and the order in which the problems surface is fairly consistent:
- Entity structure. Decided at the start, most expensive to change later. A badly designed entity tree only shows up when permissions, reporting or billing need to be separated between organisational units.
- Inventory volume. Two million assets means deduplication rules, agent run scheduling and disciplined purging of deleted items. Without a purge policy the database grows faster than the estate it describes.
- Saved searches and dashboards. A view that aggregates over every ticket since go-live is imperceptible at tens of thousands of records and blocking at hundreds of thousands.
- The profile and permission matrix. It multiplies by the number of entities. At 650 users, the difference between configuring by role and configuring by person is measurable in admin hours per month.
What transfers to a smaller deployment
The numbers do not transfer; the discipline does. One entry point instead of three parallel channels. Templates before automation — automating an inconsistent process multiplies the inconsistency. And an asset register that serves as the source of truth for other functions too, not just an attachment to a ticket.
Form Creator moving into the core is a practical side benefit: one less dependency on a community plugin, which matters given the vulnerabilities found in GLPI plugins.
How to check your own position
Rather than comparing against someone else's figures, measure your own: tickets per month, asset count, active technicians and the size of your largest tables. A test on a copy of production data against the current branch — GLPI 11.0.8 was released on 24 June 2026 — tells you more about readiness than any reference study. And when moving from GLPI 10 to 11, it is a step you cannot skip anyway.