Most services firms produce all three documents and are precise about only one of them. The proposal is written to win, the MSA is written by lawyers, and the SOW inherits whatever nobody else claimed.
The result is predictable: terms appear twice with different wording, and the version that governs is whichever one the client's counsel reads first.
The proposal sells the approach
A proposal exists to make a buyer confident. It carries the understanding of the problem, the approach, the team, relevant experience, and an indicative commercial shape.
What it should not carry is binding operational detail. Acceptance windows, liability positions, and precise deliverable definitions written in sales language have a habit of being attached to the contract later and read as commitments.
- Belongs here: problem framing, approach, team, credentials, indicative price or range.
- Does not belong here: acceptance criteria, liability, IP terms, payment mechanics.
- Mark it clearly as indicative and subject to a signed SOW.
The MSA sets the rules of the relationship
A Master Services Agreement governs everything that is true regardless of which project you are running: liability, indemnities, insurance, confidentiality, data protection, IP ownership, subcontracting, dispute resolution, and termination.
Its value is that it is negotiated once. Every clause you push down into individual SOWs is a clause you renegotiate on every engagement, usually under time pressure with the delivery date already promised.
- Belongs here: liability caps, indemnities, insurance, confidentiality, data protection.
- Belongs here: IP ownership principles, subcontracting, non-solicitation, governing law.
- Belongs here: the statement that SOWs are governed by and subordinate to this agreement.
The SOW defines this specific engagement
The SOW is the only document that describes what is actually being done, by when, for how much, and how both parties will know it is finished.
Everything project-specific belongs here and nowhere else: deliverables, assumptions, exclusions, dependencies, fees, milestones, change control mechanics, and acceptance.
- Belongs here: deliverables, quantities, phases, and schedule.
- Belongs here: assumptions, exclusions, and named client dependencies.
- Belongs here: fees, invoicing milestones, change control, acceptance criteria.
The four overlaps that cause arguments
Contradictions between documents are more damaging than gaps, because both sides can point at something in writing.
- Price: an indicative figure in the proposal and a different fee in the SOW, with the proposal attached to the contract.
- IP: general ownership language in the MSA and different deliverable-specific language in the SOW.
- Acceptance: an informal 'sign-off' promise in the proposal alongside a formal review window in the SOW.
- Change control: a light process in the SOW and a formal amendment requirement in the MSA.
Write an order of precedence, and mean it
Every set of stacked documents needs one clause stating which wins. The usual order is MSA, then SOW, then any attached schedules, with the proposal excluded entirely unless specifically incorporated.
The clause only works if the documents are actually consistent. Precedence resolves a conflict; it does not make the conversation about the conflict pleasant.
When you do not have an MSA
Smaller engagements often skip the master agreement, which means the SOW has to carry the relationship terms as well as the project terms. That is workable, but be deliberate about it rather than discovering the omission during an incident.
Keep the project sections and the legal sections visibly separated in the document, so that when the client returns for a second engagement you can lift the legal half into a standing agreement and stop repeating it.
Put this into practice
SOW Studio turns discovery inputs into structured scope, a reviewable estimate, and a client-ready Statement of Work — with your team approving every step.
No credit card required. Full Professional capabilities for 14 days.