92% SLA attainment and angry customers: reconciling a global support report
Corvus IT Support runs 24/7 managed services for 180 enterprise customers. Contracts promise a six-hour first-response SLA for P1 and P2 incidents. In HubSpot Service Hub, the SLA is set to six business hours for every ticket, and priority is not a required property. The monthly report shows 92% first-response SLA attainment, but three enterprise customers escalated in the same month. Investigation finds: tickets auto-close after seven days without customer reply; 18% reopen; agents sometimes move tickets to closed to clear their queue; phone and chat contacts are not consistently ticketed; and the SLA timer starts when the ticket is assigned, not when created. The support manager wants to add a dashboard that shows 92% in green and move on.
1. Explain why the 92% figure is not trustworthy. What would you audit first?
Read the worked answer
The 92% figure measures a different promise from the contract. The contract says six hours for P1 and P2 incidents; the HubSpot SLA applies six business hours to every ticket. That means nights and weekends do not count, low-priority tickets dilute the number, and a P1 can be measured against a business-hours clock. The timer starts at assignment, not creation, so queue time before assignment disappears. Auto-close after seven days without a customer reply and an 18% reopen rate mean some tickets are counted as resolved before the customer agrees. Agents moving tickets to closed to clear the queue make status a workflow convenience, not an outcome. Phone and chat not being ticketed means the worst channel experiences may be absent from the report entirely.
Audit first: sample 30 P1 and P2 tickets from the month, reconstruct created-to-first-human-response in calendar time, compare to contract, and check status changes, reopens, and channel source. Then fix the measurement before defending the number.
2. Redesign the SLA policy and ticket lifecycle to match the contracts.
Read the worked answer
Policy: define P1-P4 with examples and require priority at creation. P1 and P2 follow the contract clock, 24/7 calendar hours, six-hour first response; P3 and P4 use business hours. Timer starts at ticket creation, not assignment. Pause only when the ticket is in a defined waiting on customer status, and record the pause duration. Auto-close should become pending closure with a reopen window; a reopened ticket keeps its original creation time and links to the prior ticket. Every phone and chat contact must create or link to a ticket before the interaction is closed.
Lifecycle: new -> triage -> assigned -> in progress -> waiting on customer -> resolved -> closed. Triage has an owner and a 15-minute target for P1 and P2. Escalation rules page the on-call for P1 and for named enterprise accounts. QA samples status changes weekly so closed cannot be used to clear a queue. The routing workflow writes priority, contract tier, channel, and pause reason so the SLA report can be reconstructed.
3. What should the replacement report show, and how should it be read?
Read the worked answer
Replace the single green percentage with a report by contract tier, priority, and channel. Show median and 90th-percentile first response in calendar hours for P1 and P2, attainment against the contractual clock, resolution time separately, reopen rate, auto-closed and reopened counts, backlog age, and breach reasons. Add a data-completeness line for phone and chat ticketing. Read the median for the typical experience and the 90th percentile for the enterprise tail; a 92% average can hide a P1 that waited 14 hours. Separate first response from resolution because one can be good while the other is poor. Use drilldown to ticket IDs so an escalation can be traced to a status change or an unlogged call. Trend by month, but annotate policy changes, auto-close changes, and staffing changes so the trend is interpretable.