Tel 800.661.2530 |
Contract or Policy? Which One Does a Software Company Need and When!
While this is a complex issue (like many legal issues), from the perspective of a software and SAAS attorney, I think there are some practical tips to remember when thinking about when to use policies and when to use contracts.
FIRST, THE DEFINITIONS. Policies are generally defined as a set of basic principles and guidelines, formulated and enforced by the governing body of an organization, to direct and limit its actions in pursuit of long term goals (i.e. soft commitments). Contracts are generally defined as a voluntary, deliberate, and legally enforceable (binding) agreement between two or more parties (i.e. hard commitments).
SECOND, 3 TIPS TO REMEMBER!
1) When to Use a Policy. Policies communicate how you plan to operate your business (whether internally or externally), and you can generally change them at any time. However, if you change them you need to think about if you need to notify/inform the groups impacted by the policy change (not necessary their approval for the change, but simply notifying them of the change). Also, remember that courts generally look at written policies as a form of a commitment, and don't like it when a company violates its policies.
Examples: Internal (HR, IT, and Sales Compensation Policies) and External (Support and Privacy Policies). I recommend that you notify all the impacted customers, employees, etc. if possible of material changes to those policies. It is pretty hard to notify everyone that has read your Privacy Policy, but you could notify your customers who bought something online from you if you make a significant change to your Privacy Policy. For example, Facebook and eBay often notify their members when they make significant changes to their Privacy Policy (they are consumer facing companies though, and they both have online ways of notifying you (i.e. not sending you a direct email)).
General Drafting Tips. a) Changes should be prospective, and not retroactive. b) Draft for reality, and not to look good.
2) When to Use a Contract. Contracts are a stronger form of commitment, and one party cannot generally change the contract without the consent of the other party. Use contracts for harder commitments, for protection from claims (if things were to go wrong) and to protect your assets.
Examples: SAAS agreement, EULA, Reseller Agreement, signed Quota Letter with a sales rep.
General Drafting Tips. a) Contracts should be clear and concise, and written in plain English. b) Make sure you fully understand them, as your company is making a legal commitment that cannot be changed (except with the other party's permission). c) Shorter is better than longer.
3) When Policies and Contracts are Interlinked. While this can get very messy, the rules above stay the same unless you say otherwise in the contract. In other words, you can still change the policy without the other side's permission, but you will need their permission to change the contract.
Examples:
a) You may want to link your Support Policies to your EULA template--which I recommend by the way. The way this should work is the EULA cannot be changed without the permission of the other party, but the Support Policies could. I think this has become a best practice for SAAS, Software and IT companies, and is a great way of using hard commitments (contracts) and soft commitments (policies).
b) You may want to link your Sales Compensation Policy to your written Quota Letter–which is another structure I generally recommend. The way this should work is the Quota Letter cannot be changed without the permission of the sales rep (i.e. the commission percentage) but the Sales Compensation Policies could. I also think this has become a best practice, but remember that it is generally a good idea to notify your sales reps of any significant changes to your Sales Compensation Policy in advance, and try not to make changes retroactively (there are legal and morale issues at play here). This is an area you should definitely talk to an attorney about, before making any changes.
General Drafting Tips: a) Describe in your contract that the policy may change from time-to-time. b) You may want to state–in your contract– that your policies will not materially degrade (example, your Support Policy may be changed but it will not materially degrade).
This may have been a little more detail than you thought you would be getting into, but hopefully you have gotten a taste of the issues from a the perspective of a software, SAAS or IT company.Think through this list when deciding if you need a contract or a policy.
Legal Disclaimer. This is for information and educational purposes only, and does not constitute legal advice. Talk to an attorney regarding these issues.
Related posts:
- 3 Privacy Tips for a Software or SAAS Company (Courtesy of the US Supreme Court in 2010) Well, while the US Supreme Court in its decision in the...
- If Google Can Do It, Why Can’t You! Why aren’t your policies written so they can be easily consumed...
- Can You Change Your Software Contracts Unilaterally? As a software copyright attorney, I was wondering if you...
2 Responses to “Contract or Policy? Which One Does a Software Company Need and When!”
Leave a Reply
CONNECT WITH ME
Jeremy, Useful advice.
I especially like “c. Shorter is better than longer.” Longer,negotiable contracts tend to slow down the sales process as red-lined revisions bounce back & forth between vendor and customer. These delays constrict cash flow, which can be a particular challenge for SaaS companies.
Peter Cohen
SaaS Marketing Strategy Advisors
http://www.saasmarketingstrategy.com
Peter, I agree.
There is no reason that these contracts need to be long or overly complicated (which they are too often), and the larger SAAS companies have shorter and simpler agreements (which is kind of counterintuitive). Most SAAS companies don’t realize this is possible. Thanks for the post. Jeremy