A Service Level Agreement, or SLA, is an average response and resolution times that your support team delivers to your customers.
Providing support based on service levels ensures that you're delivering measured and predictable service. It also provides greater visibility when problems arise.
You can define SLA service targets in Targetprocess so that you and your agents can monitor your service level performance and meet your service level goals. To set up the holistic process that could support the agreed service level targets you build the solution connecting multiple parts of Targetprocess together. In this article we'll describe available features, their purposes, and compare their capabilities. We'll also provide recommendations and best practices on how to configure and use them.
In Targetprocess, a Request is a key work item used for interaction with customers. All support requests, from all channels, become Targetprocess Requests. A Request captures your customer's initial request for support and all the conversations your agents have with the customer along the way to solving their support issue. Every Request has its own unique numeric ID assigned. Customers expect that the agreed service level targets are met per every Request.
It is possible to set up calculations of real-time SLA metrics per every request. When calculations are configured, calculated values are displayed in the detailed views of the requests. The calculated values can be added to cards on views as well.
The following metrics are supported for real-time monitoring:
- Time spent since creation
- Time spent till first submitted comment
- Time spent since last submitted comment
- Time spent since last process workflow state change
The results of measurement can use more and less precise units such as hours and days.
Non-working hours, weekends, holidays cannot be excluded from the calculations at the moment.
The custom calculations are configured with the help of Calculated Custom Fields and Custom Formula Metrics. In both cases the results of calculations are displayed in the Custom Fields panel in a Request detailed view.
Custom Fields and Metrics can be added by Administrators. Find administration guides here: How to set up Custom Fields?, Configuring Metrics.
Use Calculated Custom Fields when the custom calculation has reference to a present moment such as DateTime.Now. Use Custom Formula Metrics in any other case.
Use built-in Targetprocess fields as data source. Here are the available fields:
in formulas and filters
|Date when a ticket was created||Creation Date / Created||CreateDate|
|Date when a ticket was moved to In Progress* state||Start Date / Started||StartDate|
|Date when a ticket was moved to a final workflow state||Completion Date / Finished||EndDate|
|Last date when a comment has been submitted to a ticket||Last Commented||LastCommentDate|
|Last date when a ticket workflow state has been changed||Last State Change||LastStateChangeDate|
|Time spent from move to In Progress* state to a final workflow state / to current moment of time||days||Cycle Time||CycleTime|
|Time spent from creation to move to a final workflow state / to current moment of time||days||Lead Time||LeadTime|
More information: Lead and Cycle Time
Formulas for Calculated Custom Fields:
|Calculated Custom Field||Unit||Formula|
|Time spent since creation||days||(DateTime.Now - CreateDate).TotalDays|
|Time spent since creation||hours||(DateTime.Now - CreateDate).TotalHours|
|Time spent since last submitted comment||days||(DateTime.Now - LastCommentDate).TotalDays|
|Time spent since last submitted comment||hours||(DateTime.Now - LastCommentDate).TotalHours|
|Time spent since last process workflow state change||days||(DateTime.Now - LastStateChangeDate).TotalDays|
|Time spent since last process workflow state change||hours||(DateTime.Now - LastStateChangeDate).TotalHours|
Formulas for Metrics:
|Metric||Custom Field Type||Unit||Formula|
|Time spent till first submitted comment||Number||days||(Comments.MIN(CreateDate) - CreateDate).TotalDays|
|Time spent till first submitted comment||Number||hours||(Comments.MIN(CreateDate) - CreateDate).TotalHours|
|Time spent till move to In Progress* state||Number||days||(StartDate - CreateDate).TotalDays|
|Time spent till move to In Progress* state||Number||hours||(StartDate - CreateDate).TotalHours|
|Custom Deadline Date||Date**||CreateDate.Value.AddDays(2)|
|Custom Deadline Time||String||CreateDate.Value.AddHours(48).GetDateTimeFormats('t').ToString|
* In Progress is the first state after Planned state when a Planned state is defined. Or, it is a next state after initial one otherwise.
** Day, month, and year of a date are displayed in Date custom fields. Precise time is truncated and not displayed.
Using conditional operators, multiple formulas may be combined into single advanced one.
Check for SLA violation can be performed right in the formula:
Custom Formula Metric: IIF((Comments.MIN(CreateDate) - CreateDate).TotalHours >= 4, False, True) IIF(CustomValues.Number("SLA Hours") >= 4, False, True)
In the example below, we'll calculate time spent since last submitted comment (if there is at least one comment submitted) or time spent since creation (if there are no comments yet).
Calculated Custom Field: IIF(Comments.Count > 0, (DateTime.Now - LastCommentDate).TotalHours, (DateTime.Now - CreateDate).TotalHours)
With advanced formulas it is possible to add or subtract few days, counting only business days. Say, the requests are created on business days only, and the SLA resolution time is 2 days. Then, for Monday, Tuesday, and Wednesday the deadline is set 2 days later on the same week, while for Thursday and Friday it must skip a weekend and come 4 days later on the next week.
Get what day of the week a date is:
Custom Formula Metric: CreateDate.Value.DayOfWeek.ToString() CustomValues.Date("SLA Date").Value.DayOfWeek.ToString()
Add custom number of days depending on day of week:
Custom Formula Metric: IIF(CreateDate.Value.DayOfWeek.ToString() == "Thursday" || CreateDate.Value.DayOfWeek.ToString() == "Friday", CreateDate.Value.AddDays(4), CreateDate.Value.AddDays(2))
Display Values on Views
The calculated values can be added to cards on views within Customize Cards feature.
You should be proactive when it comes to SLAs rather than reactive. Being proactive means creation of alerts to the Support team. For example, the alert is created one hour before the SLA is breached, so the team knows that the clock is ticking but they still have time to meet the target. Highlighting tickets that fail to meet service level targets helps promptly identify and address problems.
In Targetprocess alerts are created with the help of color highlighting. Requests displayed in queue change their colors on the fly. For example, regular tickets are displayed as white. They become amber one hour before the SLA is breached. And they become red immediately after the SLA is expired.
Sending notification emails and creating sound alarms for alerts and reminders is not supported at the moment.
Use the following two features for proactive warnings:
- Visual Encoding
- Custom Mashup Extension
Visual Encoding highlights cards based on conditional rules. Set the rules based on built-in fields or based on custom calculations.
Visual Encoding rules are configured by view owners. Use syntax of Advanced Filters.
Visual Encoding based on built-in fields
In the example below, a SLA value is calculated per each request within built-in field named LastStateChangeDate. Say the SLA limit is 7 days. We'd like to highlight cards to ember one day prior to SLA target limit. And highlight red the cards that violate the limit. Use the following Visual Encoding rules for this purpose:
|Color||Visual Encoding Filter|
|Red||?LastStateChangeDate <= Today - 7(days)|
|Amber||?LastStateChangeDate > Today - 7(days) and LastStateChangeDate <= Today - 6(days)|
Visual Encoding based on custom calculations
Set up the custom field with result of calculation of selected SLA metric. Then compare the custom field value with selected goals in the conditional rules. Assign colors to each goal.
Custom Fields are configured by Administrators.
In the example below, a SLA value is calculated per each request within custom field named SLA Hours. Say the SLA limit is 24 hours. We'd like to highlight cards to ember one hour prior to SLA target limit. And highlight red the cards that violate the limit. Use the following Visual Encoding rules for this purpose:
|Color||Visual Encoding Filter|
|Red||?SLAHours >= 24|
|Amber||?SLAHours >= 23 and SLAHours < 24|
In Visual Encoding filters, names of custom fields are specified without spaces and quotes. Learn more about filters: Advanced Filters overview
Visual Encoding rules based on Calculated Custom Fields may slowdown performance of your system. Use Requests Classes Of Services mashup as a replacement whenever possible.
Custom Mashup Extension
Requests Classes Of Services mashup (custom add-on) calculates SLA values and highlights cards in views based on agreed service level targets. It doesn't require to set up any Calculated Custom Fields and Visual Encoding rules. All the calculations are performed in the custom front-end code.
The performance of the code is optimized. Whole your system works faster - compared with using Calculated Custom Fields and Visual Encoding.
In this particular case requests that are marked as yellow have not been replied for more than 20 hours, so we’d better hurry up. Red means it’s been there for more than 24 hours and needs to be replied asap. The green one was added less than an hour ago, so there is a chance to create a wow-effect and reply to the customer right-away.
Mashups are installed and configured by Administrators.
More information: Requests Classes Of Services
Reports help to analyze results of your support process retrospectively. You can view how well you are meeting your SLA policies.
Basic SLA policies measure initial reaction time for newly created requests. Advanced SLA policies may also limit cycle time / total processing time for requests. When a workflow is set up for Requests then some workflow states such as "Open", "Reopen", "In Progress" may be selected as target for measurements, while other ones such as "On Hold", "Pending", "Details Requested" may be considered as non-valuable.
The following calculated values and targets are supported for historical reporting:
- Time spent till first submitted comment
- Total processing time
- Total processing time in selected workflow states
These metrics can be calculated and displayed per each request. It is possible to calculate averages with daily / weekly / monthly distribution. It is also possible to see results distributed per project, and per request category.
The reports can be built and browsed in Targetprocess. Manually export a report into a tabular or graphical file in order to use it in an external tool.
Tabular Reports in Targetprocess do not support Calculated Custom Fields. Export Views to CSV file or build Visual Reports to get values from Calculated Custom Fields in tabular format. Custom Formula Metrics do not have this limitation.
Time spent till first submitted comment
The values are provided by Custom Formula Metric. They are calculated and set to the corresponding custom field for each request. The report uses requests and custom field values as the data source.
Total processing time
The values are calculated and set to the built-in field Cycle Time for each request. The report uses requests and field values as the data source.
Total processing time in selected workflow states
The reports of this kind use requests and historical data of state transitions as the data source.
Reporting on recurrent events
Some events when response is avaited by a customer may occur multiple times for the same Request. Examples of such events are:
- Customer's comment submitted
- Request's state changed from "Pending" to "Reopen"
Strict SLA policies measure reaction time for each occurence of any of these events. Breaches of such SLAs are not recorded by Targetprocess.