Agreement, schedule and SOW do different jobs.
The labels vary. The operating distinction is between the enduring rules and the project-specific work.
A service agreement commonly holds the relationship terms that may apply across more than one piece of work. A schedule or statement of work commonly holds the deliverables, responsibilities, dates, acceptance process, price and project-specific assumptions.
Where a client supplies a master agreement that cannot realistically be changed, the schedule or SOW may be the document in which the supplier can still make scope, dependencies, evidence, acceptance and change control concrete. The documents must be read together. Whether a schedule or SOW changes a conflicting master term depends on the particular documents and any agreed order-of-precedence wording.
What Agreement Build puts into working order.
- 01
The work
Deliverables, exclusions, assumptions and the line between the agreed project and additional work.
- 02
The dependencies
Client information, access, decisions and other inputs that the delivery team needs, together with the consequences of delay.
- 03
The evidence
The outputs, records or completion events that show what was delivered and when.
- 04
The decision
Who reviews the work, the criteria or process for acceptance, the review window and the treatment of valid rejection or silence where appropriate.
- 05
The money and change
Payment triggers, invoicing mechanics, additional work and the route by which scope, fee and timing change together.
What the published service includes.
- structured intake and a scoping call;
- one service agreement or SOW package in a defined lane;
- deliverables, evidence, acceptance, payment and change terms; and
- an attorney-reviewed plain-English deal summary.
Complex matters are scoped separately. Written scope, fee and timing follow a conflict check. Do not treat published “from” figures as a quote for a specific deal.
Do not draft the schedule as an appendix to the legal work.
For project-based services, the schedule is often where the commercial promise becomes operational. It deserves the same attention as the clauses that look more traditionally legal.
The agreement still needs a handover.
A usable agreement must be understood by the team that will work with it. The deal summary identifies the commercial structure in plain language so the client can see what was agreed without treating the summary as a substitute for the signed contract.
If the real problem is that contracting depends on inboxes, unclear ownership and improvised approvals, the document may not be enough. That is the Contract Flow Design lane: intake, ownership, approvals, templates, legal-review points, records and handover designed as a recurring process.
How to start an Agreement Build.
- Send short, non-confidential context: what is being sold, what document exists, and when the matter needs to move.
- Operative.law completes a conflict check.
- The structured intake and scoping call define the agreement lane, source documents and intended output.
- Written scope, fee and timing are agreed before work begins.
This guide is general information, not legal advice. It does not create an attorney-client relationship or prescribe a structure for a particular transaction.
Not ready to start a build? Run the 10-minute Definition-of-Done Checklist first.