Push to Front - 1- Overview

Push to Front - Overview 

Push to Front overview :

The goal is to manage as many incidents as possible with first-line support teams (frontline). When incidents are escalated to the second and third support line (or higher) too frequently, it creates an additional workload and management burden for those teams. In many cases, this impacts the organization in terms of time and cost. Resolving repetitive incidents is not the teams' primary task of L2, L3 or higher, and having a high dependence on these teams affects the performance of the incident process. The key is to identify and measure how many incidents are currently being resolved at the front line (L1) and how many are at the remaining levels. This helps us understand which incidents have this behavior, what impact this has on times and costs, what categories they are in, what teams handle them, and how it affects the organizational structure.

Push to Front - Overview:

Responses to the questions posed by clients:

• Overview metrics of the ‘Push to Front’ mechanism:

  • Due to their impact on the organisation, the "push to the front" mechanism is mainly used for key, critical or urgent incidents that require rapid resolution. These incidents are typically related to essential services or disruptions to business operations.

  • It can be used less frequently, in low-priority incidents or requests for information (depending on the type of service) if they do not directly affect daily operations.

  • Identifying the number of incidents resolved in the 1st, 2nd and +3rd line, their time and cost is important to assess their impact on performance.

• Evidence of the number of steps.:

  • It is essential to analyze historical data and events to identify this behaviour pattern. It will help us determine if our behaviour aligns with the organisation's service expectations.

  • For example, you can identify what percentage of incidents are resolved on the 1st line, with what time & cost and how many need to involve specialist levels.

  • What impact does this have on times & costs, generating new questions about when and why this happens, it is only for a Service or a type of request, does it only happen for high-priority tickets, in a part of the year, etc?

• Filters & perspectives:

  • Use the filters to perform a Slice & Dice on the data to know the real behaviour of the support lines.

  • Creating a filter with the appropriate questions will help us discover what happens in our service and assess the real impact on the organization.

• Impact on resolution time:

  • When tickets are resolved solely through the intervention of a single level (e.g., L1), the resolution time tends to be faster. This benefits the organization as it reduces the workload at higher levels.

  • However, it is essential to strike a balance with the need for effective ticket resolution. If too many incidents are resolved solely at the first level, with inadequate quality, there could be a negative impact on solution quality or long-term customer satisfaction.

When an organization does not have identified support lines or levels:

It is recommended to handle the information by manually creating these support levels and subsequently loading the data. If the analysis yields positive results for the organization, it can be implemented in JSM for automatic generation.