Customer Ticket Rate and Volume

1 Report Purpose

The purpose of this report is provide you, the analyst, with insight into how often project personnel receive requests for either new capabilities or bug fixes. What is provided is a measure of the rate (frequency) that tickets are entered into the tracking system. In addition, the volume, or backlog of requests, is also analyzed.

2 Benefits of Reviewing Customer Ticket Rates and Volume

As a product matures, end users typically become complacent with the existing product features and naturally desire additional capabilities or new requirements via feature requests. Early evaluation of these requests is fundamental in maintaining customer satisfaction and allocating resources commensurate with the needs of the product team. With respect to bugs, not all defects are disastrous but they should be caught early so that timely repairs are made as soon as possible. This equates to the Mean Time to Repair/Recover, or MTTR, metric. The customer ticket rate coupled with the customer ticket volume, provides an important indicator into the state of the quality of the product and the proficiency of the product development team to both supply new capabilities as well as repair defects.

3 Report Analytic Parameter Settings

3.1 Setting Explanations

This report can be adjusted by you, the analyst, at report creation time to focus on different time ranges:

3.2 Parameter Settings Used In This Report

The following parameter settings were used:

• Ticket Type:
  • New Feature and Bug
• Interval:
  • day
• Date range:
  • From 2009-12-16 to 2019-06-06

4 Results

4.1 Fundamental Analysis

• Ticket entry rate:
  • On average, a new ticket is submitted every 3.46 days,
  • 50% of tickets enter at a time interval of less than 1.67 days and 50% at a greater time interval,
  • The largest time interval between tickets is 40 days which occurred on 2010-03-22.
• Ticket Type analysis:
  • There were 994 New Feature and Bugs found within the date range provided.
  • Note: Within the date range there were:
    • 521 New Features
      
    • 473 Bugs
      
    • 50 other ticket types (neither New Feature or Bug)

A run chart of Customer Ticket Rates (rounded to the day-level)

A run chart of Customer Ticket Volume (rounded to the day-level)

4.2 Advanced Analysis

The mean Gap Closure Rate (GCR) is -0.42. It is represented graphically by the colored region between the two lines in the above chart.
GCRs >= 0 are good, as they indicate issues are being closed at a rate equal to or greater than the rate of new issues arriving. GCRs of < 0 are a problem as they indicate a potentially run-away situation where issues are growing faster than the ability of the team to address them. Stable user volume alongside increased ticket volume (negative GCR) suggests potential issues in production or testing. High numbers of unresolved issues makes it difficult for the team and management to keep abreast of the status of a project.

5 Recommendations

Before considering the following recommendations you should make sure that the results reported above make sense in the context of the project, that project personnel are receptive to any changes, and that any recommendations to be implemented will help the project perform measurably better in a way that project personnel care about, project leadership cares about, or the project’s customer(s) care about.

If the project is experiencing an excessive (negative) Ticket Closure Rate then the following recommendations are advised:

• The project team lead should periodically examine the backlog of features and/or bugs to determine if any should be closed without action. Work off the high priority issues, establish a cap of total numbers and cancel those deemed not worth the effort to fix or implement.
• If not already implemented on the team, consider a Defect Triage meeting where team members meet to sort out the priority of all open bugs. When and how these open bugs need to be fixed is decided in this Defect Triage Meeting. The objective here is to track all the defects and make sure the correct resolution is implemented in a timely manner. Basically you are going to determine:
  • What you are going to fix now
  • What you are going to fix later
  • And what you are never going to fix
    A similar process can be executed for working off the New Feature requests.
• Utilize an individualized version of this report to determine if the rate started a sudden rise at a particular point in time. Examine the conditions present at that time to gain insight into what can be done to mitigate a similar situation. Are New Feature requests behaving different than Bug fix requests? Is resource re-allocation something to consider?

---