Lost clauses: What to look for in software agreements
Software publishers are negotiating contracts every day, but software buyers only do this occasionally. Phil Downe of IT Negotiations.com shares his experiences of negotiating software licensing and contracts, and how software publishers extract revenue from unwary customers.
I loathe the banality of “the devil is in the detail”, but you can’t discount its wisdom when it comes to IT agreements. Let me tell you a true story about what happened during a software deal as a result of a divestiture. The original agreement provided for a divestiture re-assignment to another party with the vendor’s written permission, which permission would not be unreasonably withheld. I’m facing the vendor’s vice-president of sales and with a straight face he states; I’m allowing the assignment, I’m giving written permission but I never said there wouldn’t be a transfer fee and proceeded to demand a $900,000 fee.
Ever since that blatant cash-grab I’ve asked vendors to include the words, “at no additional cost” in a number of areas where it may appear redundant, but I’d rather be overly cautious than face that situation again. That got me thinking about several areas within technology agreements, (terms, SOWs, SLAs, et cetera) where ambiguity could create issues that can easily be avoided. While discussing similar experiences with associates in the software procurement industry, the group came to refer to these wishful additional terms as the “lost clauses.”
The Ethical Wall
Software procurement can be quite complex these days. There always seems to be a core product representing the “easy sell” then the add-on enhanced licenses, modules, premier support and so on, which tend to run up costs significantly, especially with professional services, which are required to configure, customize, develop interfaces for, and test the code prior to production. Most procurement professionals will try and steer away from an open-ended time and materials professional services agreement in favor of a fixed-price arrangement. This obviously introduces a degree of financial risk for the vendor and a safety buffer gets built into the price to cover minor overruns and delays. Anything that might cut into the vendor’s profit margins will incur a change request and each of those will increase the fixed-fee implementation costs.
One way for the purchaser to reduce risk is to create a “wall,” an idea borrowed from the financial industry to ensure ethical trading by separating market makers from stock traders. It could also be useful as an in-scope/out-of-scope listing to increase clarity within a technology deal. One schedule, Schedule A of a proposed software licensing and implementation agreement, could list everything that is in-scope and at no additional charge, (interfaces, reports, training materials, et cetera). A second, Schedule B would list everything that is out-of-scope and must be vetted by the vendor for accuracy. The caveat is if it’s not listed on Schedule B, then it’s automatically assumed to be included on Schedule A, at no additional cost.
Scalable support
Vendors hate giving customers this future flexibility. Support revenue gross margins are reportedly in the 85-to-90-percent range. Some vendors go to great lengths to lock you in to the highest cost support agreements and make it incredibly difficult to cancel or suspend support for portions of the software that are no longer in use. A couple of well known vendor tactics are: if you attempt to cancel support for any software product on a single order (presumably purchased at a discount) then the support charges for every other product on the discounted order goes up to the latest full list price; and if you purchase premium support on one licensed product then you must have the same level of support on all licensed products.
I would like to think a client might feel more comfortable or require premium support initially, but should have the right to downgrade it to a basic support package in the future. That might be a difficult concession to get from a vendor when you’re already captive, or well into the deal but if you ask for that flexibility in a competitive RFP the vendor will hardly risk losing the business with a refusal.
Parking Licenses
In the first example above the cancelled support might also compel the client to give up the rights to the licensed product, but what if we find ourselves in a bit of a financial contraction and just want to suspend the use of the licenses for a short period? The concept of “parking” has been around for a while for fully paid, perpetual licenses. Parking gives you the right to shelve the unused portion of high-volume licenses or unused modules so you can reduce annual support charges on the unused, pro rated portion. Negotiated terms can govern the process to re-instate the licenses, if needed at a later date. Any reactivation fee should be considerably less than the basic annual support charge as the vendor expended no effort in bug fixes or helpdesk support while the license was parked.
Back to on-prem
In the case of cloud-based monthly subscriptions retrofitting on-prem might apply if the alternative exists. What choice will you have in the future if the new version of subscription product or interface is undesirable, or your new monthly subscription charges are going up significantly? If you’re dealing with a sole-source vendor and in many cases you will be, then your vendor will likely not discount any alternative, on-premises solution if they want to keep you buying subscriptions. Consider keeping your options open. If you’re going from on-prem to cloud don’t forfeit your rights to the on-prem version, park the licenses instead.
Future terms
Prohibit retroactive changes to T & C’s. When a software vendor updates its T & C’s (usually on a website you will never visit) the changes are typically to lower their risk and increase revenue and are always for the benefit of the vendor, not the customer. If you’re in negotiations and both parties agree to the T & C’s it would be best to ensure that the vendor cannot unilaterally change those T’s & C’s without your consent. One example comes to mind where a vendor initially required a user license for every employee who used the product. Eventually they changed that wording to read every employee who could use the product. Several years into the deal the client needed another 100 Time & Labor licenses and were shocked to find that they actually needed another 900 licenses to comply with new vendor terms.
Software audits
I’m certain by now you have thought of many other lost clauses that could have been added to this article, but space is limited so please let me conclude this by touching on one last issue that seems more relevant than ever.
Vendors are auditing customers relentlessly. Whether the vendor calls it a SAM engagement or a compliance audit you should assume the only purpose is increased revenue generation. I’d pay special attention to the initial agreement terms and the vendor’s rights to verify the products in use, especially when it comes to providing access to your systems. If they can see the target product, then they can probably see every other vendor’s product as well and that can’t be good.
A non-disclosure agreement (NDA) is a must. It should limit the vendor’s authority; they can coach and provide input to the scripts to be run but not have direct system access. The NDA should limit the data collection to the specific product in question and it should also have a definitive completion date. These audits will drag on forever, especially if the customer is compliant and the vendor isn’t finding any low-hanging fruit.