SLA: Jira Service Management using eazyBI Reporting

At RadBee, we help many Jira Service Management clients to create valuable eazyBI reports for monitoring the performance of their customer service teams and generate specific and targeted analysis toward their goals.

Built-in Jira Service Management reports often do not bring you the perspective you are looking for. What if you need to track each workgroup's performance separately and measure the ticket status and assignment to a specific workgroup while excluding time when tickets are in the waiting for customer status.

In this use case, we’ll review quite a complicated client support management flow and the solution of data import configuration we came across with a help of the eazyBI fantastic support team. You can apply the logic or use the code snippets in case of a similar situation.

What is SLA?

A service level agreement (SLA), is a written understanding between a service provider and their client (internal or external) that outlines the services that will be provided, the expected level of responsiveness, and how the performance will be measured. The SLA will include details like the amount of time that the service will be available and the time required for customer support to respond. Furthermore, the agreement also sets out what happens if the service provider fails to meet the requirements of the agreement.

Can I measure the performance of several service teams?

The customer support team consists of several teams, which we’ll call workgroups. A support ticket can be transferred from one workgroup to another several times. We want to measure the performance of each workgroup throughout the lifecycle of the ticket.

The ticket status can be paused during the support ticket lifespan while waiting for a customer response. During these on-hold periods, we don’t want the time to be counted.

The customer support uses Jira Service Management (“JSM”). We have added the custom field “Workgroup” in Jira, of the type “Group Picker (single group)”. This field indicates the group which is currently assigned to the issue.

Jira Service Management alone cannot provide a granular level of detail within a support ticket lifespan. JSM’s native SLA is on the issue lifespan and cannot be configured to account per each workgroup.

How to track each workgroup's performance separately with eazyBI?

You can extend Jira Service Management reporting capability by using the eazyBI for Jira. It’s possible to import custom fields from the Jira history file in eazyBI. For many standard custom fields, data import requires simply ticking a box. To import calculated custom fields, add JavaScript code to the custom field definition in eazyBI advanced settings. However, we faced a bit more complex situation.

In our case, “Workgroup” is a “Group Picker (single group)” type of field. With the right definition, this field can be imported as a dimension into the eazyBI data cube along with the field history. Together with historical measures, the changes can be analyzed for this field.

When tickets are passed between workgroups during the ticket lifespan, various situations appear. Out-of-the-box eazyBI calculates the total elapsed time between the timestamp when the “Workgroup” value was first entered and the timestamp when the same “Workgroup” value was changed for the last time. Without custom fields, eazyBI cannot take into account the time elapsed while a ticket is in each individual workgroup.

So, we need to track to which “Workgroup” the issue is assigned at a given time. There may be zero, one, or multiple time periods that need to be aggregated for each workgroup. Also, a ticket may come back to the same workgroup more than once. It means that a ticket could be assigned to the same workgroup more than once.

We also want to identify whether the issue has “Active” status–not paused while waiting for customer response. In other words, we need to measure only the “Active” time that elapsed since any workgroup value was assigned and now.

Measure the ticket status and assignment to a specific workgroup

1. As one support ticket may bounce around to any workgroup until it’s closed, we added a definition via eazyBI advanced settings to import the custom field "Workgroup" as a dimension, property, as well as all its changes.
2. While creating a support ticket, the “Workgroup” field must have a value assigned in Jira Service Management.
3. During the ticket lifespan until its resolution (issue status is “Open”), the ticket is considered “Active” as long as it is not paused–waiting for customer response. While a ticket is “Active”, the performance parameters of its workgroup are measured. While the ticket is “Waiting for customer,” we pause the measurement of workgroup performance. The time period in which measurements are paused will not count toward SLA metrics. To account for active and paused time, we add a JavaScript code via eazyBI advanced settings to create a new custom field only for eazyBI reporting needs "Days in Workgroup". It can be imported as a measure and property.

This way, we capture and measure the support ticket events. And stratify them per workgroup, only for the time periods in which the JSM ticket is “Active”.

You can find more details about the created custom calculations in this community post “How to measure the SLA for each workgroup throughout the lifecycle of a ticket”. 

Report Examples

1. The active time of all closed issues per workgroup–how many active days issue closed in a certain month spent in each workgroup.
2. The active time of all open issues in a workgroup–trending report visualizing the accumulated active issues in a workgroup per day.

Notes

• This measure can get complicated if the ticket is assigned to another workgroup before the customer response arrives.
• Another complication arises if the ticket status is changed to “Waiting for customer,” but there is no record of “comment to customer” in the JSM database. We assume that there would be some communication with the customer before going into “waiting for customer” status.
• Unless the issue was handled entirely within the same workgroup, we can’t rely on the definition of “Time to First Response” set in JSM for reporting the performance in eazyBI. For example, if the ticket has a changed “Workgroup” before the first customer comment in JSM, the trigger for “Time to First Response” will never occur. Thus, JSM’s measured time to the first response may be inaccurate.
• “Time to Resolution” (only “Active” time) is the accumulated active time elapsed between ticket creation and its assumed “Close” status.

Jira Service Management provides quite powerful real-time reporting. You can monitor your team's performance and trends in your workload. Despite the option to create your own custom Jira reports to query any combination of performance data, there might be situations when it does not bring you the perspective you are looking for. Try eazyBI Reports and Charts for Jira to customize Jira Service Management reporting.

Read More About eazyBI on Blog:

• Analyze Jira Apps With eazyBI
• Explore Insight Asset Management Data With eazyBI
• eazyBI, Where Is My Jira Data?
• Custom Jira Reports – First Steps With eazyBI