This is the fourth 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 this post
• Research, Analysts, consultants and forums
• Marketing and Shows
• ‘MSP team’ investment requirements
• Product capabilities and principles
• RMM’s, PSA’s and integrations
• Activity maps and company strategy
• Product management best practices

Commercial agreements/billing

The way you bill can dramatically decrease the opportunity with MSP’s. Keeping in mind what I covered in post 2 about the way MSP’s primarily manage their customers, aligning to the business practices will only make it easier for them to adopt your service and make you their vendor of choice.

In this section I will touch on a few key areas which you will need to consider when structuring your commercial agreements with MSP’s

Per-User vs Per-Device billing

You will need to decide on whether to adopt a per-user or per-device model. There are some services that will only fit in one of these models, but others can apply to either model. This may be counter to the golden rule of aligning with the MSP’s business, but as a vendor, I think that if your software is installed on a device, then you should stick with a per-device model. This will keep it simple for you to bill and report as well as forecast and model as you’ll be asking the MSP about their device counts in the sales conversation.

Per-user billing works great with SaaS/Cloud services where the end user is directly served and follows them from device to device, like Microsoft 365/GSuites, Security awareness training or Multifactor authentication (MFA).

Trying to wedge a per-user billing model on what is typically billed as per-device is a pain to support as you’ll need to come up with a user to device ratio to calculate what will make commercial sense from a gross margin perspective on COGs, also, building in systems to monitor abuse.

There are exceptions where per-user may be favourable for typical per-device services when you have heavy device-sharing by employees, I touched on Retail/Hospitality in post 2, these verticals are rife with this behaviour, also, Virtualised Environments where multiple users concurrently use a single server/device will mean per-user would probably work best – but you’ll need to figure out if it’s really worth chasing these £$’s.

I should point out that there are services that do not operate on a per-user or per-device model but on a per-site/client basis. These models are quite common for certain types of products where they allow the MSP to deploy the service without needing to worry about the amount of users/devices connecting to that site. I’m not a fan of this model as MSP’s don’t charge their customers like this and it makes it hard to price and cost out as a vendor as you could be dealing with 10 users/devices connected or 10k. 

Usage data

Once you have the per-user vs. per-device model decided, I want to underscore something that I’ve seen overlooked over the years which is usage monitoring. It seems pretty obvious but you need to ensure you can see the usage of your service and make this data available to your customers so they can reconcile this with the bill. Without this data you’ll also be struggling to properly quantify several health and cost metrics.

Instrumenting your service to report on the following should make usage reporting very straightforward:

• User and/or Device name (+ GUID/unique ID)
• Last seen timestamp (recommend UTC to avoid downstream issues when going global!)
• Site or customer of the MSP (+ GUID/unique ID)
• MSP name (+ GUID/unique ID)
• SKU name (what service the usage relates to)

You should run a daily job to collect this information and store this away so your billing system can calculate the usage based on any given day of the month. This will help when the MSP is trying to reconcile the way they bill their customers with the way you as a vendor bill them.

I like to define usage as ‘seen in the last 30 days’. Doing anything complicated with calendar months or anchoring a usage day of the month is asking for trouble and the 30 day approach is widely used.

I should state that usage can also apply to service consumption beyond a device or user having the service activated, examples include backup solutions and logging services (SIEM) where there may be a per GB charge.

Your system needs to support the use case where MSP’s will decommission devices/users and come up with a business rule to support the logic so your customers don’t feel hard done by when they upgrade/re-image devices or offboard client employees.

MSP’s don’t want to commit resources to investigate low-level discrepancies in your usage data/bills. However they do expect you as a vendor to get this right as if there are any discrepancies found later down the line, they will expect to be compensated retrospectively!

Billing Frequency and commits

In the MSP world, there are 2 main billing models worth discussing, there are many other variations but these are most common.

• Month-to-month no term commit
  • Volume discount = no
  • Term = 30 days rolling
  • Usage/overage = yes, based on 30 days last seen
  • Price Premium = yes, increase by >30% on annual commit price
• Monthly billed with term commit
  • Volume discount = yes, tiered with price breaks
  • Term = 1,2,3 year options
  • Usage/overage = yes, based on 30 days last seen
  • Price Premium = no

With month-to-month, you will bill them based on their usage on a monthly basis. I recommend you set a floor with a minimum volume commit of at least 5 devices/users and set the price point at least 30% higher than an annual term contract.

