// Corporate Legal Consultancy
Before work starts: what to check in a service agreement
Define what is included, what each party must provide and how completed work will be accepted. Review the arrangements for changes before a commitment becomes a delivery problem.
Before you sign a service agreement, work order or statement of work, check that the people doing the work can find five things in it. What you get, with exclusions and assumptions. What each side must provide, and by when. How finished work is accepted, by whom and within what period. Who can approve a change, and how its cost and schedule effect is recorded. And what is handed over at the end, including access, documents and rights to use the work. This applies whether you deliver the work or buy it. It is a delivery check, not a substitute for legal advice on the terms.
Read the agreement as the delivery team would
Imagine the project starts tomorrow. Can the people doing the work identify the approved scope, the current schedule and the person authorised to accept the result? Do the proposal, the statement of work (or the work order or purchase order terms) and the agreement describe the same commitment?
A useful review follows the work from commencement to handover. It brings the delivery team into the discussion while the commercial terms can still be clarified.
Make the promised output recognisable
“Implement a management dashboard” leaves important choices unresolved. Which measures and data sources are included? How frequently should it refresh? Who will use it? Does the price cover historical data cleanup, training and support?
Specify the deliverables at a level that allows both parties to recognise what is being purchased. Record exclusions and assumptions alongside the scope, especially where they affect price or timing.
Identify the other party’s contribution
Delivery may depend on information, approvals, access or decisions supplied by the customer. Name those dependencies and the people responsible for providing them. Agree how a delay will be raised and how its effect on the plan will be assessed.
The same review should identify work involving another supplier. If a third party must enable an integration, clarify who coordinates that work and what happens if the third party cannot meet the proposed date.
How will you know the work is accepted?
Acceptance needs a practical procedure as well as a signature space. Establish the criteria, the reviewer, the review period and the treatment of defects or incomplete items. Clarify what happens when part of the work is accepted and another part needs correction.
For the dashboard example, the review could use an agreed sample dataset to check the named calculations and views. This makes the conversation more precise than asking whether the customer is “satisfied”. The legal effect of acceptance provisions still needs review in the context of the particular agreement.
Watch for silence counting as acceptance: for example, work deemed accepted if no defects are reported within a set number of days. That can be fair. But both sides need to know the period, and someone needs to be watching the calendar.
Keep changes out of informal side agreements
Teams will discover new requirements. Establish who can request a change, who can approve it and how its effect on cost and timing will be documented. A request from a day-to-day contact should not be assumed to carry commercial authority.
| Before committing | What the delivery team should be able to locate |
|---|---|
| Scope | The included deliverables, exclusions and assumptions. |
| Inputs | The information, access and decisions each party must provide. |
| Acceptance | The checks, authorised reviewer and treatment of unresolved items. |
| Changes | The approval route and record of agreed price or schedule effects. |
| Handover | The documents, access, training and other materials to be supplied. |
| Continuing work | The boundary between delivery, defect correction and ongoing support. |
Connect completion to handover
An installed application may still need administrator access, instructions or agreed licences before the customer can operate it. Identify the handover materials and confirm the relevant ownership and usage rights. Check how those provisions interact with payment, support and termination terms.
Are payments tied to milestones? Confirm whether each one falls due on delivery or on acceptance, and what happens when only part of a milestone is accepted.
Our spreadsheet-to-application example shows acceptance criteria agreed before development begins and checked against everyday tasks.
This is general commercial guidance. Legal terms should be reviewed for the particular agreement and applicable law.
Common questions
Statement of work or agreement: which document says what, and which wins?
The agreement sets the legal and commercial terms. The statement of work, or work order, describes what you get, the dependencies, the schedule and acceptance for one piece of work. Many agreements say which document wins if the two conflict. Check that yours does.
Who is allowed to approve a scope change?
Whoever the agreement names. Without a named role and a written note of the cost and schedule effect, a casual request from a day-to-day contact can become unpaid work, or a dispute.
Does this replace a legal review?
No. This is a delivery check: it makes sure the people doing the work can find what was promised. If you need the terms reviewed, our Corporate Legal Consultancy can help. Adviserve is not a law firm. Legal advice is provided by independent enrolled advocates. Adviserve coordinates the work, the documents and the timeline.
Reviewing an agreement before delivery begins?
Send the draft agreement with the proposal behind it. We can read them side by side and list each deliverable, dependency or acceptance step your delivery team cannot yet locate.
Related capability:Corporate Legal Consultancy
Related briefings
Buying software: the questions about data, exit and ongoing cost
Assess a software purchase beyond the demonstration. Establish where information will be held, how it can be exported and what the business will pay to operate, support and eventually replace the system.
Read the briefing Technology & AutomationWho owns support after an application goes live?
Establish who receives support requests, investigates incidents, approves changes and maintains the application. Agree those responsibilities before launch, while the delivery team is still involved.
Read the briefing