When it comes to M&A activity among software suppliers that already reside in your vendor master, there's often very little good that can accrue for you, the customer, despite the acquiring company's marketing spin. Believe me on this one. I was paid the big bucks -- well, relatively speaking, though not like the bankers doing the deals -- for a number of years to put the marketing spit shine on deals (and I still do it on occasion today, though I wash my hands as quickly as possible afterwards). I've also been the architect of a good many deals, some of which have worked for shareholders -- especially more recently in my career -- and some that, well, let's not go there. It's always good to learn on someone else's dime early in your career, I say.
In the majority of cases when one of your software providers is acquired, you can bet on one or more of the following at some point within 12 to 36 months of the deal closing:
- An attempted push through in maintenance and support costs
- A sun-setting of support for the version/application you're on (forcing an upgrade in the case of installed software or a changeover to a different platform in the case of an On Demand environment)
- Turnover in your account management and customer support area -- expect new faces and/or fewer faces unless the acquiring company is trying to sell you something new (which brings me to the next point)
- To be aggressively cross-sold to (i.e., to have other products marketed to you by the acquiring company)
- Aggressive marketing spin pushed in your direction about how much "you're valued as a customer"
Obviously, the way you chose to respond in these situations after the fact is entirely up to you. But basically, unless you've put in place a pre-emptive approach to managing acquisition risk in your supply base, the odds are against you. Call me an acquisition cynic, but like the futures and options market, I've come to believe the majority of software acquisitions really are a zero-sum game. In most cases, the spoils usually go to the victor -- i.e., the acquiring company -- at the expense of the end-customer, at least in most cases where deals work out according to the corp dev guy's plan (i.e., me in a former life). This situation puts the onus on the company licensing (or renting the software, in the case of SaaS deals) to plan for the worst upfront during the licensing phase.
When it comes to software licensing, I'm no pro. I can negotiate with the best of them, but I'm as much a poser as the folks at analyst or consulting firms who claim to be the experts (95% of whom are not). The real pros from a negotiation perspective are seasoned folk like Vinnie Mirchandani and Brian Sommer who have lost both hair and friends over the years from practicing their art. And from a T&C vantage point, it's folks like Jeffrey Gordon, who I sought out for some advice on the matter. And here's what he had to say on the subject of contracting and legal positioning when acquisition issues arise (from a customer perspective):
"In my view, once a customer finds out that one of their provider's is getting purchased, there's really not a whole lot they can do other than check the agreement for "stability". But here are a few tips:
1. First, talk with the business owner who has been managing the relationship. Get a feel for how things have been going ... ask probing questions to check for satisfaction, quality of product, quality of service, etc. The customer is potentially going to have an opportunity for some leverage with the acquirer -- and information is key.
2. Now, look at the assignment language. Does it allow for the idea that the vendor (or both parties) could transfer/assign the agreement to a "successor in interest" or as a result of "legal process"? If so, the assignment is going to happen without a hitch. If not, the customer might have a way to get out of the agreement as a result of the assignment -- it just depends on the customer's desires and happiness with the proposed vendor.
Some customers have been known to put a "poison pill" into the agreement -- which absolutely bars assignment or transfer because they SPECIFICALLY don't want an agreement with another player in the industry. I've seen this several times with financial services vendors (and others) ... where they say that they can transfer the agreement, but not to a competitor of the customer, for example. This prevents a situation where the customer becomes a customer of one of their own market competitors.
3. Next is to check whether the customer has a perpetual or term-based license. If it's perpetual, the assignment might not matter at all, especially if the customer is no longer on maintenance. You'd get to just keep using the product if you were the customer, and the acquirer wouldn't be able to do much to affect your use of the product either.
4. Which means that the next review point is with the maintenance language. Review the SLAs and make sure that when the acquirer contacts the existing customer, that the customer "reminds" the new buyer of the existing contractual obligations. It's an opportunity to reduce risk by setting expectations. It's also a chance to review the need for maintenance and whether the acquirer is going to provide the standard of service to which the customer has grown accustomed.
5. In review of maintenance/support language, I would also suggest looking for any guarantees of product releases (uncommon, but out there). An acquirer might be looking to sunset an existing product."
These are all great points from the author of The Software Licensing Handbook. Thanks, Jeff, for chiming in. Stay tuned for further commentary from Jeff in a follow-up post that will examine how acquiring companies can mitigate contracting and customer risk in M&A situations. And look for further commentary on the evolving M&A environment in the Spend Management sector as I dust off my old corp dev cap.