In part 1 of this series about negotiating procurement deals, we talked about the parties to the agreement and how that easily overlooked issue can cause problems such as unlicensed use of the software being acquired. Other basic issues can cause deals to go sideways. This post addresses the first issues that an organization’s business team is likely to discuss with its vendors, which may also be under-defined in the agreement.
You might not even think about them, but they are the heart of the contract that you will ultimately sign: what are you buying, when are you going to get it, when are you going to pay for it and how much are you paying? If your agreement is clear about those issues, your company is going to avoid some of the most significant problems that can arise in procurement deals.
What are you buying?
The buyer who has spent a lot of time with the vendor’s salesperson may be taking this element for granted. After all, the salesperson may have given several product demonstrations, sent numerous emails and repeatedly called the buyer to talk about the deal. So when the buyer is ready to pull the trigger, seeing the common name of the product (Generic SaaS or Software) or service (Branded Threat Assessment Services) that you’ve discussed for months may be all that is needed for you to understand what you expect the vendor to deliver. Will the judge with no experience in your industry share that understanding if something goes wrong with the deal? Perhaps not.
The judge is going to look to the terms of your agreement to evaluate whether the vendor delivered what it was required to deliver. Since many parts of vendors form contracts work to eliminate everything the salesperson said from that evaluation, they need to be reviewed holistically. Consider the near-ubiquitous “AS-IS, WITH ALL FAULTS” disclaimer that many software agreements contain, or disclaimers about not meeting customer requirements, or integration clauses specifying that the contract is the entire agreement, superseding any prior discussions.
Does the common name of the product seem sufficient in light of these concerns? Probably not. Health care organizations can be left paying for software products that do not meet their needs, sometimes for significant amounts. For example, one medical group was left footing an $800,000 bill for a failed software integration when the agreement contained no commitment about the product working seamlessly with its patient management system, as the salesperson had allegedly promised.[1]
When are you going to get it?
Vendors may have very different ideas about delivery timing than their salespeople may lead their customers to believe. Does the agreement say anything about delivery? Is there an implementation period before you’ll be able to put the product into use? Whether there’s a simple disclosure of login information to start using the product or a complex implementation that the vendor needs to lead, it’s perfectly fair to put a no-later-than date in the agreement about when the product must be live.
For complex implementations, the vendor will often demur on giving such a commitment, citing all the things that it needs from the customer in order to complete the project. But that’s a discussion the parties need to be having before signing anyway; if vendors require customers to provide any resources to get the product working, they should be prepared to describe that assistance in the agreement. Once the customer has agreed to provide that particular assistance, is there a good reason to omit that deadline for completion in the agreement?
When are you going to pay for it (and how much)?
The total cost of the product or service often commands the bulk of the customer’s attention. However, the savings that you think you’re getting may evaporate if there are delivery problems. For example, if the product is expected to cut costs once implemented, but the go-live date arrives months later than expected, how much did the delay cost? Maybe there’s a prior agreement that you had to renew because the new product wasn’t delivered on time, or maybe you only had to keep paying for the existing agreement until the new product went live.
Which vendor do you think is going to be more motivated to hit your timelines: the one you’ve paid 100 percent upon signing your new agreement, or the one who has some or all of its fees withheld until completion? And which party is bearing the risk of failure? If final payment is due on completion or, say, 90 days from signing, “whichever comes first,” there’s a different incentive structure than if payment is due on the later of those two dates.
Software often requires separate maintenance and support fees in connection with a license agreement, and those fees may be just as significant as the up-front costs. Does the commencement date for those fees align with the signing of the agreement or the successful delivery of the software? Again, consider how the payment structure allocates the risk of a failed or delayed implementation.
Practical Takeaways
Your approach to the issues discussed in this post may vary across deals. Communicating your intent about them to your attorney will not only make your legal reviews more efficient, but also help to avoid disputes with your vendors.
For more information on this topic, please contact Jon Boguth at (248) 457-7845 or jboguth@wp.hallrender.com or your regular Hall Render attorney.
For more information on Hall Render’s Health IT services, click here.
