SLAs
Track response and resolution against the agreed service policy.
StatusNewOpennext 1 days
Agree on the policy before measuring it
A service policy defines the response and resolution targets for a priority, together with its calendar and pause behavior. Admin prepares the version, and a different Support Manager reviews it before use. A manager’s approval applies to the submitted values; changing the target or calendar afterwards requires another reviewed version.
Resolve any permitted VIP priority uplift before choosing the policy for an incoming ticket. The resulting episode retains its approved target and calendar version. If the policy or business calendar is missing, show a configuration exception instead of guessing a deadline. A ticket cannot be described as within its SLA when the service target has not been established.
Approval conditions
Support Manager: Approve submitted SLAPolicies prepared by another actor
Submitted
- SLP-83535 SLAPolicy 362 25
- SLP-20033 SLAPolicy 585 30
- SLP-33615 SLAPolicy 669 30
- SLP-39174 SLAPolicy 306 20
- SLP-53373 SLAPolicy 564 10
SLP-83535
- PolicyCode
- PC-726
- Name
- SLAPolicy 362
- Priority
- Low
- Version
- Rev A
- FirstResponseMinutes
- 25
- ResolutionMinutes
- 80
Approval waits for the support manager.
Understand the service window
The resolution schedule shows service episodes from their intake or reopen time to the computed resolution deadline. These are service windows, not customer appointments. The original deadline remains available alongside the current deadline when eligible pauses extend the window. The team can see when service began and how much permitted working time remains.
Business-minute calculations follow the pinned calendar, including holidays, time zones and daylight-saving changes. Pending time pauses the clock only when the approved policy permits it and the team is actually waiting on the customer. Entering or leaving Pending counts the interval once. OnHold does not automatically receive the same treatment, because it can describe work delayed for a different reason.
StatusOpenPendingOnHold
- TCK-31879: SE-26038, 20 Sep · 14:30 to 20 Sep · 16:30, Open
- TCK-24149: SE-30278, 26 Sep · 10:30 to 26 Sep · 11:00, Pending
- TCK-11071: SE-24763, 19 Sep · 12:00 to 19 Sep · 14:00, Open
- TCK-70535: SE-37362, 18 Sep · 12:00 to 18 Sep · 14:00, Pending
- TCK-62699: SE-67874, 20 Sep · 09:30 to 20 Sep · 10:00, Open
- TCK-83897: SE-37531, 16 Sep · 11:00 to 16 Sep · 12:30, OnHold
Distinguish response from acknowledgment
The first eligible public agent reply establishes first response. An internal note, automated receipt message or customer’s follow-up does not. For email, retain the correlated provider acceptance; for a portal reply, confirm that the response is durably visible to the customer. An uncertain external send cannot be recorded as a completed response simply because the local request was submitted.
Resolution is a separate event with a customer-facing outcome. If the ticket reopens during its allowed window, create a new service episode and preserve the earlier result. Previous deadlines and breaches stay attributable to the episode in which they happened. Restarting work must not erase an earlier service miss or make the initial response appear faster.
no first response atdue today
| Ticket Number | Customer | Priority | Assignee | First Response Due |
|---|---|---|---|---|
| TCK-45042 | CUS-210 | Low | PB | 16 Sep |
| TCK-64221 | CUS-054 | Medium | UJ | 10 Sep |
| TCK-63104 | CUS-233 | High | WC | 16 Sep |
| TCK-82993 | CUS-012 | Urgent | CD | 15 Sep |
| TCK-92206 | CUS-013 | Low | CM | 10 Sep |
| TCK-63234 | CUS-221 | Medium | WE | 14 Sep |
Investigate a breach without rewriting it
A breach records the target, episode and point at which the commitment was missed. The manager acknowledges it with a cause and a follow-up decision. That acknowledgment finishes the review action; it does not remove the breach from attainment or replace its original due time.
Use the reporting view to distinguish elapsed time from eligible business time and compare the same kind of measure across tickets. A report should expose missing configuration and unresolved episodes rather than treating them as successful service. The team can then explain its performance from the actual targets and outcomes behind each result.
Review the working record
Compare a reopened request with its prior episode when investigating a missed target. The service schedule preserves both windows, and the breach record identifies the episode actually measured. Current work and historical attainment should remain understandable together.
Closed service measures retain their episode priority, category and resolution owner. Reassignment cannot rewrite an earlier result. Response and resolution obligations have separate denominators, with missing or unfinished observations visible.
Modules
-
Tickets
Keep the customer conversation with the request.
-
Queues
Route each request to someone who can take responsibility.
-
SLAs
Track response and resolution against the agreed service policy.
-
Knowledge
Give agents useful internal answers close to the ticket.
-
Portal
Let customers follow their own requests with clear updates.
-
Escalations
Move difficult or urgent requests to the right level of support.
Reports
All reportsFirst-Response Time
Median, p75 and p95 elapsed UTC minutes from Episode 1 StartTime to its eligible FirstResponseAt, grouped by frozen initial priority and category. Exclude unanswered observations from duration percentiles and show their count separately.
Resolution Time
Median, p75 and p95 elapsed UTC minutes from each ServiceEpisodes.StartTime to that episode ResolvedAt, grouped by PriorityAtStart and CategoryAtStart. Count distinct resolved episodes; unresolved windows stay separately visible. Elapsed duration includes waiting time; business-calendar SLA target arithmetic is separate.
SLA Attainment
Report first-response and resolution obligations separately for closed episodes. First response applies only to Episode 1 and becomes eligible once answered or its deadline has passed; resolution uses each closed episode. Success requires an eligible completion timestamp on or before the retained deadline. Group by frozen policy, PriorityAtStart, TeamAtResolution and AgentAtResolution with explicit missing buckets. Retain every breach and show not-yet-eligible obligations separately.
Roles and permissions
Owns staffing, queue health and service policy within assigned teams.
Works assigned support requests and escalates specialist questions.
Works specialist assignments and accepts escalations in the assigned team.
Uses a lightweight portal to open and follow their own requests.
Related processes
Approve a service policy
Set service targets that the team can apply and explain.
4 stages · 1 approval
Route a new support request
Move a verified request into an eligible owner’s queue.
4 stages · 0 approvals
Work and resolve a ticket
Keep specialist handoffs and service commitments connected.
4 stages · 0 approvals