Many MSPs can benefit from offering different levels of service to their customers - it allows them to tailor their product to the size and budget of the organization they serve. The challenge is finding ways to automate this to deliver consistency without significant effort. Some common methods we've seen range from defining automation policies to run scripts to deploy software and linking these policies to each customer to just manually running the scripts needed to deploy the applications. The challenge with this - like all manual actions - is consistency. The RMM Suite solves this through Service Class Automation.

Service Class Automation

Just to clarify the term, "Service Class" (or Class of Service) usually assigns a name to the delivery of specific services. A good example is the classic Bronze / Silver / Gold terms, where Bronze might provide basic monitoring and AV while Gold provides advanced monitoring, proactive maintenance, and comprehensive endpoint security services. This can related to several services within an MSP practice, including monitoring, software, maintenance, patching, and security.

The RMM Suite employs a basic Service Class of Unmanaged and Managed, which is used broadly to apply or block automation. 

Unmanaged - This can be a "break/fix" or "time and materials" customer with no automation. RMM Suite customers also use this mode to onboard new clients. Since an unmanaged customer receives no automation, it allows a period of time after deploying agents to perform discovery actions. This can lead to preparing custom configurations, setting up software licenses for automated deployments, and identifying any special monitoring requirements. Once all customer preparation is completed, a client can be switched to Managed. This is defined using either a Customer Custom Field or - in VSA - a Machine Group root name.

Managed - This represents a generic state where ALL automated services can be applied. The automation policies specifically look for the "unmanaged" status, treating all other status types as "managed". This allows a generic classification of "managed" as well as specific sub-classifications or Service Classes. The service classes can also be used to drive client billing.

Service Classes - These are codes - whether colors, metals, animals, or simply an alpha-numeric ID - that define a specific set of services. These codes can be distinct or cumulative - that's completely up to the MSP. Cumulative codes take a bit more planning and configuration effort, but can simplify certain aspects of the automation.

Distinct Code Mapping

Distinct codes will map a set of specific components and services to a single code. A system filter identifies the code and applies the appropriate services. Note that the same services can be associated with multiple Service Class codes.

Iron - Basic AV, Patching

Steel - Basic AV, Antimalware, Patching, Application Updating, Basic Monitoring

Titanium - Advanced AV, Endpoint Security, Antimalware, Patching, Application Updating, Basic Monitoring, Advanced Monitoring

There are three automation policies and three filters. The filter checks for the Service Level code and applies the automation policy. The policy applies the products and services that are part of the Service Class. You will see that two policies have Basic AV, Antimalware, and Application Updating, three have Patching, and two have products unique to that class, This is a simple mapping of code to services and works well when there are a small set of classes and products.

Cumulative Code Mapping

This method creates a filter and automation policy for each distinct product or service instead of the service class. The filter applies a specific product or service when it matches one or more Service Class codes. This is how it works:

Basic AV - Filter triggers at Iron OR Steel levels

Advanced AV - Filter triggers at Titanium level

Antimalware - Filter triggers at Steel OR Titanium levels

Patching - Filter triggers at Iron OR Steel OR Titanium levels

Basic Monitoring - Filter triggers at Steel OR Titanium levels

Advanced Monitoring - Filter triggers at Titanium level

While this is certainly more complex and requires distinct filters and automation policies for each service, it provides greater flexibility when there are additional Service Classes. Consider adding a new "Tin" service class that only provides patching, and an "Aluminum" level with Patching and Application Updating. By simply updating the filter associated with the products to trigger on these new service classes, the automation applies without the need to create both new filters AND automation policies. 

How the RMM Suite uses Service Class Mapping

Each day, when the Daily Audit application runs, it determines the Service Class code assigned to the customer. This starts by checking for a Customer Custom Field called CCOS. The value - if defined - is mapped to the "SC:id" tag and written to the System Roles Agent Custom Field, along with any other TAGs based on the applications and services found. The TAGs can be used to drive views to apply policies, which is useful for applying the monitors associated with these Service Classes. The TAG can also be used directly by the Daily Maintenance tool to install application components, either by local script or RMM script.

A second advantage of this method is the Service Class identity is added to a machine-specific field. Some RMMs do not expose the Customer Custom Fields to agent scripting and this circumvents that deficiency.