Route a new support request
Move a verified request into an eligible owner’s queue.
4 stages · 0 approvals
Roles and responsibilities
-
Step 1Capture the request
Ticket NumberSubjectCustomerPriorityMedium
-
Step 2Triage the issue
Ticket NumberSubjectCustomerQueue
-
Step 3Reserve an eligible owner
Ticket NumberQueueAssigneePriorityMedium
-
Step 4Begin the conversation
Ticket NumberSubjectCustomerPriorityMedium
Process steps
Follow the process from start to finish. Select a step to see who acts and what changes.
Capture the request
Retain the source event and resolve the customer identity under the configured intake policy. Repeated delivery of the same event returns its existing ticket. A familiar email address can help staff investigate a request, but it cannot authorize a customer login. Fields supplied by a customer do not establish internal ownership, service policy or a different person’s identity.
Triage the issue
Choose the category, permitted priority and destination queue. Apply any eligible priority uplift before selecting the approved effective service policy. Create the service episode from that policy’s targets and business calendar. If a required choice is missing, retain a visible configuration exception without inventing a due date or pretending that an owner has been selected.
Reserve an eligible owner
Apply the queue’s routing strategy to active, authorized agents with the required skills and available capacity. Reserve that capacity as the owner is selected so concurrent requests cannot all claim the same remaining slot. If the team is full, use a permitted terminating overflow path or leave the request visibly unassigned for the manager.
Begin the conversation
The assigned agent checks the public request and the current service target, opens work and prepares the next customer response. Internal diagnostic notes remain private. Public replies and files follow the intended customer visibility, and an uncertain email delivery is reconciled before another copy is sent. The assignment history explains how responsibility reached this agent.
Approvals and controls
0 approvals required in this process
- Portal identity comes from the authenticated principalNot a customer field or an email match.
- Keep unresolved intakeUnassigned work visible to the people who can correct it.
- A repeated intake or routing command returns the recorded result and does not duplicate a ticket or capacity reservation.
- Customer access cannot expose internal notesUnrelated requests or direct private attachment URLs.
Records and postings
| Stage | Records | Effect |
|---|---|---|
| 1 Capture the request | CustomersTickets | Create one scoped ticket |
| 2 Triage the issue | TicketCategoriesTicketsServiceEpisodes | Set category and service window |
| 3 Reserve an eligible owner | QueuesAgentsAssignmentHistory | Assign work without exceeding capacity |
| 4 Begin the conversation | TicketsTicketCommentsTicketAttachments | Start accountable support work |
Process reports
All reportsTicket Volume Trend
Tickets per day, week or month by source and initial episode PriorityAtStart/CategoryAtStart. Tickets awaiting valid triage remain a separate untriaged bucket.
First-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.
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
› route a new support request · capture the request on Customers, Tickets
✓ Retain the source event and resolve the customer identity under the configured intake policy.
› route a new support request · triage the issue on TicketCategories, Tickets, ServiceEpisodes
✓ Choose the category, permitted priority and destination queue.
› route a new support request · reserve an eligible owner on Queues, Agents, AssignmentHistory
✓ Apply the queue’s routing strategy to active, authorized agents with the required skills and available capacity.
› route a new support request · begin the conversation on Tickets, TicketComments, TicketAttachments
✓ The assigned agent checks the public request and the current service target, opens work and prepares the next customer response.
Other processes
3 moreApprove a service policy
Set service targets that the team can apply and explain.
4 stages · 1 approval
Work and resolve a ticket
Keep specialist handoffs and service commitments connected.
4 stages · 0 approvals
Close the request and collect feedback
Finish the service episode without losing the customer’s response.
4 stages · 0 approvals