A red clock beside a ticket does not by itself explain a delay. The team may have been waiting for a customer photo, an automated message may have counted as a response, or reassignment may have changed the calculation. When buying support automation, define what the clock measures and what action it triggers.
Start with one or two operationally meaningful measures. First response differs from resolution, and customer waiting time can differ from employee working time. Do not buy a large dashboard before you can explain the calculation for one ticket from its event history.
A ticket story with a clear owner
In a fictional appliance service center, a customer submits an issue and an employee requests a photograph of the device number. The ticket waits for the customer. After the photograph arrives, the visits team must arrange an appointment. The customer later reopens the ticket because the appointment was not confirmed. This is a proposed workflow, not a service-level commitment announced by Nextwave.
Assign follow-up ownership at each stage even if another team receives a subsidiary task. Distinguish transferring responsibility from sending a request for help. An alert addressed to a group without a named person or understood queue may work technically while the issue makes no progress.
An event worksheet instead of “automatic escalation”
| Event | Clock decision | Follow-up decision |
|---|---|---|
| Issue created | Start the measure under its definition and approved calendar. | Assign priority, owner and queue. |
| Information requested | Does one measure pause? Which continues? | Record the request and follow-up owner. |
| Customer replies | Resume or begin measurement under its definition. | Return the ticket to a known owner. |
| Target approaches or is exceeded | Show remaining time or extent of breach. | Define action, recipient and follow-up interval. |
| Team or priority changes | Document the effect on the calculation. | Assign the new owner and record the reason. |
| Resolved then reopened | Resume measurement or start a new target? | Review the return reason and assign it. |
Not every clock must pause while waiting for a customer or restart when status changes. The requirement is a definition matching your chosen commitment, with confirmation that the product, plan and configuration can implement it. Write exceptions alongside the rule rather than relying on the state name.
Working hours need a calendar
Are you measuring continuous elapsed time or a particular team's working hours? Specify time zone, working days, holidays and treatment of a ticket arriving shortly before closing. If teams serve different markets, define which calendar applies rather than inferring it solely from the customer's country.
Zendesk documentation describes response, update and resolution targets and the use of business or calendar hours. Jira Service Management explains conditions for starting, pausing and finishing measurement. These are configurable mechanisms, not automatic commitments to particular service times. Metric meanings and behavior also vary by product.
Priority needs a reviewable decision
Do not make a customer's word “urgent” an unexplained rule. Agree suitable priority inputs and who can change priority and why. Ask how a change affects the running target: does it retain elapsed time or apply another calendar? The implementer should explain the actual selected solution's behavior.
Also define which response counts. An automated acknowledgement may not mean an employee understood the problem. Request a test including an automatic message, an internal reply and a customer-visible reply. Check what enters the calculation instead of assuming every message stops the clock.
Validate a short, known timeline
Prepare an approved test calendar and known creation, response, waiting, resolution and reopening times. Calculate expected results with the process owner before running the test, then compare them with the platform. Do not apply short experimental targets to a live queue sending real alerts to employees or customers.
Test escalation itself next: who received the task, can they access the context, what happens without action, and how are unnecessary repeated alerts avoided? Request a record linking event, rule, action and result, with a way to review exceptions after launch.
The customer service automation scope worksheet distinguishes subscriptions from implementation work. When discussing support automation with Nextwave, send the event worksheet and timeline. They reveal what needs configuration and what requires a team decision before estimation.
Metric sources
The Zendesk SLA policy guide and Atlassian SLA conditions guide were opened on 3 November 2026. They support distinctions between targets and calculation conditions, not availability in every plan or a claim of successful real customer service.
