This is the sixth post in this series, if you’ve not read the first post I’d recommend you skim it first for context. As a reminder, here is what I’m covering in this series:

• What is an MSP? – Covered in post 1
• TAM/SAM – Covered in post 1
• Economics of an MSP and their customers – Covered in post 2
• Personas – Covered in post 2
• Vertical analysis-Covered in post 2
• Share of Wallet – Covered in post 2
• The assisted sale Covered post 3
• Product Penetration Scale Covered post 3
• Financial Modelling Covered in post 3
• SaaS metrics Covered in post 3
• Commercial agreements/billing – Covered in post 4
• Research, Analysts, consultants and forums – Covered in post 5
• Marketing and Shows – Covered in post 5
• RMM’s, PSA’s and integrations – Covered in this post
• Product capabilities and principles
• ‘MSP team’ investment requirements
• Activity maps and company strategy
• Product management best practices

RMM’s, PSA’s and integrations

I’ve hinted throughout this series about the importance of integrating with RMM’s and PSA’s, the reason being that I’ve not met a successful MSP that does not use an RMM or PSA in the last 5 years.

For any viable GTM or Product strategy, you need to intimately understand your customer’s business and figure out ways to access and provide value to them en masse. A very effective approach involves targetting customers via services they use day in, day out, for MSP’s you should have an integration plan for PSA’s and/or RMM’s.

Depending on your service, it may only make sense to integrate with PSA’s only, read on for why this is.

Note. I am consciously separating RMM’s and PSA’s in this post, where in reality, a few providers merge both into a single platform. This is so you can understand the two distinct use cases for integrating into either.

Remote Monitoring and Management (RMM)

Borrowing ConnectWise’s definition:

Remote monitoring and management (RMM) is a process designed to help managed IT service providers (MSPs) remotely and proactively monitor client endpoints, networks, and computers. RMM can also be referred to by other names like remote IT management or network management.

A small footprint, often called an “agent,” is installed on client workstations, servers, mobile devices, and other endpoints to deploy remote monitoring management. These agents then feed information about machine health and status back to the MSP.

Essentially the RMM is referred to as the “single pane of glass” for the MSP technician where they monitor and take action on their client’s environment from a console the MSP or the RMM provider hosts for them (SaaS).

The RMM technology has traditionally come in two forms, self-hosted (on-prem) and cloud-hosted, on-prem RMM’s are dying a death as most RMM’s are hosted by the RMM vendor now – this has led to changes in how 3rd party vendors integrate into RMM’s.

You can see who cloud hosts vs allowing on-prem in the spreadsheet I keep sharing, although it looks like there’s still a lot of support for on-premise, the trend is certainly moving to cloud-only with all newcomers omitting on-prem support.

Why does this matter? If your MSP’s are looking to use your service within their chosen RMM, you may need to integrate into both environments, which is a royal PITA! This is because some of the largest MSPs are still using on-prem.

Integrating into RMM’s is only relevant for certain technologies, the same spreadsheet above lists out a good set of examples, here are a few I’ve picked out:

• Systems Management
  • User Account mgmt + automation
  • Patch Management
  • Backup Integrations
  • Remote Support Integrations
  • System monitoring tools
• Security Solution Integrations
  • Endpoint protection (inc. EDR/XDR)
  • Managed detection and Response (MDR)
  • Password Management
  • Mail Protection
  • Web Filtering
  • Vulnerability Mgmt
• Compliance Audits (PCI, PAN, HIPAA)
• Support/Chat applications
• Documentation management
• Enterprise File Sync

Check out another spreadsheet I shared in the first post for example vendors, if you see a competitor, then you should consider integrating!

Why and how do you integrate with RMM’s?

First and foremost, integrating for the sake of it doesn’t make sense if the MSP is not seeing the value for their operations and business overall.

