This post isn’t designed to be a definitive guide on how your organization should be run or the roles involved, however, it is designed to show what I feel have become cornerstones of MSPs that I’ve been involved in over the last 10 years or so. It is also created from a technical/management perspective. I am not a salesperson and don’t personally feel that I’m in any position to define how to run a sales team. If anybody reading is, feel free to get in touch and I’ll append any information that is relevant.
Before we start, If you’re a ConnectWise user, you can browse to the University and browse to the Education > Blueprints section to view their flows and designs to save reinventing the wheel. Their blueprints by MSP look like this:
All of the sections are clickable with additional documentation, videos and Visio diagrams which is great for getting to know how parts of the products work.
Naturally, we’re in the industry where teams crossover, staff are members of multiple teams and some MSPs are bigger/smaller than others so these would generally be scaled to size.
The support desk will generally work on all of the ‘Reactive’ issues that are raised by clients. These generally are created by email, chat, portal, phone call or tray icon and are to be worked against within the client’s SLA.
Dispatcher: All of the initial calls/tickets will initially be handled by a service dispatcher. The dispatcher is generally technically aware, but not necessarily a technician. They should update the ticket with any notes or canned text to the client to let them know that XYZ is happening. Generally, the dispatcher should gather as much information about the issue as possible without resolving the issue, so as to help the technician assigned to the job. Depending on the technical expertise, this role could be expanded into solving very basic things such as password resets, PC Builds and so on.
Example: A client calls in to say that they need a file recovering, your dispatcher should be collecting the file name, folder path, the date they want to restore back to and so on.
Ideally, they should be assigning tickets in the method that your company uses (ITIL, Criticality, SLA, Skill or however). The dispatcher should also be checking through all of the open tickets to ensure that they all have the next actions in them, scheduled for either the current day or a future day to ensure no tickets are left behind.
1st – 3rd Line: The most common role within the company, tickets generally would become assigned and progress up from 1st – 3rd within the timescales of your SLA. Occasionally, a call will come in that skips the queue (more often than we’d all like to admit). If a call for a ransomware attack comes in and an entire client network is down, you’ll probably want to skip the 1st & 2nd line for example. I like to keep the previous level engineer involved in the resolution of any escalated tickets as a chance to progress their skills/knowledge when possible.
Possibly an unpopular opinion: I generally try to keep the first engineer as the point of contact. If a ticket is escalated from the 1st – 2nd line to be resolved, the 2nd line engineer should do all that they can to explain to the 1st line engineer what they did to resolve the issue and then allow the 1st line engineer respond to the client. If every time your client has a fault the same 2nd line engineer calls them with the fix after the 1st line engineer has told them that they cannot fix it, they’ll soon start requesting that specific engineer every time.
Service Manager: Amongst the many roles, the service manager should be ensuring that the flow from dispatch to resolution is all occurring within the SLAs. The service manager should also attempt to communicate with clients when a normal resolution isn’t possible or if the issue is sensitive. They should be proactively looking to grow the service team knowledge, reduce tickets and the other Management roles that generally occur such as team meetings, quarterly reviews, etc.
An amazing thing to have is a separate NOC team (Network Operation Center). This team should be proactively resolving issues that have been detected by your RMM software. Generally involving patching, scripting, stopped service, low disk space, drive fragmentation, print spoolers and so on. There should also be an area of development here, if the NOC team is constantly fixing the same issues, there’s a need to automate that process further. In smaller companies, I’d suggest the service team simply get a pool of proactive tickets to collect from when they have free time. Within ConnectWise Automate, you can utilize tools such as PowerBI and BrightGauge in order to create dashboards to categorize and filter the automation that’s occurring. It’s great to see how many hours have been saved by automation and a list of the biggest ‘manual’ time input into a certain area of improvement.
If you have the means, a dedicated person (or persons) for the development of scripting/monitors would be ideal. You can still have the NOC proactively fixing issues that your RMM has found, but they are all able to put forward their reports of time spent to help the development of better automation.
All of the Project work should be separated from the Service Desk. Even if the same technicians are doing the work, keep the jobs separate. More times than I care to count that an engineer could be doing a server install and then XYZ needs fixing and causing the project to become delayed or more problematic and the client then arguing that XYZ was support work and not project and to reconsider the invoice. In ConnectWise, I consider a project anything that originates from an Opportunity. This could be an office move, server install, workstation install or even a printer. They are easy to distinguish from the calendar screen and it helps to differentiate that this is chargeable work that’s booked in with the client.