Support Adventure - The premium MSP staffing company

MSP Best Practices

At Support Adventure, we have helped over 50 MSPs improve their processes by helping them implement the MSP best practices we have collected over the years. In doing so, we have helped them optimize their MSP’s services and structure to become both more efficient and more customer and employee-friendly. Our bird’s-eye view of the MSP industry gives us a perspective that allows us to see what works and what doesn’t for MSPs of all sizes supporting clients in a wide range of industries.

We’re constantly updating the information we’ve gathered on our MSP blog, as well as providing a summary of MSP industry best practices on the page before you. If you’d like to add something to the list, disagree with something we’ve posted, or find valuable information to help you run your MSP and just want to say thanks, please leave a comment below.

Are you looking for someone to help you elevate your MSP game or not sure how to apply these MSP best practices yourself? We’re here to help. Contact us using our Become a Client form today to start the conversation!

MSP Best Practices

MSP Communication Policy

When you’re the owner of an MSP, you’re probably getting bombarded with notifications from every direction.

You might have an inbox that’s full of all sorts of random messages from clients and staff. Your phone is often ringing nonstop and you’re receiving chat messages from various staff members. It can be absolute chaos!


Oftentimes, when MSPs grow into large organizations, they fail to put in place one very important thing: a communication policy. There are many ways to communicate in an MSP environment, but the base camp for communication should always be the ticketing system. This is where all records and notes for cases should be kept in an organized fashion. Your staff must use the ticketing system correctly and keep information there in an orderly fashion, otherwise there could be negative consequences. For instance, if you get a complaint from a client and need to review a staff member’s work, it can be very hard to figure out what actually happened without proper incident reporting and note taking. Every MSP needs to have a well defined note-taking policy for their engineers that establishes:

  1. Which specific details need to be documented in the ticketing system.
  2. What the policy is for logging any communication outside of that ticketing system.

After-all, the whole idea of a communication policy in an MSP is to have a system that separates urgent matters from the non-urgent ones. Urgent items of information can then easily get in front of the people who most need to know about them to make fast-acting decisions. The non-urgent matters also get dealt with, but in a systematic way where they are not disrupting the more time-sensitive issues.


At Support Adventure, we have a ticket note writing guide that we give to all of our new clients for free, very few of them have their own and they often find the ideas we’ve compiled to be very useful and in line with what they always wanted ticket notes to look like. A key part of the guide is that every case note should end with one of four things:

  1. Ticket Resolved: The case/task/project is resolved and no further action is needed apart from whatever post-ticket review procedures are in place.
  2. Next Steps: The person assigned to the tickets takes ownership and has a plan for moving forward with the case/task/project.
  3. Waiting For: Resolution of the case is pending due to waiting on a vendor, third party, client response, etc.
  4. Escalation Required: The worker assigned to the case does not have the time, resources or ability to complete the case/task/project. The ticket is flagged to be reassigned to someone who can resolve it.


Your communication policy must define what happens when documentation is missing and how that is dealt with. Here’s an example of a common dilemma: William is a senior technician who was on site last week to set up a printer but he failed to do the following:

  • Write comprehensive enough ticket notes about the steps he followed.
  • Include specific details about the printer set up which really need to be documented, such as the IP Address.
  • Document which drivers to use and where to find them and how to install them.

Does it go through dispatch? How do you later compile and review incidents of missing documentation and ensure that there is a concerted effort to reducing their occurrence? A system should be created to look at this at a periodic basis.


What happens if something urgent occurs? You need to define:

  • What is urgent.
  • What the threshold should be for urgent tickets.
  • What triggers this policy? Eg. a whole network down, a major data breach, major data loss, VIP users, etc.
  • Who will be alerted in these situations and how.

If you are a service manager and you want to be notified every time there’s a complaint about a technician, put that in your communication policy and give clear instructions in writing to your staff on how they are supposed to notify you. Include what type of information you want to be sent to you and where to send it (email, phone call, assigned ticket, chat message, or a combination of the above).


