If I Were Launching an MSP Now | Brendon Liner

Brendon Liner, founder and vice president of Minneapolis-based Nology Networks, shares three suggestions he’d apply if he were launching an MSP from scratch today:

1. Prioritize customer service and soft skills over technical skills – When we hire helpdesk staff in our organization, we always hire with soft skills and customer service skills in mind first, and technical skill second.

Our helpdesk people are the front line to our customers.

Sales people and account managers obviously build the relationship, but when customers have a problem, things are stressful and tensions are running high, they are talking to a helpdesk person that is working to solve those problems.

Make sure that helpdesk people have empathy and can understand that these aren't just technical problems, but actually business problems – they impact how our clients can run their business.

Helpdesk people must resolve those problems while also understanding the customers’ frustrations and putting themselves into those clients' shoes.

It’s not just thinking of it as a technical problem, it’s really making sure that clients understand that we care, that we're putting every effort that we can into solving it as quickly as possible, because we truly understand how that problem might be impacting their business.

Helpdesk staff is on the front lines every single day.

They are the ones interacting with the clients most, and they are the ones who can make or break keeping clients happy or potentially losing a client.

It's not the sales people and the account managers that are maintaining those relationships in the real world.

It's the helpdesk people.

2. Standardize your product offerings – As an MSP, when we started, we wanted to do everything, be everything, sell every product to everybody.

Quickly we learned that as a business, you can't scale that way.

If you're taking every project, regardless of whether it's in your wheelhouse or not, even if you can do the projects and have the technical skill set to complete the projects, often times it detracts from how you can scale if you're putting your hands in too many custom projects.

We quickly learned that it's best to standardize on a product set, find out what you're really good at and focus on those.

Sometimes you have to say no to potential clients and refer the business to somebody else when those projects get too customized or fall outside of your core competencies and those standardized products.

As an MSP and also a cloud service provider, we know what we're good at, which is the managed services, the helpdesk, and then our cloud services, which is our application hosting, our data hosting, virtual server infrastructure.

We focus on those products.

When we find ourselves getting into something that isn't a standard product that we offer, we have to either guide the client back to a standard offering, or sometimes say “no” to the business.

That allows us to scale with a lot fewer employees, and more quickly.

3. Emphasize documentation – As any MSP grows – and I'm sure many can relate – they manage things in Excel spreadsheets, and Word documents, and different apps here and there.

We quickly found out we can't scale unless we have really thorough documentation.

When you only have ten clients, it's really easy for your helpdesk people to have every piece of information in their head and know everything about that client.

But when you scale to 400 clients, which is about where we are today, it's impossible for every person on the helpdesk to know everything about every client.

We use a documentation platform, IT Glue, which we swear by and added to our business about two years ago.

It's been amazing for us.

We have every piece of every client documented.

When a call comes in for support, we can literally open up that application, and if we need to know where the wireless access point is located in an office, or exactly the applications, the versions and the licenses, and who's authorized to do what on the account; we have every piece of information in that documentation system.

If anything, we over-document to make sure that we know every single piece about our client.

It doesn't matter which person takes the call.

They can open up the application and know every piece of information about that client.

Nothing fits inside someone's head as the only source of knowledge.

By over-documenting versus under-documenting, you're not wasting time down the road trying to relearn your client's environment each time.

Editor’s note: Comments are edited to improve readability.

If you’d like to be featured on a future “If I Were Launching an MSP Now,” email us with your name, company name and phone number at[email protected].