May
29

MSPs: Are You Ready To Say Goodbye To Break-Fix?

MSPs: Are You Ready To Say Goodbye To Break-Fix?

May 29
By

I didn’t expect to be writing this post. If I were running a small business like a dental office, I would always choose the flat fee of a professional services model over the old-school “break-fix” way of doing things, even if someone on my staff were an IT natural and that flat fee cost more per year than what I had spent on repair the previous two.

Why would I choose to spend more money than I was used to spending up to that point? Here’s a quick list:

  • Continuous, proactive monitoring and upkeep of my increasingly complex system (including patches, updates, and spam filtering, among other things)
  • Reliable backups
  • Simple invoicing (vs. a five-page itemized one)
  • Consistent budgeting
  • SLAs for uptime, response time, security, and compliance

Surprisingly (at least to me), many customers are reluctant to move to this model. StorageCraft partner Vince Tinnirello, CEO of Denver-based MSP Anchor Network Solutions, told me the story of a law firm that balked at migrating to the professional services model. Vince said the firm didn’t understand the value:

Why would we pay for something we don’t need? Why wouldn’t we wait until something breaks?” they said. Then one day they called us in a panic because their server went down, and they needed to access documents for court. When I said I couldn’t get anyone to their site for three days, they were outraged. “Why? Your service level is atrocious!

I reminded them that with break-fix, they weren’t paying for a service level [but] for first available. “Respectfully, we’re not sitting with our feet up waiting for people to call. If I have [you and another client] calling, and the other has a professional services contract, guess who gets priority?

When Tinnirello’s team got to the law firm, they discovered that the firm’s backup tapes were blank—and even worse, the main screen of the firm’s primary server had shown warnings that the backups were about to fail. “All this stuff was preventable if somebody had been looking after it,” Tinnirello told me. “The thousands of dollars the firm ended up having to pay us was way more than it would’ve cost them to have had a service contract with us. And I doubt the judge was understanding when they said, ‘We don’t have the documents because our server went down.’”

Professional Services: the Best Solution for Them—and You

Only two reasons exist for an MSP to maintain break-fix contracts: recalcitrant clients and a (probably) misguided attempt at higher profits, but who wouldn’t want higher profits?

Under the break-fix model, if something breaks down, you could feasibly earn more bank charging by the hour every time something in a client’s system breaks. But isn’t operating in a reactive “firefighting” mode being pennywise and pound-foolish? When the time comes to fix something, you’re usually working from scratch because you haven’t been monitoring the customer’s systems to know what conceivably could have led to this problem. While you will charge that additional troubleshooting time to your customer, your resources become unavailable to help your other customers (or you hire additional staff who spend time goofing off until the next emergency, not exactly an efficient use of your resources). It makes more sense from a business perspective alone to know the amount of revenue your MSP will be earning each month, rather than hope for that big score from a foolhardy customer.

What about obstinate clients like the law firm Tinnirello described? Just explain the benefits of having you perform ongoing services for them and the advantages of having SLAs as protection. And if they refuse to see the light? You may have to terminate those contracts, just as Tinnirello eventually did with that law firm. And Tinnirello has no regrets about that decision.

Can you give some other reasons why a professional services model is better than a break-fix one—or vice versa? Please let us know in the comments!

Photo credit: Jeff Poskanzer via Wikimedia