For emergency circumstances, we recommend MSPs use an incident management tool like PagerDuty or Opsgenie. Rather than calling in for emergencies, PagerDuty and Opsgenie can be used as a prearranged escalation pattern for alerts that escalate automatically. Also the information is easier to digest in the moment for the receiving party and track later for the management’s analysis. These tools can send an alert to an email address allocated for urgent issues, which can then trigger a chain of alert and escalation. The first alert can go to the service desk manager’s email, followed by an alert two minutes later in the form of a notification on the person’s smartphone and then if that fails to get acknowledged a phone call and/or an SMS. Fifteen minutes later, another alert can go out to the director of operations. Just make sure that only real emergencies end up triggering these patterns to avoid a “boy who cried wolf” scenario. You can also use escalation patterns for after hours support. For example, you might engage outsourced after hours front line support, as well as an on-call senior level technician that can handle problems outside the scope of the front line techs. If an urgent issue comes up, the senior engineer on-call can receive a smartphone notification with all the relevant details about the issue and automated phone calls afterwards if he fails to acknowledge that. This way, they get to see the details of an issue via a message, as opposed to having to stop what they’re doing and be thrown into a call with no context, possibly while being woken up from sleeping. PagerDuty and OpsGenie afford them a couple of minutes to review the issue before they have to jump into action and offer a response. These less intrusive notification methods will ensure that your on call technicians are able to have a greater quality of life.


When communication isn’t streamlined and efficient, it can waste people’s time and lower productivity. Receiving calls without voicemails could have you wondering what the call was about, and whether it needs urgent attention. Getting chat messages may distract you, especially if they start with a simple ‘Hi’ and then proceed with you waiting for someone to type as opposed to having the whole message with the description of the issue sent immediately as would be in email. Some things are better communicated in a ticket or an email. Other non-urgent matters can wait until a weekly meeting and then be added to the agenda. This is often the most efficient strategy, as non-urgent issues can receive focused attention and be discussed in real-time. Employees can brainstorm solutions in the moment and have a back-and-forth dialogue to work things out.

MSP Helpdesk Ticket Note Writing Guide

Ticket notes are an integral part of running a successful MSP, especially one that employs remote technicians.

At Support Adventure, most of our technicians work remotely, and the MSP they work for is rarely located in the same country where the engineer works. But despite the distance, cohesion is created through an organized ticketing system and a culture of good communication. We realized early on that ticket notes show the value of our service, and so our ticket notes needed to be spot on. That led us to create a Ticket Note Guide to help our clients have success.


Ultimately, your MSP is in the business of providing exceptional service to clients. The ticket notes that your staff writes must reflect that. Having a well organized ticket handling policy helps clients see that you’re doing a good job at fulfilling their requirements.

Tickets must include all relevant information so that:

  • Technicians can best assist users.
  • Management can be informed about what has transpired with an issue.
  • It is clear what steps have been taken to resolve an issue.
  • A technician’s performance can be tracked.

Detailed logs help minimize the need for a discussion about how a case was handled. If a client complains about your service, you can refer to your ticket notes to avoid a situation where it’s your word against theirs. If a ticket was well-written, you can use it to show how your technician tried to remedy the situation.

Ticket notes must be as detailed as possible to help those reading understand what actions your technician took to fix an issue. Extra specific pieces of information, such as passwords and IP addresses, help in this regard. We do not recommend writing passwords in ticket notes however, rather linking the specific place in a system like IT Glue where they are stored.

If you want our full ticket note writing guide, click here to get it for free

Here’s a preview of some of what is inside:


Every ticket should end in one of these for outcomes.  By choosing one, the tech clearly broadcasts their consideration of the position of the ticket and what, if anything needs to be done with it.

  1. TICKET RESOLVED – No further action is required. The resolution has been confirmed with the client or they have been notified that the ticket is complete.
  2. NEXT STEPS _________: – You are aware of the next steps which need to be taken. You have written a description of what you plan to do, and have scheduled a fixed or tentative time for these steps to be taken. You have also communicated this to the client.
  3. WAITING FOR  _________: – You require someone else to complete an action before you proceed with the next steps. You have described who you are waiting for and what they must do. You have scheduled a tentative time to follow up on the progress of these actions should you have not heard back.
  4. ESCALATION REQUIRED: – You cannot complete the ticket due to a limitation in knowledge. You wish to pass the ticket to someone else on the team who may be in a better position to resolve the issue.


