Every business needs to have their standards and common ways of doing things. Many small businesses and Managed Service Providers (MSPs) don’t figure this out until they have a ton of ad hoc processes in the heads of employees.
Nobody takes the time to write things down, especially when you’re just getting started. It’s far easier to just cram through issue after issue, project after project, and proposal after proposal. Eventually, you need to start making standards.
It’s not just your technology stack. It’s FAR more than that. Your technology stack is important, but I’m also talking about documentation standards, standard processes for your clients to do things, and yes your technology stack. Solid processes and documentation will make your Managed Service Provider more efficient.
Overall Documentation
First, let’s cover the overall documentation idea: You should have a standard place to document all of your client and internal information. It should be a SINGLE place. I’ve heard “I didn’t know where the documentation was” so many times in my career, and it’s frustrating. Nearly every instance it was because a piece of the documentation spread between the PSA, SharePoint, and some other file in another random tool.
Get your documentation into one place and your MSP will be better off for it.
Internal Documentation
When you hire technicians you have multiple options for how to document their tasks. I’m a fan of documenting based on the techs that will be needing the documentation. Your lower level techs need more hand-holding than your senior engineers.
Lower Level Techs: Document the core tasks of your lowest level techs. Making sure that your most junior technicians can function at a high level is important. I am a fan of building a baseline set of tasks for your first level techs and build documentation up to expand their abilities. Documenting these core tasks and responsibilities allows you to layer on more and more types of work while you get new techs up-to-speed. I recommend that you build your documentation similar to the below list.
- Triage and Dispatch — Everyone on your technical staff should know how to triage and dispatch work to the technicians in your MSP. For every new tech joining your firm I would make sure they know how to triage and dispatch tickets even if that isn’t their long-term job.
- Password Resets — Your lowest level techs should handle all of your password reset tickets. Make sure that this is documented well so your junior techs can do this well as early as possible.
- New Users and Group Memberships — Another good set of simple to perform, and repeatable tasks that can be interrupted. Make sure that you build a good checklist of the tasks to create new users.
- Software Installation and Computer Prep — This is a very common request as well, and if you have good scripting or tools like Immy.bot, Rewst, or your RMM can make this quite easy.
- Basic Troubleshooting — Build out a number of documents and decision tree documents to help your junior techs learn to troubleshoot.
- Escalation Process — Your junior engineers MUST know when and how to escalate when they’re over their head. The last thing you want is a tech grinding away at an issue and wasting a bunch of their and your client’s time. Know when to ask for help!
Higher Level Techs: Often, your higher level techs can make due with some chicken scratch on a sticky note. They’re used to getting an IP address and a password and they have to build the picture from there. I recommend using diagrams for the complicated things. Think about diagrams outlining a SAN or clustered VM hosts and that sort of thing.
Otherwise, as long as you have the obvious items documented (firewall IPs, server info, and passwords) they’re probably going to be fine. One thing that you should encourage is for these techs to teach your lower level techs how to solve problems that they’re solving. This way, the next time the issue comes up the lower level tech can handle it. They should also have that lower level tech do the documentation. Make sure to give some time to deliberately document on a regular basis.
Client Documentation
What does it mean to be UP? The most important piece for client documentation is to know what it means for the client to be “UP.” What systems are critical for that client? When any pieces of that puzzle are offline what is the impact to that client?
As long as your documentation covers their basics (again: firewall IPs, server info, and passwords), and you what it means for that client to be UP you are off to a good start. Sure, you should have more documented. In my time at several MSPs this would have saved a lot of heartburn for both us and our clients. We often spent time trying to document everything, but didn’t think to ask the client what it means for them to be fully online and able to perform their jobs. I can’t tell you how many times we ran into issues where a ticket indicated something wasn’t working that seemed unimportant. Often, this seemingly unimportant issue was actually a client that couldn’t do a core function where we just didn’t realize how vital it truly was!
Document the nuances. After you document what it means for a client to be up you should spend some time documenting the nuances of their network. Do they have a weird configuration or system that you haven’t seen before? Document the heck out of that. Is there a system that requires you to rub your belly and pat your head? Yep, document that too!
There are many things you could document, but I think it makes a ton of sense to document the things that aren’t common. The things that you don’t have a lot of experience with, the nuances, are the tickets that will trip you up and make supporting that client harder. Write that stuff down and save yourself a headache. And for the love of science, if a tech solves a tricky issue at a client, they should be required to spend the necessary time to document that so the next person doesn’t have to go through that again.
Standardizing Core Processes
Establishing and setting standards around your core processes will also return a lot of efficiency for your team. In this case, I’m talking about things like standardizing how you connect to file storage, map printers, setup remote access, and configure other common items. As you standardize how all of your clients perform some of these core functions you will simplify your support process.
You will find that your support team can build more processes for your lower level techs to work more tickets without having to escalate. The biggest benefit with this standardization is that you can document this standard once without having to make different articles for each of your clients.
Putting it All Together
When you combine the documentation standards along with the standard core practices you will continue to build a more and more efficient business. When you layer in your tech stack and make sure that your clients are all on your tech stack you can really maximize the efficiency in your MSP.