Ping & Pong - 2 - Support teams

Ping & Pong - Support Teams

Ping & Pong overview :

In an ideal world, an incident is resolved quickly and without the intervention of too many support teams. However, in many cases, it happens that, support teams start sending incidents to each other again and again (ping pong), which of course is an unwanted situation. There is a correlation between “ping pong” behaviour and the overall duration of an incident.

"Ping pong" is a special type of rework or LOOP, but not between activities but between support teams. This loop can have different ways of being evidenced.

We distinguish two types of ping pong behaviour: "linear" and "circular". Both are characterized by having an unusual number of work transfers between support teams for a specific incident. In the linear behaviour of ping pong, the case goes back and forth between a very small number of teams. Circular ping pong, on the other hand, is characterized by incidents that are continually sent to other support teams, generating loops to explore.

Ping & Pong - Support Teams:

Responses to the questions posed by clients:

• Overview metrics of the ‘Ping & Pong’ mechanism:

  • Due to their impact on the organization, the "ping pong" mechanism is evidenced when support teams exchange a ticket several times with each other. Evidencing an unproductive situation in most cases. If these incidents are related to essential services or disruptions to business operations, this can have very serious implications.

  • Identifying the relationship between the number of steps and the speed of resolution helps organizations identify situations with low productivity, being able to focus on finding the right solution for each case.

  • Find out which are the tickets that suffer from this behavior, detecting if they are of a type of REQUEST, a Support Teams, priority and another value that helps us define what happens and work on the causes.

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