In the case that an escalation is to be performed on a ticket where the escalating technician is not in direct contact with the technician who will receive it, this form will help have the technicians craft proper notes for handover:

  1. The issue as it stands (25 words or less):
  2. Things I have tried to resolve with this ticket:
  3. Why I cannot resolve this ticket:
  4. Possible Next Steps:
  5. Any other info (e.g. callback times):


Including one of these four statuses in the last line of your ticket notes helps create clear understanding about a ticket’s progress or resolution. This also helps establish what needs to happen in order for pending tickets to continue on their road to completion. Knowing when next steps can be taken, and by whom, ensures that tickets don’t become neglected.


We encourage our technicians to write 4 lines for every 15 minutes. A good rule of thumb to guarantee that all information is logged correctly is this: ensure that 4 lines of notes are logged for every 15 minutes of time logged.  At first, this might feel like a lot of details. But when you incorporate all of the above guidelines, you will find it easier to think of information to include. 


#Called the client
#Logged onto their machine via RMM
#Confirmed with the client what the issue is
#Reproduced the problem
#Told client we will work on the issue and call them back
#Researched applied this fix from this link:
#Called the client back
#Confirmed the issue was fixed

As you can see, it’s easy to fulfil the requirements by simply realistically writing the steps which are taken in the course of working a ticket.

Time Tracking On MSP Technician Timesheets

In this guide, we will explore time tracking on MSP technicians’ timesheets.Explore questions like: How strict or how much slack should you give employees? And what should your expectations be? Achieving a good balance of this is essential to making your staff members feel organized on the help desk.Too much time tracking will lead to stress. If staff have to track every minute of every single day, they will feel suffocated. You need to define a policy on what technicians’ targets are, and they need to be reasonable.A timesheet and ticket notes are all that MSPs are going to see if a technician is doing a good job. We insist that ticket notes be thorough. Technicians must document what they have done with their day and what they’ve done on each ticket.


Some MSPs aim to track every single minute during the full duration of the technician’s working hours. This type of micromanagement of their time is oppressive, especially for those working from home.You have to account for reasonable occurrences in the life of your staff, such as:● Going out for a smoke● Making some coffee● Being interrupted by a partner or child that lives with them● Going to the washroom● Having a chat with a colleague, etc.Be flexible and make room for numerous unexpected disruptions. Otherwise, if you ask your staff to track every single minute, you are essentially asking them to lie.

Check out this article we wrote about how every-minute time tracking is preventing your MSP from scaling.


We have some MSP clients that don’t track time at all on the help desk. This is problematic because there is no information to distinguish in the statistics of a ticket why some tasks needed five minutes to resolve while others needed an hour.The technicians who naturally manage to make tickets disappear quickly might look better in the statistics in a way that isn’t representative of the effort put in. You won’t have an accurate idea of which clients are consuming the most time and which technicians are wasting time.If a technician bills an hour and a half on a ticket, but lacks thorough notes detailing what that hour and a half was spent doing, there might be something you need to optimize there.


At Support Adventure, we track time in 15 minute intervals. A 23 minute task can be inputted as 30 minutes. This way, there is no micromanagement and no stress for the workers. Tracking this way takes less time, as you don’t need to calculate the exact amount of minutes a task has taken and timesheets look neat and tidy at the end of the day and you can easily highlight tickets where the rounding has not been done properly.


A rough guideline of what is expected from our technicians is the following: four lines of ticket notes for every 15 minutes spent. That is the level of resolution of ticket notes that you’re looking for.Say your technician is working on a password reset, they can write brief notes such as:● Line 1: User called in. I answered the phone.● Line 2: User requested password reset for the account.● Line 3: Logged into panel. l reset password.● Line 4: Confirmed user was able to log into the system after I reset the password.That is an example of a 15-minute password reset ticket. We believe it’s a reasonable expectation to have technicians doing at least four things every 15 minutes.


