The trivial detail that will either future-proof or sabotage your PSA.

The sneakiest lesson that working inside hundreds of MSP systems has taught me.

Every implementation I run for MSPs holds something fascinating: a secret.

Unravelling a PSA (Professional Services Automation) set up is like gradually learning the story of an MSP; how they think, and how they’ve translated their own unique business processes into an off-the-shelf package, such as ConnectWise or Autotask.

And something that has become undeniably clear is that, regardless of size, there is ONE ever so simple, seemingly trivial thing that decides whether that PSA set up is going to scale with the MSP, or if its going to create major headaches and de-rail efficiencies in 1, 3 or 10 years time: Naming conventions.

Why it’s more than a harmless admin detail

We can quickly see if an MSP is under control or not from a billing perspective by the sheer presence or absence of a naming convention for each service line item they sell. The good ones have evolved into having a naming convention process which can scale as high and as far as they ever wish to go.
A lack of a naming convention in your PSA contracts & billing modules is welcoming future chaos. You might think its okay to wing it and pick a general name for “Antivirus” service, but what about when you’re reselling multiple vendors’ AV? Or the same product but through different distributors? Different terms (monthly vs annually)?

Wherever there’s multiple variations of services under the one naming banner, monthly reconciliation, pricing changes, and even decommissioning products can be like looking for a needle in a haystack.

Think scale

Beyond your own organic growth, with the rate of M&A activity in the MSP industry, it’s not a ridiculous notion that acquisitions or mergers should be factored in to today’s data planning.

On top of merging people, systems, processes together, both MSPs will have to decide on tech stacks. Similar categories of tech stack, however vastly different, make up of the tools resold.

We recently worked with an MSP who’s now an amalgamation of six different MSPs, with more to be rolled in over the next 12 to 18 months. Their PSA just had one general service name for “antivirus”, however they had found themselves selling four separate antivirus products under that name. Ouch.

So what naming convention is actually best? Follow these two rules:

The 1:1 Rule

The easiest way to future proof yourself is simple – the 1:1 rule. Every single vendor and every single product line of that vendor should have its own corresponding service or product inside of your PSA.
There is an unfounded belief in this industry that putting a vendor’s name in the service is a no-no, and it needs to be a unique tagline of some description. While the decision is completely up to you, in our experience in the future you will wish you just went with the vendor name itself.

The naming convention formula

Selecting a naming convention is up to you but we here is a solid starting point:
[Business Line]-[Frequency]-[Vendor Name]-[SKU]

EG:
Microsoft Exchange Online (Plan 2) billed monthly = MSNCE-M-EOP2
Sophos endpoint antivirus billed quarterly = AV-Q-SOPHOS-EP
and so on.

How to get started

Cleaning up your existing services is not as daunting as it may seem.

A good exercise for this is to take an invoice that you received from one of your suppliers and if it’s in excel you can then do a unique function and ‘drag out’ all the unique names of the services that you are currently buying. Every single one of those lines should have its own home inside your PSA.

Simple copy and paste of the service names from the vendor into an excel will work:

Put in the function of =unique(then select the column) you wish to retrieve the unique service names for, see the results below in green.

Now, set your naming convention. Below are examples following the

[Business Line]-[Frequency]-[Vendor Name]-[SKU] formula:

Want the excel template & more detailed instructions? Email me at adam@cloudolive.com and I’d be happy to share my templates, with compliments.

Like this type of content? Join our CloudOlive newsletter where we share our lessons of going deeper than anyone on the planet in optimizing MSP billing.

About the author

Adam Ross is a co-founder of CloudOlive, a company that was established in 2020 with the goal of solving a universal MSP challenge: SaaS billing management.

Visit CloudOlive’s website to know more.