To Scale Your MSSP: Treat It Like A Car Engine

Author: Scott McCrady

One of the biggest issues MSSPs have in scaling their business is providing services that actually scale. Most of the time it is not due to lack of vision, desire, or technical know-how - it’s down to those two pesky groups always causing problems: customers and your sales team (they’re of course actually my two favorite groups). In the effort to meet customer requests, MSSPs get manipulated into offering one-off, custom capabilities that are rarely programmatic, and rely on human memory or intervention to deliver. This “scope creep” can occur as part of a new contract or come up midterm but they don’t get you that lovely Five Nine experience customers want.

To address this challenge, one effective approach that has worked for me is to treat the service like a product. Many sales people and customers view a service as something that can be changed, adjusted or customized. Over time, however, customizations can have a catastrophic impact on cost and operational efficiency for the MSSP. And, as that inevitably leads to missed and delayed delivery, one-off customizations hurt the customer in the long run as well.

Another useful analogy is to view the services portfolio of your organization as a car, and treat the managed security service as the car engine. Primarily, the MSS should be designed to go very fast, with little to no hiccups. Customizations such as pretty and uniquely built reports -- like unique paint or custom wheels on a car – fall under the domain of consulting services.  The typical immediate response to bringing in consultants is that it adds cost and complexity.  Potentially, that can be true. But I’ve found it more often provides a superior customer experience, and usually still well within a cost envelop that customers can maintain.

Customer Requests: Five Suggestions for MSSPs

Putting it into practice, customers can – and will – ask for anything, from the way policies are managed and during certain time frames, to customized reporting, to unique ways to receive logs for analytics. So how do you handle them all? Here are some suggestions:

1. The impossible-to-scale request: Sometimes you have to explain to a customer that there is virtually no way to make their custom request systematic and programmable inside the service. But then they tell you or your sales team, “Well, the other guys say they can do it.” (For those Monty Python fans out there, any time I heard that, I recalled the French Knights who, when asked if they wanted to go on a quest for the Holy Grail, replied that they “already got one.”) Typically, the truth is, if you can’t scale the request, odds are high that the other guys can’t either.

However, if you know for sure that what is being asked can’t be delivered in a consistent manner, then I would turn the tables. Explain to the customer:

  • Exactly why the request is not possible programmatically as part of the service
  • Why saying it is possible would be falsely exaggerating
  • How you can deliver the result with excellence and consistency with a combination of consultancy and MSSP capabilities.

This almost always worked in our favor, as it put a spotlight on the other guys not being as forthright as they should be about their capabilities.

2. Be honest and transparent: At the end of the day, customers want a great experience. The car analogy makes the point that anything outside of the realm of MSSP capabilities will likely end up being an annoying “knock in the system” for the term of the contract, which is no fun for anyone. Remote MSSP services are much cheaper than onsite consultant, and customers understand the model. It’s been amazing how authenticity goes a long way. Many times, the process has gone like this:

  • I explained that I really would like to deliver on their request, but it’s just not scalable the way it is described
  • I explained I want them to be happy, so suggest we look at other options
  • After that conversation, they’ve either change their requirement or were okay with other options presented

3. Do it…if you are going to add it to the roadmap anyway: There is nothing better than being paid in advance for work you were thinking about doing anyway. The caveat here is don’t forget and don’t defer. In a particularly joyful time in my career, when we were winning deals hand over fist, the customer requests were all smart, well-thought-out and deliverable…we just hadn’t built them yet. So we agreed, and then the dev team put in some seriously long hours to deliver on those commitments, and on the overall roadmap as a whole. It was well worth the effort.

4. Partner with the consultant. Depending on the size and complexity of the company, this can be either hard or easy. In small companies, the onsite guys and the SOC guys tend to work synergistically, often based in the same office. In large organizations, it can be very disparate. So make sure whoever is going on site to help out has spent some time in the SOC. We would usually get that person to spend at least one day in the SOC, meeting the teams and getting to know with whom they would be partnering. This is definitely best practice.

5. Happy customers and employees are a beautiful thing: My experience has been that in order to dramatically increase customer service and overall employee job satisfaction, you often need to do one of two things. Either:

  • Scale back what the customer is asking for into a core MSSP proposal, or
  • Maintain it, and deliver customizations through an alternative method

Aggressive Roadmaps Will Rev Your Engine

Obviously, everyone has to do what is in the best interest of their business and customers. And having hard-and-fast rules is challenging. This is by no means a recommendation to say no to all enhancements. In fact, having an aggressive roadmap, which delivers on true customer needs that are repeatable and remotely deliverable, is very important. If you can limit the amount of one-off solutions being delivered from that precious high-speed “car” engine, it will give you and your customers a much better overall security posture and experience.

Scott McCrady is VP of APJ sales and global strategic partnering at SonicWall.