Push to Front - 4 - by Support teams

Push to Front - By Support Teams

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 behaviour, 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 - By Support Teams:

Responses to the questions posed by clients:

• Usage of the ‘push to front’ mechanism for Organization:

  • The ‘push to front’ mechanism is primarily employed for critical or urgent incidents that require swift resolution. These incidents are often related to essential services or serious disruptions in business operations.

  • As for where it is less commonly used, it tends to be in low-priority incidents or service requests that do not directly impact daily operations.

  • Identifying the impact of the activity being resolved, analyzed from the perspective of the applicants, helps to validate the impact on clients. Are they always the same clients who require specialists to get involved?

• The time window for evidence:

  • To identify the time window during which this pattern is evident, it is essential to analyze historical data. Data analytics tools can help determine the times of day or days of the week when there is increased utilization of the ‘push to front’ feature.

  • For instance, there might be an increase during peak working hours or on specific days of the week, such as during new version/release deployments.

  • Our resolution and support levels for all departments are balanced. Is there part of the organization that overloads more than another?

• Paths and impactful variants:

  • The paths and variants with the most impact typically involve critical incidents or recurring situations. These can directly affect productivity and customer satisfaction.

  • Analyzing workflow processes and resolution patterns is crucial to identifying specific paths that generate the most impact. This analysis may include factors such as the number of escalations, resolution duration, and customer satisfaction.

  • Do the departments have any specific behavior? Are there possibilities of lack of homogeneity for reasons specific to each group? Behaviors, growth in the number of tickets or their resolution time, etc. have been identified.

• 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.

  • Is there any correlation with incident priorities? We can identify changes in the behavior of certain groups, which may occur due to external or internal changes to IT service management, but which affect.

Recomendation:

When an organization does not have identified support 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.