We encourage you to have your technicians track all the time that they spend working on a ticket and related documentation. They should also include details about all the time they spent researching a ticket before they call a client.All the time they spend updating documentation and ticket notes, as well as time spent writing the ticket notes after a ticket is complete, should be tracked. You should define these expectations in writing so that technicians are clear on how to do their job well.


What we view as fair is every minute time tracking for about 65 percent of the day, or 15-minute increments for about 80 percent of the day.We believe this is pretty humane, as your staff will take time for making coffee, bathroom breaks, getting up to stretch, etc. Technicians absolutely must log when they spend time on issue-related research or documentation. If this isn’t logged, you can’t bill the client for it.Many MSPs have a review with their clients every few months, and in those reviews, you can show exactly how much time is spent working on their tickets. If your clients are paying you a monthly set fee to manage their systems, you can show the value by comparing if you had billed them by the hour, how much that would have cost them.


  1. Rounding up to the nearest 15 minutes.
  2. Expecting about 80% of the day to be logged with rounding up.

These methods let people breathe. They account for those reasonable occurrences and prevent your staff from lying to you about how they spend their time.

Ticket Intake Models (Calls, E-mails...)

In this guide we will tell you about how tickets should ideally come into your help desk and what is the best way to deal with them. This content is geared towards MSPs that have more than 5-10 technicians, where an intake strategy can greatly improve the effectiveness and efficiency of a help desk.


We often find that MSPs think that the best way to serve clients is to have a technician pick up the phone immediately when calls come in. This may be true in certain situations. But implementing this policy in a less than optimal way can quickly create situations where your staff are stressed out from the lack of focus they have on their tasks. This lack of a well-defined structure then creates an inconsistent service where your clients never know what will happen when they dial your helpdesk.

One of our technicians, Rados, wrote an article to share his stressful experience being in a MSP ring group. Click here to read it!


What sets your MSP apart from your competitors is what you promise to your clients in your service-level agreement and in the day to day communications with users. The support process, how they are treated on the phone, and the quality of service need to be consistent. We believe that is the most important thing to guarantee.We are now going to explore two models that can greatly improve the level of service, dispatchers and intake/triage technicians.


Most MSPs don’t want a dispatcher answering the phone right away because it can lead to a perception of inadequate service. Clients might think, “When I call, the first person I spoke to couldn’t help me right away.”But think of it this way…If you have a medical problem and you walk into a hospital, does the first person that you talk to prescribe you medicine? Does the first person you talk to at a restaurant cook your steak? Not in well organized systems which deal with high volume. You have to wait to see the doctor or be seated at a table first receive a well-done steak. The concept is the same with having a dispatcher.It might actually be the case that the cook is the first person you talk to if it’s a small mom-and-pop restaurant. But if you want to replicate a model that is scalable, you need to create more order and specialized roles. Bringing on a dispatcher will vastly improve handling intake and ensure a consistent process for clients.


In the example we used before of a hospital, there might be nurses and paramedics that will know how to take the first steps in the process. They can check your vital signs or administer certain drugs before seeing a doctor if needed.In the IT industry, there are similar roles called intake or triage technicians, whose job is to take the first steps on the tickets.Some MSPs have a ring group of intake technicians so that somebody is hopefully always available when a client needs support and the first person they talk to is able to help.These intake technicians should be people who are good at customer service and able to inspire confidence with consistent results.When your client contacts your help desk, the first steps might be something straightforward that can easily be solved. A notorious example would be a password reset or a permission issue.If the triage technicians cannot solve a ticket after 15 minutes, half an hour, or whatever you set the threshold to, they should pass it on to a technician who can.


We recommend you let your clients know that if an issue is not urgent, they can email in a ticket. It’s much easier to run a help desk if people email in rather than call.When they send an email, the ticketing system usually already has all their information. So you need to put a vested effort into training your clients to email in tickets whenever possible. This can be as subtle as having the staff ask them if they have already emailed in a ticket when they do call.You can provide them a guide of what they can expect when using your service. This will inspire confidence in your service through clearly defined SLAs and metrics to adhere to.

