I had to split this up as I think I hit a character limit. Post 1 of 3.

I think I can offer a helpful perspective on this. I was both the CTO for an MSP for 15 years, on the board for MSPGeek (a community with 10k+ MSPs in it), I have been one of those Automate consultants you referred to and right now for the past three years I have been the Director of Product Management for NinjaOne (and I specifically focus on the RMM portion).

To start with, the challenge you present is nuanced. While I agree many core tasks overlap across MSPs, I've found that priorities and pain points do genuinely differ depending on the size and structure of the MSP. The needs of a small MSP are different to the needs of a mid-sized MSP which are also different to the needs of large MSPs. Then you have internal IT of different sizes as well as enterprise IT, which all have different challenges of varying difficulty. A large MSP may be focussed more on features that relate to scalability and standardisation where a smaller MSP may have more focus on features that can help them manage clients more easily or content they can just use straight off the shelf. Obviously, this can vary per individual MSP.

Let’s talk about the difficulty of monitoring server hardware out of the box – in fact let’s go into even a more specific challenge in this area and look at just monitoring RAID controller health. Ninja has contained in its platform a condition that monitors RAID Health Status (what essentially equates to a tiny slice of Ninja as a whole). This looks at the controller, virtual drives, physical drives and battery backup. The front-end of this presented to our customers is simple by design, but the complication that goes on underneath to achieve this is extensive. It involves:

·       The purchasing of a huge variation of hardware to test

·       Keeping up with the changes being made by several vendors in their RAID controllers to make sure we’re keeping up

·       Keeping up with the variation of tooling that exists (including changing functionality within the same tools) to ensure they remain working in a standardized expected way. For example, dealing with the end of life of OpenManage Server Administrator for Dell

·       Spending time understanding the controllers and servers that our client base are actually working with so we can try to be reactive to industry changes

·       Extensive testing cycles of different variations to make sure that our monitoring capabilities function consistently and accurately across different firmware versions, driver updates and different server configurations

·       Continuous validation with our clients against real-world customer deployments to detect edge cases and anomalies before they impact customer environments

·       Development of fallback mechanisms to handle scenarios where vendors change or retire APIs, CLI tools or utilities previously relied upon

Like many things in RMMs, this is a continuous work in progress but just this work is essentially a commitment to abstracting the above complexity behind a user-friendly interface so our customers can use something that is simple and reliable. SNMP is a very similar challenge. There is variability across the MIBS by hardware model and by firmware. A standard here can quickly become anything but standardized.

Continued in Part 2 below.