Have You Outgrown Your RMM? Part 2, The LESS Obvious Red Flags to Look For

In my last blog I took a look at some of what I see as the most obvious signs that your MSP business might have outgrown its RMM. These included:

• Feeling growing pains as you try to scale your RMM: from slow onboarding of new customers to manual monitoring of agent deployment and discovery runs. 
• Loss of confidence in your RMM’s monitoring results: from stale/misconfigured alerts to being forced into reactive incident remediation with techs being forced onsite to resolve problems.
• Patch mismanagement: from underutilizing your RMM to detect, approve, and deploy patches to not effectively monitoring patch status.

In this blog, I’m going to turn my attention to looking at some of the less obvious signs to reconsider your RMM.

Does your RMM make onboarding customers painfully manual?

To start with let’s go back to onboarding customers. When I was an MSP, probably similarly to most MSPs, I had some 27 things on my onboarding checklist. So, when a new customer came in, I’d work my way through that list to bring them onboard and into our RMM. In the past, a lot of manual effort was required to do this, but with enhancements to the automation capabilities of RMM platforms, this doesn’t need to be a slow or manual process any longer. If you can’t (or you’re struggling to) set up automations to enable the discovery of new devices, see what type of devices they are, and then automatically put them into a patch or a monitoring profile, then I think this is a good example that you may not be taking full advantage of your RMM’s capabilities, and quite possibly that you have outgrown those capabilities altogether.

Related to this is another key point to look out for. And that is that you need to be able to talk to your customers to establish what their business-critical systems are, and then have the ability to tailor your monitoring to specifically target and support those business-critical systems in order to help ensure you can meet your SLAs. If this is not something you are able to customize inside your RMM, you may not have the right solution to meet your customers’ needs. 

Related Product

N‑central

Manage large networks or scale IT operations with RMM made for growing service providers.

En savoir plus

Is your RMM your go-to platform for monitoring, patch, and remediation efforts?

As an MSP, I believe your RMM solution should be one of your core platforms alongside your PSA and your backup product. If you’re not looking at your RMM your central source of truth when it comes to monitoring, patching, and remediation then, in my opinion that’s a major red flag—albeit a less obvious one for many MSPs.

Your techs should not be receiving alerts and immediately thinking let’s remote in, rather than trusting your RMM platform. If they’d rather spend a bunch of time poking around in a user’s machine, this could be a clear indicator that they’ve lost trust in the RMM, and as a result are not using it to its full potential. If they’re trusting their own IT skills against having faith in the functionality in the RMM to run things like self-healing or automatically remediate issues, then you need to understand why.

I’ve seen instances where MSPs have lost such trust in their RMM to do monitoring that they find another tool to do the job. There may, of course, be a justified reason for this, for example if the environment needs a specialized monitoring package that common RMM’s don’t provide. However, in many cases, the reality is that the care and attention that goes into keeping an RMM’s monitoring capabilities working effectively has not happened for some time, and someone has decided to bring a new tool in that actually overlaps with capabilities that the RMM already has.

Are you unable or unwilling to provide RMM access to customers for visibility? 

Having lost faith in your RMM can also manifest itself in another way. If you’re not happy sending out reports to your customers from your RMM (ie what’s been caught in their spam folder etc), are you ashamed of it? Alternatively, if you don’t trust giving your customers access to either see the work that you’ve done or do things like give them access to remotely connect into their own devices, is this because you lack trust in its role-based permissions. Either way if you’re not happy putting your RMM in front of your clients in this way, then this could be a yet another soft sign that it’s time for change.

If you’re reading this and mentally checking all the boxes, then maybe it’s a time to have a serious conversation with your vendors and your team. In my next blog I’ll look at the some of the reasons you shouldn’t change your RMM platform. I’ll also set out how to review your situation on an ongoing basis to ensure you don’t end up leaving things to the last minute, and end up damaging your relationship with your RMM vendor and forcing yourself into an unnecessary change.

MSPs can face some obvious challenges in knowing what the right RMM tools are for their business. The N‑able N‑central team helps mitigate these concerns by offering customers with existing RMM contracts with certain N‑able competitors the opportunity to switch to N‑central for just $1/month for up to 12 months*, as well as providing onboarding services for 1-on-1 training of techs, and migration services for hassle-free client migration. For existing N‑central partners, N‑able also provides health checks to you’re getting the optimum value from N‑central. To find out more contact your Partner Success Manager.

Chris Massey, Senior Manager of Partner Growth, N‑able

Chris has over 13 years’ experience in leading service delivery, technical operations, product, and marketing teams for an Enterprise MSP. He helped grow a service provider from 25 to 280 employees over a decade and was a key part of several organic growth and M&A activities for the service provider. Chris is focused on working with partners to overcome common challenges they experience with the MSP.

 * Terms and conditions apply