SLA Calculations using Dovetail Carrier
I was recently working on a project that wanted to track SLAs, but the specific SLA rules were more complex than could be handled just using business rules. But, the logic would be pretty straightforward to enforce via code. So we came up with a solution that used a combination of business rules and a custom Dovetail Carrier extension. In this post, I’ll walk through how we accomplished this.
There’s a lot of information here, so grab a cup of coffee (or perhaps a glass of scotch), settle in, and lets get to it.
Photo by @ederpozo
SLAs
Over the past 20+ years of working in the Support/CRM space, I’ve worked with a number of organizations that want to enforce SLAs (service level agreements) in their Support app.
Example SLAs
- All cases must be responded to within 2 business hours
- All Urgent priority cases must be responded to within 1 hour regardless of business hours
- All cases must be responded to within the phone response time as stated on the contract
- All cases must be closed within 5 days.
- All subcases of type “Hardware Upgrade” must have a technician onsite within 36 hours.
- All new cases for a Gold level customer must get a call back from a senior tech within 1 hour.
- An initial response must occur within 8 business hours
- etc.
If the SLAs are straight forward, you can typically set these up using a combination of business rules, calendars, and (sometimes) contracts.
Complexity
But, it’s not uncommon to run into SLA definitions that are difficult to implement, as they often have some odd-ball logic or conditions that need to be implemented.
There may be different milestones that need to be reached, such as
- Initial Response
- Parts on site
- Technician on site
- Problem Fixed
- Status Update provided
- Case Closed
- etc.
The requirements may be different based on the Severity or Priority of the issue.
The requirements may also be different based on the customer’s contract. Or a particular Site field.
Different parts of the SLA may be based on elapsed time, support center business hours, customer business hours, or even “by the end of the next day”.
There may be the need to pause or suspend the clock for a particular milestone, or for the whole SLA.
In short – there are a ton of different ways that SLAs can be defined.
And just as there are a number of ways to define the problem, there are a number of different ways to solve it.
As I mentioned at the start, the project we recently did was more complex than could be handled just using business rules. But, the logic would be pretty straightforward to enforce via code. So we came up with a solution that used a combination of business rules and a custom Dovetail Carrier extension. Lets dive into the details.
SLA
The SLAs we needed to enforce were for an Initial Response to a case, and for providing Status Updates as the case progressed. The specific times for each were based on the Severity of the case.
For example:
- An Urgent severity case must receive an initial response within one hour, and status updates must be provided every 4 hours (elapsed time).
- A High severity case must receive an initial response within two hours, and status updates must be provided once a day.
- A Medium severity case must receive an initial response within 1 day (8 business hours), and status updates must be provided every 3 days (24 business hours)
- etc.
As you can see, we have different rules for different severity levels, multiple actions that must happen (Initial Response, Provide Status Update), and we have a mix of business hours, elapsed time, and relative time (once a day). Some case activities will count as a status update (such as a log email), and some won’t (such as an Internal Note).
Again, a lot of complexity for business rules; but not too much for a bit of actual code.
The Plan
We’ll track the next action that needs to be done, along with when it’s to be done by.
We’ll have a custom Dovetail Carrier extension that will calculate these values.
A business rule will fire on certain actions, and the rule will publish a message into Carrier’s queue, telling it to do the calculation and update the case fields.
When the case is closed, we’ll clear the Next Action and Next Action Due Date fields
If a SLA is violated, we’ll notify people, and also increment a counter on the case that tracks the Number of SLA Violations.
Custom Case Fields
We added three new fields to the case table: Next Action, Next Action Due Date, and Number of SLA Violations.
The Next Action and its Due Date will let us know what is the next action we need to do, and when we need to do it by.
The Number of SLA Violations tells us how many times over the course of the case’s lifetime that it violated its SLA.
Custom Carrier Extension
I previously blogged about how to create custom Carrier Extensions, including sample code.
We’ll follow that same pattern here.
We created a custom Carrier SLA extension which adds support for 3 new custom message types:
- CalculateNextDueDate
- ClearNextDueDate
- IncrementNumberOfSlaViolations
CalculateNextDueDate
Message:
type=CalculateNextDueDate
ActEntryObjid=[Activity Objid]
CaseID=[Case ID]Logic:
This is where the heavy lifting is done. This is C# code that uses the Dovetail SDK as well as some of our other available libraries (such as the Business Calendar Calculator).
- Based on the Activity and the case severity, it will calculate the Next Action and Next Action Due Date
- Update the case, setting the NextActionDueDate and NextAction
- Insert a new custom activity log for the case
- Activity Name: “Next Action Due Date Calculated”
- Additional Info: “Next Action of ” + NextAction + ” is due at ” + NextActionDueDate
- Insert a new time bomb for this activity
Also, rather than completely hard-coding all of the values, we made them configurable within the application settings file.
For example:
<add key="DueDateSettings.UrgentInitialResponse" value="1 hour" />
So if we need to do some tweaks to the specific values, we can make those changes without changing code.
ClearNextDueDate
Message:
type=ClearNextDueDate
CaseID=[Case ID]Logic:
- set NextDueDate=1/1/1753
- set NextAction = “” (empty string)
IncrementNumberOfSlaViolations
Message:
type=IncrementNumberOfSlaViolations
CaseID=[Case ID]Logic:
- This action will simply increment the table_case set x_num_sla_violations field
Now that we have the hard part done, we can create business rules that invoke these actions.
Business Rules
SLA: CalculateNextDueDate
Whenever a certain action happens, a business rule will fire, which will publish a CalculateNextDueDate message to Carrier.
| Name | SLA: CalculateNextDueDate |
| Start Events | Create, Phone Log, Log Note, Log Email, Reopen, Change Severity |
| Cancel Events | None |
| Conditions | Logger != dovetailapp |
| Action | CalculateNextDueDate |
| When | Fires immediately from event creation using elapsed time |
| Repeats | No |
| Create Activity Log | Yes |
| Message Type | Carrier Message |
| Message | type=CalculateNextDueDate ActEntryObjid=[Activity Objid] CaseID=[Case ID] |
SLA: ClearNextDueDate
When the case is closed, a business rule will fire, which will publish a ClearNextDueDate message to Carrier.
| Name | SLA: ClearNextDueDate |
| Start Events | Close Task |
| Cancel Events | None |
| Conditions | None |
| Action | ClearNextDueDate |
| When | Fires immediately from event creation using elapsed time |
| Repeats | No |
| Create Activity Log | Yes |
| Message Type | Carrier Message |
| Message | type=ClearNextDueDate CaseID=[Case ID] |
SLA: Violation
If a case’s SLA is violated, a business rule will fire, which will publish an IncrementNumberOfSlaViolations message, and it will also notify the case owner.
| Name | SLA: violation |
| Start Events | CalculateNextActionDueDate |
| Cancel Events | CalculateNextActionDueDate |
| Conditions | None |
| Action 1 | Notify the case owner – sla violated |
| When | Fires immediately from NextActionDueDate using elapsed time |
| Repeats | No |
| Create Activity Log | Yes |
| Who to Notify | Case Owner |
| Message Type | Message |
| Message | RE: SLA Violation: About Case [CaseID] : [Title] Case [Case ID] has violated its SLA Title: [Title] Severity: [Severity] Customer: [Contact First Name] [Contact Last Name] at [Site Name] Next Action: [Next Action] Next Action Due Date: [Next Action Due Date] Owner: [Current Owner] |
| Action 2 | Increment the NumberOfSlaViolations flag on the case |
| When | Fires immediately from NextActionDueDate using elapsed time |
| Repeats | No |
| Create Activity Log | Yes |
| Message Type | Carrier Message |
| Message | type=IncrementNumberOfSlaViolations CaseID=[Case ID] |
Take note of the When in that rule: “Fires immediately from NextActionDueDate using elapsed time”
That NextActionDueDate is a custom business rule calendar that is based on the table_case.x_next_action_due_date field.
Also note that the start and cancel events are the same. This means when a new due date is calculated, it will cancel any previous rules that were set to fire in the future.
UI – Case Page
On the case page, we’ve some a small customization to display the custom fields.
If the SLA is in an OK state:
And if the SLA has been violated:
UI – Case History
When the business rules fire, it will be shown in the case history:
When the next due date is calculated, this will also show in the history:
This makes it very easy to follow along with exactly what happened, and when.
This is also super helpful when troubleshooting SLA calculations. I’ve had to explain a few SLA calculations to users, and so far, I’ve been able to determine everything from the case history, without having to dive into logs or to the database itself. Easy.
UI – Queries
We added Next Action Due Date and Number of SLA Violations to the console and query grids, and made them available as filters.
This allows for queries such as:
- cases where the NextActionDueDate is today
- cases where the NextActionDueDate is tomorrow
- cases where the NextActionDueDate is within the next 12 hours
- cases where the SLA has been violated (number of sla violations > 0)
- cases where the SLA has been violated more than once (number of sla violations > 1)
- etc.
Query for open cases that are Due Today:
SLA Violation Notification
When an SLA is violated, a notification will be sent to the case owner:
Additional Configuration / Setup
In order to enable all of this to work, we also had to add a few custom properties as well.
- Create a new activity code of Next Action Due Date Calculated
- Create a new rule property for Next Action
- Create a new rule property for Next Action Due Date
- Create a new Business Rule Calendar for table_case.x_next_action_due_date
- Create a new Business Rule event of Next Action Due Date Calculated
This is all pretty standard Clarify/Dovetail setup, and most of it can be done using Dovetail Admin.
Reporting
In addition to the querying capabilities I outlined earlier, we can also report on these cases and their SLAs.
We have all of the data needed, so we can easily report on things like:
- Percentage of cases that missed their SLA. Could be further broken down by workgroup. By severity. Or by individual user.
- SLA adherence over time. Are we getting better or worse?
- Are SLAs being violated multiple times per case? How many?
- Average Time to initial response.
- Time to Resolution
- etc.
You can use your favorite reporting tool, or our Dovetail Agent Reporting module.
Additional Business Rules
Here’s a few ideas for some additional business rules that you might find useful.
Warnings
- Business rule that fires 1 hour before the NextActionDueDate. Notify the case owner with a SLA warning message.
Notify Supervisors
- For the SLA: violation business rule, in addition to notifying the case owner, you could also notify the case owner’s supervisor.
Suspend
If you wanted to temporarily suspend the SLA, you could do it with business rules. For example:
- Business rule that fires on Change Status. If new status = ON HOLD, then publish a ClearNextDueDate message.
- Business rule that fires on Change Status. If previous status = ON HOLD, then publish a CalculateNextDueDate message.
Carrier SLA Extension Code
For our customers that have purchased Dovetail Carrier, we can provide you access to the SLA Extension code.
Although it’s unlikely the code will exactly match your SLAs, it is a good starting point to build off of.
If you’d like access to this code, just contact our support department and we’ll grant you access.
Summary
If you made it this far – bravo! I warned you it was gonna be a lot of information!
Once you get the SLA extension coded up and in place, the rest of this is pretty straight-forward.
Will this mechanism work for your business needs? Maybe. Maybe not. Like most things in software – it depends.
But it is another tool in your toolbox that you have available.
And perhaps it will spur on some other ideas of working with SLAs, or perhaps other ideas of using Carrier Extensions.
I know there’s a lot of information here, so if you have any questions, or want to discuss – feel free to leave a comment below, or fill out the contact form.
Rock on.
