Zendesk Business Hours Reporting

Your team works 9 to 5, Monday to Friday. A ticket arrives Friday at 4:50pm and gets a reply Monday at 9:05am. Did that customer wait 15 minutes or 64 hours?

Both answers are correct, and Zendesk stores both. Which one you put on a dashboard decides whether the team looks excellent or negligent — and most reporting arguments in support ops trace back to two people quoting the same metric on different clocks.

Business hours reporting is not a nice-to-have refinement. It is the difference between a first reply time your team believes and one they explain away. But it only works if the schedule underneath it is right, only six metrics support it, and the way Zendesk applies schedules to a ticket has a wrinkle that produces numbers nobody can reconcile.

What this guide covers

• Exactly which Explore metrics have a business-hours variant, and what to do about the ones that do not
• How schedules get applied to tickets, and why two metrics on the same ticket can use different schedules
• How holidays behave in reporting
• How to report on tickets created outside business hours, which is a different problem entirely
• When calendar hours is the honest choice

For the concept, see business hours vs calendar hours. This page is about making it work in Explore, and it sits underneath most of the timing reports in the support metrics dashboard.

Only six metrics have a business-hours variant

This is the constraint that shapes everything else. In the Support - Tickets dataset, exactly six duration metrics ship with a - Business hours version:

Each comes in minutes and hours. Everything else in Explore is calendar-only.

That list is shorter than most teams assume, and the omissions matter. Reply time and next reply time — follow-up speed after the first response — have no business-hours variant. Neither does time to first assignment. If you build an SLA-style internal target on any of those, you are measuring in calendar hours whether you meant to or not, and overnight gaps will land in the number.

Two ways to handle it. Restrict the report to tickets created and closed inside your working window, which is clean but discards data. Or accept calendar hours for those metrics and say so on the chart. The second is usually better: a footnote is cheaper than a metric people quietly distrust.

How a ticket gets a schedule

Every ticket has a schedule, whether you configured one or not. The first schedule in your list is the default and applies to all tickets. On Enterprise plans you can create more, but a second schedule does nothing on its own — you route tickets to it with a trigger using the Ticket: Set schedule action, with conditions on organization, group, brand, or whatever matches your regions.

This is the most common misconfiguration we see. A team sets up EU and US schedules, never builds the routing triggers, and every ticket keeps riding the default. The business-hours metrics look fine, they are simply all measured on one region’s clock. To check a specific ticket, open its audit trail and look for the schedule event.

Getting this wrong is expensive in a way that is hard to see: your overnight regional queue looks slow because it is being measured against hours it does not work.

The wrinkle: two metrics, two schedules, same ticket

Here is the detail that causes reports to disagree, and almost nobody knows it.

Zendesk has two kinds of duration metric, and they treat a schedule change differently:

• Single-event metrics — first reply time, first resolution time, full resolution time. These record one value for the whole ticket, using the schedule in force at the time of the relevant event, applied across the entire duration.
• Multi-event metrics — requester wait time, agent wait time, on-hold time. These accumulate across the ticket’s life, capturing the schedule at each status change and never recalculating earlier events. A single ticket’s total can therefore blend several schedules.

So if a ticket moves from the EU schedule to the US schedule mid-life, its first reply time reflects one schedule and its requester wait time reflects both. Add those numbers up across a queue and they will not reconcile, and no amount of re-filtering will make them.

Practical consequences:

1. Do not mix single-event and multi-event business-hours metrics in the same arithmetic. They are measured on different clocks by design.
2. Be careful re-routing schedules on live tickets. Every reassignment adds a seam to the multi-event metrics.
3. When numbers refuse to reconcile, switch to calendar hours. Zendesk’s own guidance for business-hours discrepancies is to fall back to calendar hours, and that is the right instinct — calendar hours has no schedule dependency, so it cannot be wrong in this particular way.

If your account has one schedule and never changes it, none of this applies and business-hours metrics are simply better than calendar ones. The wrinkle only bites multi-schedule accounts.

Holidays are already handled — and invisible

Any report based on business hours automatically treats scheduled holidays as outside business hours. You do not need to do anything, and there is a real benefit: a public holiday no longer looks like a team-wide performance collapse.

The limitations are worth knowing before you rely on it:

• You cannot report on holidays alone. There is no attribute that isolates holiday time; it is simply excluded.
• Holidays only go two years ahead, so this is a recurring calendar task.
• There is no recurring holiday. Every year needs adding by hand.
• No partial-day holidays. A half-day close is either a full holiday or a schedule edit.
• Holidays are per schedule. Multi-region accounts need each schedule’s holidays maintained separately.

The failure mode is boring and common: someone stops maintaining the holiday list, business-hours metrics quietly start counting a national holiday as working time, and a seasonal dip in the numbers gets blamed on staffing. If you review one thing on this page annually, make it the holiday list.

Reporting on when tickets arrive, not how long they took

