Set service targets that the team can apply and explain.
4 stages · 1 approval
Follow the process from start to finish. Select a step to see who acts and what changes.
Define the priority, first-response target, resolution target, effective date and business calendar. Include whether waiting on the customer pauses eligible service time and how long the customer can reopen a resolved request. Check that the configured calendar covers the intended time zone and holiday behavior. Missing configuration stays visible for correction instead of being replaced with an invented deadline.
Save complete draft targetsApproval waits for the support manager.
Submit the version the service team intends to use. The reviewer needs the complete set of targets and calendar assumptions together, because changing one affects how the commitment is measured. Preserve who prepared the submission. A later edit creates a revised proposal and requires a new decision; it cannot quietly change values already placed in the approval inbox.
Freeze the submitted revisionApproval waits for the support manager.
A Support Manager other than the material preparer checks the submitted values and records approval. Administrative access does not provide this decision on the manager’s behalf. If the policy needs correction, return it with the open question and review the corrected version later. Only the independently approved version can be selected for incoming work.
Authorize the reviewed policySupport Manager: Approve submitted SLAPolicies prepared by another actor
Approval waits for the support manager.
Triage resolves any permitted priority uplift before selecting the approved effective policy. The service creates the episode with its frozen targets and calendar, then projects its due times into the ticket. The schedule shows the start and computed resolution deadline. Later eligible pauses retain the original target while recording why the current window changed.
Create the measured episodeSLAPolicies
| Stage | Records | Effect |
|---|---|---|
| 1 Prepare the policy | SLAPolicies | Save complete draft targets |
| 2 Submit for review | SLAPolicies | Freeze the submitted revision |
| 3 Approve the version | SLAPolicies | Authorize the reviewed policy |
| 4 Apply the service window | TicketsServiceEpisodes | Create the measured episode |
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.
| 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 |
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.
Tickets per day, week or month by source and initial episode PriorityAtStart/CategoryAtStart. Tickets awaiting valid triage remain a separate untriaged bucket.
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.
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.
Move a verified request into an eligible owner’s queue.
4 stages · 0 approvals
Keep specialist handoffs and service commitments connected.
4 stages · 0 approvals
Finish the service episode without losing the customer’s response.
4 stages · 0 approvals
Create your ERP.AI account and get started with Proto.
We use essential cookies to run the site and optional cookies for features, analytics, and relevant content. See Cookie policy
We use cookies to enhance your experience, analyze site traffic, and serve relevant content. By clicking "Accept All," you agree to our use of cookies. You can customize your preferences at any time.
Learn more about how we use cookiesThese cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
These cookies enable additional features that enhance your experience, such as live chat, video playback, personalized content recommendations, and remembering user preferences.
These cookies help us understand how visitors interact with our site by collecting anonymous usage data. This allows us to measure performance, detect issues, and continuously improve the user experience.
These cookies allow us and advertising partners, including X, to deliver ads tailored to your interests. They track browsing habits across sites to provide relevant advertising and measure ad effectiveness.