Green service desk, unhappy claims teams
Meridian Assurance's IT service desk supports 1,400 internal users across claims, underwriting and finance. The service desk SLA has been unchanged since 2018: P1 response within 15 minutes and resolution within 4 hours, P2 response within 4 hours, and service availability of 99.9% measured monthly with planned maintenance excluded. The Q3 report shows 99.97% availability and 98.2% of incidents responded to within target, and the service owner has circulated it as evidence of strong performance. In the same quarter the internal satisfaction survey fell from 4.1 to 3.2 out of 5, and the CIO commissioned interviews. Users described repeating information, being passed between the service desk and the applications team, and waiting days for a fix to a recurring claims-export error. Ticket analysis shows 38% of incidents were reopened within seven days, and the top five recurring issues account for 21% of volume. Claims staff say they cannot tell whether a claim is stalled because of the system or because of a person.
1. Explain how the service desk can report 98.2% response compliance and 99.97% availability while user satisfaction collapses.
Read the worked answer
The metrics measure the supplier's activity, not the customer's outcome.
Response is not resolution. Response time measures the moment a ticket is acknowledged. A ticket acknowledged in nine minutes and resolved in four days scores perfectly on response. Nothing in the SLA reports time to restore service from the user's perspective, and nothing reports first-time fix.
Scope excludes the cause. The SLA covers the service desk. The recurring claims-export error is owned by the applications team, which sits outside the agreement. So the dominant source of user pain contributes nothing to any reported figure - the SLA is measuring the part of the chain that is easiest to measure, not the part that matters.
Availability is defined technically. Planned maintenance is excluded, and availability is measured at the infrastructure layer. A claims handler whose export fails every morning while the server is up experiences an unavailable service; the SLA records it as available.
Reopens are invisible. A 38% seven-day reopen rate is the strongest signal in the data: users are returning with the same problem. Because the SLA has no repeat-contact or reopen measure, the failure is scored as a success twice - once on first closure, once on the reopened ticket.
Aggregation hides the tail. A mean resolution time inside target can coexist with a small population of tickets waiting days. The 21% of volume from five recurring issues suggests a problem management gap that no SLA metric would surface.
The general lesson. Compliance with an SLA tells you the provider met what was written down. If what was written down is scoped to the provider's own activity and excludes the outcome the customer cares about, high compliance and low satisfaction are entirely consistent.
2. Identify the SLA design errors at Meridian and state what you would change in the agreement itself.
Read the worked answer
Errors present:
- No service level requirements process. The SLA dates from 2018 with no evidence it was ever derived from what claims staff need. It has never been reviewed against changes in the claims process.
- Wrong scope. The agreement stops at the service desk boundary, so the applications team - the source of the recurring export failure - is outside it.
- Activity measures instead of outcome measures. Response and technical availability are provider-side counters. Neither correlates with a claim being progressed.
- No quality or rework measures. Reopen rate, repeat contact and first-time fix are absent, which is precisely why quality collapsed undetected.
- No OLA linking the service desk to the applications team, so hand-offs have no target and no owner.
- Definition loopholes. Excluding planned maintenance from availability, and not defining how a partial or degraded service is counted, let real unavailability disappear.
- No review cadence with the customer. The report is issued, not discussed.
Changes to the agreement:
- Re-scope to the end-to-end incident lifecycle for claims and underwriting, including applications support, with an OLA to the applications team using the same definitions.
- Replace or supplement response with time-to-restore targets, and add first-time-fix percentage, reopen rate (target well below 10%) and repeat-contact rate.
- Add a customer-experience measure agreed with the claims process owner, such as the percentage of claims handlers reporting they can complete their task without a workaround.
- Tighten availability: exclude only pre-agreed, communicated maintenance windows; count degraded service as a defined fraction of unavailable; measure at the user transaction layer.
- Add a problem management commitment covering the top recurring issues, with a target for known errors resolved per quarter.
- Institute a monthly service review with claims, underwriting and finance representation that reviews the metrics and the narrative together.
3. How would you rebuild the service level requirements for the claims process, and who must be involved?
Read the worked answer
Start from the claim, not the ticket.
Framing. A claims handler's job is to move a claim from notification to settlement. The service requirement is therefore about how IT enables that flow: can the handler open, edit and export a claim without interruption, how quickly is access restored when it fails, and how often does the same failure recur. Those are the questions the SLR workshops should answer.
Who must be in the room. The claims process owner (accountable for the outcome), two or three frontline claims handlers (the people who experience the failures), the service desk manager, the applications team lead, the problem manager, and an SLM facilitator. Underwriting and finance should contribute written input if they cannot attend. Excluding the applications team would repeat the original design error.
Method. Run two sessions of about 90 minutes. In the first, walk through the claim journey and record where IT interrupts it, using the last quarter's reopen and repeat-contact data as evidence. In the second, convert the pain points into requirements with a measurable expression and a rationale - for example, "a handler must be able to export any claim within 30 seconds on 99% of attempts during business hours, because export failure blocks the settlement clock".
Translate into documents. Requirements that the service desk can meet become SLA commitments; requirements that depend on another team become OLAs; requirements that depend on a supplier (the export tooling, a document store) become underpinning contracts. Where a requirement is not currently affordable, record it as an accepted gap with an owner rather than quietly dropping it.
Validate and review. Take the draft back to the claims handlers before signature, and set a review at six months, plus a review trigger whenever the claims process or the application stack changes. Track satisfaction and reopen rate as the validation that the requirements were expressed correctly.