Terms and conditions for service providers: 14 clauses
Terms and conditions for service providers in design work: 14 clauses sorted by project stage, input and approval wording, and a 30-point audit.
Kristian Hoffmann
SaaS founder and operator
Terms and conditions for service providers are the standing rules behind every project you sell: what you deliver, what the client supplies and by when, how payment and changes work, who owns the result, where liability stops, and how either side can end the work. For web designers and agencies, the clauses you end up pointing to mid-project are usually not the liability boilerplate. They are the input clauses — content deadlines, feedback windows and what counts as approval — because those are the ones a live project tests week by week.
This article is about the terms you agree with clients for project work. The terms of use for a website or app are a different document, covered in Terms of service: what it is and why you need one. Here you get five things. The article maps 14 clauses by when each one gets tested and gives drafting patterns for the input clauses. It works through the numbers for payments and delays, provides a 30-point audit and ends with a plan for switching terms at the turn of the year. It is operational guidance, not legal advice. The sample wording is an illustration to adapt. Whether a clause holds depends on the law that governs your contracts, so have the final text reviewed by a lawyer where you and your clients are based.
Where your terms sit: three documents, one agreement
Wikipedia defines terms of service, also known as terms of use and terms and conditions, as "the legal agreements between service providers and service consumers" (Wikipedia: Terms of service). For a design studio, that agreement works better as three layers that change at different speeds.
The general terms are the rules that stay the same for every client. The statement of work (SOW) is the document for one project: deliverables, price, dates and named inputs. A change order is a signed amendment to one SOW, used when the scope moves.
| Layer | How often it changes | What it holds | Example line |
|---|---|---|---|
| General terms | Once or twice a year | Payment mechanics, what a revision round is, rights transfer, liability, termination | "A revision round is one consolidated set of comments from the named approver." |
| Statement of work | Every project | Pages and templates, input list with due dates, fee, milestones, approver's name | "Client supplies final copy for eight pages by the end of week 2." |
| Change order | Whenever scope moves | Added or removed work, price, date shift | "Adds a blog template: +€900, launch moves six business days." |
Here's how to sort a sentence. If it would need editing for the next client, it belongs in the SOW. If it would read the same for every client, it belongs in the general terms.
Then add one sentence saying which document wins when they conflict. If the SOW wins on project details, an exception you negotiated can't be quietly overridden by the standard text.
Client terms vs website terms of service
Wikipedia treats the labels as names for the same kind of agreement, so the title isn't worth a drafting session. The audience is what separates the documents: website terms address everyone who uses a site, while the terms in this article govern paid work for one client. Spend the saved time on two facts you'll want to prove later: which version of the terms the client saw, and when and how they agreed to it. How to collect that acceptance online, including clickwrap versus browsewrap, is covered in the terms of service guide linked above.
Check which side a template was drafted for
Templates are not neutral. Practical Law, for example, publishes a standard document titled "General Terms and Conditions for Services (Pro-Service Provider)" (Practical Law)). The client's procurement team may be working from the mirror image.
Terms written by buyers read very differently. In the services terms that Ireland's Environmental Protection Agency uses on behalf of the Climate Change Advisory Council, the supplier undertakes that it must "obtain and at all times maintain all necessary licenses, consents and permissions" (Terms and Conditions for the Purchase of Contractors, Services & Service Providers, PDF%20web%20version.pdf)).
A larger client may send their own terms instead of signing yours. If that happens, start with one question before anything else: which way does each obligation run?
The 14 clauses, sorted by when they get tested
Templates usually list clauses in legal order. It's more useful to sort them by the point in a project where each one gets tested: three before kickoff, six during the work and five at handoff or exit.
| # | Clause | Tested | Question it has to answer | Failure mode |
|---|---|---|---|---|
| 1 | Precedence and governing law | Before kickoff | Which document wins, and which law applies? | Terms and SOW contradict each other with no tiebreaker |
| 2 | Scope by reference | Before kickoff | Do the terms point to the SOW for deliverables? | Scope described twice, differently |
| 3 | Fees and payment | Before kickoff | What triggers each invoice, and when is it due? | Final payment tied to an event only the client controls |
| 4 | Client inputs | During | Which inputs, due when, and what moves if they are late? | "Timely" instead of a date |
| 5 | Feedback window | During | How many business days to respond, and what does silence mean? | Window stated, outcome missing |
| 6 | Revision rounds | During | What exactly is one round? | Rounds counted but not defined |
| 7 | Approval | During | Who approves which version, in what form? | "Looks good" from someone not named in the SOW |
| 8 | Change requests | During | Does change work wait for an accepted quote? | Work done first, priced after |
| 9 | Client-supplied materials | During | Who confirms the rights to uploaded logos, photos, fonts and copy? | Nobody asked where the hero image came from |
| 10 | Rights transfer | Handoff | What transfers, when, and what may you keep showing? | Portfolio use not agreed |
| 11 | Third-party services | Handoff | Who owns and pays for hosting, domains, plugins, font licences? | Client site running on the studio's accounts |
| 12 | Confidentiality and data | Handoff | What client data do you hold, and how is it returned or deleted? | Credentials still sitting in an old email thread |
| 13 | Liability | Exit | Where is liability capped, and what is excluded? | A copied cap nobody checked against the governing law |
| 14 | Termination | Exit | What notice applies, what gets paid, and what is handed over? | No handover list, so every file becomes a negotiation |
Templates written for websites make clauses 4 to 9 easy to miss. TermsFeed frames its template around "the terms, rules and guidelines for using your website or mobile app" (TermsFeed). That's the right document for your own site. It says nothing about when a client's copy is due.
The input clauses generic templates leave out
Client inputs: a named list, a due date, a clock that moves
"The client will provide content in a timely manner" gives neither side a date. Put the list in the SOW with a due date for each input, and put the consequence in the general terms.
Illustrative wording: The Statement of Work lists each input the Client supplies and its due date. If an input arrives late, every later date in the Statement of Work moves by the number of business days it was late, plus up to five business days to reschedule the work.
The five-day buffer exists because a reserved slot doesn't wait. By the time late copy arrives, the week you held for it may already belong to another client.
Here's a worked example with fictional numbers. A website build is planned for 30 business days. Final copy for eight pages is due on day 10 and arrives on day 18. Under the clause, launch moves from day 30 to day 43: eight days late plus five to reschedule. Without the clause, day 30 is still the launch date in the signed document, and moving it becomes a new negotiation.
Feedback windows: decide what silence means
A feedback window is the number of business days a client has to respond to a delivered draft. Stating the window is the easy half. The half that tends to get skipped is what happens when it closes with no reply.
| When a window closes without a reply | Effect | Where it fits | Trade-off |
|---|---|---|---|
| Pause | The project pauses; dates move under the input clause | Default for anything client-facing, including final launch approval | You carry the idle slot until the client returns |
| Deemed approval | The draft counts as approved | Intermediate steps such as a sitemap or wireframe | Whether it holds depends on the governing law and the wording; get it reviewed |
Pause by default. If you use deemed approval at all, keep it for intermediate steps, not for the version that goes live under the client's name.
Revision rounds: define one before you count them
"Two revision rounds included" means nothing until the terms say what a round is. One workable definition is one consolidated set of comments, from the named approver, on one version.
A fictional example: a landing page includes two rounds, and each extra round is billed at five hours at €85. Three stakeholders send comments on the same version in four separate emails. Counted per email, that's four rounds, two of them billable: €850. Counted as one consolidated set, it's one round with nothing to bill.
The definition doesn't create or cancel the €850. It settles in advance which reading applies, and it can give the client a reason to gather feedback before sending it.
Approval: a name, a version, a date
An approval you can rely on later has three parts: the approver named in the SOW, the version identifier and the date. A thumbs-up emoji in a chat thread, from someone the SOW doesn't name, under an unlabelled screenshot, has none of them.
Illustrative wording: Approval means written confirmation from the Client's named approver identifying the version approved. Approval of a version closes the revision period for that deliverable.
Client-supplied materials: ask the rights question at upload time
The contractor terms quoted earlier put the licensing burden on the supplier. For material the client gives you, your terms set the reverse direction. That covers logo files, product photos, stock images, font files and copy lifted from an old brochure. The client confirms they hold the rights needed for the project, including your work with the files.
The clause is easier to use when the intake form asks the question as each file arrives. One field per upload does it: Source: own / licensed (licence attached) / not sure. A "not sure" in week one is a five-minute conversation. After launch, it can turn into a takedown request.
Payment, change and exit: put numbers where the adjectives were
Payment triggers that don't wait on client content
A payment clause can fail without anyone noticing. Take a fictional €6,000 site paid in a 40/40/20 split: €2,400 at signing, €2,400 on design approval and €1,200 at launch. Launch depends on content only the client can supply. If that content doesn't arrive, the €1,200 doesn't become due, even though the work behind it is finished.
The fix is a trigger with a fallback:
Illustrative wording: The final instalment is due at launch or 15 business days after final design approval, whichever comes first.
Also state the payment period on each invoice. Whether you can charge interest or fees on late payments, and at what rate, depends on the law that governs the contract, so check before you write a figure into your terms. One thing you can settle in the terms yourself is whether overdue invoices pause work.
Change requests: quote first, work second
A change is anything not listed in the SOW deliverables, or any edit to something already approved. The rule worth writing down: no change work starts until the client accepts a written change order. The order states the price and how many business days the launch moves.
The second number matters as much as the first. It ties the change to the same date clock the input clause uses.
Termination: notice, money, handover list
Three decisions, each written as a number or a list:
- Notice. How many days' written notice either side gives to end the agreement without cause.
- Money. Either completed milestones plus work in progress at a stated hourly rate, or a fixed cancellation fee. Pick one.
- Handover. Which files are delivered (source files, exports, credentials for accounts the client owns) and on what condition, for example once outstanding fees are paid.
One drafting approach ties the transfer of rights in the work to payment of the relevant fees. How rights in design work pass by default differs between legal systems, so this clause needs your lawyer, not a template.
Liability: the first clause to send for review
Capping liability at the fees paid under the affected SOW and excluding indirect or consequential loss are common drafting patterns; the terms of service guide linked in the introduction walks through both. For service terms, the point is review, not wording. Whether a cap holds, and whether it can cover every kind of loss, depends on the governing law and on whether your client is a business or a consumer. The usual mistake here is copying a cap from a template written under another country's law, and nobody notices until a claim arrives.
A clause you can't show happened is a clause you'll negotiate again
Every input clause describes an event: an input arrived, a window closed, a named approver confirmed a version. When a client disputes one of those events, the clause is only as useful as your record of it. If the record is split across an inbox, an expired file-transfer link and a chat thread, you're back to negotiating.
| Clause | Event | Record needed | Weak record | Stronger record |
|---|---|---|---|---|
| 4 Client inputs | Input arrives | Arrival date for each named input | An attachment somewhere in a thread | Intake checklist showing each required input and when it came in |
| 5 Feedback window | Draft delivered, reply received | Both dates | Your sent folder | Delivery and response logged against the project |
| 7 Approval | Approver confirms a version | Name, version, date | A chat reaction | Approval attached to a specific version |
| 8 Change request | Client accepts a quote | Accepted change order | "OK, go ahead" in an email | Change order stored with the SOW |
| 9 Supplied materials | File uploaded | Source or licence for each file | Nothing | Source field on the upload |
| 14 Handoff or termination | Files handed over | List of what was delivered | Memory | Export archive of the final handoff |
The dispute-day test
Pick your last closed project. Using only stored records, without relying on memory or asking a colleague, answer five questions:
- On which day did each required input arrive?
- How many revision rounds happened, counted by your own definition?
- Who approved the final version, and which version was it?
- Was any change worked on before a change order was accepted?
- Exactly which files were handed over?
Score one point for each answer you can document. Three or fewer means your terms are ahead of your workflow. Your next edit belongs in the process, not the contract.
A client portal is meant to close that gap. In cluein.me, each client gets one link where they fill in a structured brief, upload files and approve results, without creating an account. The project exports as a ZIP containing the files plus the brief as JSON and Markdown. The brief, the uploads and the approvals then sit in one place next to the SOW, not across forty emails. Whichever tool you use, check it against the table above: for each event, can it show who did what, and when?
A 30-point audit for your draft terms
The audit has fifteen checks worth two points each, with no half points. Three of them are hard gates, marked G. If a gate fails, fix it before scoring the rest, because the other checks depend on it.
| # | Check | Points |
|---|---|---|
| 1 | G Scope is defined by reference to a SOW, not described in the general terms | 2 |
| 2 | Precedence between terms, SOW and change orders is stated, along with the governing law | 2 |
| 3 | Each invoice has a trigger and a payment period | 2 |
| 4 | G The final instalment has a fallback that doesn't depend only on launch | 2 |
| 5 | G Client inputs are named with due dates in the SOW, and late inputs move later dates | 2 |
| 6 | The feedback window is stated in business days | 2 |
| 7 | The outcome of a window that closes without a reply (pause or deemed approval) is chosen and written down | 2 |
| 8 | One revision round is defined | 2 |
| 9 | Approval names the approver, the version and the form of confirmation | 2 |
| 10 | Change work waits for an accepted change order with price and date impact | 2 |
| 11 | The client confirms rights to the materials they supply | 2 |
| 12 | The point at which rights transfer is stated, along with whether you may show the work in your portfolio | 2 |
| 13 | Third-party accounts: who owns them, who pays, and who holds logins at the end | 2 |
| 14 | Termination covers notice, payment for work done and a handover list | 2 |
| 15 | The liability cap and exclusions have been reviewed against the governing law | 2 |
- 26–30: ready for a lawyer's review.
- 18–24: fix the input and payment lines first, since those are the ones a live project tests.
- Below 18: rebuild on the three-layer structure before polishing the wording.
Switching terms at the turn of the year
October and November are a practical time to finish new terms if you want them in place for projects and retainer periods that start in January. Three groups of agreements need their own switch date.
Count back from the switch date
- New projects. Every SOW signed after a date you choose refers to the new version. Put a version number and date in the footer of the terms, and name that version in each SOW. Then "which version did they agree to?" has a one-line answer.
- Existing retainers. Read the change clause in each current agreement before you announce anything. If an agreement requires 30 days' written notice, a switch on 1 January needs notice sent by 2 December. Sending it in November leaves time for questions before that deadline.
- Proposals in flight. Decide whether a proposal sent in November and signed in January uses the old version or the new one, and say so on the proposal.
Holiday closures and the business-day clock
Your studio may close for a stretch around the end of the year. If so, a feedback window counted in calendar days can run out while nobody is reading email, on either side. Count windows in business days and define business days in the terms: your working days, excluding closures announced in writing.
Write this year's closure dates into the SOW of any project that runs across them. Name a deputy approver on the client side too. An approval window doesn't work if the one named approver is away for two weeks.
FAQ
What are the terms and conditions for a service?
They are the standing rules for every engagement a service provider takes on. They cover scope (by reference to a project document), fees and payment, client obligations, changes, rights in the work, confidentiality, liability and termination. Details that differ per project, like deliverables, prices and dates, usually sit in a separate statement of work that the terms refer to.
What should terms and conditions for a design service include?
For a service business, start with the 14 clauses in the map above. Treat three of them as non-negotiable: scope defined by reference to a SOW, named client inputs whose lateness moves dates, and a final payment trigger with a fallback. Terms for a website or app cover how people may use the site itself, which is a different document from the terms for client projects.
What are some examples of terms and conditions?
Webtrends' professional services terms are an example written by a provider. They open with numbered sections on project authorization and services, payment for services, and term and termination (Webtrends). The Climate Change Advisory Council's conditions for contractors and service providers, quoted above, show the buyer's side. Reading one of each shows how the same obligations look when written from opposite sides.
What are common terms and conditions?
Icertis's list of key elements includes acceptance of terms, user responsibilities, intellectual property rights, payment and fees, limitation of liability, termination and dispute resolution (Icertis). For design work, the clauses that set usable terms apart from generic ones are less common: client inputs, feedback windows, revision rounds and approval.