Tracking Deadlines and Service-Level Agreements for Work Items

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.

Work Items

Requests

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.

User Stories and Bugs

Use User Stories and Bugs to track work activities. User Stories and Bugs do not have support for direct communication with external users. To track the status of User Stories and Bugs and interact with your customers attach Requests to work items using Relations.

Real-Time Monitoring

It is possible to set up calculations of real-time SLA metrics per every work item. When calculations are configured, calculated values are displayed in the detailed views of the entities. 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 the last process workflow state change

The results of measurement can use more and less precise units such as hours and days.

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 an entity detailed view.

Custom Fields and Metrics can be added by Administrators. Find administration guides here: How to set up Custom Fields?, Configuring Metrics.

Use built-in Targetprocess fields as a data source. Here are the available fields:

More information: Lead and Cycle Time.

Formulas for Calculated Custom Fields:

Formulas for Metrics:

Using conditional operators, multiple formulas may be combined into a 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.Today - LastCommentDate).TotalHours, (DateTime.Today - CreateDate).TotalHours)

With advanced formulas it is possible to add or subtract a few days, counting only business days. Say, the entities 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 a custom number of days depending on the day of the week:

Custom Formula Metric:
IIF(CreateDate.Value.DayOfWeek.ToString() == "Thursday" || CreateDate.Value.DayOfWeek.ToString() == "Friday", CreateDate.Value.AddDays(4), CreateDate.Value.AddDays(2))

A webhook (Deprecated. Please consider using Automation Rules instead) may be configured to automatically set Planned End Date field for a work item as soon as it is created or enters some particular workflow state.

Display Values on Views

The calculated values can be added to cards on views within Customize Cards feature.

Proactive Warnings

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.

Use the following two features for proactive warnings:

• Visual Encoding
• Custom Mashup Extension

Visual Encoding

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 the syntax of Advanced Filters.

Visual Encoding based on built-in fields

Last State Change Date

In the example below, an SLA value is calculated per each request within a 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:

Planned End Date

In the example below, a due date is set per each work item within a built-in field named PlannedEndDate. We'd like to highlight cards to ember one day prior to the due date. And highlight red the cards that violate the deadline. Use the following Visual Encoding rules for this purpose:

Visual Encoding based on custom calculations

Set up the custom field with a 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, an SLA value is calculated per each request within a 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:

Custom Mashup Extensions

Requests Classes Of Services

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.

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.

Reporting

Reports help to analyze the 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 a 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:

• Difference between planned and actual end dates
• 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 work item. 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.

Difference between planned and actual end dates

The values are provided by Custom Formula Metric. They are calculated and set to the corresponding custom field for each work item. The report uses values of built-in fields as the data source.

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.

More information: Processing Time and Cycle Time Reports.

Reporting on recurrent events

Some events when the response is awaited 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 occurrence of any of these events. Breaches of such SLAs are not recorded by Targetprocess.

See Also

• Tracking Due Dates and Filtering Out Expired Entities
• How to use Targetprocess for customer support