Do Four Hour Break/Fix Service Contracts Really Guarantee Anything?

Most companies presume that when they purchase service contracts that guarantee four hour break/fix response times for their computer hardware, they are purchasing the appropriate level of support to ensure they can recover their new equipment should it fail for some reason. This level of confidence is especially critical in circumstances where companies deploy new hardware in conjunction with mission-critical applications - or when that equipment is embedded as part of a custom system, such as a medical device like an MRI. With these applications, any downtime is unacceptable. So companies want and need the assurance that their hardware will be back up and running and, while a four hour recovery window for these applications is still not ideal, it is better than having no time frame for a recovery at all.

Yet what many companies fail to recognize is that these service contracts guaranteeing 4 hour break/fix response times only promise one thing: a vendor response, not a hardware fix nor application availability. So if the technician shows up at the company site - or at the hospital - within 4 hours of the call being placed, the vendor has satisfied the terms of the service contract even though the problem may be no closer to being fixed than when your company originally reported the problem.

This train of thought on the part of companies represents a serious disconnect between what is promised in the service contract and what companies may think they are receiving when they purchase it. Right or wrong, the corporate expectation is typically that the vendor will have someone onsite within four hours, the equipment fixed or replaced, and the application brought back online. In the world of real life, however, companies find out only after an incident occurs that it may be hours, or even days, before the application comes back online. This disconnect helps neither the vendor, since a perception is created that the vendor failed to deliver on an in-force service contract, nor its client, since the application is out of commission until the hardware is repaired.

What good is a four-hour break/fix SLA when your MRI is out of commission for a week waiting for a repair to the embedded server? In real life, the technician that arrives on-site at the hospital may take that long just to figure out how to open up the MRI device and find the server. This situation is no less dire when the server is embedded for satellite television service, or used for more straight-forward uses - like running an Exchange or Oracle database.

Companies that purchase pre-assembled systems from embedded systems manufacturers face additional challenges. Embedded systems manufacturers procure servers and storage from distributers and then offer these pre-assembled systems with these storage and servers as one unit. The embedded systems manufacturer finds themselves as much at the mercy of the systems manufacturer as their end-user customer - and they learn the actual value of four-hour break/fix SLA's in much the same way.

Companies that purchase these pre-assembled systems with four hour break/fix service contracts may find themselves somewhat in a quandary as to who to call for support when hardware fails. Does the company call the embedded system manufacturer that understands the criticality of the application and how it operates but can not actually fix the hardware? Or, does the company call the vendor that services the server and/or storage but whose technician may not understand the hardware's role in the pre-assembled system's configuration? In this case, fixing the hardware without an understanding of how the company utilizes the pre-assembled system could ultimately break or interrupt corporate processes.

Making this situation even more complicated is that companies may actually end up with two service contracts - one for the pre-assembled system that they bought from the embedded system manufacturer and another for the hardware within the pre-assembled system. So if and when a hardware problem does occur, the company may first need to make a determination which component broke and then call the responsible vendor as opposed to just contacting the company from which they bought the system. If it is not clear where the problem lies, a company may need to call both vendors and let them sort out the problem.

Bottom line, companies that purchase these service contracts care primarily about one thing - fixing the hardware problem and bringing the application back online. This gap in understanding about what service contracts actually deliver, the problematic nature of resolving hardware issues within pre-assembled systems and the need to call multiple vendors to resolve the hardware issue only serve to frustrate companies and introduce questions about the support arm of embedded systems manufacturers.

The good news is that at least one distributor, Bell Micro, has enough experience in working with OEM customers to have identified this as an across the board issue. Bell Micro offers more immediate remedies than waiting for equipment fix, and has internally put pressure on suppliers like HP in order to bring some real resolution to this problem with better OEM-ready programs.

Bell Micro and its strategic partner HP now recognize that a customer does not want to "own" support but really wants the OEM that sold them the equipment to "own" support for it. Bell Micro also realizes that for OEMs to deliver on this customer expectation that they need an easier, more practical way to provide a one-stop shop for equipment support. In a forthcoming blog entry, I'll examine in closer detail the steps Bell Micro is taking to address this perennial challenge and what this means for companies in terms of receiving the four hour application fix that they expect when they purchase a service contract.