The clock is the whole argument
Every service-level target is really two decisions wearing one label. The first is the number, such as a first reply within four hours. The second is quieter and matters more: which hours count. A ticket that arrives at ten at night and gets answered at nine the next morning has either breached a four-hour target badly or met it comfortably, and nothing about the ticket decides which. The clock does.
Out of the box the clock runs continuously. Elapsed time is the plain difference between when the ticket was created and now, which means overnight, weekends and public holidays all count against you. For a team with round-the-clock coverage that is exactly right. For the far more common team that works ordinary weekday hours, it produces a dashboard full of red badges that record nothing except the passage of the night.
The cost of that is not cosmetic. Once a breach badge means nothing, people stop reading it, and then the badge cannot warn you on the day something has genuinely gone wrong.
The targets you are measured against today
Before changing how time is counted, it is worth knowing what is being counted against. Each site starts with a set of defaults per priority, and they are deliberately conventional: low priority allows a day for the first response and three days to resolve, normal allows four hours and a day, high allows an hour and eight hours, and urgent allows fifteen minutes for the first response and four hours to resolve.
Those are starting points, not rules handed down. The SLA policy screen in the dashboard lets you set your own first-response and resolution targets per priority, and most teams should, because the defaults were chosen to be recognisable rather than to describe your team.
Two behaviours are worth knowing while you are in there. A ticket moves into a warning state once only a quarter of its target remains, so a warning is an early signal rather than a near miss. And the targets apply from ticket creation, not from the moment somebody picked it up, which is the honest way round but does mean an unassigned queue burns real target time.
What the business calendar changes
The business calendar replaces plain subtraction with counted time. Instead of asking how many minutes have passed, the clock asks how many of those minutes fell inside your opening hours, and ignores the rest. A ticket that arrives on Friday evening with a four-hour target is not in trouble on Saturday morning; it has consumed no target time at all, and it starts consuming it again when Monday opens.
You configure it as a weekly grid, one row per day of the week, each with an opening and a closing time. A day whose closing time is not later than its opening time is treated as closed, which is how you mark weekends. If you have never touched the page, the calendar behaves as Monday to Friday, nine to five, which is also what most teams migrating from another helpdesk are used to.
Alongside the grid sits a holiday list. Any date on it is skipped entirely, exactly as if that day were closed, which is what makes a bank holiday stop distorting a whole week of reporting.
The switch is not on the calendar page
Here is the step that most often makes people think the feature is broken. Filling in the calendar does not, by itself, change any SLA badge. Calendar-aware timing is a separate switch, and it lives with the other feature flags rather than on the calendar screen, because turning it on changes every badge for every agent at once. That is a rollout decision, not a save button.
It is off by default, deliberately, so that an existing team's numbers do not shift under them without anyone choosing it. The calendar page shows a banner when the flag is still off, which is the fastest way to check where you stand. The order that works is: fill in the week, add the holidays you already know about, confirm the grid says what you meant, and only then flip the switch.
Do it in that order and the change is a single visible step you can announce. Do it the other way round and the team spends a day working against a default week you had not reviewed.
Everything is stored in UTC
This is the caveat to understand before you type any numbers in, because it is the one that silently produces a wrong answer. The opening and closing times are stored and evaluated in UTC. They are not translated into your local time, and the holiday dates are UTC dates too.
If your team sits in a UTC region, there is nothing to do. If you do not, translate your hours before you enter them: a team working nine to five in a region an hour ahead should be entering eight to four. The same translation applies to the holiday list, and to any day whose hours straddle midnight UTC once translated, which is where teams in the Americas and the Asia-Pacific region need to take particular care.
Remember also that a region observing daylight saving changes its offset twice a year while the calendar does not. If your local hours are fixed, your UTC hours are not, and the grid needs revisiting when the clocks change. Putting that on the same reminder as the annual holiday refresh is the cheapest way to keep it honest.
The displayed timestamps you will be checking these hours against have a related trap of their own, in the opposite direction: they follow whatever your account believes about daylight saving, which a stored offset alone cannot express. Why your timestamps need a region, not just an offset is worth reading before you conclude the calendar is misbehaving.
Holidays are single fixed dates
The holiday list is a list of specific dates with labels, not a set of recurring rules. Each date is added once, applies once, and does nothing the following year — there is no stored every-fourth-Thursday-in-November rule that keeps firing.
You do not have to type them all in by hand, though. There are holiday presets for US, UK and EU calendars that fill in a year's worth at once, resolving the moving dates correctly for whichever year you apply them to. What they do not do is roll forward on their own: a preset is applied to one year at a time, so next January somebody still has to apply it again. Note too that the UK preset deliberately leaves out Good Friday and Easter Monday, which you have to add yourself.
That is easy to live with as long as somebody owns it. The pattern that works is to add next year's dates in the same sitting as this year's, label them with names your team recognises rather than official ones, and include the days you close that are not public holidays at all: a company offsite, an all-hands afternoon, the quiet week between Christmas and New Year if you genuinely close it.
The failure mode is not dramatic, which is why it goes unnoticed. A year later the list has quietly emptied, the clock runs through a national holiday, and the first sign is a Monday morning of breach badges nobody can explain.
What to check the week after you turn it on
Expect the numbers to move, and expect them to move in the direction of looking better. That is not the feature flattering you; it is the removal of hours you never claimed to be working. Still, check a handful of specific things before you trust the new picture.
- A weekend ticket. Open one created on a Saturday and confirm its remaining time did not fall over the weekend.
- An overnight ticket. The evening arrival should be untouched until the morning opens.
- A holiday you have already listed. If it still counts, the date is probably in local rather than UTC form.
- Your reporting. Comparing a calendar-aware month against a wall-clock month is comparing two different measurements, so note the switch date wherever you keep your reporting and say so when you present the trend.
One behaviour is worth knowing because it is invisible when it happens: if the calendar cannot be read for any reason, the clock falls back to plain elapsed time rather than failing. Badges keep rendering, which is the right call, but it does mean a sudden return to overnight breaches is a signal to check the configuration rather than the team.
What to measure
Track breach rate before and after the change as two separate series rather than one line with a step in it, and keep both visible for a quarter. Anyone who joins later and sees only the combined chart will read the step as an improvement in service, which it is not.
Then watch the measure the calendar cannot flatter: time to first response measured from the next moment you were open. If that number is drifting upward while your breach rate improves, the calendar is hiding a real staffing problem rather than removing a false alarm, and the arrival curve at your opening hour is usually where the answer is.
Finally, review the calendar itself on a schedule rather than on demand. Hours change, teams move region, holidays expire. A calendar reviewed twice a year stays a description of your team; one that is never reviewed becomes a slowly widening piece of fiction that your SLA reporting sits on top of.
The switch itself lives with the other per-site flags, and the model behind them is explained in feature flags in your live chat workspace.