Service management is nothing new for companies. Organizations have been providing services to customers as long as there has been business. The Managed Services Provider (MSP) space is a different story, as companies that provide managed services to small businesses has really only been a thing for about 25 years. Before that the idea of a managed service was only understood in the context of large companies providing services to other large companies. For enterprise IT departments and specifically MSPs, providing service to customers is paramount to what they do and heavily influences their ability to be successful. This article will discuss service management within an MSP, specifically how the “helpdesk” function of an MSP is structured to provide services to customers. While there are many ways to do this (which we will discuss in another post), the most popular are often stated as “tiered systems” versus “pods.”
What is service management?
Service management is how an organization manages the resources required to provide services to their customers. The ultimate goal of any service management system is meeting the needs of the customer in the most efficient way possible. There are many things to consider when designing a service management system. Some of them include the speed of delivering service, the efficient use of resources, the scalability of the system, and the resilience of the structure to name a few. Customers want a service that is delivered in the most timely way possible, but service managers have to weigh that desire with the cost of providing the service. The most cost effective way to provide services is to make sure the resource that handles a request is a match for the skill level required.
Many organizations choose to hire only top professionals so they can provide the highest level of service. This typically backfires though as top talent is costly and most incoming requests don’t require a high skill level. Lower level tasks also have a tendency to bore higher level engineers, leading to short employee tenure. The key is to accurately match the skill level needed based on the number of tickets/incidents received. So if 80% of your tickets are Tier 1 level tickets, then 80% of your resources should be Tier 1 staff. If 15% of your tickets are Tier 2 level, then you need 15% of your staff to be Tier 2. This is an oversimplification but does give you an idea of what the ultimate goal would be. In the end, you should have a system that is speedy to respond, efficient in the use of resources (to guard margins), and scalable as you grow the business. Lastly, resilience is paramount. You cannot have a model that falls apart when a few employees leave the company or a few folks call in sick.
Service Management Structures
There are many ways to design a service management structure and certainly variations within each model, but let’s focus on the two most popular. “Tiers” as we will call it, is a way to structure your helpdesk into levels of talent. So you may have a Tier 1 level, Tier 2 level, Tier 3 level and so on. The idea here is to force all calls through Tier 1 to ensure the lowest level issues don’t occupy the time of your highest paid employees. This is common because it is easy for companies to categorize employees by their skill level. It also provides a visible path for employees to work towards as they grow. As the company increases in size, the tiers can be supplemented through the use of subject matter experts (SME) that focus on only one task or technology. Having technicians that focus only on “quick fix” tickets, “Office 365” or “backup tickets” is an example of the SME concept and is typically necessary once the amount of tickets in a particular area reaches a level where it is justified to hire a full time employee to perform those tasks. This helps to scale, provides consistency in those SME areas, and provides further career pathing for incoming employees.
Another way to structure your service desk is most commonly called “pods.” A pod is a group of individuals that form a support team. Typically these teams are 6-12 employees that are assigned a book of business which can range from 30-100 customers. The idea of pods is to structure your service so that companies always talk to technicians they know, and that technicians limit the number of clients they work with so they can be more intimately knowledgeable of those environments. In a typical pod you normally have technicians that perform many roles. While some have clearly defined roles (field engineer, helpdesk, account manager) it is more common that each person within the pod can perform any role necessary. Some companies that use the pods system will have only support personnel within the pod while others will include an account manager and sometimes a customer service rep to help with scheduling and ticket triage. This system scales as more pods can be added as the company grows.
Using Service Management Tiers
Should you use tiers or pods? Let’s look at the pros and cons of each approach so you can make an informed decision. In the end, the goal is the satisfaction of the customer. Use this as a measure of success. Also, have some patience. Just because something does not seem like it is right for your environment, it does not mean it won’t work. There are tweaks for each model that may meet certain needs (like the use of a dispatcher), so don’t throw the baby out with the bathwater if you get frustrated. The key is to analyze what is working and what is not working to ensure you find what works best for you.
The tiers concept is very common and typically the go-to model for large companies that need to support several thousand users or more. As stated above this model has many advantages. Categorizing employees based on skill set is an easy way to structure the tiers. Most users of this model try hard to create a support “pyramid” so that there are far more level 1 technicians than level 2 technicians. The same goes for level 3 versus level 2. This pyramid structure is cost effective as level 1 technicians are less expensive than level 2 or level 3. This also strongly supports the growth of the team assuming the environmental culture encourages training and mentoring. From a hiring standpoint, you can always hire in at the bottom and be moving folks up the ladder. Clearly defining the tiers and communicating these requirements to staff supports the idea of career paths, which has been known to increase employee engagement.
The downside of tiers is the distance you put between your customer environments and your staff. While a tech can probably be familiar with 30 or 40 environments, at some point they lose the ability to know them all well. For those that use tiers they typically have a strong culture of documentation to assist with this deficiency. Without strong documentation, the time to close tickets can grow over time, making customers feel like you don’t know anything about their network. (Have you called Comcast lately?) For tiers to work properly it is also important that customers be a similar size. If you are selling to large and small customers (which is not recommended) your tiers will struggle to provide the appropriate support due to the large range of different technologies or technology levels in use. It will make defining what a “tier 1” technician is very difficult as what is a tier 1 that supports companies of 10-20 employees is different than a tier 1 that must support companies of several hundred.
Using Service Management Pods
Using pods is very appealing. For most MSP’s they want their customers to have the best experience and many build their business and service management with the goal of communicating the “local feel” of support. They want customers to feel like the company is small even when it is growing by leaps and bounds. They use the pods structure to always ensure the clients get the same individuals onsite as well as in their remote interactions. This part of the pods system works great and is known to encourage long term clients. This concept also increases the use of “tribal knowledge” within each pod, which can speed the support times (although it can put extra pressure on training new people.) Documentation becomes less important than in the tiered model, since the technicians are already familiar with all environments they support.
The pods model does not come without challenges. The main challenge is a lack of efficiency. In the pods system, it is possible to have high level resources sitting on their hands in one pod while others are overwhelmed with work in another. This can be managed, but sometimes it takes time before the problems are discovered and resources are reassigned or borrowed by other pods. Management of employees can be challenging as a manager usually sits over several pods and may find it difficult to figure out what is going on at any given time. The use of pod leaders or supervisors can alleviate some of these issues, but the model itself is not built for efficiency, but the preservation of tribal knowledge. The other issue that seems to be common is the lack of resiliency. When one or two techs in a group of 20 call in sick the load is easily distributed to others, but if 2 call in sick in a pod it can be devastating as a higher percentage of the resources is missing from the service team. Some have solved these issues with floaters that come to work each day floating between pods, but this works against the system goals themselves. Further, employees that leave the company create giant holes that are difficult to fill quickly and are felt by the customer.
Choosing the right model
There is no “right” model as there are successful MSP’s using each of the two models. Also, the way you use dispatchers within each model can change the effects of each framework quite a bit. You should pick the model that works best for your organization. Before you decide to abandon a model that you have put in place, dig a little deeper into what is causing it to fail. Many times the failure of a model is not the model itself, but a lack of accountability. To read more about a culture of accountability, head over to Richardson and Richardson Consulting where they have an article on the topic.
Here is a helpful hint. If your organization decides to go with the tier model, make sure you build a culture of training (in addition to accountability) so that you can bring in entry level staff and move them up through the ranks. Focus on career pathing and work hard to communicate the paths to your staff. This will increase employee engagement and you will have employees longer. If you decide to use the pods model, focus your energy on documentation so technicians don’t get too comfortable with clients that they feel documentation is not necessary. Also make sure you have a plan in place for when multiple folks on the same team call in sick. Cross training can help in these circumstances. A strong time sheet submittal and approval process can also help considerably so you will know when you have resource issues.
As always, if you need assistance with your service management, check out the RedVine Service Delivery Framework. It can shed light on the best way to manage a service department and works with either the tiers model or the pods model. If you need further assistance, contact us for a free no obligation conversation about your team.
