This guide aims to provide an understanding of the Closed vs. Reopened Report, along with a comparison to Jira's standard reporting functionality.

Introduction

In today's rapidly evolving technological landscape, organizations heavily rely on their IT infrastructure to deliver seamless services and support to their customers. Ensuring the smooth functioning of IT services is crucial for maintaining productivity, customer satisfaction, and achieving business goals. This is where ITSM, or Information Technology Service Management, comes into play.

ITSM is a set of practices, policies, and processes designed to manage and deliver IT services effectively and efficiently. It provides a structured framework for organizations to plan, design, deliver, operate, and control their IT services, aligning them with the needs and objectives of the business.

At its core, ITSM aims to enhance the quality of IT services, optimize resource utilization, minimize downtime, and improve customer satisfaction. By implementing ITSM practices, organizations can streamline their IT operations, standardize processes, and establish clear communication channels between IT teams and other business units.

ITSM plays a crucial role in managing and delivering IT services effectively. By implementing ITSM practices, organizations can enhance service quality, improve operational efficiency, and align IT services with business objectives. The various components of ITSM, such as incident management, problem management, change management, service request management, asset and configuration management, and service level management, work together to establish a structured framework for IT service delivery and support. In the following sections, we will focus on a specific aspect of ITSM: the "Closed vs. Reopened" report, which provides insights into incident resolution.

Importance of tracking and analysing closed and reopened incidents

In the world of IT service management (ITSM), incidents are an inevitable part of the landscape. Incidents can range from service disruptions and system failures to software glitches and user errors. Resolving these incidents promptly and effectively is crucial for maintaining smooth IT operations and ensuring customer satisfaction.

However, it is equally important to track and analyse incidents even after they are resolved, as this provides valuable insights for continuous improvement and proactive problem-solving. This is where the significance of tracking and analysing closed and reopened incidents comes into play.

Reopened incidents refer to cases where a previously resolved incident resurfaces due to incomplete resolution, unresolved underlying issues, or other factors. Analysing reopened incidents helps pinpoint weaknesses in the incident management process, identify areas requiring further investigation or improvement, and ensure that incidents are resolved completely on the first attempt.

How can IT Managers benefit from measuring “Closed vs Reopened“?

Understanding metrics like "closed" vs "resolved" can provide valuable insights into your ITSM processes and effectiveness (not only Incident and Request Management!).

1. Measuring Team Performance: By monitoring the closed vs resolved metric, IT teams can measure how effectively they're dealing with incidents, service requests and other types of tickets. If a large number of issues are being reopened after being marked as resolved, it might indicate that problems are not being addressed properly in the first instance.

2. Quality Assurance: The frequency of reopened tickets can provide valuable feedback on the quality of work. High levels of re-opened issues might suggest poor initial resolution, a lack of understanding about the problem, or that the problem is more complex than first assumed.

3. Identifying Trends: Monitoring the ratio of closed to reopened issues over time can reveal trends. A sudden increase in reopened issues, for instance, might suggest new problems with a system or service, or potentially a knowledge gap within the team.

4. Process Improvement: Keeping track of the closed vs resolved issues allows you to identify areas where your service management processes can be improved. For instance, if you find that issues are frequently marked as resolved but are later reopened, this could indicate a need for better problem analysis or more rigorous testing procedures.

5. Customer Satisfaction: It's frustrating for users when issues they thought were resolved reappear. Monitoring the number of reopened issues can therefore provide an indirect measure of customer satisfaction. By minimizing reopened issues, you're likely to improve user experience and satisfaction.

6. Resource Allocation and Planning: The metric allows you to better understand your service desk's workload and capacity planning. If many issues are being reopened, this is an indication that more resources may be needed to ensure issues are fully resolved the first time.

Hence, the closed vs resolved metrics serve as an important KPI for ITSM teams to gauge their efficiency, quality of service, and user satisfaction. They can also provide key insights for strategic planning and resource management.

Understanding the "Closed vs Reopened" Report

When analysing reopened incidents, it's important to identify the reasons behind their recurrence, whether it's due to incomplete resolution, unresolved underlying issues, or other factors. This analysis helps in addressing root causes, improving incident management processes, and ensuring incidents are fully resolved.

The "closed vs Reopened" ratio is calculated by comparing the number of closed incidents to the number of reopened incidents. This ratio provides insights into the effectiveness of incident resolution, as a higher ratio indicates a lower rate of incidents being reopened and suggests better overall incident management performance. Monitoring and analysing this ratio helps in identifying areas for improvement, implementing preventive measures, and ensuring incidents are resolved thoroughly on the first attempt.

Actonic “closed vs Reopened Report” also provides user with Data Source table enabling the quick analysis of when Reopening happened, what was the exact transition, and providing a supportive comment to explain if the transition is counted in the report itself:

What are the differences of the Actonic report against Jira out-of-the-box solution?

In Jira Service Management user could set up a report against Time series for issues closed and issues reopened. To do so, you will need to create Jira Service Management report against two date series:

• Resolved Issues in closed, Closed, done etc statuses

• Resolved Issues in the same statues but ever been in “Reopened“ Status (if you have it introduced in your workflows)

Report will typically look like one shown below:

The default report in Jira doesn't offer insights into the rate of Reopened Issues, which you will need to calculate separately. Additionally, it does not provide information about tickets that have been reopened multiple times. Also, if the "Reopen" status is absent from your workflows for some reason, it will be quite challenging to quantify the occurrence of reopened cases.

In contrast to Jira's built-in reporting, the Actonic "Closed vs Reopened" report allows you to:

• Calculate and visualise the Reopened Issues Rate as a percentage, offering a more actionable metric as compared to the raw counts provided by default in Jira. This accelerates trend analysis and facilitates quicker decision-making.

• Export the Chart, Data Table, and Source data in various formats. This enables a more in-depth analysis using external tools, or the incorporation of report results into other reporting applications.

• Choose whether to count multiple reopen-close situations for a single ticket as one (that is, reporting against the number of tickets reopened) or to count each reopening occurrence (that is, reporting against the number of times reopening occurred). This allows for a more granular analysis and more informed decision-making based on the circumstances.

• Whether the "Reopened" status is a part of your workflows is not an issue. The report calculates actual transitions of the ticket from "Done" (and possible sub-states) back to previous states and then to "Done" again, ensuring that it accurately captures instances of reopening.