Technicians in Ring Groups -There’s only so much a person can take!

There’s only so much a person can take

I just left a position at an MSP because I couldn’t handle answering the phone anymore.

The MSP was fairly organized and all members of staff were easily approachable. There was this sense that everyone was in it together and willing to help each other.

I had watched it grow over the years. The amount of clients and supported users, implementation of new RMM tools, ticketing systems, documentation platforms, even how to write proper ticket notes, and  escalation procedures. It was, for a time, a great MSP and seemed to embody good practices.

Despite that, a recent event laid bare a deep flaw in the way the MSP operated.

Imagine this scenario. It is mid-september and there is a spike in service requests. Two members of staff quit just before this. We have onboarded new clients recently, adding about 150 new users – this increases our total number of supported users to 1500+.

Increased call and ticket activity ensues with limited staff to assist. Compounding the problem is that all technicians are in a call group. This meant that each of us had to answer 20-25 calls per day while working on a queue of tickets that seems to constantly hover in the mid to high 20s. For two weeks. Stating it was a ‘busy’ couple of weeks was an understatement.

The amount of calls that I had to answer were extremely distracting and mentally draining.

There was rarely an instant where I answered the call and could say “Sure! I can assist with that.” or similar. It was simply too busy.

Client expectations were such that they were used to getting assistance right away, no matter what the issue was, over the phone. And their demeanour changed when I stated that I could not help them right away.

There wasn’t much I could do. I had to listen to clients explain why their issue was urgent, why they needed this looked at right away, how they wanted to speak with someone else that could. All I could say was that we are all busy, we will try to assist as soon as we are able. I couldn’t get a break. There was pressure from all sides with no sign of relief anywhere in sight.

If I was not in a call group, answering the constant barrage of calls, I would have been able to handle this increase in activity. I would have been able to work on my queue of tickets, with full attention, and slowly close them off. Technicians would have been able to focus on tickets that have already been submitted and are in the queue instead of jumping to callers that rang about any issue or question.

If there was a simple change in how calls were handled by the MSP, it could have shielded technicians from distractions that did not need to be there, and, more importantly, provided a consistent level of service to the clients.

What is having all technicians in a call group? When does it work?

Having all available technicians in a call group is a great example of a MSP worst practice.

It entails having all technicians answer all calls with the intention that issues will be addressed and resolved right away, if not quickly. For this practice to work effectively, the amount of supported users needs to be relatively small, allowing the technicians to manage the influx of calls with sufficient attention to complete each ticket.

This can work for a time as it conveys a sense of customer-centric service, whereby users can feel comfortable in the fact that they can have their problems addressed right away.

This was indeed the case with the MSP I worked with. There was a sense of familiarity between the technicians and the clients; they knew each other very well, calls were made directly to technicians without submitting tickets via email, and when tickets were submitted, they were addressed to technicians directly.

You can see how having all technicians in a call group works here. When I first started working for them, it was very manageable to handle the phone while working on tickets. There were not many new clients and it more or less worked out like this, for a while.

Nothing lasts forever 

As we got more clients, there was a change. There was more emphasis on uniform practice, documentation, and we switched RMM and CRM providers as well.

The call group remained albeit in a different form. Not many technicians were answering the phones due to the increase in calls and ticket volumes. To remedy this, the call group configuration was changed so that it no longer rang for everyone but it rang for only the last technician in the group that answered a call. Meaning, if you did not answer the call, it went directly to the technician’s voicemail or was dropped, forcing them to answer the call.

This is when the phones started to become more stressful. There was not so much pressure before to answer if you were busy since somebody else could. Now you had to answer it if it rang. I cannot emphasise how distracting this was. It was already annoying to have to listen to the phone when it rings, wondering if I should pick up the phone or if another technician will answer.

With this ring group change, everytime I heard that chime, I paused for a second and prepared myself for literally any possible scenario – because it could have been anything: a sales call, a general inquiry, an urgent request, a non-urgent request, a third-party vendor, or a user following up on another ticket. This also made every technician a switchboard, having to know to whom to transfer the call to and waste precious time sending the call out.

The worst part about it was that if this was regarding another technician’s ticket, and they were not available, or if it was urgent, it was up to the person that answered the call to assist. I, who have no idea what this issue was, regardless of what I was doing, have to drop everything, and get absorbed into this ticket because the technician who was either off, on site, or whatever reason. It was up to each technician to have to go through this added activity.

The added stress was starting to gather. And, more importantly, this practice started to instill cognitive dissonance with the client, or anyone who called in general, that whatever the technician is doing is not important and they should drop whatever they were doing to assist the call. Management should have taken the hint and not tried to entrench the call group model if it was not working.

All calls and no focus makes Jack a dull tech

