With nearly any high-ticket item you can purchase today, you get a warranty that guarantees certain performance expectations for a specified period of time. It's not so straightforward with software purchases, however. Complaints range from the use of overly complex legalese, to numerous disclaimers that seem to undo any promises that the warranty makes.
Indeed, software vendors seem to be in a class of their own when it comes to selling a product with little guarantee that it will perform in a way buyers expect. Here are a few things to keep in mind, before signing on the dotted line (click here for additional online resources).
Limited Coverage
Software vendors typically provide a limited warranty that promises the application will perform substantially in accordance with the documentation provided and that if it doesn't, a commercially reasonable effort will be made to repair it, either via bug fixes or at the next general patch distribution.
Vendors also might offer to reimburse what you paid for the product, but considering that the software purchase price is about 20% of the total cost of ownership, that's hardly a generous refund, says Al Case, founder of TechSpend LLC, an IT procurement advisory service in Tampa, FL.
In addition, software warranties often include bold uppercase letters disclaiming all warranties of merchantability -- which means the product is saleable -- and "fitness for a particular purpose," which means it will do what it says it will do, Case adds. He compares this to buying a cooking knife, where these warranties would guarantee the tool was good enough to be sold and designed to cut whatever it was advertised to cut.
"If you bought that knife, and it wouldn't cut anything, the seller would have an obligation to replace the knife," he says. Not to mention, the store that sold it to you might be able to turn around and sue the knife manufacturer if numerous customers had the same complaint or at least get reimbursed for expenditures like restocking fees.
More Disclaimers
With the number of disclaimers that vendors include in most software warranties, they often appear to be giving with one hand and taking with the other, says Gregg Kirchhoefer, senior partner at Kirkland & Ellis LLP, a law firm in Chicago. "They make a statement about what the warranty would be, and it's fairly limited in scope, and then everything else is disclaimed in order to take away from any promises made in the marketing materials or in what the salesman has said, either expressed or implied," he says.
For instance, most vendors limit their liability for direct damages, which are losses that are directly attributable to the software's failure to perform or a direct outgrowth of that failure, Kirchhoefer says. For instance, if a software failure results in your not getting labels printed in time to make a regular shipment, and you have to ship everything via Fedex, there are monetary damages attributable to that.
"They say two things: 'We're not responsible if this breaks, but if it does, we'll fix it when we get around to it,'" Case points out. "And, 'if you lose business, or it causes other damages, we're not responsible.'"
So if you get a system up and running and think everything is fine, only to discover three months later that a logic bug resulted in 50 clients never getting billed, most vendors are under no legal obligation to take responsibility under the terms of the warranty, experts note.
Vendors also tend to include an exclusion of consequential damages, those losses that don't flow directly from failure to perform but as a consequence of it. For instance, if a delivery is delayed by a day, that may cause you to lose a large customer and the profits attributable to that customer.
"Most vendor agreements take a very firm position on consequential damages," Kirchhoefer says, "because something like the failure of an ERP system, for instance, can have a very significant impact on their stock price."
Moving Toward a Fix
While most large-scale systems vendors will not negotiate terms of the warranty, you may be able to make up for warranty gaps through the software contract itself, Case says. He advises that buyers negotiate for specific performance levels that they expect the software to perform and include a section on those service levels in the agreement itself. For instance, you can specify the size of the server you want the application to run on and the number of transactions you want to accomplish in a given period of time.
"If you know your business processes 10,000 transactions per day, and you want to process 25,000 transactions a day, you should get that in the software agreement so that the vendor commits to that performance level and is on the hook if they don't," he says. "If the system fails to perform to those service levels, it doesn't matter whether it's due to a bug in the software or corruption or a logic error. You're not arguing that the software failed or didn't meet a 'fitness for a purpose' warranty -- you're just arguing that this service level wasn't met."
The goal, Kirchhoefer says, is to tie the coverage to a realistic, practical, and somewhat more objective standard of performance than a loose and broad-based statement of failure to perform. "You need to have specifications that are meaningful for the basis of how the software is supposed to perform," he suggests.
One caveat with this strategy, he warns, is that you may not be able to negotiate a penalty large enough to cover the cost of a catastrophic system failure. You also need to be prepared for quid pro quos that the vendor might send your way. For instance, what if the system outperforms the specified performance levels? "The vendor might come back and say, 'You owe me,'" he says.
Reverse Psychology
If buyers do define performance levels, they also have to negotiate a remedy for failure, Kirchhoefer says. For instance, it's advisable to define different levels of severity, response times, and escalation mechanisms that, for instance, increase the resources devoted by the vendor the longer the failure continues and possibly the amount of damages, as well.
Buyers also need to ensure that the recovery measures they require act as a disincentive for the vendor to sell software that fails to perform. "You want to have at least enough in place that it's more expensive to not fix something than to fix something so they keep harm from happening in the first place," he says.
Customization Woes
Buyers should also check into whether there are exclusions in the warranty that remove vendor responsibility if software modifications are made by a third party or the customer itself. "Vendors have a very legitimate concern in that regard -- if someone else is mucking around with the internals of the code and breaks something, why should they be on the hook?" Kirchhoefer says.
But if the customization occurs not in the kernel but through preplanned mechanisms such as APIs and interfaces, the agreement shouldn't exclude that, he says.
Some vendors will put a mechanism into the agreement that says they'll fix a problem even if it's uncertain as to who caused the problem, Kirchhoefer points out. If it turns out later that the problem isn't attributable to the vendor's code but to something the customer did, the contract stipulates the customer will pay for that part of the remedy.