When I blogged about sales tools earlier this year (Your Sales Tools), I should have included a contract as one of the items that you will need to sell. Forgive my oversight. When thinking about how you contract with your customers, I recommend keeping the following three items in mind.
- The smaller the deal size, the less you should negotiate. For deals less than $5 K MRR, consider using EULA (End User License Agreement) language or a quote with Ts & Cs (Terms and Conditions) attached
- If you do use a contract, write it in plain English. If you find yourself using works like “shall”, “heretofore” or “said party”, slap yourself several times
- Do not use lawyers. At least not for the bulk of your negotiations. You should negotiate the contract with a customer yourself: lawyers are paid to worry and, if you have them negotiate a deal, they will paper it heavily and complicate it unnecessaril
The following are components of a software contract that you are likely to focus on.
Price and Terms
It is best to describe these either in the quote or in an appendix to the contract itself. Make the figures and how they are calculated simple and clear – imagine someone reading the contract two years from now who has no idea how your business works. Would they understand it?
The contract should make clear that the IP is yours and will remain so regardless of what happens to the business relationship with your customer.
Make clear that customer data created or stored in your software is the customer’s and detail a way that they can retrieve it as needed but especially if the contract is terminated.
Remember that technology firms make lousy insurance companies. I am not sure why, but some customers often see the standard liability and indemnification language contract and assume that you should indemnify them for all manner of issues (e.g. damages for business interruption or hardship). You need to be firm about this: your wireless provider does not pay you for the inconvenience/ aggravation of poor service (They would be out of business if they did.), nor should you cover your customers for issues arising from service provided in good faith. Of course, this doesn’t remove liability for fraud or malfeasance.
Termination for Cause
Typically each side offer this to the other for a reasonable cause, or a failure to perform. Make sure that the contract stipulates both a reasonable notice period and a right to cure.
If you are a cloud offering, your customers rightly expect a high level of uptime. Be specific about what you uptime you will commit to and calculate it after allowing for regular maintenance downtimes.
Customer Service and Support
Detail exactly what kind of coverage (live, chat, email) support you will offer and when in an appendix.
Detail these in an appendix to the contract and be specific about timelines and deliverables.
If you offer training, detail this in an appendix to the contract.
Source Code Escrow
If your company is small and unproven, potential customers may insist that you set up and pay for a source code escrow that you keep current and that they have the right to access so you fail to maintain your software (e.g. because of bankruptcy). This is easy to do – there are numerous escrow services available – and, once setup you need only keep the source code in escrow current. You can refuse to do this if you have reached critical mass or are not worried about losing the deal.