Using EazyBI to report Jira Service Management SLAs

At RadBee, we’re able to help many of our clients who are using Jira Service Management to better use EazyBI for monitoring the performance of their customer service teams and generate specific and targeted reports toward that goal.

This story is the product of an exceptionally complicated client support situation. We found ourselves closely interacting with EazyBI’s fantastic support team, in order to configure specific data import capabilities into EazyBI. You’re welcome to use the logic and code provided at the end, if you face a similar situation.

Applicable scenario: Service calls are handled by several team, so we need to measure the performance of each

You’re the customer support manager and your customer support staff consists of several teams, which we’ll call “workgroups.” A support ticket can “move” several times from one workgroup to another. You need to measure the performance of each workgroup separately, throughout the life cycle of the ticket.

Also, during the support ticket lifespan, there may be times during which the ticket status may be on pause while waiting for a customer response. During these pause periods, you don’t want the time to be counted.

Your customer support runs on Jira Service Management (“JSM”) and you configured in Jira the custom field WORKGROUP, of the type “Group Picker (single group).” At any given time, this field indicates the group which is currently assigned to the issue.

But Jira Service Management alone cannot provide a granular level of detail within a support ticket lifespan; JSM’s native SLA are on the issue lifespan and cannot be configured to account per each WORKGROUP. The solution: use the EazyBI App, to extend the capability of Jira Service Management , and report performance metrics for each workgroup separately.

The complexities in this scenario

Generally, it’s possible to import into EazyBI data related to custom fields from the Jira history file, and there are many standard custom fields for which data import requires simply ticking a box. For importing data related to calculated custom fields, JavaScript code can be added to the custom field definition via EazyBI’s Advanced Settings. Some custom fields are “EazyBI-friendly,” but our specific scenario is extra complicated. Why?

In our story, WORKGROUP is a “Group Picker (single group)” type of field. So far so good – with the right definition its history can be imported into the EazyBI cube and can be used as a dimension. And when EazyBI imports, from Jira’s issue changelog, the sequence of value changes for the WORKGROUP custom field, ticket time for each workgroup can be calculated.

But when tickets pass between workgroups during the ticket lifespan, various additional situations which require calculations become relevant, and these are not trivial to implement. Out-of-the-box EazyBI only 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.

In our scenario, EazyBI needed the capability to track to which WORKGROUP value the issue is assigned at any point in time. For each workgroup, there may be zero, one, or multiple time periods that need to be aggregated. Also, a ticket may come back to the same workgroup more than once, which means that a ticket could be assigned the same WORKGROUP value more than once.

We also needed the ability to identify whether the issue has ACTIVE status – not paused while waiting for customer response. In other words, we needed to measure only the ACTIVE time that elapsed since any workgroup value was assigned and NOW.

The solution

The solution works as follows:

1. Because a support ticket may bounce around between any of the workgroups until it’s closed, we added via EazyBI’s Advanced Settings a JavaScript code to create the custom field definition WORKGROUP which can be imported as dimension, properties and change records can be imported.
2. In Jira Service Management , when a support ticket is created, the WORKGROUP field must be assigned a value.
3. During the ticket lifespan, until its resolution (issue status is OPEN): The ticket is considered ACTIVE as long as it is NOT in a status of “Waiting for customer.” While a ticket is active, the performance parameters of its workgroup are being measured.

   While the ticket is “Waiting for customer,” we PAUSE measurement of its workgroup performance. In other words, the time period in which measurements are paused will not count toward SLA metrics. To account for active and paused time, we added via EazyBI’s Advanced Settings a JavaScript code to create DAYS IN WORKGROUP that can be imported as a measure and property.

To summarize: we capture and measure the support ticket events, and stratify them per workgroup, only for the time periods in which the JSM ticket is deemed to be active.

Here’s how this metric is calculated:

• For OPEN tickets:
  1. ISSUE AGE is the time elapsed between ticket creation and NOW.
  2. ACTIVE TIME in each workgroup; the time elapsed between the ticket creation and NOW, minus the time period during which it was paused (waiting for customer).
  3. ACCUMULATED ACTIVE TIME across all workgroups: the total ACTIVE TIME the ticket spends in all workgroups, with the ability to drill down to a level of workgroup and specific time period.
• For CLOSED tickets:
  1. ACTIVE TIME and ACCUMULATED ACTIVE TIME work the same as for OPEN tickets.
  2. ISSUE AGE is provided by existing EazyBI measures, so no special implementation is required.

Based on these metrics we could measure and create reports for:

• TIME TO FIRST RESPONSE in each workgroup – the ACTIVE time elapsed from the assignment of an issue to a certain workgroup until the time a first comment was made to the customer in that same workgroup.

Notes

• This measure can get complicated if, before the customer response arrives, the ticket is assigned to another workgroup.
• 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 before going into “waiting for customer” status, there would be some communication with the customer.
• 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 on EazyBI. For example in JSM, if the ticket has a changed WORKGROUP value before the first customer comment, the trigger for “time to first response” will never occur. Therefore, JSM’s measured time to first response may be inaccurate.
• TIME TO RESOLUTION (only ACTIVE time) is the accumulated active time elapsed between a ticket creation and its assumed CLOSE status.

Here are the two measures configured for us by the EazyBI support team, using Java script that was added into EazyBI via System Settings / Advanced Settings:

• For resolved tickets: A measure that calculates the ACTIVE TIME for each WORKGROUP value the ticket was assigned. Once the ticket is resolved, the measure calculates the time between transition to the last workgroup value and the ticket’s CLOSED status.
• For unresolved tickets: A measure that calculates the ACTIVE TIME elapsed between the last transition into a WORKGROUP value and NOW.

In addition to these predefined measures, we added two measures under Define new calculated measure, to allow queries of the EasyBI Cube with and without the time dimension.

Report Examples

• Active time of all closed issues in a workgroup, by month

  

  How many active days issues that were closed in a certain month spent in a certain workgroup

• Trending: Active time of all open issues in a workgroup in a certain month

  Trending report visualizing per day the accumulated active issues in a workgroup in a certain month

Code snippets

Blog posts in this series:

1. How we Saved a medical device company time, compliance headaches and money
2. How paperless validation assists pharma success
3. Painless migration from Excel