As we began to get more clients, the ticket volume, as well as the frequency of calls, increased. And this began to take a toll on me. After any given day, I was mentally exhausted because of all the juggling I had to do. The stress of having to deal with clients’ urgency added to this since they will demand their issue be looked at right away – especially if that is what they have expected and received in the past as consistent service from other technicians. 

What I essentially had to do with every call was to negotiate with the user and manage their expectations while trying to resolve tickets in my queue. I ended up working in a free-for-all environment where everyone was multitasking phone duties while simultaneously working on tickets. It was quite the challenge to get used to this.

It became rare for me to work on tickets without me being interrupted – there was always at least one phone call interruption per ticket. It was not that common to have sufficient time to prepare for calls (retrieve login credentials, initial research of issue) since as soon as I was prepared, or was in the right headspace, I was immediately removed from that when I heard that chime. It was as if I lost my place and I had to find it every time I ended that call and go back to the ticket.

I became so resentful of the phone. It made me look at it as a source of stress, distraction, a draining force. It tainted everything that came out of it. Even calls from people that were not demanding but just wanted to simply follow up on the ticket status, began to be placed in that light.

Simple password resets, a call transfer to a technician – all of this was due to the structure in place. It made me recoil and not want to reach out to people as I have before. The insistent calls were taking away from my queue of tickets that I worked on.

There were numerous instances where while working on a ticket an end user had given me a limited window to access their computer and I would get a call. The caller just wanted something simple, like admin credentials to install an app, a password reset, or some small initial issue that sounded easy to resolve. It made me sound dismissive that I could not assist them because I was in a time constraint and couldn’t help them. I would constantly hear ‘But X always helps when I call.’ What was I to do? Explain to them the inherent flaws of the MSPs system? No, I couldn’t, I had to tell that I couldn’t even though I wanted to help them.

Flaws in the system

The problem here is with the system that is in place. Despite having good documentation, CRM and RMM platforms, and emphasizing proper ticket notes and escalations, having all technicians in a call group was one that was inherently flawed and most in need of updating. It is placing unnecessary work on technicians and undercutting all the other efficiencies and practices in place. More importantly, education of the client was not done to prioritise sending requests via email instead of the phone.

A user calling to raise an issue, no matter the urgency, because of previous experiences of immediate attention to issues, is a great example of mismanaged expectations.  There are instances where this has, in my experience, gotten out of hand with users calling, demanding immediate attention to an issue as critical as an external display or keyboard not working on their laptop. These issues are not critical.

The above example creates an inconsistent helpdesk experience for the user whereby, depending on the technician the user reaches, can get a different experience based on the technician’s workload. These inconsistencies were also compounded by other members of staff. They would simply state to clients to ‘call the helpdesk’ if they had any further issues.

The problem with this was that the other technicians did not raise this as a ticket in the system and was through their personal work email correspondence. None of this was actually in the CRM ticketing system. They should have raised a ticket for the end user, given them the ticket number, and said to give this ticket number to the helpdesk instead of making them raise one on their behalf, adding to their workload. 

Think of your technicians – do not have them in a call group!

It is not difficult to see how the scenario described at the beginning was the straw that broke the camel’s back and made me leave. Had I simply not been exposed to the large amount of phone calls, and their added extra work, I would have been able to perform my duties without distractions, added stress, and with more energy when I worked on tickets. For me personally, having the peace of mind that I can focus on one ticket at a time, to give all my attention to a specific issue, is the ideal. No interruptions, no random phone calls, just enough time to prepare and reach out to the end user with a resolution. I am happy, the user is happy, everyone is happy.

Having all technicians in the same call group was a practice that should have been changed as the MSP began to scale upwards and increase the amount of clients. The MSP should have implemented a system of shielding the technicians from the incessant calls. A uniform experience for all clients when they called should have been created, rather than exposing clients to technicians that either could or could not assist them. I would have gladly helped users had the MSP simply not forced me to juggle incoming calls and my queue of tickets.

What would also help to remedy this problem is to make the client aware of when to use the phone and when to send an email. The system in my previous MSP did not shift emphasis away from phones as it increased the amount of users. It should not have been up to me to negotiate with every user while I was busy when someone would be available to get back to them, especially when we were all working from home and it was difficult to instantly communicate with everyone.

We can see from the above how the practice of having all technicians in a ring group is not a good practice. It creates a free-for-all, every technician for themselves environment, picking up all calls regardless of what they are doing. It is a practice that works up to a point, particularly when the workload is underwhelming with less telephony and ticket traffic, and technicians have enough time to work on their own tickets and answer calls. When your business begins to grow and there is an increase in traffic, this practice becomes responsible for undesirable working conditions for the technicians and an inconsistent experience for customers that reflects poorly on the technician and the MSP. Do the technician a favour, and your MSP, do not have them in a call group!

If you are looking for the best remote MSP staff, check out our remote MSP staff page and start hiring today!