MSPmentor Blog
Only You Can Prevent Firefighting: Don't Let Your Engineers Get Burned by Customer Onboarding

Only You Can Prevent Firefighting: Don't Let Your Engineers Get Burned by Customer Onboarding

As an MSP, you want to continuously land new customers. However, the onboarding process for these customers can be a logistical nightmare. This is mainly because your new customers expect to see results right away. And, even if you did a proper audit, you may have missed some of their issues. This can lead to your engineers dealing with a huge influx of tickets before they really know what they’re looking at, putting out fire after fire without being able to think about the problems they may be creating down the line.

Firefighting might be necessary, but it often exacerbates existing issues--snowballing them into a mess that takes up valuable time and resources. Let’s take a look at just a few of the many reasons firefighting will hurt your bottom line, and some tips for putting out fires or stopping them before they start:

1. Competing priorities: The reality is that, as an MSP, you have finite time and resources, despite what customers may think. If you are firefighting, you aren’t able to spend time setting up automations and being proactive. You have to decide the most efficient way of allocating those resources to best serve your customers. It’s difficult to deliver the best managed services possible when you’re constantly distracted by new emergencies, whether it’s issues with business-critical applications, network connectivity, infected machines or whatever other mess your predecessor left behind for you.

Tip: As important as it is to put out fires, a good practice is to make it standard operating policy to always leave a customer environment better than you found it. Spending that extra half hour focusing on long-term fixes after a crisis can prevent the next fire from happening.

2. Finding exceptions for VIPs: We’re all familiar with this scenario: A customer executive demands more leeway when it comes to security. Before you took over, the previous IT staff may have created one-off exceptions that disabled or modified security policies. This gave the customer what it wanted, but left you with a gaping vulnerability and the responsibility of cleaning up infections.

Tip: Tapping into the right security tools—ones that don’t impact performance or hinder users--can make the difference between arguing over making exceptions and a grateful customer executive that is protected without being annoyed.

3. Shortcuts and rework are expensive: Ask any engineer with crisis experience, and he or she will tell you that emergency response is grueling. When dealing with a fire, the goal is to put it out, not meticulously plan every little detail of the response. To make customers happy, your engineers might take shortcuts to get the job done at lightning speed, which can cause problems further down the line.

Here’s an example from our recent white paper: A customer calls dispatch with a network outage that the engineers are eager to address. To troubleshoot, they shut off everything that could be between the user and the network, including security controls. In all the chaos, the engineers didn’t take notes on what was set up before the changes were made—and after the outage was corrected, put off reverting the changes. The result? Gaping holes in security policies that cause future infections—meaning more fires for your engineers to put out. Are you beginning to see a pattern here?

Tip: Having a standardized checklist of what must be enabled for all customers and a set of tests to verify that the network is in compliance can help prevent engineers from leaving shortcuts in place.

The moral of the story? Don’t leave your engineers to fight fires without a plan for getting out. You won’t always be able to fully understand a new customer’s environment right off the bat— but you can take steps to cut down on firefighting.

One solution is OpenDNS’ Umbrella for MSPs. As a cloud-delivered service, it’s hardware-agnostic and can be set up in minutes. By deploying a layer of malware protection in the first day of service, you cut down on the fires giving your team breathing room. Instead of battling malware-related tickets or fighting with legacy security solutions, you can invest your energy in fixing underlying issues and on bringing in your automations.

You can’t always predict when a crisis will break out, but you can reduce the likelihood of future fires. Taking steps to prevent issues in advance will have a profound effect on your engineers, your customers and your bottom line.

Guest blogs such as this one are published monthly and are part of MSPmentor's annual platinum sponsorship.


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.