Are you undertaking ongoing software projects for clients?
If yes, then you will definitely have come across the Master Service Agreement or the MSA – your go-to document for defining your relationship with the client. It acts as an umbrella agreement, streamlining terms which you intend to apply to all projects with the client. Those terms which are specific to the project are covered under a ‘Statement of Work’ or a ‘Scope of Work’ document which is usually attached to the MSA. As goes with any agreement, clarity of terms is crucial with an MSA as well. A well-crafted MSA not only protects your business but also prevents misunderstandings and ensures you’re compensated fairly for your work. On the other hand, unclear or vague MSA terms can lead to disputes, payment delays, and even costly legal issues.
Here’s five things you gotta be careful about:
- Balance between the agreement and the Statement of Work (SoW)
It can sometimes become tricky as to what should be included within the MSA and what should be moved to a Statement of Work. For example, do you include payment terms in the agreement or the SoW? You might have a standard invoicing policy which you want to follow with all clients. You may also have a standard policy for interest on delay in payments. But then, milestones for each client will be different. So should you include it in the MSA or the SoW? Same for acceptance mechanisms. Should you fit this in the MSA? Or will this vary according to the project? The answer is that there is no ‘one size fits all’ arrangement here. You might want to give different grace periods to different clients. You might also want to apply different interest rates for delay in payments for different clients – obviously terms will not be the same for clients giving significant business and clients giving scanty business. And even for the same client, you might want to vary terms for large and small projects. So at each stage, you will have to determine what to put in the agreement and what to include in the SoW.
- Ensuring clear and milestone-based payment terms and acceptance mechanisms
Payments in the MSA are usually tied to the completion of specific project milestones. For instance, you might agree that a certain percentage of the total payment is due after the initial design phase, another portion after the software development phase, and the final payment upon successful deployment. But the thing is milestones are linked to acceptance as well. What if you have created something, but it’s not acceptable to the client? So you need to ensure these: Clear Payment Terms: Specify how much the client will pay and when, defining the amount due for each milestone or deliverable. Clear Acceptance Mechanisms: Specify within how much time the client needs to respond to the deliverable and also that it will be deemed accepted if they don’t respond in that time. Late Fees: Include a clause that outlines penalties if the client fails to make timely payments.
- Ownership of Intellectual Property (IP)
Intellectual property ownership is often one of the trickiest aspects of any MSA. Standard software created by the developer is owned by the developer. But the problems arise when creating custom software, since even that will have standard elements which the developer uses for other clients. So while the client provided materials will be client IP and custom elements created for the client will also be client IP, there is always something called “residual IP” – standard elements that the developer has deployed to create the custom IP, which will be owned by the developer. However, a lot depends on the product / service, its deployment and the agreement between the parties. You have to be very clear about what you want to retain the ownership of. And even if you are retaining the ownership, do you want to allow the use to the client? For how long? This would have to be factored into the MSA.
- Support and Maintenance
Your MSA (of course with your SOW) should clearly define what support you’ll provide once the project is live. Will you handle bug fixes, minor updates, or performance enhancements? Are these tasks covered under the original agreement, or will they incur additional fees? The bottom line is that the client should neither have the liberty to stretch the support to the size of an independent project nor should be charged excessively for every single item in the support.
- Disclaimers, Indemnification and Limitation of Liability clauses
These are dangerous clauses in any contract. Especially if you are getting an MSA from a client, you need to check these thoroughly. Does it expose you to unlimited liability in any circumstances? In what cases? In which circumstances will you disclaim any liability? These clauses must be read thoroughly and the implications must be clearly understood, since they can make or break a deal. For instance, are you providing the software on an “As is” basis? Is the custom software dependent upon any client materials on specific information? In these cases, you can disclaim or limit your liability.
Looking to implement an MSA and have questions about how to structure it effectively? Book a call with us using this link below for FREE guidance on this.
