SLA management in Customer Service

Service Level Agreements (SLAs) in Dynamics 365 Customer Service are how commitments to customers — "we'll respond within 1 hour, resolve within 4 hours" — get tracked, enforced, and reported. SLAs encode the response-time and resolution-time expectations that drive both customer satisfaction and operational discipline.

The model. An SLA record defines:

• Applicable to — usually the Case table, but configurable.
• Applicable when — conditions that determine when this SLA applies (e.g. only Premium-customer cases, only Voice-channel cases).
• Business hours — the operating calendar (24/7, business hours, multi-region) the SLA respects.
• SLA KPIs — the measurable commitments (first response time, resolution time, etc.).
• Status — Active or Inactive.

An SLA item is the specific KPI within an SLA:

• KPI — the field being tracked (First Response By KPI, Resolve By KPI, or custom KPIs).
• Applicable when — sub-condition that narrows this item to a slice (e.g. high-priority cases get tighter timing than normal-priority).
• Success criteria — what counts as "met" (e.g. case status is Resolved).
• Warning after — duration after which the SLA is at Warning state (e.g. 80% of the resolution window consumed).
• Failure after — duration after which the SLA is Breached (the commitment is missed).

Business calendars. SLAs respect business calendars — a 1-hour response SLA at 5pm Friday with a Mon-Fri business calendar doesn't breach over the weekend; the clock pauses outside business hours. Multi-region operations use multi-calendar SLAs that apply per customer's local time.

SLA timer. Inside the case form, the agent sees a timer widget for each active KPI: time remaining, status (Active / Warning / Breached), with colour coding (green / amber / red). The visible countdown changes behaviour — agents prioritise cases that are about to breach.

Pause and resume. SLAs pause automatically when the case enters certain statuses (e.g. On Hold — Waiting for Customer) and resume when status changes back. Pause rules are configured per SLA; the pattern keeps the clock honest about active service time vs waiting time.

Escalation. When an SLA approaches warning or breach, Power Automate flows can trigger escalation actions: notify the supervisor, reassign the case, create a Teams notification, escalate the customer relationship. Configured per SLA item.

Entitlements integration. SLAs are typically applied through entitlements — contracts the customer has that grant specific SLA terms. Premium-support customers get Premium SLAs; basic customers get standard. Entitlement configuration drives which SLA applies to a given case.

Reporting. SLA performance feeds into:

• Real-time agent and supervisor dashboards — current cases approaching warning / breach.
• Historical KPI reports — % cases meeting SLA, average response/resolution time, breach reasons.
• Customer scorecards — per-customer SLA performance over time, used in QBRs.

Common pitfalls.

• No business calendar — SLA clock runs 24/7 and looks bad even when service was fine.
• SLA fires for cases that shouldn't have one — over-broad "Applicable when" conditions cause noise.
• No pause configuration — customer-wait time is counted against the support team, demoralising and misleading.
• Reporting only after breach — should warn at 80%, not at 110%.

Operational discipline. Tune SLAs based on actual data, not aspirations. Start with achievable targets and tighten over time as the team performs. SLAs that breach constantly become noise; SLAs that always succeed are not stretch targets.