Designing SLA calendars that survive shift changes and public holidays

Every ITSM implementation has a moment, usually about six weeks after go-live, when the service desk manager sends the first quarterly SLA report to the CIO and quietly notices that the numbers are wrong. Not by a lot — a percentage point here, a rogue breach there — but wrong. The pattern is always the same: an incident opened at 4:55pm on the Friday before Kurban Bayramı, marked breached on Monday morning, when in reality no technician was ever on duty. The SLA policy said "9 to 5, Monday to Friday", the calendar said Ramazan Bayramı was on Wednesday, and somewhere between those two facts a ticket fell through.

The naive SLA calendar — the one every ITSM ships with as its default — is what causes this. It is the single most common source of unreliable SLA reporting, and it is fixable. This post walks through the calendar model we use and recommend, and the four categories of complication that any calendar in production has to handle.

The naive default: "9 to 5, Monday to Friday"

Most ITSM tools, out of the box, offer a business-hour SLA calendar that looks like this:

• Monday to Friday, 09:00 to 17:00.
• Weekends excluded.
• A short list of "public holidays" that someone has to remember to update every December.

This is fine for a small company where the IT team all live in the same city, work the same hours, and take the same holidays. It is not fine for anywhere else. In the real world, at least four categories of complication break this model within the first year:

1. Public holidays that move — most Turkish religious holidays are lunar-calendar based and shift 10-11 days earlier each year.
2. Shift models — a 24/7 NOC does not observe "business hours" at all.
3. Technician time-off — the SLA clock keeps running whether or not the assigned tech is at their desk.
4. Multi-region operations — Istanbul opens at 09:00 Europe/Istanbul; London opens at 09:00 Europe/London; the P1 ticket does not care.

We will take each in turn.

1. Turkish public holidays are not fixed dates

The Turkish official holiday calendar has two kinds of days:

• Fixed civil holidays. New Year (Jan 1), National Sovereignty and Children's Day (Apr 23), Labour and Solidarity Day (May 1), Commemoration of Atatürk, Youth and Sports Day (May 19), Democracy and National Unity Day (Jul 15), Victory Day (Aug 30), Republic Day (Oct 29). These are simple date rules.
• Movable religious holidays. Ramazan Bayramı (3.5 days) and Kurban Bayramı (4.5 days) are set by the Hijri lunar calendar and shift each Gregorian year. In 2026 Ramazan Bayramı runs March 20 (half-day) to March 23; in 2027 it starts around March 10. Kurban Bayramı in 2026 runs May 27 (half-day) to May 31; in 2027 around May 17.

The half-day rule matters. The Council of Ministers routinely declares the working day preceding a bayram as an official half-day (arefe), where public offices close at 13:00. Private-sector service desks vary — some follow the government's half-day, some observe a full workday, some close entirely. Whichever policy your organization follows, the SLA calendar has to encode it explicitly. A half-day is not "half business hours"; it is a specific window that begins at the usual opening time and ends at 13:00.

On top of these, the Turkish Presidency occasionally declares an ad hoc holiday — the day after a national football victory, an emergency day of mourning, or a bridging day between a fixed holiday and a weekend. These cannot be pre-loaded into any calendar. The SLA calendar model must support insertion of a one-off holiday at 24-hour notice without recomputing history.

Any SLA calendar that requires an engineer to redeploy code to add a holiday will fail in its first year of operation. The calendar has to be data, not configuration.

2. Shift models are not "business hours"

A 24/7 network operations center does not have business hours. It has shifts. The SLA calendar for a 24/7 desk should be entirely different from the one for a Monday-to-Friday desk. And in most real organizations, both exist side by side — the 24/7 NOC handles P1 infrastructure incidents while a 09-to-18 desk handles L1 requests. You cannot use one calendar for both.

The three shift patterns we most often model:

• Standard day shift. Mon-Fri, 09:00 to 18:00, with a one-hour lunch window that does not pause the SLA clock (technicians overlap lunch on purpose).
• Extended-hours day. Sun-Thu (for finance-sector desks whose business follows a Sunday-Thursday week), 07:00 to 21:00.
• Round-the-clock rotation. Three-shift 24/7 with hand-offs at 08:00, 16:00, and 00:00. SLA clock runs continuously; hand-off is invisible to the customer.

The right calendar model attaches to the SLA policy, not to the service desk as a whole. A P1 infrastructure incident is measured against the 24/7 calendar; a P4 "please add me to the group mailbox" request is measured against the 09-to-18 calendar. Same organization, two calendars, ticket-by-ticket routing.

3. Technician time-off — the argument nobody wants to have

Here is the question that will show up in an SLA review meeting sooner or later: a P2 ticket was assigned to Ayşe on Friday afternoon. Ayşe took the following Monday off as annual leave. The SLA clock kept running. She resolved it Tuesday morning, four business hours after her return, and the report says she breached. Is that fair?

Two schools of thought:

1. The customer's perspective. The customer does not know or care that Ayşe was on leave. The SLA promises a response in X business hours; the response was late; the SLA breached. Root cause: routing should have moved the ticket off Ayşe when leave was requested.
2. The team's perspective. If technician time-off does not pause the SLA, then service desks with high vacation utilization look artificially worse than desks that discourage vacation. That is a perverse incentive.

