Northwind: SLA Timers That Never Stop
Northwind sells support under Gold and Silver contracts. A single SLA defines a four-hour first response and a two-day resolution, and entitlements give Gold customers 40 cases per year.
Three problems have surfaced. First, cases for several Gold customers never get an SLA KPI instance at all. Second, agents report that timers keep counting while a case is waiting on a part, so warnings fire on cases nobody can progress. Third, an entitlement was exhausted during a customer outage and new cases could not be created, which escalated badly. The service director wants predictable behaviour and an explanation she can give to account managers.
1. Several Gold cases never receive an SLA KPI instance. List the most likely causes in the order you would check them, and state why an existing open case will not gain a timer after you fix the configuration.
Read the worked answer
Check in this order:
- Is an SLA actually set on the case? The case carries an SLA field, normally populated from the entitlement or by default. A case with no SLA value gets no KPI instances.
- Is the SLA and its items activated? Draft SLA items do not run, and a published SLA whose items were never activated silently does nothing.
- Does the entitlement match the customer and channel? Confirm the customer's entitlement is the one applied, that it is active, and that its dates and channel restrictions cover this case.
- Does the SLA item's applicable-from field resolve to a value? If the field it reads is blank on those cases, the item does not apply.
- Was the case created after the configuration took effect? KPI instances are created when the case is created.
That last point explains the second question: an already-open case will not retroactively gain a timer. Decide explicitly whether to manually set the SLA field and accept the resulting start time, or to leave history alone and apply the fix prospectively - and state that choice to the account managers.
2. Timers keep running while a case waits on a part. Explain how to make the SLA pause correctly and what must be standardised for the fix to hold.
Read the worked answer
Pause is driven by status, not by intent. On the SLA item, enable pause and resume and set the pause status to the exact status reason that represents waiting. The timer then stops when the case reaches that status and resumes when it leaves it.
The usual failure is a mismatch. If the configured pause status is 'On hold' but agents actually use a custom 'Waiting for parts' reason, the case never reaches the configured status and the timer keeps running. Two status reasons that look similar to an agent are different values to the SLA engine.
Standardise before configuring:
- Agree a small set of on-hold status reasons with the operations lead, and remove or rename duplicates.
- Make the chosen reasons easy to find on the case form, ideally with a business rule that prompts for a follow-up date.
- Configure warning and failure actions (notify the owner, escalate to the queue supervisor) using Power Automate, and confirm nobody assumes failure automatically changes the case status - it does not.
Then test with a single case: pause, wait, resume, and confirm elapsed time excludes the paused interval.
3. An exhausted entitlement blocked new case creation during a live outage. Evaluate the options and recommend a policy for entitlement exhaustion.
Read the worked answer
Treat blocking as a deliberate business decision, not a default. Blocking protects revenue on a consumed support contract, but it fails exactly when the customer is most exposed, so it must have an escape route.
Options:
- Leave blocking on and add a process for account managers to authorise an override or extend the term. Workable, but only if the override is fast enough for an outage.
- Turn blocking off and allow cases beyond the term, then bill overage. Simplest operationally, requires finance agreement.
- Route over-term customers to a different entitlement or queue so the relationship is preserved and the commercial conversation happens separately.
Recommendation: do not block for customers with an active incident; disable blocking or add an explicit fallback entitlement, and report on consumption so account managers see exhaustion approaching before it bites.
Also verify the design: confirm each customer has exactly one default entitlement so the applied term is predictable, that term units (cases versus hours) match how support is actually sold, and that reported consumption reconciles with the contract before anyone quotes numbers to a customer.