Improving Your MSP's Help Desk Culture

The lifeblood of your business is the happiness of your clients, the service they’re receiving and their perception of it. How are they ever going to be happy with this service unless it’s being delivered by people who are happy with their jobs? You must prioritize company culture so that you can increase employee retention rates, satisfaction and team spirit.


Create written standards and guidelines to follow so that everybody’s on the same page with a well-indexed knowledge base. One of the best things you can do to organize your help desk is to write down the way the whole system is supposed to work. This way, everybody knows that there are consistent standards.


Group huddles allow for a time where everyone can get together as a team. Employees can raise suggestions for anything they feel would help the group. Everyone should be able to throw things in and harmonize their energy with their coworkers.


Have a dispatcher or service coordinator to assist, guide and organize technicians. MSPs are often chaotic because they don’t have a dispatcher as the nucleus of the help desk, managing the fulfillment and allocation of tickets.


It’s important to make sure that your documentation is kept up-to-date and that a certain amount of mentoring occurs from higher level staff to more junior team members.There should be somebody, ideally a dispatcher or a senior technician, that closely monitors escalations for training and mentoring purposes. After an escalated issue is resolved, the dispatcher or senior technician should reverse the escalation and brief the original technician. That junior technician can then read through the ticket notes and understand what solved the issue. This is a clever practice to help them grow.You can also create documentation incentives. For example, you could provide a reward at the end of the month for the technician who flagged the most number of missing documentation items, or reverse escalated the highest number of tickets. Rewarding the improvement of documentation and transfer of knowledge are great ways to keep your documentation complete and up-to-date.


Applaud good client feedback in your staff huddles. Pat your staff on the back when they do a good job. Some MSPs have an attitude of “If there ain’t no complaints, then we’re good.” But we believe that technicians need positive reinforcement as well.


An all hands on deck alerts, such as a notification that gets sent out to all senior technicians, helps to resolve the problems when the front lines get overwhelmed. When a senior tech working on a project receives the alert, they can jump on the helpdesk and knock down some tickets. This reduces the heavy load in times when the front-liners feel weighed down by too many tickets, calls, etc. An overloaded front line team will lead to inconsistencies in client service. As an MSP, you want to ensure that clients know what to expect when they submit a ticket and get a consistent result.


Give your technicians an anonymous way of submitting feedback regarding what they don’t like about their job or what can be improved. At Support Adventure, we hire technicians, assign them to MSPs and monitor their results. We act as a mediating force which listens to both sides to create harmony in the relationship. Technicians give us a lot of feedback that they wouldn’t tell the MSPs were they direct employees. You can emulate this by making an anonymous feedback system.

Click here to read an article we wrote on why your MSP should invest in improving customer service (and how to do it). 

Attracting The Best MSP Staff

Finding the right staff can be very tricky, and the job market can be very competitive.

You want to take great care in the following:

  1. Where you post job ads.
  2. How you attract ideal applicants.
  3. The application process and how likely the staff you want will want to complete it.
  4. How you figure out which applicants are the right fit for your MSP.

Once you start interacting with applicants, you need to place a great deal of care in how you speak to and connect with them. Because the nature of MSPs requires exceptionally intelligent, personable and talented people, the applicants you truly want probably have other options and offers. So as much as they are pitching to you why they would be a good fit for your company, you should be doing the same to them. They need to know why your company is a great fit for their career goals and lifestyle.


The best job interviews are the ones where both the applicant and the interviewer feel comfortable and are building rapport and a sense cultural compatibility.

Avoid interrogation style job interviews where you fire off technical questions to test a prospect’s knowledge, as if you’re the person with all the power. Great candidates are hot commodities who are also interviewing you. They’re scanning your communication style for tells of what it would be like to work for you. They use the interview to get a feel for whether or not your company would be the best environment for them to grow and flourish. Don’t underestimate the power they have to choose between different companies taking an interest in them and how a one-sided “what can you do for me?” interaction can be off-putting to the best candidates.


In your job postings, you need to convey to potential applicants:

  1. Your values as a company.
  2. Why your company is a great place to work.
  3. What the atmosphere is like for your staff.
  4. What commitments you make to your staff.

