Most complaints about slow support are really complaints about not knowing. Someone who's told "we usually answer within four hours" waits calmly; someone who's told nothing writes again after twenty minutes.
In your project's Operating hours settings, you'll find the basics: a Show online status switch that controls whether availability is shown at all, the reply-time message shown during office hours, and an out-of-office message for when you're closed.
Write the reply time as something you can keep on a bad day, not on a good one. Customers remember the promise, not the average.
Each team can have its own operating hours, with its own timezone and opening times per day. A team can also be marked as always available, which suits an on-call rota that doesn't follow office hours.
The timezone matters more than people expect. A team set up in one office's timezone appears offline at odd moments once someone joins from elsewhere.
Teams can also override the reply-time and out-of-office messages. Anything not set falls back to the project, so you only fill in what genuinely differs.
Individual days can carry their own reply time as well. This is the honest way to handle a Friday with half the team, or a Monday morning when the weekend's backlog is being cleared — rather than publishing one optimistic figure and missing it twice a week.
Separately from what customers are told, a team can carry a default service-level target — the time within which a conversation should get a first response. Leave it empty and the team uses the project's setting.
This is the internal number, and it's what compliance is measured against in reports. It's worth setting it to something you actually intend to hold: a target nobody meets stops being read after the second week.
Keep the two consistent. Promising an answer within four hours publicly while measuring against eight internally means your reports look healthy at exactly the moment your customers are unhappy.
