AI Support Reports: Name the Clock Behind the Reply Time

Your support report says a customer received a reply within two hours. The customer says they waited all weekend. Both statements can be accurate if the report counts business hours while the customer counts the time between sending a request and receiving help.

For a small business using AI to summarise support performance, that difference belongs in the headline, not in an obscure note. Before asking whether service is fast enough, establish which clock the report uses and which experience the business intends to improve.

Two clocks can describe the same request

Elapsed time runs continuously between the chosen start and finish. A business-hours measure counts only the portions that fall within a specified support schedule. The schedule is part of the calculation, so “two hours” without its basis leaves the result incomplete.

Zendesk’s reporting documentation states that it stores both calendar-hour and business-hour values in ticket data and provides a business-hours first-reply metric. The existence of both measures is useful: they answer different questions about the same service interaction.

Its schedule documentation explains that a weekly schedule includes a time zone and daily business hours. Configured holidays are treated as outside business hours for those metrics. When reading an exported report, identify the schedule that supplied the result rather than inferring it from the company’s address.

A weekend example with the calculation visible

Consider a fictional design business offering support Monday to Friday, 09:00–17:00, in Europe/London. For this example, there are no holiday exceptions or other clock pauses. A request arrives at 16:30 on Friday 30 October 2026. The qualifying first response arrives at 10:30 on Monday 2 November 2026. Both timestamps are in GMT.

The business-hours total is straightforward:

• Friday 16:30–17:00 contributes 30 minutes.
• Saturday and Sunday contribute no time under this schedule.
• Monday 09:00–10:30 contributes 90 minutes.
• The total is 120 minutes, or two business hours.

The continuous interval is 66 hours. A direct timestamp subtraction checked that elapsed total for this article; the scheduled portions above sum to two hours. This is an illustrative calculation, not a test of Zendesk, Jira or a real support account.

The business can therefore report “two business hours to first response” alongside “66 hours elapsed”. If its defined target is at most two business hours, this fictional case meets that target. That finding alone says nothing about whether the weekend wait suited the customer’s needs.

Meeting a target is one management question

A business-hours target can help assess a team against the hours it is scheduled to provide support. Elapsed waiting time can help the owner examine the wider service offered to customers. Neither measure should silently replace the other.

Imagine that the fictional customer needed a corrected artwork file for a Saturday event. A Monday response might satisfy the published support-clock target while arriving too late for that particular purpose. This hypothetical does not establish that the business broke an agreement. It reveals a service-design question: is its support availability appropriate for the uses it encourages?

Possible responses include clearer expectations, an earlier submission cutoff, better self-service instructions or a separately staffed urgent route. Those are options to assess against actual demand and available capacity. A favourable target-compliance figure does not select the answer for the owner.

Give an AI summary the clock definition

An assistant preparing a management update needs more than a column labelled reply time. Supply the unit, clock basis, schedule, time zone and reporting period. Also define the event that starts the clock and the event that stops it.

A useful instruction would be: “Summarise first-response performance using the supplied business-hours measure. State the support schedule and time zone. Keep elapsed customer waiting time separate where available. Do not infer resolution from a first response, or infer a customer outcome from target compliance.”

Ask the assistant to identify missing fields before comparing teams or periods. If one export uses calendar hours and another uses business hours, a smaller figure does not demonstrate a faster service. First make the measurements comparable or explain why they remain separate.

Read the calendar as an operating rule

Atlassian’s Jira Service Management guidance on SLA calendars describes using calendars to track goals against the times and days agents respond, with a selected time zone. The relevant lesson for an owner is that a calendar is part of how a target is measured, rather than a decorative setting beside the dashboard.

Keep a record of the calendar used for a report, including working days, intervals and exceptions. If the business changes its support schedule, record when the change applies and verify how the reporting system handles it. Do not assume a historical calculation keeps the same meaning after configuration changes.

For the weekend example, adding Saturday support would change the counted interval. The underlying arrival and response timestamps would stay the same. That is why a change in the reported business-hours figure needs to be interpreted alongside any change in the schedule.

Keep acknowledgement, response and resolution distinct

An automated receipt can tell a customer that a request arrived. A response can begin addressing the request. Resolution concerns what happened to the problem. Define which event your own measure counts, and inspect the actual platform rule before interpreting its result.

If an AI-assisted workflow sends an immediate acknowledgement, keep that event visible without automatically presenting it as completed support. Equally, a human message asking a necessary clarification may be a legitimate response without resolving the issue. The classification should follow the documented rule and the evidence in the case.

MaryChuks’ guide to reading an AI service uptime promise examines the broader need to identify what a service measure covers. Here, the particular decision is which periods the response clock includes and how that relates to the customer’s wait.

Use a report that supports a decision

For an owner reviewing support, a compact report can show:

• The response metric, its unit and the schedule used.
• Target compliance under that defined rule.
• Elapsed waiting time, clearly labelled where measured.
• Unanswered requests that have not yet produced a completed response interval.
• The action proposed, the evidence behind it and the person responsible.

Do not let a completed-response report stand in for the whole open queue. Name the population included before drawing conclusions about everyone who requested help. A report becomes more useful when its exclusions are visible.

Return to the customer who waited through the weekend. The business need not choose between defending its team’s scheduled performance and understanding the customer’s elapsed wait. It can record both accurately, then decide whether its hours, promises and support routes fit the service people actually need.

Sources

• Zendesk: reporting first reply time within business hours.
• Zendesk: setting business hours and holidays.
• Atlassian: setting up SLA calendars. Live documentation checked 30 October 2026; these pages are used as configuration guidance, not dated news.