Why your MSP shouldn’t rely on technician group chat for escalations

MSPs have utilized group chat for internal communications amongst technicians especially now with the current pandemic. 

Using group chat serves as a quick means to communicate amongst team members. It has also become a means for technicians to raise escalations, or bring up general difficulties, while working on tickets.

Why do MSPs use group chat?

The instinct is obvious and the idea is simple. Since all technicians are in the same group, it becomes the default place to go for assistance. What usually happens is:

1. A technician needs assistance or to escalate a ticket.
2. They message the group chat for help.
3. Ideally, a technician responds quickly with either a resolution or next steps.

Common problems with group chat

Though the above approach appears simple and effective, in practice, this is not always the case. Reliance on this approach gives a false illusion of efficiency because of the inherent flaws of group chats. Some shortcomings include:

• A technician might not respond right away, or at a later point, or possibly never.
• The plea for assistance gets lost in the chat. 
• The ticket sits in the queue, neglected and getting stale. 

Some possible solutions and alternatives

Reliance on this method of escalating tickets needs to be changed. This is not to say that there are no positive aspects to using a group chat. Elements can be incorporated into a proper escalation system.

1. First, we need to identify the inherent flaws of using solely chat for ticket escalation. 
2. We can then implement a policy of ticket ownership-based escalations.
3. Combine positive elements of chat with ticket ownership-based escalation.

Combining elements of live chat with strict procedure and documentation, we get a system of escalation that ensures tickets will get escalated properly up the chain instead of going unnoticed in the chat and going stale.

Group chat, pros and cons

The effectiveness of using group chat for escalation works in some situations and is predominantly based on the size of the MSP and how many members are in the chat.

Group chat for escalations has its advantages. It can grab the attention of a technician right away if they are available to assist. Available technicians can give instructions or suggestions that can provide a quick resolution.

Though with these advantages, come some disadvantages as well. They are listed and discussed below.

1. Escalations occur off-ticket.
2. Signal to noise ratio.
3. Temporary nature of chat.
4. No transfer of ownership.

Escalation request occurs off-ticket

When an escalation request occurs off-ticket, there is no record of the technician reaching out to other members in the group chat within the ticket. This can cause issues further down the line if, for example, the ticket is not resolved and goes stale possibly causing blow-back for the technician from the client. 

You want to have all actions taken by the technician on the ticket for accountability. If there is no quick resolution and there is an investigation as to why it took so long, saying that you asked the group chat for assistance might not be a sufficient excuse. All this needs to be stated in the ticket.

Signal to noise ratio

The signal to noise ratio in group chats can have a lot of irrelevant topics brought up. It can include everything from general greetings, news, announcements, office banter; a lot of topics. If non-technical topics go on for a while, an escalation request can be lost in the flood of messages. 

Notifications can build up with a group chat and technicians can just mute the chat if they are busy or working on something, ignoring the escalation request since it can contribute to general background noise.

Temporary nature of chat

The temporary nature of chat is also another problem. If the request is not picked up right away, the request gets buried with every subsequent message and is forever lost. Rarely will a busy technician comb through the many messages looking for a request. Once it has passed, it will never come back unless brought up again.

No transfer of ownership

Escalating requests within the group chat does not transfer ownership of the ticket. The ticket will remain with the original technician while they wait for a response. During this time, the technician needing assistance can get distracted while waiting; more urgent tickets can get assigned to their queue, for example, that require their immediate attention. During all this time, the ticket is still assigned to the original technician, going stale, and, more importantly, not getting the attention it deserves.

Relying on live chat for escalations can impact the MSP as well. Since tickets are not being looked at promptly, they will sit in the technicians’ queue, getting stale. With resolutions not provided for tickets quickly and effectively, the client has to increasingly wait if the ticket has to be escalated. The client will frequently follow up with the request, with the technician again using the group chat for assistance. Only when the client complains to senior management will this get the attention it deserves. By that point, the technician assigned will get blowback and the MSP’s reputation will be negatively impacted.

Using a proper ownership-based escalation policy

With all of the inherent problems outlined above of using a group chat for escalation, let us discuss how having a proper escalation policy can overcome these pitfalls. 

Having an organized, proper ownership-based escalation policy allows technicians to complete all necessary tasks as much as their ability allows before the ticket is escalated to the next technician. It ensures that tickets will not go stale in anyone’s queue as technicians wait for a response from the group chat to get assistance.

What to do when technicians are not able to resolve tickets

When technicians are not able to resolve the ticket, instead of reaching out for assistance in the chat, they should:

1. Complete all possible notes on work that they have done in the ticket.
2. Either assign the ticket to a dispatcher or remove themselves from the ticket.

