How to Address Ticking Timebombs Clients

Overworked designer
Share on linkedin
Share on twitter
Share on facebook

We all have clients that just won’t approve any projects and their infrastructure just keeps getting older and older. It’s so bad that it becomes a bit of a running joke in MSPs. This client is now a ticking timebomb and a real risk for our MSP.

We find ourselves asking “How did we get here!?” We think we’ve done everything right; every year our vCIO held a meeting, presented a risk assessment, a roadmap detailing the projects needed to bring them up to par as well as a precise budget. But nothing ever changes.

At first, it was this one server that was running an unsupported OS and the client said they didn’t have the budget to change it right away because times were tough. Now, a couple years down the road, nothing is under warranty, and you can’t believe that you let things get this bad.

Here is what we do in our MSP that works almost every time. Once we feel we’ve done everything possible through the softer approach. We will write up a disclaimer in which we:

  • Identify the problematic system(s)
  • Describe the risk and consequences of its failure
  • State that will not be responsible for any losses caused by this situation
  • State that issues arising from this situation will not be included in our monthly agreement and will be billable

Here is a link to an example

We then present it to our point of contact explaining that he or she must sign it for us if they want us to continue to support them. In 19 years of owning an MSP, I think we only had a single client sign one of these. It will almost always lead to them finally addressing the situation.

Why this works so well is that by putting it on paper (ok electronically) and having the point of contact sign it off, the responsibility has now been transferred onto his or her shoulders. I’ve found that this often happens when we aren’t dealing with the ultimate decider (even if we thought we were) and our point of contact is scared of asking the “boss” for money. The PoC will be a lot more scared of being responsible for a major crash and things will finally move.

This can happen when dealing with a co-owner, CFO or COO that’s afraid of whoever is the ultimate decider. This point of contact is always asking if there is another way and convinces him or herself that it isn’t so bad. Basically, the PoC is trying to push this responsibility onto us as an MSP and would hold us responsible if ever anything happened.

I want to be clear that I’m not advocating to pull a disclaimer out every time a client refuses to move forward with an important project. This is more of a “last resort” type of thing. Finally, we should always address the situation when that first server fell off warranty and not let it snowball.

Newsletter

SaaS-Based App for vCIO Efficiency

IT Roadmap & IT Asset Lifecycle Management