Ah, the dog days of summer. The preferred watering hole near the offices of Baer Business Law is Tir Na Nog at 16th and Arch Streets in Center City, across the street from LOVE Park and just around the corner from Wolf Block’s old offices. In the pit of the Great Recession, you just can’t beat their happy hour offering of $3 Red Stripes, although you will have to hover and circumvent authorized channels to grab the sparse outdoor seating.
Your IT vendors laughing at the contract you signed
Hard-working business professionals and entrepreneurs deserve their occasional happy hour time. What you do NOT want to happen, however, is the vendor of an IT system critical to your business metamorphosing into Jimmy Buffett and vanishing just because, in the words of the great crooner’s duet with Alan Jackson, “It’s Five O’Clock Somewhere.” The key to preventing this is negotiating strong coverage periods, service level agreements (SLA’s), escalation procedures and other safeguards in your maintenance and support agreement. If a critical web or data processing application or piece of network equipment malfunctions, chances are that either you or members of your IT team are going to be there all weekend, so it’s important to make sure the vendor is properly motivated at the outset.
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.