Close the request and collect feedback
Finish the service episode without losing the customer’s response.
4 stages · 0 approvals
Roles and responsibilities
-
Step 1Allow the follow-up
Ticket NumberSubjectPriorityStatusMedium
-
Step 2Confirm closure
Ticket NumberSubjectCustomerAssignee
-
Step 3Deliver the invitation
TicketCustomerStatusSent AtSent
-
Step 4Record explicit feedback
TicketCustomerStatusSent AtSent
Process steps
Follow the process from start to finish. Select a step to see who acts and what changes.
Allow the follow-up
The customer can reply or reopen through the permitted portal action while the configured window remains open. The service returns the request to Open and creates one new episode for that accepted action. A repeated request returns the same result, while prior response, resolution and breach history remain available for an accurate account of the original service.
Confirm closure
When the window expires, the closing service checks the unchanged resolved revision. A concurrent valid customer reply prevents stale automatic closure. Record the closed outcome and its time only after this condition holds. Staff can then distinguish an eligible finished episode from a request that has returned to the team for more work.
Deliver the invitation
Create one invitation for the eligible closed ticket episode and its actual customer. Retain the survey identity through queued, accepted, failed or unknown delivery. If the provider result is uncertain, reconcile the original request before attempting another send. A locally queued survey has no SentAt or score, and a provider acknowledgment does not establish a response.
Record explicit feedback
Accept a deliberate integer score from one to five and the optional comment through the bound customer identity or a valid single-purpose token. Opening a link does not submit the rating. Repeated submission preserves the accepted answer. The support manager can review low scores in the underlying ticket context while nonrespondents remain visible as missing responses.
Approvals and exception handling
0 approvals required in this process
- An expired or consumed survey token cannot submit a new score; store its hash rather than a reusable bearer token.
- Ticket and survey customer identities must agree within the same workspace.
- CSAT reporting uses actual respondentsShows missing responses; unanswered surveys never become zero or satisfied scores.
- The closure episode key prevents repeated closure events from creating repeated invitations.
When the process needs attention
-
hold
Confirm closure
Record the closed outcome and its time only after this condition holds.
-
reject
Deliver the invitation
Retain the survey identity through queued, accepted, failed or unknown delivery.
Records and postings
| Stage | Records | Effect |
|---|---|---|
| 1 Allow the follow-up | TicketsServiceEpisodes | Resume work when eligible |
| 2 Confirm closure | TicketsServiceEpisodesTicketActivityLog | Preserve an unchanged closed outcome |
| 3 Deliver the invitation | CSATSurveys | Send one correlated survey |
| 4 Record explicit feedback | CSATSurveysTickets | Retain one verified customer response |
Process reports
All reportsResolution 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.
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.
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.
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.
CSAT Trend
Average explicit 1-5 responses by response period and the linked closed episode TeamAtResolution/AgentAtResolution. Each SurveyKey counts once. Show responded, unanswered and eligible invitation counts; exclude missing scores from the average. Later assignment changes cannot move historical scores between staff.
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
› close the request and collect feedback · allow the follow-up on Tickets, ServiceEpisodes
✓ The customer can reply or reopen through the permitted portal action while the configured window remains open.
› close the request and collect feedback · confirm closure on Tickets, ServiceEpisodes, TicketActivityLog
✓ When the window expires, the closing service checks the unchanged resolved revision.
› close the request and collect feedback · deliver the invitation on CSATSurveys
✓ Create one invitation for the eligible closed ticket episode and its actual customer.
› close the request and collect feedback · record explicit feedback on CSATSurveys, Tickets
✓ Accept a deliberate integer score from one to five and the optional comment through the bound customer identity or a valid single-purpose token.
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
Work and resolve a ticket
Keep specialist handoffs and service commitments connected.
4 stages · 0 approvals