One GLPI, many SLA policies

How we tested

We configured four organisations in one GLPI instance, each in a separate entity, with policies modelled on published service level documents and contracts.

• Simulated time. GLPI calculates deadlines from the server clock. January to March was therefore simulated with a single controlled clock shared by the web server, scheduled tasks and database. Each action took place at its scheduled time, and scheduled tasks ran as in production.
• Users and channels. Requesters submitted tickets through the self-service form and email. Technicians worked in the web interface and, where a service desk would use an integration or log a phone call, through the REST API under their own accounts.
• Ticket volume. 1,701 tickets: 32 scenarios, each designed to test a single rule such as a holiday, a pause, a priority change, a handover or a backdated opening date, and 1,669 tickets with a representative mix of priorities, pauses, reminders, reopenings and handovers.
• Reference calculation. An independent calculator, validated against 38 manually computed cases, derived every deadline and verdict from the written policy and the event log. It does not use GLPI’s results.
• Versions. All organisations ran on GLPI 11.0. Team handovers and three findings were repeated on GLPI 12.0, which introduced a new OLA model.

Service desk response times were randomised. The study compares GLPI with the policy on identical tickets; it does not assess service desk performance.

Where GLPI matches the policy

For most tickets, GLPI deadlines matched the policy to the minute: 93.2% of response deadlines and 88.2% of resolution deadlines fell at the same business moment. Priority-based coverage, public holidays, the five-day recess, the six-day working week, “close of next business day” and the pause while awaiting the user were all applied as defined.

The four organisations remained independent. Each entity applied its own rules and calendars, and each supervisor’s report contained only that organisation’s tickets.

Across all tickets, GLPI and the policy reached the same verdict (met or missed) on 3,227 of 3,402 response and resolution results, or 94.9%.

Where GLPI differs from the policy

To identify the cause of the 175 differing verdicts, we applied GLPI’s behaviour to the independent calculation one point at a time and recorded how many differences each accounted for. None of the differences is a calculation error. In each case GLPI applied its configuration consistently, and the policy defined the same term differently.

1. 01

   Any update counts as the response

   The first follow-up, task or solution by anyone other than the requester stops the response clock, including private notes and the requester’s own email.

2. 02

   All pending reasons stop the clock

   Pending reasons control reminders, not the clock. A wait for a supplier pauses the deadline in the same way as a wait for the user.

3. 03

   Calendars carry no time zone

   Opening hours are interpreted in the time zone of the session performing the calculation, so results can vary by channel and user.

4. 04

   Day targets end at closing time

   Work completed after hours on the final day is recorded as late, whereas an hour-based target ending at closing time moves to the next opening.

What counts as a response

Many policies define a response as a communication from the service desk to the user. GLPI records a ticket as taken into account at the first follow-up, task or solution added by anyone other than the requester. In this study, that included private tasks not visible to the user (13 tickets) and the requester’s own email replies (24 tickets). Emails are collected by a scheduled task that does not run as the sender, so the requester exclusion does not apply. A category or priority change does not count while the ticket status is New. Where a contract requires a reply to the user, response figures from GLPI are therefore higher than the contract measure, and the gap widens as more tickets begin with an internal note or a follow-up from the user.

GLPI · Ticket

GLPI · Ticket statistics

Which waits stop the clock

GLPI pauses the resolution clock for every ticket in Pending; the pending reason controls reminders, not the clock. The managed service provider’s contract permits a pause for the customer but not for a supplier. When the team set one UK customer ticket to Pending with the reason “Awaiting vendor”, GLPI added 330 working minutes to the deadline, extending it by 36 hours.

GLPI · Service levels

GLPI · Service levels

The time zone of a calendar

A GLPI calendar defines opening hours but no time zone. The hours are interpreted in the time zone of the session performing the calculation. For the UK customer, London hours entered in the calendar produced London-based deadlines when the London requester submitted a ticket through the web form, and India-based deadlines when the ticket arrived by email or was recalculated in a technician’s session in India. The same London user also received different deadlines through the web form and the REST API, as API requests are calculated in the server’s time zone.

GLPI · Calendar

GLPI · Service levels

GLPI · Service levels

A common workaround is to enter the customer’s hours in server time, in this case 14:30 to 23:00. This matched the policy until the UK clock change at the end of March. Of the 13 UK tickets created after the change, 4 received a different response deadline and 5 a different resolution deadline.

Deadlines at the end of the day

When a day-based target ends after closing time, GLPI sets the deadline at closing time, so work completed after hours is recorded as late even though no business time has elapsed. When an hour-based target ends exactly at closing time, GLPI moves the deadline to the next opening. Both represent the same business moment, but only the first treats after-hours work as late.

Ticket lifecycle cases

