SLA working hours in Latch make response and resolution clocks follow your actual support schedule. Set the working days, daily support window, and time zone. Outside that schedule, the SLA clock pauses.
A high-priority ticket lands on Friday at 4:45 pm. The support schedule runs Monday to Friday, 9 am to 5 pm. A continuous clock shows a wait of over sixty hours by Monday morning.
The team has logged fifteen minutes of service time.
That is not a missed deadline. That is a clock that never paused.
How SLA Working Hours Pause the Clock
Enable Count working hours only to define which business hours count towards the SLA.
Choose:
- the working days
- the time zone
- the daily start and end time
With a Monday-Friday, 9 am-5 pm schedule, a Friday ticket consumes the remaining Friday minutes. The clock resumes when the next working window begins.
Latch uses the same working-hours schedule for:
- first-response time
- resolution deadlines
- SLA report durations
- at-risk windows
- breach time
The deadline and the report share one definition of elapsed service time.
Why Business-Hours SLA Calculations Matter
An SLA pairs two decisions: the time allowed and the business hours that count. Many reports surface the first and bury the second.
A four-hour resolution target means one thing against a non-stop clock and something else against scheduled hours. Nights and weekends can turn expected downtime into apparent breaches.
That creates familiar arguments:
- Operators dispute reports that penalise closed hours.
- Managers lower targets to offset a clock that never stops.
- Customers see an inconsistent promise.
- Teams compare queues across time zones without adjusting for the schedule.
The target is not the whole SLA. The support schedule is part of the policy.
Configure SLA Working Hours by Time Zone
A time like "9 am" is incomplete without a zone. A London team and a Nairobi team can display the same window but operate on different clocks. Latch stores the zone with the schedule, so the SLA follows the support operation, not the browser or server location.
This matters when managers review performance across locations. Each report should reflect when that support schedule is active, not whichever machine happened to calculate the timestamp.
Set Priority-Based SLA Targets
The support-hours clock defines when time counts. Priority targets define how much time each type of work gets.
Latch lets administrators set:
- an overall SLA attainment target
- a first-response attainment target
- a first-response time in minutes
- separate attainment and resolution targets for Critical, High, Medium, and Low priority work
A critical outage deserves a tighter target than a routine request. The report compares actual time with the target for that priority.
A single average can hide serious misses among routine work. Priority-based SLA targets show where the service promise is breaking.
Existing SLA Deadlines Remain Unchanged
Changing the schedule does not rewrite history. The working-hours clock applies only to new SLA deadlines. Existing deadlines stay. Manually set deadlines stay.
That boundary keeps a policy change from moving the target for work already in progress. Teams get a better clock without retroactively altering the commitment on an existing case.
What the Support Schedule Does Not Cover
This is a repeating weekly support schedule: selected working days, one daily window, and one time zone.
It is not a holiday calendar. It does not define different hours per day, model follow-the-sun rotations, or replace an escalation policy. Teams that need those still require a fuller coverage model.
For many support operations, the weekly schedule is the important first fix. It removes the largest source of false urgency without making the policy hard to understand.
Build More Accurate SLA Reports
First response is useful, but it is only one view of queue health. Aging, blocked work, rework, and outcome quality still matter. Queue health metrics beyond first response time covers the broader operating picture.
The working-hours clock makes the SLA part of that picture more credible. Operators see real deadlines. Managers see which priority is missing its target. Closed hours stop looking like a service failure.
Accurate time also depends on clear ticket states and ownership. Hard-edged ticket status workflows keep reporting tied to meaningful operational events instead of loose labels.
For teams building a broader support operating model, Latch brings these controls into one operational workflow system.
An SLA should measure the service the team agreed to provide.
It should not measure the hours when nobody was scheduled to provide it.