How to Write a Service Agreement for Freelancers

Scope of Work: Services, Deliverables, and Out-of-Scope Requests

Write the scope of work as a checklist before you send the agreement, then copy that wording into the contract. Clear scope stops fee disputes, reduces revision loops, and gives both sides a shared reference when priorities change.

List the services you will perform in plain verbs (for example: research, write, design, build, test, hand over). Tie each service to a deliverable with a measurable format and count, such as “three landing page wireframes in Figma” or “one 1,500-word article in Google Docs”. Name the acceptance standard as well: required sections, brand guidelines, file types, and any accessibility or performance targets that apply.

Set boundaries for what “done” means. Define the number of revision rounds, the turnaround time for feedback, and what counts as a new request versus a correction. If the work depends on client inputs, state what you need (logins, assets, approvals) and pause dates when those inputs arrive late.

Handle out-of-scope requests with a change control rule. Require written approval for changes, confirm the extra fee or day rate, and reset deadlines when scope expands. Add a short line that excludes work you do not provide (for example: paid media management, legal review, or ongoing maintenance) unless priced in writing.

Fees and Payment Terms: Rates, Invoicing, Late Fees, and Expenses

Clear payment terms reduce cash-flow gaps and prevent work from stalling mid-project. Use a simple structure: state the rate (fixed fee, day rate, or hourly), set an invoicing schedule, and tie payment due dates to a clear trigger such as “on receipt” or “within 14 days”. Add a late-payment clause that sets interest and recovery costs in line with the Late Payment of Commercial Debts (Interest) Act 1998 where it applies, and say you may pause work until overdue invoices are paid.

This approach wins because it removes ambiguity around when money is owed, what counts as billable time, and which costs the client must reimburse. It also gives a clean process for change requests: extra work gets priced and approved before it starts.

Where alternatives fit: use milestones for long projects, retainers for ongoing support, and deposits for high-risk starts. If you bill expenses, require pre-approval above a set amount and attach receipts to the invoice.

Timelines and Approvals: Milestones, Client Inputs, and Change Control

Most timeline disputes start when the agreement sets dates but does not state what pauses the clock, who approves what, or how changes reset delivery.

Build the schedule around milestones, not a single end date. For each milestone, name the deliverable, due date, and approval window (for example, “client feedback within five business days”). Add dependencies for client inputs such as access, brand assets, logins, or subject-matter review.

Lock in change control as a written process: define what counts as a change, require written approval, and state the impact on fees and dates. Use a trigger: “Any request that alters deliverables, adds rounds, or changes acceptance criteria is a change.”

• Set acceptance rules: what “approved” means, and what happens if feedback is late or incomplete.
• Cap revision rounds per milestone and price extra rounds at the contract rate.
• State the handover format and sign-off method (email approval is enough).

This structure prevents scope creep, keeps delivery dates defensible, and gives both sides a clear path to re-plan when priorities shift.

Intellectual Property and Usage Rights: Ownership, Licensing, and Portfolio Use

Default ownership rules can hand the client broader rights than you meant to give, unless the agreement states exactly what transfers and when.

Start by naming each category of work: pre-existing materials (your templates, libraries, methods), project deliverables (the specific files you will hand over), and third-party items (stock, fonts, plugins). Then state the rights the client receives for each category, using plain language such as “exclusive ownership”, “non-exclusive licence”, and “internal business use”.

Set the transfer trigger to payment. A simple clause works well: you assign rights in the deliverables only after you receive full payment, while you keep ownership of your background materials and grant a limited licence to use them as part of the deliverables. If the work includes open-source code, reference the relevant licence terms and require the client to keep notices intact.

Cover portfolio use in one sentence. Specify whether you may display the work in your portfolio, on your website, and in pitches, and add a carve-out for confidential or unreleased projects with a written approval step.

Avoid vague phrases like “work for hire” (not a UK concept), “all rights worldwide in perpetuity” without limits, and clauses that claim ownership of “ideas” or “methods”. Remove any term that blocks you from reusing general know-how, or that forces you to transfer third-party rights you cannot legally assign.

Confidentiality, Data Protection, and Liability: Practical Limits and Compliance

Tight clauses cut breach risk, limit open-ended exposure, and reduce the chance of unlawful personal data handling.

Define confidentiality by category: client business information, credentials, pricing, and non-public deliverables. Limit use to delivering the services, restrict access to named subcontractors, and set a security baseline (unique passwords, access control, encrypted storage where available). State how long duties last after termination, and keep trade secrets protected indefinitely.

Run a separate data protection check. If you handle personal data (names, emails, analytics IDs, HR records), name the controller and processor, require written instructions, and limit processing to the project scope. Where you act as a processor, attach a short schedule aligned to ICO UK GDPR guidance, covering sub-processors, breach notification, deletion/return, and international transfers.

Cap liability and exclude losses you cannot price. Link the cap to fees paid or payable, exclude indirect or consequential loss, and keep uncapped items clear (fraud, deliberate misconduct, and death or personal injury caused by negligence). If a client insists on unlimited liability, require matching insurance and a higher fee.

• Do not let “confidentiality” also assign all IP by default; keep rights and secrecy separate.
• Limit legal compliance to UK law and the project territory.
• Remove indemnities for client data, instructions, or third-party tools outside your control.

Red Flags to Avoid: One-Sided Terms, Hidden Obligations, and Unclear Exit Rights

Reject any clause you would not accept if roles were reversed, and rewrite it in plain English before signing. One-sided terms hide cost and risk in places clients rarely explain: unlimited revisions, “all future work” ownership, broad indemnities, and payment tied to vague “acceptance”. These clauses create disputes because neither side can point to a clear limit, trigger, or remedy.

Prioritise three checks: reciprocity (both sides have comparable duties), specificity (clear triggers, time limits, and caps), and a clean exit (how either party ends the work and what gets paid). If the agreement lets the client terminate “for convenience”, require payment for work done, committed costs, and a handover of completed deliverables.

Where a client needs stronger protection, narrow it instead of refusing it. For example, keep indemnities limited to your breach, keep non-solicitation short and role-specific, and set acceptance as “deemed approved” after a fixed review window.