I have blogged a few times about capabilities around service level agreements (SLAs) within Dynamics 365 Customer Service! This time I plan to cover a specific requirement that frequently arises …. as we often need to understand the impact on our SLA when re-opening a resolved case.
Obviously, we’d like to think our agents always fully resolve all issues on their first attempt! But in the real-world sometimes we don’t “fix” something and need to re-open the associated case.
When we first resolve the case maybe the associated SLA will have been successfully completed. But what will happen if we need to reopen the case and continue working on it? Should our SLA restart or remain in its completed state?
Below you can see I have a resolved case, notice that my first response in and resolve by SLAs have therefore already succeeded.
Below you can see the same case again, after I have reactivated it. You might expect my SLAs to have changed … as the case obviously wasn’t resolved and my service level agreement therefore had not been achieved. But as you can see both my SLA KPIs are still showing succeeded. Meaning the SLA is not impacted by reopening the case.
This is the expected out of the box default behaviour! Once an instance of an SLA is complete it receives no further updates.
So …. how can we change these results? In your “Customer Service Admin Center” under the case settings heading, I can access “Other Settings”. (As shown below.)
Tip: I think you can navigate to the same option by selecting “service terms” under the operations heading. And selecting “Other SLA Settings”.
Below I have highlighted the option “Recalculate SLA on terminal status”. Terminal status would involve the case becoming read-only because it has been cancelled or resolved.
Meaning if we changed the case status from being resolved to active the SLA would be recalculated.
So to alter the behaviour of my SLA on case reactivation I’d change this option to be “Yes”.
Once changed, repeating my earlier test we can see that my first response SLA is still succeeded but my resolve in SLA is “ticking” once again. Meaning my SLA has restarted.
But why was the “first response in” SLA still succeeded I hear you say!! The reason is that the criteria by which first response had been achieved is still true. So the new SLA KPI instance for first response is instantly succeeded. But the case is now open again so the “resolve in” SLA has not been achieved and is still running. (As closing the case will achieve that SLA.)
Looking the SLA tab might help you understand what has happened.
I now have 4 SLA KPI instances. Two for my “First Response In” KPI and two for my “Resolve In” KPI. When the case was reactivated any existing SLA records were cancelled. Regardless of them being succeeded, in progress or whatever. Then new instances were created.
With my resolve by (shown below), we can see that my cancelled row was originally show as succeeding at 10:56am. But as the case is open again the new SLA instance is still in progress.
My first response KPI had already been met meaning this new KPI instance immediately became succeeded.
My initial first response was at 10:56. The case was reopened at 2:10pm. Meaning my first response KPI originally succeeded at 10:56. But as the case was reopened at 2:10pm and the condition was met then and that instance of SLA was therefore deemed to have succeeded at 2:10pm.
I know what I have just explained may seem a little confusing! (But if you try this it will make sense!) First response was completed at 10:56. But the KPI now “suggests” first response was done at 2:10pm.
And I guess here lies the types of challenges re-opening cases and restarting SLAs might present. You need to consider how the SLA data will appear and be interpreted by users.
You possibly need to think over the implications for your reporting. And if a customer’s problem isn’t resolved on your first attempt do you want to reactivate the old case (and its SLA) or simply create a new case. In many scenarios I think it is valid to create a new case each time a customer reports a problem. (Regardless of it being the first instance of that problem or not.)
Therefore, the requirements for restarting the SLA or opening a new case may differ from company to company. But at least we have options!