Our recommendation, and the model we build for by default:

• Technician time-off does not pause the SLA on the assigned ticket.
• Instead, the calendar system triggers a re-assignment when a technician's leave begins with active tickets in their queue.
• The re-assigned ticket keeps its original SLA and its original clock.
• The manager gets a warning at leave-request time if the technician has tickets whose SLA target falls inside the leave period.

This forces the correct behavior: leave planning is a management responsibility, and the SLA report reflects the customer's experience, not the internal staffing arrangement. The team's incentive is preserved because the tickets are moved, not because the clock is paused.

4. Silent hours per user

A separate but adjacent concept: some organizations want to promise a customer "your ticket will get a response within four business hours" while also promising the technician "you will not receive push notifications between 22:00 and 07:00, even if the SLA calendar is running." Modern ITSM has to model these separately.

The distinction:

• SLA calendar = the business's promise to the customer. Governs when the clock runs.
• Notification calendar per user = the technician's personal push/email preference. Governs whether the phone buzzes.

These will conflict. A P1 incident opened at 03:00 on a 24/7 calendar is a genuine breach if nobody picks it up. If every on-call technician has notifications silenced, the ticket sits until 07:00 and the customer's four-hour clock expires. The answer is not to fold the two concepts together; it is to model on-call rotation as a distinct calendar that overrides personal silent hours during the on-call window.

5. Multi-region and time zones

An organization with offices in Istanbul, Ankara, and London does not have one business day — it has three overlapping ones. If the SLA calendar is stored in the server's local time, then daylight-saving transitions will silently break reporting twice a year. If it is stored in UTC, then business hours will appear to shift for users in different zones unless the UI is careful.

Our rule: all calendar entries are UTC in storage, and every calendar carries its own display time zone. The SLA calculation runs against UTC; the UI renders against the calendar's time zone. Users in a different time zone still see the correct opening hour for the calendar they are looking at.

A P1 raised at 08:55 Europe/Istanbul against an Istanbul calendar is inside business hours. The same ticket, if raised at 08:55 Europe/London against the London calendar, is not yet inside business hours (London opens at 09:00 GMT = 11:00 Europe/Istanbul in winter, 12:00 in summer). Routing is what decides which calendar applies.

6. Emergency change windows

Change management adds one more wrinkle. An emergency change to a production system may require the service desk to pause the SLA on any ticket whose resolution depends on that system. This is the one legitimate case for a manager-initiated SLA suspension.

The rule we implement:

• An emergency change is a first-class object with a start and end window.
• Any ticket flagged as depends on CI X where CI X is affected by the change has its SLA clock paused for the duration of the change window.
• The pause is logged with the change ID, so the audit trail shows exactly which ticket was paused for which change.
• When the change closes, all paused tickets resume automatically.

This is not a way to hide breaches. It is a way to model the fact that resolution was genuinely impossible during a controlled outage.

Putting it together

The full calendar model, at the level of entities, looks like this:

These are separate concerns, and they interact in predictable ways. The SLA calculation reads WorkCalendar plus WorkCalendarHoliday plus WorkCalendarOverride plus SlaPauseWindow. The notification layer reads OnCallRotation plus UserSilentHours. Reporting can slice by calendar, by pause reason, or by breach cause — because each piece of information is stored, not inferred.

Why this matters for reporting

A well-designed calendar answers the question that always comes up on the second or third quarterly review: why did ticket #4728 breach? The answer has to be more than "it did." Ideally, opening the ticket shows the SLA panel, and the panel shows exactly which calendar was applied, which windows were open, which pauses occurred, and how many business minutes elapsed before response. If the pause was change-driven, the change ID is linked. If the technician was on leave and the ticket was re-assigned, the re-assignment shows in the timeline.

The point of modeling this correctly is not perfectionism. It is that SLA reports get scrutinized. When the CIO asks why the P2 compliance number dropped, the operations team either has a defensible answer, complete with the specific tickets, calendars, and pauses that drove the change — or they do not, and the SLA report becomes an object of doubt rather than a tool.

The LinaDesk implementation, briefly

LinaDesk models each of the entities in the table above as first-class Domain aggregates. WorkCalendar is the anchor; WorkCalendarHoliday and WorkCalendarOverride are child records; SlaPolicy references a WorkCalendarId. The SLA computation is a pure function of a ticket's status transitions and the calendar entities visible at each transition. Because pauses are stored as explicit records, replaying the SLA calculation for any historical ticket produces the same answer today as it did the day it was closed — which is what audit teams want, and which is not true of ITSM systems that recompute against the current calendar.

The Ramazan Bayramı ticket at the top of this post, in this model, is not a breach. The ticket is opened at 16:55 on the last business day before Bayram. The WorkCalendarHoliday for the four Bayram days sets the calendar to closed. The SLA clock only ticks the five business minutes remaining before 17:00 that Friday, then resumes at 09:00 on the first business day after Bayram. The response window survives.

Related reading

• Why on-premise ITSM is having a moment in 2026
• Migrating from ManageEngine Service Desk Plus — a field guide
• LinaDesk vs ServiceNow, ManageEngine, Freshservice — comparison table
• LinaDesk Security & Compliance