By Joe Auer
A customer recently negotiated an agreement that called for an annual revenue commitment to the supplier. It’s quite common for a supplier to exchange pricing concessions for this type of guarantee from a customer. But what happens if the customer fails to do the guaranteed amount of business with the supplier? In their excitement over getting a great discount, customers often overlook this point. Before agreeing to an annual revenue commitment, you must answer these three questions: • Do we have the ability to meet the revenue commitment?
- What’s the likelihood that we will actually achieve the commitment?
- What if we fail to meet the revenue commitment?
Ignoring these issues can result in a costly problem such as – at the minimum – having to make up the revenue shortfall to your vendor. This alone could wipe out the great discount you got on the front end of the deal.
In verifying your company’s ability to meet its annual revenue commitment, survey the end user of the product you’re about to buy. The end user should share the responsibility for the commitment you’re about to make. Review usage history with the end user so you can determine with a high degree of certainty what the optimum order level should be.
Regardless of the best plans, estimates and negotiations, the world changes. The best protection against a changing world is the “significant business change” clause. If this clause is drafted correctly, it will protect you if your company’s revenue or profit falls. On the other hand, if business booms, you can secure discounts for purchasing more of the vendor’s products.
This clause should specifically allow you to reduce the level of your annual revenue commitment to a vendor without having to pay any adjustment fees. Here is the “downturn” portion of such a clause:
If the customer is unable to fulfill its obligations for the annual revenue commitment due to a downturn in business, customer and vendor shall negotiate, in good faith, appropriate and commercially reasonable changes to this contract. In any event, the customer shall not be liable for any fees, charges or penalties due to a change in the customer’s annual revenue or profits.
This clause effectively hedges the downside and eliminates a nasty contract “gotcha.”
Mail Bag
Ted Vahan, a vice president at systems integrator Covansys in Charlotte, N.C., sent me this note:
I found your article in Computerworld about protecting your trade secrets interesting [Business Advice, April 9]. As a consultant, it is a topic I have debated with clients and colleagues in the past.
While I understand the need for protecting intellectual property, many clients want it both ways – you have to have the experience coming in the door, but they want you to leave it behind when you’re done! Let’s face it – you always stand the best chance of winning an engagement if you can demonstrate that you have done the same thing before. In fact, that’s very often the deciding factor in awarding engagements.
All that being said, I think your article makes a lot of sense. However, you should point out that most consultants want to get repeat business with existing clients as well as add new clients, and the best way to approach such situations is to work it out with your consultant to set appropriate restrictions that both parties can live with.
Thank you, Ted, for the note. I feel strongly that we should strive for appropriate rights and obligations that both parties can live with.
You’re also right on when you say that clients want consultants to have related experience coming in the door but that clients should, of course, be very leery of a consultant they suspect might use another client’s intellectual property.
JOE AUER is president of International Computer Negotiations Inc. (www.dobetterdeals.com), a Winter Park, Fla., consultancy that educates users on high-tech procurement. ICN sponsors CAUCUS: The Association of High Tech Acquisition Professionals. Contact him at joea@dobetterdeals.com.
Copyright by Computerworld, Inc., 500 Old Connecticut Path, Framingham, MA 01701. Reprinted by permission of Computerworld.