Follow-the-Sun Coverage With a Single Business-Hours Calendar
Acme Support runs three hubs: New York (28 agents), Berlin (14), and Manila (20). The Freshdesk account timezone is America/New_York and the only business-hours calendar is Mon–Fri 09:00–17:00 New York time, with US holidays. The Manila team works 09:00–18:00 Manila time, which is 21:00–06:00 the previous day in New York. APAC tickets are created while the NY calendar is closed, so a 4-business-hour first-response SLA shows a due time of 13:00 New York the next day - roughly 20 hours after the customer wrote in. APAC CSAT is 3.9 versus 4.6 in the US, and 180 APAC tickets are older than two days. The VP wants to 'cut first response to one hour' to force faster replies. You are asked to fix the root cause before changing any SLA target and to avoid creating false breaches for agents who are legitimately offline.
1. Before changing the SLA target, what evidence would you pull, and what does it tell you about whether this is a calendar problem, a staffing problem, or both?
Read the worked answer
Start by joining 60–90 days of ticket data to the business-hours calendar and the group. For each APAC ticket, compare four timestamps: created, first public agent reply, SLA due, and breach. Segment by hub, shift, priority, and whether the ticket was ever Pending.
If tickets are created during Manila hours but first replies also happen during Manila hours, yet the SLA due time is the next New York morning, the calculation is the problem: the clock is only running during America/New_York 09:00–17:00. If first replies are slow even inside the Manila shift, you have a staffing or triage problem. If many tickets sit Pending, you have a status problem.
Also check which business-hours calendar is attached to the SLA policy and whether APAC holidays are present. The evidence should distinguish 'we set an unrealistic target' from 'the clock does not represent the agents' working day'. Do not cut the target to one hour before this segmentation, because that would create false breaches for US tickets and encourage agents to game status.
2. Recommend a configuration approach. Address multiple calendars vs. a 24/5 calendar, holiday handling, and the VP's one-hour proposal.
Read the worked answer
Preferred fix: use multiple business-hours calendars if your plan and SLA configuration support them. Create an APAC calendar (Mon–Fri 09:00–18:00 Manila, with Philippine holidays), an EMEA calendar, and a US calendar; attach the correct calendar to the SLA policy for each group, or use separate SLA policies scoped by group. If the account can only have one calendar, a 24/5 calendar is the fallback: it stops the clock from being artificially closed, but you must then use priority-based targets and accept that regional holidays need a separate mechanism.
Do not accept the one-hour global target. It would apply to all tickets, including US tickets raised at 16:00, and would either cause mass breaches or push agents to set Pending. Instead, keep a realistic 4-business-hour target for P1/P2 in the correct calendar and measure 'first reply within shift' as an operational metric.
Validate in sandbox with 50 historical APAC tickets: replay due times, compare old vs new, and confirm no false breach. Then pilot with the Manila group for two weeks and monitor CSAT and breach reasons.