Complete internal notes

The first and most important step here is to complete internal notes stating what has and needs to be done so the next technician will be informed. All information is contained within the ticket so if it is picked up by anyone, it can quickly be assessed what the next steps are, and no need to follow up via chat with the original technician for clarification.

The dispatcher can take the ticket, find the next available senior technician, or whomever the MSP has designated as the first point of escalation, and assign the ticket to them or pass it along the escalation chain.

Assign the ticket to dispatcher/remove yourself from the ticket

Another approach is to have the engineer complete all necessary notes and to simply remove themselves as a resource from the ticket. The ticket will then go into the unassigned queue where a dispatcher, or whoever assigns out tickets, has a look at the notes, and assigns it out.

Psychological benefits

Both of the above approaches, either assigning out to a dispatcher or removing themselves from the ticket, will have a psychological aspect to it as well for the initial technician assigned to the ticket. It will remove the ticket from their queue, effectively removing it ‘off their plate’. 

Having a technician’s queue filled with incomplete tickets, in constant ‘Waiting’ status, adds a demoralizing aspect. The lack of traction, or movement, on these tickets, constantly diverts attention away from tickets that are newer and potentially doable within a short amount of time. Technicians will be more productive if they get a constant stream of workable tickets instead of being stuck on one or several of them.

In Short…

Technicians need to get into the habit of writing good internal notes while the MSP needs to have a system that re-assigns these unassigned tickets. A dispatcher, or a designated technician working the unassigned queue, can reassign tickets out, gaining traction up the escalation chain. The above policy can only be effective if they are done proactively with each ticket that needs escalation.

The technician needs to get into the habit of using the above procedure to initiate the escalation process and not have tickets linger in their queue.

A better way forward – combining the best of both worlds

As outlined above, having an ownership-based escalation model can remove many of the pitfalls that simple chat escalations can produce. If done correctly, it ensures that tickets that require escalation are moved up the chain with all relevant information.

This is not to say that there are no good aspects of group chat escalations and that it should be avoided. On the contrary, positive aspects of group chat can be used in conjunction with a proper escalation policy to ensure the potential of quick resolutions and, if no assistance is provided via chat, the ticket can be looked at by another technician without going stale

Example of a system to address the issues

Group chat, or live, escalations can work in conjunction with ownership transfer escalations. We can use both to create a new system such as the one below.

1. Technicians have 30 minutes to solve the issue.
2. If they are unable to solve in that amount of time, they reach out for a live escalation in the group chat.
3. Technician waits 15 minutes and if they get a response, great. Ticket resolved.
4. If there is no response, the technician completes internal notes within the ticket.
5. The technician removes themselves from the ticket or they assign the ticket to a dispatcher.

Internal Notes

Internal notes would include

• the issue as it stands
• things done to resolve the issue
• why the technician is unable to solve it (either lack of technical skills, specific knowledge, etc.)
• possible next steps
• other relevant information (such as call backs and client communications regarding the issue)

If there’s no dispatcher

If the MSP has no dispatcher in place, reassigning the ticket would depend on the system that they have in place. If the technician removes themselves from the ticket, a client manager, designated senior technician, or whoever would be responsible, would pick up the ticket. All they would need to do is to look at the internal notes the initial engineer left.

With the above hybrid system, the ticket no longer just sits in the technician’s queue, getting stale and not being looked at. It is proactively being moved along the chain and getting the proper attention it requires for a quick resolution.

Conclusion

We can see after we have identified the problems of using group chat, it no longer appears as a reliable means for escalations. For its advantages of instantaneous communication, there are numerous pitfalls, and also risks of neglecting tickets, if this is the sole method for escalating tickets. 

As outlined above as well, implementing a policy of ownership-based escalations, either by means of a Dispatcher or the technician removing themselves from the ticket, ensures tickets are passed along the escalation chain. This method, however, is dependent on technicians completing all possible ticket notes, ensuring all information is contained and can be understood by anyone reading it. 

Though using group chat has its drawbacks, we can use its benefits to create a proactive system of escalation. It shifts emphasis away from using chat escalation solely and incorporates a policy of ownership-based escalation to overcome this MSP worst practice.

At Support Adventure, a recruitment agency for MSPs, we are quite familiar with these practices and their effects. We can provide a consultation for an effective communications policy for your MSP as well as provide staffing to affect these policies.

With experience finding positions for over 200 remote technicians and other help desk professionals, while helping 100+ MSPs hire remote staff, we are confident in our ability to meet your staffing needs. For more details or to become a client, please visit our MSP Staffing services page.