Examples might include:

● Helping employees develop in their careers

● Clear communication of expectations and what they are judged on

● Obtaining new certification

● Open-door policy

● Listening to an employee’s needs

● Lifestyle benefits such as a work-from-home policy

Make sure that the perks of working for your MSP are clear to applicants, it will say a lot about why you’re providing a great environment for them.


Working from home has gained a lot of traction in 2020. This is important for the MSP space because most help desk technicians are introverts who may prefer working from home. Now, more companies will allow them to do that. If you have a work-from-home policy, be sure to include information about it in job postings and interviews.


When it comes to application questions, we recommend that you don’t limit them to technical questions based on education or certifications.

We have found that testing what someone can do is more beneficial to an MSP’s hiring process than testing someone’s wealth of knowledge. How impressive someone appears on their CV/resume cannot guarantee that they will be an impactful contributor in the complex environment of an MSP.

Instead of conducting a knowledge-based hiring process, give applicants a chance to show how they process information.

At Support Adventure, we achieve this with the following:

  1. A written test that reveals an applicant’s client-facing communication style. The test gives them some simple ticket notes, typically three, which take about 20 to 40 minutes to complete.
  2. An automated video interview system where applicants are taken to a website to record an introduction video and answer some knowledge-based questions.

We know who we want to interview based on how they have presented themselves in these two tests. We filter out a lot of applicants just by looking at the written test submissions and their video test results.


As previously stated, applicants use the interview for hints of what it would be like to work for your company. They often choose an MSP that seems focused on their well-being and stability. They get a feel for this during the interview by doing the following:

  1. Paying attention to whether or not you are stern and too serious.
  2. Observing if you make jokes and build rapport or if you only care to talk about the job.
  3. Listening to whether or not you take an interest in learning about them.
  4. Reading your verbal and non-verbal cues that express a domineering and authoritarian attitude.

Instead of interrogating your candidate, you should be making them feel welcome in your company. You do this by building rapport. This is crucial because prospective employees want to:

  1. Get a sense as to whether or not they would enjoy being a part of your team long-term.
  2. Feel like their ideas will be validated and included.
  3. Get a feel for if their career will flourish while working for you.
  4. Feel that there is room to make them a key team player.

You can build rapport by:

● Being the 3 “C”s: casual, curious, and conversational.

● Not interviewing in a patronizing style.

● Listening and learning how the candidate can add some missing pieces to your team.

● Mixing up typical work subject questions with more personality and lifestyle-oriented questions.

● Mixing up typical questions with more atypical, original, or quirky questions.

Click here to read an article we wrote about interrogation-style interviews 

Below, you can see a table contrasting the feelings that our engineer Jonathan had after one interrogation style interview and one non-interrogation style interview. He had a much more positive opinion of the MSP that represented the latter.

Interrogation Style Interviewer

Non-Interrogation Style Interviewer

Interviewer was more domineering which made him feel uncomfortable.

Interviewer was more interactive which made him feel more welcome.

Interviewer was cold and uptight which made Jonathan feel unwelcome.

Interviewer made some jokes which helped Jonathan to bond with him and asked about his favorite superhero.

Interviewer was all business which made Jonathan feel like he had to be a “yes-man” to get the job.

Interviewer and Jonathan disagreed about something, which created a healthy discussion where they found resolution.

Onboarding New Staff To Your MSP

Here we’re going to tell you about the best practices when onboarding new staff to your MSP. We will cover all of the various aspects you should consider when training and on-boarding new technicians to your help desk.

Credentials should be prepared before the onboarding process begins so that technicians are ready-to-go to with training.

We strongly recommend that if you plan on hiring more than two or three people, that you have a training plan in writing. You can also create it as an indexed video with a checklist of all the expectations one will face on the job.

