Your standards are your DNA as an MSP. If someone was to log onto to one of your client’s network, they should almost be able to know you are managing them just by going through how everything is configured. The standards by which you setup your clients are your DNA.
These should be unique to your MSP and certainly not to a member of your staff. This means that one of your employees should not set something up a certain way for one client and then another employee sets it up differently at another client. Your standards must be detailed for everything you do.
You will gain in efficiency in so many different areas of your business. Everybody will benefit from knowing there is one way things are setup and that’s it. The most obvious example is at the service desk. If every client is setup the same way, then there is no time wasted looking through documentation or trying to understand how things are configured. On the project or deployment side, if things are well-documented, engineers will not have to figure out how to configure something, which saves a huge amount of time.
We also use it in the sales process. Going over our process shows the maturity of our business and the seriousness we bring to table.
I wish we started doing this from Day 1 in our MSP. But no, we waited until we hit the wall before getting serious about this. I would recommend you start doing this immediately, no matter what size you are. It will be so much easier to bring people on board and subsequently scale.
I believe every MSP should have a continuously updated set of standards for all the technology they deploy and support. It must constantly evolve with new releases of software or new tactics used by hackers. An MSP needs a process to create and review standards—but also one to audit their clients to ensure they are being applied as they change.
This can seem like a tremendous amount work to put in place. However, it’s like every big goal: slow and steady wins the race. Let me explain how we did it in our MSP.
For us, standards are generally 2 things:
- What technologies, products, apps, tools do you deploy and support? (often referred to as your stack)
- How are they configured?
We have two committees for these standards in our MSP.
Technology Vision Committee
Role: Define our stack
We have three members in this committee that meet monthly. It’s our head of our internal systems, strongest vCIO and myself (CEO).
Our role is to decide which technologies we will standardize. The big ones are obvious because they are deployed at all of our clients: firewalls, EDR, DNS Filtering, email security, etc. The others usually come from a client request. For example, a client needs to backup their fleet of Apple laptops and the current standard solution that is built into our RMM doesn’t support Mac. We don’t treat this as a one off and have the vCIO assigned to this client figure it out. We need to ensure we choose the right product as we will probably need it at another client in the future.
We will figure out what our requirements are, research the possible options, speak to our TPG group peers (www.trueprofitgroups.com), read what the community is saying online (r/msp), create a shortlist, speak to the vendors, test the products, and usually use ourselves as the first deployment, if applicable.
Throughout the process, we keep the standards committee updated on where we are with the candidates and selection. We are open to suggestions and before we choose a product, we run it by the standards committee.
Standards Committee
Role: How do we configure our stack?
The members of the standards committee are our vCIOs, project team tech lead, and head of our internal systems. They meet on a weekly basis and determine the preferred configurations of the solutions we deploy. When a conclusion is reached, they:
- Update the project team deployment guide
- Update the standard in our database (we use confluence for this)
- Update the audit in the corresponding Propel audit
We started this slowly and built up our database from scratch years ago. Our project team spearheaded documenting the specific configurations for recurring projects. Slowly, we started building our standards. Today, we have complete set of standards and that we audit against our clients once a year.
Auditing is key to this process as it identifies where the gaps are. They can be because our standards evolve or simply a mistake was made at some point. These gaps are then addressed immediately in the case of a mistake or added to the roadmap that we present during our strategic planning with the client.
Propel Your MSP was built for this exact process & making the vCIOs job a whole lot simpler!
Simon is the President of S3 Technologies, a leading Canadian MSP he co-founded in 2003. He built and scaled the vCIO team which eventually lead to him co-founding Propel Your MSP in 2018 to help MSPs with their vCIO services.