Individual scenarios identified four further behaviours that affect specific tickets:

• A month equals 30 working days. Under the public sector contract, a ticket logged on 29 January with a one-month target was due on 6 March rather than 1 March.
• Backdating does not change deadlines. When a technician corrected the opening date to the time of the call, the deadlines remained as calculated from the original creation time. Policies that start the clock at call logging require the service level to be reassigned after the correction.
• A new service level inherits pending time. When a priority change after a Pending period assigned a new service level, GLPI added the accumulated Pending time to both the new response and resolution deadlines (570 minutes on GLPI 11.0, 575 on GLPI 12.0). Response deadlines are otherwise never paused.
• Solved time is excluded. When a user rejected a solution, the time the ticket spent in Solved was added back to the deadline. This is consistent with the policies in this study, but contracts should state it explicitly.

GLPI · Service levels

Two further behaviours affect reporting. GLPI’s “exceeded” columns exclude tickets in Pending, so an open ticket past its deadline does not appear in the late list while it is pending; this applied to five tickets at month end. GLPI also tracks deadlines rather than update frequency, so a requirement such as “update P1 tickets hourly” cannot be measured from its service level fields.

Teams and OLAs

Internal IT escalated tickets from the service desk to the network team and then to the server team, each with its own OLA and working hours. The same handover was run on GLPI 11.0 and on GLPI 12.0, which introduced a new OLA model.

GLPI 11.0 · Service levels

GLPI 12.0 · Service levels

• One target per ticket (11.0). Each handover replaces the internal target, so the service desk and network team results are available only in the ticket history.
• One OLA per team (12.0). The network team’s clock started at handover and began counting at its 12:00 opening. Only a network team member could stop its response clock; a reply from the service desk on the team’s behalf did not, and the network team missed its target by 30 minutes.
• A team’s OLA runs until its group is removed (12.0). When the service desk handed over without its group assigned to the ticket, its 4-hour OLA continued until resolution and was recorded as late. When the desk assigned its group and removed it at handover, the OLA ended at handover and was met.
• Pauses (12.0) extend every team’s resolution clock, and a team’s response clock only while that team is not assigned.

What reaches the report

At each month end, each organisation’s supervisor ran GLPI’s ticket search with its “exceeded” columns, as for a service review.

GLPI reports showed higher resolution attainment than the written policy for every organisation, by 1.0 to 5.9 percentage points, mainly because Pending paused tickets for waits the policies do not permit. Response attainment differed in both directions: lower where a day-based target ended at closing time or the UK calendar was interpreted in India time, and higher where a private task or the user’s email counted as the response.

For the public sector contract, the penalty clause yields 2,228 units for the quarter. Applied to GLPI’s deadlines and resolution dates, the same clause yields 1,855 units, 16.7% less, with 23 tickets assessed differently. GLPI has no penalty field, so penalties calculated from exported GLPI data inherit all of the differences above.

What we recommend

1. 1

   Define the response and measure accordingly

   Where only a reply to the user qualifies, report response time from the first public follow-up by the service desk rather than from GLPI’s take-into-account time.

2. 2

   Keep non-pausing waits out of Pending

   GLPI pauses for every pending reason. Where a contract does not pause for suppliers, track those waits without the Pending status, or adjust the figures before a review.

3. 3

   Calculate in a single time zone

   Set server and user time zones deliberately, and review customers in other countries after each clock change. Hours entered as a fixed offset remain valid for one season at most.

4. 4

   Express targets in GLPI terms

   Use working days rather than months, and define whether end of day means closing time or the next opening.

5. 5

   Remove the group at handover (GLPI 12.0)

   A team’s OLA continues until its group is removed from the ticket or the ticket is resolved.

6. 6

   Validate initial reports against the contract

   Recalculate a sample of tickets from the contract before GLPI figures are used in a service review or penalty claim. The differences are systematic, so a small sample is sufficient to reveal them.

Methodology

• Volume. 1,701 tickets on GLPI 11.0 (32 scenarios and 1,669 general tickets) with 6,831 timed events from 4 January to 31 March, and 9 tickets on GLPI 12.0. One GLPI 12.0 scenario was repeated on a new ticket after an execution error; the incomplete ticket was excluded.
• Versions. GLPI 11.0 with MariaDB 10.11 for all organisations; GLPI 12.0 for the OLA scenarios and to confirm three findings: private tasks as response, pending time on a new service level, and channel-dependent time zones. All three behaved identically.
• Out of scope. Merged duplicates, workarounds followed by a permanent fix, and automatic closure. These do not affect service level fields beyond what the resolution and reopening scenarios show.
• Evidence. For every ticket, the recorded state after each step, screenshots at each scenario step, GLPI logs and the calculation output were retained. No PHP, database, access or mail errors were logged.