Start with three separate questions: How long did completed first replies take? Which tickets still await a first human reply? Which tickets remain unresolved? Those groups overlap differently, so give each its own label and supporting ticket IDs.
Define the timer before calculating it
This original exercise measures calendar minutes from email-ticket creation to the first human public reply. Its snapshot is October 13, 2026, at 12:00 UTC. All listed events occur on that date in UTC. The records and statuses are fictional; they contain no customer identities.
| Ticket | Created | Other event | First human public reply | Snapshot status |
|---|---|---|---|---|
| T1 | 09:00 | None supplied | 09:20 | Open |
| T2 | 09:10 | Bot reply at 09:11 | 09:50 | Pending customer |
| T3 | 10:00 | No human reply supplied | — | New |
| T4 | 10:30 | Solved at 10:45 | 10:40 | Solved |
T2's bot event does not stop this exercise's explicitly defined human-reply timer. T4's solved event is a different endpoint from its first reply.
Zendesk's documentation describes first reply as ticket creation to the first public agent response and distinguishes calendar from business hours. It also documents channel-specific behavior, a legacy autoreply exception and separate SLA rules. This exercise uses its own stated human-public-reply definition; it does not reproduce every platform metric. Check the actual export definition before comparing the two.
Show completed replies with their denominator
The completed first-reply set is T1, T2 and T4, not all four tickets.
- T1: 09:20 minus 09:00 = 20 minutes.
- T2: 09:50 minus 09:10 = 40 minutes.
- T4: 10:40 minus 10:30 = 10 minutes.
Their sum is 70 minutes, and their count is three. The mean is 70 ÷ 3 = 23.333… minutes, displayed as 23.33 if using two decimal places. Sort the values as 10, 20 and 40; the median is 20 minutes.
Put “completed first human replies; n = 3” beside these results. A bare “average response time” label hides both the endpoint and the excluded records. Keep the unrounded value for calculation and round only the display.
Give the unanswered ticket its own view
T3 has waited from 10:00 to the 12:00 snapshot: 120 calendar minutes. Its completed first-reply duration remains missing. Do not substitute zero, and do not insert 120 into the completed-reply mean as though a reply occurred.
The awaiting-first-reply view contains T3 only; n = 1. Show the snapshot beside the elapsed wait so the reader knows when it was measured. A later snapshot changes waiting time; it does not create a reply event.
The unresolved-status view contains T1, T2 and T3; n = 3 under this exercise's listed statuses. T1 and T2 have received human replies but remain unresolved. Consequently, unresolved tickets and unreplied tickets are not interchangeable counts.
Keep resolution and interpretation separate
For T4, creation to first human reply is 10 minutes; creation to solved is 15 minutes. Display both endpoints when inspecting its record. Calling the 15-minute value first reply would answer a different question.
These four records do not establish an SLA result, business-hours performance or an individual agent ranking. No schedule, SLA policy or agent comparison data was supplied. Use the dashboard to locate the unanswered ticket and verify the calculation scope before making a broader operational claim.
Maintain ticket IDs, timestamps, event type and status in the support system or required workbook. The review display should let a reader switch between completed replies and awaiting-first-reply records, with the included IDs and definition changing together. The companion demonstrates this distinction with fixed records; it is not connected to a ticket system.
Copy a first-reply dashboard brief
Create one complete, self-contained US-English HTML companion for “First replies • support review”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Completed replies; Awaiting first reply; Unresolved; All tickets; T1; T2; T3; T4; Recalculate snapshot; Restore 12:00. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Create a customer-service dashboard specification in US English.
Required system or workbook format: [enter]
Ticket IDs, creation timestamps, first human public reply events,
bot events, resolution events and snapshot statuses: [paste sanitized records]
Snapshot timestamp and timezone: [enter]
Declared reply endpoint and calendar/business-time basis: [enter]
Platform export definition and exceptions: [paste or NOT SUPPLIED]
Separate completed first-reply durations, current unreplied waits and
unresolved statuses. Show exact included IDs and denominators. Missing reply
events stay missing, not zero. Exclude them from the completed-reply mean. Calculate mean and median from completed durations; retain full precision
before display rounding. Distinguish first reply from creation-to-resolution. Do not infer SLA results, business hours, agent performance or platform parity.
Return the checked record table, calculation steps and dashboard layout in
the required format. If requested, specify a sanitized HTML review snapshot
with local scope selection and matching labels/IDs. Do not send replies,
change statuses, connect systems, collect records or promise live refresh.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Customer Service Dashboard Template: Keep Waiting Tickets Out of the Completed Reply Average
A ticket with no human reply does not have a first-reply time of zero. It has an unfinished wait. If your dashboard mixes those two values, an unanswered request can make the completed-reply average look faster while the customer keeps waiting.
Start with three separate questions: How long did completed first replies take? Which tickets still await a first human reply? Which tickets remain unresolved? Those groups overlap differently, so give each its own label and supporting ticket IDs.
## Define the timer before calculating it
This original exercise measures **calendar minutes from email-ticket creation to the first human public reply**. Its snapshot is October 13, 2026, at 12:00 UTC. All listed events occur on that date in UTC. The records and statuses are fictional; they contain no customer identities.
| Ticket | Created | Other event | First human public reply | Snapshot status |
| --- | --- | --- | --- | --- |
| T1 | 09:00 | None supplied | 09:20 | Open |
| T2 | 09:10 | Bot reply at 09:11 | 09:50 | Pending customer |
| T3 | 10:00 | No human reply supplied | — | New |
| T4 | 10:30 | Solved at 10:45 | 10:40 | Solved |
T2's bot event does not stop this exercise's explicitly defined human-reply timer. T4's solved event is a different endpoint from its first reply.
[Zendesk's documentation](https://support.zendesk.com/hc/en-us/articles/4408821871642-Understanding-ticket-reply-time) describes first reply as ticket creation to the first public agent response and distinguishes calendar from business hours. It also documents channel-specific behavior, a legacy autoreply exception and separate SLA rules. This exercise uses its own stated human-public-reply definition; it does not reproduce every platform metric. Check the actual export definition before comparing the two.
## Show completed replies with their denominator
The completed first-reply set is **T1, T2 and T4**, not all four tickets.
- T1: 09:20 minus 09:00 = **20 minutes**.
- T2: 09:50 minus 09:10 = **40 minutes**.
- T4: 10:40 minus 10:30 = **10 minutes**.
Their sum is 70 minutes, and their count is three. The mean is **70 ÷ 3 = 23.333… minutes**, displayed as 23.33 if using two decimal places. Sort the values as 10, 20 and 40; the median is **20 minutes**.
Put “completed first human replies; n = 3” beside these results. A bare “average response time” label hides both the endpoint and the excluded records. Keep the unrounded value for calculation and round only the display.
## Give the unanswered ticket its own view
T3 has waited from 10:00 to the 12:00 snapshot: **120 calendar minutes**. Its completed first-reply duration remains missing. Do not substitute zero, and do not insert 120 into the completed-reply mean as though a reply occurred.
The awaiting-first-reply view contains **T3 only; n = 1**. Show the snapshot beside the elapsed wait so the reader knows when it was measured. A later snapshot changes waiting time; it does not create a reply event.
The unresolved-status view contains **T1, T2 and T3; n = 3** under this exercise's listed statuses. T1 and T2 have received human replies but remain unresolved. Consequently, unresolved tickets and unreplied tickets are not interchangeable counts.
## Keep resolution and interpretation separate
For T4, creation to first human reply is **10 minutes**; creation to solved is **15 minutes**. Display both endpoints when inspecting its record. Calling the 15-minute value first reply would answer a different question.
These four records do not establish an SLA result, business-hours performance or an individual agent ranking. No schedule, SLA policy or agent comparison data was supplied. Use the dashboard to locate the unanswered ticket and verify the calculation scope before making a broader operational claim.
Maintain ticket IDs, timestamps, event type and status in the support system or required workbook. The review display should let a reader switch between completed replies and awaiting-first-reply records, with the included IDs and definition changing together. The companion demonstrates this distinction with fixed records; it is not connected to a ticket system.
## Copy a first-reply dashboard brief
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Check T3's missing endpoint and T4's two durations against the maintained records before circulating the results. Keep the support system or workbook as the maintained source, and use the separate waiting view to identify the request that still needs a first human reply.