Response SLA Breaching for different Timezones

[Charles Fredie]

Hi All,

I need some help regarding the SLA breach,

A caller from Hong Kong location raised an incident on 19th June, the ticket got assigned to a group  where each member is from US location. Since 19th June was a holiday in US and no member was available to pick that ticket. The response SLA got breached.

The SLA details are below:
Scheduled Source: SLA definition
TimeZone source: Caller's Timezone

I understand that since Timezone source is caller's timezone so it got breached. 
How can I avoid this issue for the next time, Any help or solution on that would be much appreciated

Thanks

[wojasso]

Hi @CharlesFredie

When you let the response SLA derive its schedule and time zone from the caller, the due date is calculated according to the caller’s working hours. In your scenario the incident was raised in Hong Kong on 19 June, but the assignment group was in the US, where that day was a public holiday. Because the SLA was running on the caller’s calendar, it continued counting time even though the support group was not working and the result was a breach.

To prevent this situation you need to align the SLA’s calendar and time zone with the support team rather than the requester. A few options:

• Use the assignment group’s schedule/time zone. In the SLA definition set Schedule source to “Assignment group” (or “Assigned to”) so the engine uses that group’s calendar. Then set Time zone source to “Schedule’s time zone” so holidays and local working hours are honoured for that group.
• Specify a dedicated schedule. Create a schedule that matches the US support group’s working hours and assign it directly in the SLA. This ensures that holidays such as Juneteenth are excluded regardless of who opens the ticket.
• Create separate SLAs for different regions. If you have teams in multiple time zones, define individual SLAs per region and attach them based on assignment group or service so that each group is measured against its own calendar.
• If you prefer to keep the caller’s calendar for some metrics, you can override it at runtime via a custom condition script or by returning a different schedule in the Schedule source Script Include. This requires scripting but gives you full control.

After changing the SLA definition, test it against incidents in each region to confirm that the due dates honour the appropriate holidays. Setting the right schedule and time zone sources is the supported way to avoid cross‑time‑zone breaches.

This response was drafted with the help of AI and briefly reviewed by a human. Please excuse any errors or formatting issues.

💥 Was this answer useful? 👉 If so, click 👍 Helpful 👍 or Accept as Solution ✅ 💡🛠🧠🙌