“How many tickets arrive outside business hours?” is a different question, and the six metrics above cannot answer it. Those measure elapsed working time; this one is about arrival timing.

Explore has no ticket attribute for “created inside my schedule,” so you build one as a calculated attribute using day-of-week and hour:

IF (IN([Ticket created - Day of week],ARRAY("Monday","Tuesday","Wednesday","Thursday","Friday"))
    AND IN([Ticket created - Hour],ARRAY(9,10,11,12,13,14,15,16)))
THEN "In hours"
ELSE "Out of hours"
ENDIF

Two things to get right.

The hour list is inclusive of the hour it names. Hour 16 covers 16:00–16:59, so a 9-to-5 window is hours 9 through 16, not 9 through 17. Off-by-one here is the most common mistake in this formula.

Explore renders time in the viewing user’s timezone. The same report shows different results to a colleague in another region — which means an out-of-hours report can be quietly wrong for everyone except its author. If your team is distributed, agree one reporting timezone and state it on the chart. Zendesk reporting for distributed teams covers the broader version of this problem.

If your schedule varies by day, extend the formula with OR clauses per day. Then pair the result with the Zendesk after-hours ticket report and Zendesk peak hours report to turn arrival timing into a coverage decision.

Which clock for which audience

Choose by who is reading, not by which number is flattering.

The fourth row is the one worth dwelling on. A team hitting every business-hours target can still generate bad CSAT, because a four-hour business-hours reply to a Friday evening ticket is a Monday morning reply to the customer. Business hours measures fairness to your team; calendar hours measures the customer’s experience. When they diverge, you have a coverage problem, not a performance problem — and only the calendar-hours view will show it. See why fast first reply time does not always mean fast support.

Setting up the schedule so reporting works

Reporting quality is downstream of configuration. Five constraints to design around:

• Intervals are 15-minute increments and each must be at least an hour.
• Intervals cannot span midnight. Overnight coverage needs two intervals — 22:00 to midnight, midnight to 06:00.
• The schedule timezone is the metric’s clock, not the viewer’s and not the agent’s.
• The default schedule is the first in the list. Reordering changes which tickets fall back to what.
• Set the schedule early in the ticket’s life, ideally at creation, so single-event metrics capture the intended one.

A last sanity check that catches most problems: build a report of first reply time - business hours, filter to the top decile, and read a few tickets. If a ticket shows two minutes of business-hours time but the customer clearly waited a weekend, the schedule is doing its job. If a ticket shows business-hours time accruing at 3am, the schedule, its timezone, or its routing is wrong.

Common mistakes

• Assuming every metric has a business-hours variant. Only six do; reply time, next reply time, and assignment time are calendar-only.
• Creating extra schedules without routing triggers. Every ticket stays on the default until a trigger moves it.
• Letting the holiday list lapse. Holidays get counted as working time and a seasonal dip looks like a staffing failure.
• Mixing single-event and multi-event business-hours metrics in one calculation. They can use different schedules on the same ticket.
• Off-by-one hour lists in the created-in-hours attribute. Hour 16 covers 16:00–16:59.
• Ignoring viewer timezone on arrival-timing reports. Distributed teams see different numbers from the same report.
• Reporting business hours to customers and executives. They experience elapsed time; business hours reads as an excuse.
• Using business hours to hide a coverage gap. If the calendar-hours number is bad and the business-hours number is fine, the finding is the gap.

Where this fits in your reporting

• How to report first reply time in Zendesk — the metric this matters most for
• Zendesk requester wait time report — a multi-event metric
• Zendesk agent wait time report — separating customer delay from team delay
• Zendesk after-hours ticket report — arrival timing and coverage
• Zendesk Explore calculated metrics — building the created-in-hours attribute
• Zendesk SLA report — where schedules meet policy targets
• support metrics dashboard — the hub

FAQ

Which Explore metrics support business hours? First reply time, first resolution time, full resolution time, requester wait time, agent wait time, and on-hold time — in minutes and hours. Everything else is calendar hours only.

Do business-hours reports account for holidays? Yes, automatically. Scheduled holidays are treated as outside business hours. You cannot report on holiday time in isolation.

Which schedule does a ticket use? The default schedule — the first in your list — unless a trigger applies another. Check a specific ticket in its audit trail.

Why do two business-hours metrics on one ticket disagree? Single-event metrics apply one schedule to the whole ticket; multi-event metrics capture the schedule at each status change and can blend several. Use calendar hours if you need them to reconcile.

Can I report on tickets created outside business hours? Not natively. Build a calculated attribute from ticket created day-of-week and hour, and fix a reporting timezone before you share it.

Should SLAs use business or calendar hours? Match the promise you made the customer. A 24/7 commitment needs calendar hours; a working-hours commitment needs a correct schedule to be fair.

Do I need Enterprise for this? No — business-hours metrics work with a single schedule on lower plans. Multiple schedules require Enterprise.

See first reply time on your schedule, not a spreadsheet’s - start free