Work and resolve a ticket
Keep specialist handoffs and service commitments connected.
4 stages · 0 approvals
Roles and responsibilities
-
Step 1Investigate and respond
Ticket NumberSubjectCustomerPriorityMedium
-
Step 2Escalate when needed
Escalation NumberTicketReasonFrom AgentCustomer Request
-
Step 3Manage the service clock
Ticket NumberCustomerPriorityAssigneeMedium
-
Step 4Resolve the request
Ticket NumberSubjectCustomerAssignee
Process steps
Follow the process from start to finish. Select a step to see who acts and what changes.
Investigate and respond
Review the customer question and the applicable internal guidance. Link an article deliberately when it supports the investigation, keeping the knowledge note and the link private. Prepare a public reply that explains the useful next action without exposing internal diagnostics. An automated acknowledgment or private note does not count as the first eligible agent response.
Escalate when needed
Record the unresolved question and the reason for a specialist handoff, then route it to an eligible L2 agent or manager. The assignment event identifies the new owner. The named recipient acknowledges acceptance; until then, the unacknowledged escalation remains visible to management. Accepting the handoff confirms responsibility and does not resolve the ticket.
Manage the service clock
Keep the ticket state aligned with the actual handoff. Pending pauses eligible time only when the approved policy allows it and the team is waiting on the customer. OnHold does not automatically pause. An approaching target can trigger escalation, while a missed target creates a distinct breach that remains in service history after it is acknowledged.
Resolve the request
Record the customer-facing resolution separately from internal analysis and move the ticket to Resolved. Notify through the configured channel and open the approved reopen window. The resolution belongs to the current episode; completing an escalation or a notification alone cannot supply it. Further customer work during the allowed window creates the next episode while preserving the earlier outcome.
Approvals and controls
0 approvals required in this process
- Concurrent state changes compare the current ticket revision; stale work cannot overwrite a newer customer reply.
- Escalation acknowledgment is restricted to its named eligible recipient and remains distinct from ticket resolution.
- A repeated pauseEscalation or breach event is applied once.
- Breach acknowledgment preserves the missed targetCannot improve the historical attainment figure.
Records and postings
| Stage | Records | Effect |
|---|---|---|
| 1 Investigate and respond | TicketsTicketCommentsTicketKnowledgeLinks | Record investigation and customer reply |
| 2 Escalate when needed | EscalationsAssignmentHistory | Transfer work with a traceable reason |
| 3 Manage the service clock | ServiceEpisodesSLABreaches | Retain accurate targets and breaches |
| 4 Resolve the request | TicketsServiceEpisodesTicketActivityLog | Save an explicit resolution |
Process 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.
Ticket Volume Trend
Tickets per day, week or month by source and initial episode PriorityAtStart/CategoryAtStart. Tickets awaiting valid triage remain a separate untriaged bucket.
Run by an agent
Agent support
Proto cannot approve its own service policy; Proto cannot impersonate a customer or disclose internal diagnostics to them; Proto cannot erase a breach or turn missing CSAT feedback into a score; Proto cannot invent a provider acknowledgment for an unknown result. Required service targets and customer access rules remain enforceable at the API boundary.
# Example after configuration
$ curl -fsSL https://www.erp.ai/skill.md | paste into your agent
› work and resolve a ticket · investigate and respond on Tickets, TicketComments, TicketKnowledgeLinks
✓ Review the customer question and the applicable internal guidance.
› work and resolve a ticket · escalate when needed on Escalations, AssignmentHistory
✓ Record the unresolved question and the reason for a specialist handoff, then route it to an eligible L2 agent or manager.
› work and resolve a ticket · manage the service clock on ServiceEpisodes, SLABreaches
✓ Keep the ticket state aligned with the actual handoff.
› work and resolve a ticket · resolve the request on Tickets, ServiceEpisodes, TicketActivityLog
✓ Record the customer-facing resolution separately from internal analysis and move the ticket to Resolved.
Other processes
3 moreApprove 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
Close the request and collect feedback
Finish the service episode without losing the customer’s response.
4 stages · 0 approvals