Your IT vendors laughing at the contract you signed

Hours of Support

Standard support hours in most IT support contracts are 8:30 am to 5:30 pm Monday through Friday, excluding national holidays. The first question to think about is whether you want to require 24 x 7 x 365 support coverage. Of course, the vendor will tell you it costs more, but consider pushing them on this point. If a critical system malfunction happens at 5:31 pm on Friday, and Monday is Christmas, according to the standard contract language they won’t even take your call, much less task resources to start working on the problem, until 8:30 am on Tuesday. In the meantime, you may be unable to process transactions, and/or key web functionality may be offline.

Even if you decide that the ability to call for support outside of normal business hours is not necessary, make sure that the hours of coverage listed in the contract correspond to the time zone where you are located. If your business is in Philadelphia and the coverage period is given in Pacific time, then you will essentially have three unsupported hours each morning. Also, if a “critical” bug or outage (which should be defined in the contract as one affecting a critical function of the application or equipment or one that results in a substantial inability of the application or equipment to perform the tasks it was designed for) is reported during normal business hours, the vendor should be required to work “continuously,” notwithstanding the regular coverage period, to deliver a correction or suitable workaround as soon as possible. (In other words, they can’t stop work at 5:30 on Friday and pick up again the following week.)

Standard of Diligence and Response Times

Most initial drafts of IT support contracts (i.e., vendor’s standard forms) have wishy-washy language stating that the vendor will “respond” to bug or outage reports and “attempt to fix” the reported problems. Sometimes you may see language assuring that the vendor will use “commercially reasonable efforts” to resolve issues — a favorite lawyer’s trope because no one really knows what this means and, therefore, it’s difficult or impossible to prove in court that the vendor did not use “commercially reasonable efforts.”

If you are purchasing support, you should make sure that bugs or outages are classified by levels of severity and that, at a minimum, the vendor is required to use “continuous best efforts” to correct these problems or provide suitable workarounds, either as soon as possible or within some specific timeframe that is acceptable in view of the impact the problem is likely to have on your business operations. “Continuous best efforts” is another lawyer’s term of art, but is understood to impose a very high standard of responsiveness. To use “continuous best efforts,” a vendor must work tirelessly around the clock and devote the full resources of its business to solving the problem, which, of course, is what you want.

In addition to requiring a high standard of diligence from the vendor, it is also desirable to negotiate specific requirements for initial response to a support request and regular follow-ups. For example, you might require a vendor to respond to an initial notification of a critical bug or outage within two or four hours and provide status updates every four or six hours until the problem is resolved or its severity level can be downgraded. You might also require the vendor to propose a workaround and remediation plan (i.e., a plan for restoring functionality, including projected timeframes) within a certain time after initial notification. The exact time requirements will vary as a function of the operational impact a serious bug or outage is likely to have.

Escalation Procedures

You should consider adding a procedure to the support contract by which, if a certain amount of time passes without a critical problem being fixed, the problem will be escalated up through successive levels of technical support and product engineering all the way to senior management, with a Vice President or Senior Vice President responsible for product engineering or customer service eventually taking charge of the situation. There is no motivator like the threat of the big boss getting involved if the worker bees can’t keep the customer happy.

Remedies

What happens if a critical bug or outage remains unresolved after an unacceptably long period of time? Your business is bleeding, and all too often the contract may not require the vendor to provide any remedy other than continuing to plug away at the problem. This is particularly likely to be true where the warranty period for the application or equipment has expired. Therefore, if possible, try to include a liquidated damages clause or a partial refund of the product and support costs if the product under support cannot be fixed within the time period that your business needs. The vendor’s counsel will often resist this approach because it introduces a contingent liability or a contingency that may prevent the vendor from recognizing revenue. Ultimately, it is a question of risk allocation — who should bear the loss if the product fails outside of the warranty period, but during the period for which the customer has purchased support.

Some Support Traps

When purchasing an important IT system, make sure that the support contract guarantees the availability of support for at least several years after purchase (many support contracts contain tautological language stating that support can be purchased under the contract as long as the vendor has not discontinued support for the applicable line of products, or something like this). Also, where a cap on annual support fee increases has been negotiated, make sure that the contract does not give the vendor the ability to terminate without cause at the end of each support year. (Otherwise, the vendor could use this termination right as leverage to negotiate away the cap on fee increases. Sneaky, but it happens.)

It’s Always Five O’Clock Somewhere

Support contracts often are not as carefully reviewed and negotiated as the IT licenses or product purchase agreements they accompany. However, a strong support contract is a vital component of operational risk mitigation, and if you’re paying for it, you should have some comfort that your vendor will not be at a happy hour at the most vulnerable moment for your business.

CAVEAT: When I’m representing vendors, expect me to push back on a lot of this stuff.

The American Law Institute (ALI) is not a legislative or judiciary body, and its holdings, therefore, do not immediately carry the force of law. “Immediately” is the operative term, however, since the ALI’s publications and draft laws (particularly its magisterial Restatements of major bodies of American law) command great attention and respect among judges, law professors, leading practitioners and other vanguards of legal evolution and are widely regarded as authorities in their respective areas. Hence Microsoft and The Linux Foundation’s grave concern over the ALI’s “Principles of the Law of Software Contracts,” expressed in an open letter to the ALI dated May 14, 2009. (The letter can be downloaded here.)

The primary bone of contention is a provision in the Principles that creates a warranty by “transferors” of commercial software to anyone in the normal chain of distribution that there are no material hidden defects in the software of which the transferor was aware at the time of transfer. This warranty is implied and non-disclaimable, meaning that the licensee’s rights exist even if no warranty appears in the license agreement, and there is no way for the software provider to shirk liability for the warranty, such as by including standard boilerplate in its contract stating that the software is provided “as is, with all defects.” The warranty does not apply to software provided “free-of-charge,” only to software which is transferred for payment, but, as Microsoft and The Linux Foundation point out in their letter, this exclusion is a little ambiguous, since some vendors’ revenue models involve charging for services or support of software rather than for the initial software download or purchase. In their letter they also requested a delay in the adoption of the Principles so that software developers and distributors could have more say, but the ALI turned them down, approving the Principles at its May 19-20 annual meeting.

Having represented both software vendors and software licensees on countless occasions, I agree with Microsoft and The Linux Foundation that a non-disclaimable implied warranty of no hidden defects represents a radical departure from the law of software licensing as it exists today. Courts have generally held that software licenses are governed by Article 2 of the Uniform Commercial Code (UCC), which also provides for implied warranties to protect buyers of goods, but enables vendors to disclaim these warranties by including certain prominent language in their contracts. In other words, Article 2 of the UCC provides default terms which parties to a contract are free to bargain around. It is not clear why software should be treated any differently from, say, the computer on which it runs. Furthermore, high-dollar-value software acquisitions are usually negotiated transactions between sophisticated business entities, who often submit — or should submit — the agreements for review by licensing counsel (that’s where I come in).

Now that the Principles of the Law of Software Contracts have been adopted, software vendors and users and their respective counsels will have to wait to see whether courts and legislatures will follow the ALI’s lead in granting new rights to licensees. Please check this blog for the latest updates.