A client sends a quick message: “Can you just update the opening hours?” Fine. Then: “Actually, swap that photo too.” Then: “One more thing…” Each request is tiny. Together they eat an afternoon. This is how unbounded website support quietly destroys margins - yours and, eventually, theirs.

Why “small jobs” are not small

Every change request has a fixed cost that has nothing to do with the change itself: reading the message, opening the site, logging in, making the edit, checking it on mobile, closing the loop. Call that overhead 15 minutes minimum. If someone drip-feeds you six tiny requests across a month, you've spent an hour and a half on work that looks like six two-minute jobs. Neither side sees that clearly until the relationship starts to feel wrong.

The client thinks they're being reasonable. You think you're being taken advantage of. Both of you are right, and the problem is the structure, not the people.

The fix: define the scope before work starts

A good support arrangement answers three questions up front:

  • What counts as a change? Text edits, photo swaps, opening hours, a new product line - yes. A new page, a new feature, a redesign - no, that's a separate job.
  • How many changes are included? A finite number forces prioritisation. It also makes the value legible: the client knows exactly what they've bought.
  • How are they submitted? Batched, not drip-fed. One list, sent together, actioned together.

Without answers to all three, you're running an open tab. Open tabs always end badly.

A worked example: the SWAS policy

For sites we build and maintain, we use what we call a SWAS arrangement - Site With Annual Support. The structure is straightforward: a fixed annual fee covers hosting, security updates, and four included change requests per year. Changes are batched, not drip-fed.

Four changes sounds tight. In practice, it's generous. Most small business websites dont change that often in ways that matter. A seasonal opening-hours update, a new staff photo, a revised service description, an updated phone number - thats a full year for most clients. If they need more, we scope it separately.

The batching rule is the part that actually protects the client. When you have to collect your requests into one list before sending, you naturally prioritise. The “can you just” impulse gets filtered out. What arrives is the stuff that genuinely matters. The site gets better changes, not more changes.

How to write a scope that holds

Whether you're setting up your own support arrangement or reviewing one a developer has sent you, the scope document needs to be specific enough that a stranger could read it and know exactly what's included. Here's a plain-language template you can adapt:

WEBSITE SUPPORT SCOPE

Included:
- Hosting and SSL certificate renewal
- Security and plugin updates (where applicable)
- Up to [N] change requests per year, submitted as a single batch
- Changes defined as: text edits, image swaps, contact detail updates

Not included:
- New pages or sections
- New functionality (forms, booking systems, calculators)
- Redesign or rebrand work
- SEO campaigns or content writing

How to submit changes:
- Email a single list to [address] // one email, all requests together
- Turnaround: [X] working days from receipt of complete list

Additional changes beyond the included allowance:
- Scoped and quoted separately before work begins

The “not included” list is not there to be difficult. It's there so both sides know when a new conversation is needed. That clarity is a kindness.

What to do when a request falls outside scope

This is where most arrangements break down. The client asks for something that's clearly a new feature. The developer says yes anyway, because saying no feels awkward. The resentment builds quietly.

The right move is a short, honest reply:

That one sits outside the included changes - it's a new [page / feature / section].
Happy to scope it separately. Want me to send a quick estimate?

That's it. No apology, no lengthy explanation. The scope document you both signed is doing the work. You're just pointing at it.

Maintenance costs in plain terms

If you're budgeting for website support, ongoing maintenance for a straightforward small business site typically runs somewhere in the range of £50–£100 a month, depending on what's included. Anything more complex - a site with a CMS, live inventory, or custom integrations - needs its own conversation, because the variables are too different to quote blind.

The number matters less than the structure around it. A cheap retainer with no defined scope will cost you more than a clear arrangement at a higher rate.

The short version

Define what a change is. Set a limit. Batch the requests. Put it in writing before work starts. When something falls outside scope, say so immediately and offer to quote. That's the whole system. It works because it removes ambiguity, and ambiguity is what makes small jobs expensive.

If you want to talk through how we structure support for sites we build, start here - no obligation, just a conversation.