Skip to main content
AdviserveBook a discussion

// 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.

Back to business briefingsOctober 16, 2026Updated November 1, 2026Adviserve5 min read

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 committingWhat the delivery team should be able to locate
ScopeThe included deliverables, exclusions and assumptions.
InputsThe information, access and decisions each party must provide.
AcceptanceThe checks, authorised reviewer and treatment of unresolved items.
ChangesThe approval route and record of agreed price or schedule effects.
HandoverThe documents, access, training and other materials to be supplied.
Continuing workThe 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.

Send an enquiry 

Related capability:Corporate Legal Consultancy 

Share this briefing