With RMM’s the primary user is the MSP technician, their time is money so you need to understand what the technician requires to make their job easier and essentially increase the profitability of their business. You will understand this more as you conduct interviews and perform ride-along sessions with the MSP.

MSP’s love automation, ask MSP’s how many scripts they have and no doubt they are in the 100s. So if your technology lends itself well to being able to plug into their workflows so they can drive further efficiencies, you’ll be on the right track.

If you have agent/device software, you can dramatically increase the chances of getting full deployments if you integrate it with the RMM’s installation scripts – this has a fanatastic ROI! This is because MSP’s often partially deploy to their customers and any net-new customers or devices added are not automatically deployed with software. Learn more about typical Product Penetration Scale rates (PPS) here.

As mentioned earlier, certain technologies lend themselves well to RMM integrations, I’ve spent much of my career on Endpoint-centric technologies, which is a prime technology for plugging into their “single pane of glass”. If you have user-centric services and there is no installable software, RMMs aren’t there yet with user management, so the value may be limited (I’m sure there are exceptions!)

RMM’s are built around clients/customers and devices. An MSP will have more than one customer understanding this hierarchy is imperative as I mentioned previously that MSP’s serve lots of small businesses, your technology needs to adopt the same hierarchical structure so that it can map into the RMM structure seamlessly. See below for an example:

If your service has actionable device information, your integration would plug into this view and allow the technician to view your service’s information and take action directly from the RMM.

To get your services data into the RMM, there are two primary methods to do this:

• If you have endpoint software, leverage the RMM agent to install your software and detect the status of your service using the RMM’s built-in monitors/scripting tools
• Use an API directly from the RMM to your cloud service

Both methods will require you to work with the RMM provider to allow you access to their documentation and API’s to build out the integrations. Beware, each RMM’s (and PSA’s) documentation and quality of code varies greatly!! And things break all the time, so be sure to have adequate monitoring in place to detect these issues.

Remember, you will have to look at on-prem and cloud integrations for some RMM’s and it can be double the work in some cases!

I’m going to cover the costs and team structure in a future post so you have an idea of the investment requirements.

Professional Service Automation (PSA)

Borrowing a snippet from Datto/Autotask’s definition, here are the most common components of a PSA

…

• CRM: Win new business and manage your existing customer base with a full 360 degree view of account information
• Service Desk: The Ticketing module is ITIL-aligned with built-in best practices to make sure MSPs hit their SLA targets
• Projects: Manage projects so they come in on-time, on-budget, and on-spec
• Time & Billing: Ensure all billable time and expenses are accounted for without dispute
• Customer Agreements and SLAs: Meet commitments with detailed customer agreements and SLA documentation at your fingertips.
• Reporting: Easily understand the most important metrics and deadlines to continually improve service

…

As you can see, this is more geared toward the “business side” of the MSP, with managing contracts, service requests and billing.

If you are working with MSP’s, you 100% need to integrate your service into their PSA so the MSP’s can:

• Provision your service 
  • You need to support full-service provisioning via API which does all the things you allow directly with customers when onboarding them onto your service, so this can be replicated in the PSA
• Report upon the usage/activity of your service
  • You need daily, weekly and monthly reporting on service utilisation and key metrics. The MSP should be able to align with their reporting and billing periods and not be forced into yours 
• Trigger service requests for their technicians 
  • If anything requires the Technician’s attention, you need to make this consumable in near real-time via the PSA’s ticket solution – email ingestion or API’s can work here.

I cannot overemphasise the importance of the first point, integrating into the PSA and having a single click to enable your services, which in turn triggers the RMM to install your agent software (if you have one), is magical and catapulted previous products I managed into cash cows.

Integrating into PSA’s is technically similar to RMM’s, although it requires a lot of work on your side to ensure you can support these requirements.

I’ve scratched the surface with this post, but I hope this gives you a high-level idea of what type of integration is required to work with MSP’s. LMK if you’d like more specifics on any of the above.