On our onboarding form, we have found that the questions and information below are good to have in the training package:

  1. Documents that detail your company’s core values.
  2. What makes your MSP different from others, and what is your promise to your clients?
  3. What kind of company culture and environment are you creating for your staff?
  4. High-level overview of the company, operations, and management teams.
  5. Systems-related training resources, which should be a large chunk of the training.
  6. Walkthrough of how your MSP uses ticketing platforms and expectations of ticket notes.
  7. Any bonus reward policy or incentives.
  8. Staff member review of procedures and intervals.
  9. What is the company name, email, phone, business hours, lunch policy, holiday/overtime policy, and other standard information? It’s not always obvious.
  10. A concise list of roles, responsibilities, and job descriptions.
  11. A list of technicians’ expectations and how their performance is judged.
  12. A comprehensive list of systems that are used in any given role.
  13. Communication policy (how to communicate, what technology to use, etc.).
  14. Time tracking guidelines detailing how employees log time on the system (eg. quarter hour increments) and the target for every day of time logged.
  15. Documentation policy (procedures on how to document things properly).
  16. Escalation Procedures (if someone cannot solve a ticket, it should get to someone who can solve it as quickly as possible).
  17. Security policies and procedures (precisely define the security practices, such as identifying if people are who they say they are when asking for password resets).
  18. Information about call recordings and how they can be requested.
  19. Auxiliary tasks to fill idle time that they can do when they don’t have regular client tickets or project work.

What To Look For When Hiring An MSP Manager

We’ve seen what management looks like when it’s done well. Team spirit improves when a manager embodies the values of your company and adds structure and consistency, listening to feedback from techs and clients.


We’ve also seen some suboptimal management styles, typically when someone is promoted from the wrong position or doesn’t have the right management skills that help people thrive.

When your MSP grows to a certain point, and the owner can’t manage all the technicians by themselves, they often make the mistake of promoting the most senior technician.


Senior technicians are not always the best at looking at things from a human-oriented perspective, such as understanding what motivates people. The problem with having super smart technicians in your MSP is that they don’t always understand what motivates different types of people. They can fail to understand that not everybody has as much experience as them, or is as good at problem-solving. Also, they are often better at working alone as opposed to being a collaborative team member.


A business book we like, called The E-myth, states that in each entrepreneurial venture, there are three types of people:

● The technician

● The manager

● The entrepreneur

When you start your business, you have to be all three. When small businesses fail, it’s often because the new entrepreneurs are unsuccessful at successfully embodying these three roles.

When you start an MSP from the ground up, you become the technician, the manager, and the entrepreneur who will hopefully hire more technicians. After growing your MSP further with new technicians, you need to hire somebody who can step in and bring order to the help desk as a manager so that you don’t have to do it as much. This key hiring decision is a very important step.


Avoid hiring people that have overlapping weaknesses. Instead, try to bring on new team members with different skill sets. Many technicians might lack a human-oriented perspective to look at people and understand what motivates them. So it’s not going to benefit you to have them as a manager unless leadership is something that they truly wish to cultivate and have a natural inclination towards.


You should delegate management and supervision to people who are process oriented and capable of supervising others, especially technicians.

The ideal manager is oriented towards providing structure, stability, and consistency. They have a passion for people and procedures, and can reliably do the following:

● Check in with people.

● Listen to feedback.

● Follow and develop procedures.

● Analyze results.

They should also be good at taking feedback and tweaking procedures to achieve better results and understand human beings enough to make sure they have the right person in the right position, the right seat on the bus.


The CEO should design visions of how the business should work, how new staff should be onboarded, and how documentation should be done.

The service desk manager, as the second level of management, should decide how clients will be serviced, what procedures govern that service, how the different roles (especially the dispatch role described below) ensure consistent service, how many technicians should be on the helpdesk and other related decisions.

The third level of management is a supervisor role, such as a dispatcher or service desk coordinator. They must ensure that the designed system is being implemented and tasks are consistently completed. This is a detailed person who follows procedures and escalates to the service desk manager when something falls out of the framework of procedures they have been given.


At Support Adventure, we have both a former MSP service desk manager and a former service delivery manager. They have worked at companies with 20-40 technicians, thus they possess a lot of wisdom. If you’re trying to grow your MSP, having experienced management like this is key, and we can help.

We can find you great staff at affordable rates, or consult on your processes and procedures to ensure that your MSP is set up for success!


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.