When 99.9% Availability Isn't Good Enough

One of the characteristics of Application Service Provider and Software as a Service agreements that give users pause is the question of down time and availability.  If the system crashes, will the vendor commit sufficient resources to bring it back on-line in a commercially reasonable time? (By the way, what is a "commercially reasonable time"?)  Alternatively, will someone in the vendor's operation take the system down at noon on a Friday, so he or she can perform routine maintenance and still leave early for the beach?  If a system is hosted and run in-house, most users feel they have far more control over these exposures.

To address these situations, certain language is found in standard ASP and SaaS contracts, such as:

The System shall be operational, and the Services shall be Available 99.9% of the time each month, with the sole exception of scheduled maintenance periods, which shall last no longer than one (1) hour per day and which shall take place each morning between the hours of 3 a.m. and 4 a.m.

(I have omitted the three pages of technical specs spelling out how availability is measured.)  


At first reading, this language appears more than adequate.  The system is to be operational virtually around the clock, except for scheduled maintenance, which is to take place well outside normal business hours.  Yet at least two exposures remain:

• What if the 0.1% permitted downtime occurs when user is struggling to complete its response to a large RFP?

• What if user specifically wants to use the service between 3 and 4 a.m.?  What if, for example, user is a large investment bank that needs to do complex number crunching, and needs the processing power, and reduced pricing available with "off peak processing"?  

The first exposure is a technical one - it arises from possible hardware failures or errors by vendor or software glitches.  The proper response is due diligence - verify, before signing the contract - that vendor runs a quality operation AND has appropriate, and redundant, backup systems in place.  If Server A fails, Server B should take over automatically and user should never notice the transition.  The more critical the service is to user, the more important it is for user to select a user whose practices make it unlikely that unscheduled downtime will ever occur.
As for when scheduled maintenance will occur, that is a risk user can and must control.  A user who does not read the contract and does not realize that Vendor X performs maintenance during user's peak demand time really has no grounds to complain.  Neither should users expect vendors to readily agree to altering their schedule.  The business models of ASP and SaaS vendors call for volume and standardization.  Fast food burger joints make money by selling the same burger, millions of time each day.  Customization disrupts the system.  Rather than attempt to force Vendor X to bend, a prospective user may be better served by thanking X for her time and continue looking for a vendor whose services meet user's needs.


Next week:  Let's talk gadgets, not law.  A look at VOIP telecomm systems.  What are they and how can they contribute to your bottom line?