Smaller MSP’s tend to go for this model more than Medium and Large MSP’s, based on cash flow and other persona traits. Just because month-to-month attracts smaller MSP’s doesn’t mean you should avoid this model as many larger MSP’s will want to try your service on a few clients beyond the typical 14/30 day trial period your service may offer before jumping in with annual commits. Also, longer term analysis of month-to-month clients showed that a good portion of these clients grew their overall business over a couple of years substantially and as a vendor you can ride on their expansion.

Supporting month-to-month took a lot of convincing of finance teams, but it proved worth it based on cohort behaviours long term. Resistance came when trying to understand the impact to some of the SaaS metrics I mentioned in my previous post, specifically LTV:CAC (Lifetime value vs. Cost of Acquiring customer) ratios.

In my experience, by far the most common is Monthly billed with annual commitment. This model works by offering the MSP an annual contract, but billed every month, also included is a commitment to the amount of volume they will use – this is designed to give the MSP better price breaks and for the vendor to get a predictable revenue. They can go over this amount and be charged for ‘Overage’ for any usage beyond their commit, this is where the usage data plays a key part as your customers will want this reconciled.

On the topic of Overage, I do not recommend you have a hard ‘seat enforcement’ in place unless absolutely necessary. Inhibiting your customers from deploying more than they previously committed will hamper your growth and become very annoying for both you and your customer. Ensure your EULA/Terms of Services cover the ability to charge overage if they go over, MSP’s expect this and as long as you alert them and make it easy to reconcile you will reap the benefits of the MSP’s expansion. Find a balance of what is right for you as a vendor and the customer, if in doubt, always lean in favour of the customer.

The term length is quite a hot topic amongst MSP’s at the moment with some prominent service providers changing their terms to a 3 year minimum, which I think is not conducive to the MSPs business and do not recommend. Having price breaks on multiple years is totally fine but don’t mandate anything above 1 year.

Lastly, where things get tricky is when the MSP account size contracts(reduces) and they lose a client or decide to remove your service mid-term, therefore they go under their volume commitment. This is something you will face quite often, to address this you should get ahead of this and have well defined business rules in place to 1) do what is right by the MSP whilst 2) protect your revenues from any abuse, don’t leave it just to the account manager to resolve ad-hoc as this will tie them up from selling and leave you with accountancy headaches.

Co-terming contracts and Services

Similar to the decision about per-user vs per-device, you will need to make a call on whether you wish to have separate service contracts for each of the clients of the MSP or a single contract with the MSP to cover all their clients.

To illustrate this further below shows the contract(s) start and end with the two differing models:

The cumulative duration of the contracts is not the only aspect of this topic, it’s also the volume of service the MSP is committing to. As discussed in the previous topic, it is expected that price breaks will be made available for the total amount of volume an MSP purchases so calculating this across multiple contracts is required when not co-terming.

A key factor in the decision to co-term or not may be predicated on the type of service you have. With physical hardware services like network equipment and some backup/disaster recovery solutions, you will likely not want to have anything less than a 12 month commitment from each client of the MSP if you have warranties and support contracts to deal with. Also, the economics may not work out if you are shipping hardware to a client of an MSP in month 11 of a co-termed contract only to have the MSP decide not to renew their contract the following month when they reach their 12 month co-term contract renewal.

Renewals are a pain to manage when not co-terming. Coming back to the TAM/SAM data I shared in the first post, Large MSP’s can have >100 clients under management and if you expect them to like you for having separate contracts for each client of theirs, you’ll be mistaken!

If you are a software SaaS company I would highly recommend co-terming contracts with MSP’s. The sheer amount of work for both the MSP and your sales operations/account management teams cannot be underestimated, even if you automate this.

You may be thinking that not co-terming is stickier as the MSP is committed to a longer tail of disparate contracts, yes, it is stickier in the sense that they have handcuffs on as they are locked in, but it’s not being a good business partner in my opinion.

If you are planning on co-terming, ensure that you have per client minimum volumes – don’t just have a pool of seats which the MSP can distribute ‘onesie-twosie’. A 5 seat minimum is recommended, I have tried 10 in the past but this was met with significant resistance based on the client sizes MSP’s deal with so I stuck with 5 as the modelling supported this.  

Finally, this decision should be a joint conversation with sales, finance and legal teams as you will need to model out the impact of any changes as well as understand implications to your EULA/ToS especially how these get accepted by the MSP,  billing terms, SLA’s commitments and termination clauses.