Businesses use a master services agreement to set recurring commercial and legal rules, then add statements of work for particular services, deliverables, fees, dates, and acceptance. That structure reduces repeated negotiation only when each document has a clear job. A vague MSA plus a vague SOW multiplies uncertainty. The parties still need to decide scope, dependencies, change control, charges, acceptance, intellectual property, data, confidentiality, service levels, warranties, liability, suspension, termination, and exit. Some relationships need schedules for security, privacy, support, or subprocessors. Commercial teams should map the contract architecture before asking independent counsel to draft or review it. The current contract, tax, data, IP, sector, and dispute position should be checked for the parties, services, and transaction before signature.
Give each document one clear job
Put stable terms in the MSA: contract governance, invoicing rules, confidentiality, ownership framework, data responsibilities, baseline warranties, liability structure, dispute process, and general termination. Put project facts in the SOW: named services, deliverables, milestones, timetable, customer inputs, team, location, fees, taxes, expenses, acceptance, and project-specific service levels. Some terms will need a schedule or order form. Create a simple hierarchy that says which document prevails on a conflict and whether an SOW may override the MSA only by naming the clause. Without that control, a sales order can accidentally rewrite risk terms. Use consistent defined terms and legal entity names across the set. If different affiliates place orders, decide who is liable and whether each signs or adheres. The architecture should reflect how sales and delivery teams actually create and approve work.
- Stable MSA terms
- Project-specific SOW facts
- Schedules for specialist topics
- Clear precedence and override rule
- Entity and affiliate ordering process
Make scope measurable at handover
Describe what the supplier will do, what it will deliver, what the customer must provide, and what sits outside the price. Name formats, environments, volumes, locations, assumptions, dependencies, and decision makers where they affect effort. Milestones should point to observable completion, not broad satisfaction. Acceptance needs criteria, a review period, a rejection process tied to the criteria, cure, and a rule for use or silence that both sides understand. For ongoing services, define requests, priorities, response or resolution measures, maintenance windows, reporting, and credits only where they make operational sense. The delivery owner should read the SOW before signature and confirm that the team, timetable, and budget are real. A statement written only by sales or procurement usually misses the handoffs that create later change requests. Attach the proposal only if its status and precedence are clear.
- Services, deliverables, and exclusions
- Customer inputs and dependencies
- Observable milestones and acceptance
- Operational service measures
- Delivery-owner sign-off
Price change before it happens
Every service relationship changes. The contract should say who may request a change, what information the request contains, how impact on fees and dates is assessed, who approves, and whether work pauses while the parties decide. Distinguish a defect or missed obligation from a customer change. Set rate cards, expense rules, taxes, invoice detail, billing milestones, disputed-amount treatment, and payment timing in a way finance can operate. If fees depend on usage, define the meter, source data, audit, and dispute route. Automatic renewal and price adjustment need notice and a decision owner. The MSA should stop an informal email committing the company to material extra work, while allowing small operational changes through named representatives. Review tax and foreign-exchange treatment where services or payments cross borders. Keep signed change orders with the SOW rather than in personal inboxes.
- Change request and impact record
- Named approval authority
- Fees, taxes, and invoice evidence
- Usage or rate-card mechanics
- Renewal and price-review calendar
Design the end of one project and the relationship
An SOW can end while the MSA remains available for later work. The MSA can end while active SOWs continue, or it can bring them down too. Choose deliberately. Address termination for breach, insolvency, prolonged force events, convenience where agreed, non-payment, and security concerns. For each, state notice, cure, charges, committed costs, work in progress, refund position, data return, transition help, licence effects, and survival. A customer that depends on the service may need an orderly export and handover. A supplier may need payment security before providing extended transition. Intellectual-property and data schedules should say what happens to access and retained copies. Test one failed project and one friendly non-renewal. Independent counsel should review current law, remedies, and enforceability. The cleanest exit language is the version operations can follow on a tense day.
- SOW and MSA termination interaction
- Notice, cure, and payment consequences
- Work, data, and access handover
- Transition support and charges
- Surviving rights and duties
Primary sources and further reading
Rules and procedures change. Check the current official source and obtain advice for the facts of your matter.