Website support should feel clear before it feels helpful. If the scope is vague, the surprises usually arrive as extra cost, delayed updates, or the awkward moment when everyone thought someone else was handling it.
Artists and charities usually ask the same sensible questions before they agree to support. What is actually included each month? What counts as a routine update and what becomes a separate project? How quickly should someone reply when something breaks? How do we plan around exhibitions, campaigns, launches, or fundraising deadlines? Those questions are not fussy. They are how you avoid paying for a promise that turns out to be mostly adjectives.
A good support arrangement is usually less mysterious than it sounds. It should cover the practical work that keeps a site accurate, secure enough, and usable day to day. Official guidance from WordPress security documentation and the W3C accessibility introduction points in the same direction: reliable websites depend on ongoing care, clear ownership, and regular checks, not just a nice-looking launch.
This guide turns “website support” into plain-English deliverables. You will see what is normally included, what is usually excluded, how to plan updates around busy seasons, and which questions to ask before you sign anything. If you want the broader context first, the home page, Support page, and Features of Taeko Website Design page outline the wider service approach, while the Blog index collects related planning guides.
Why support scope matters, and what usually goes wrong
Most support problems do not begin with bad intent. They begin with soft wording. Phrases like “kept updated,” “ongoing support,” or “content changes included” sound reassuring, but they do not tell you how much work is covered, how often it happens, or when the job becomes something larger.
- Content requests pile up without a limit. A few text edits turn into new pages, new layouts, and urgent image work.
- Security is assumed rather than described. Someone says the site is monitored, but nobody has defined what gets checked or how often.
- Response times are guessed. The client thinks “support” means same-day help for everything; the provider means “we will look at it this week.”
- Small design changes blur into new features. A button change is one thing. Adding a filtered event archive or donation workflow is not.
For artists and charities, this matters because the website often carries time-sensitive work. Exhibition dates, venue details, campaign pages, volunteer information, ticket links, and donation calls do not benefit from ambiguity. A clear scope lowers stress on both sides because everyone knows what to expect.
A practical support scope in plain English: what is usually included
A useful support scope is not a shopping list of technical terms. It is a short list of repeatable responsibilities. In plain English, website support usually means looking after the parts of the site that need regular care, then separating bigger improvements into their own scoped work.
| Area | Usually included in support | Usually separate or limited |
|---|---|---|
| Content updates | Editing text, swapping a small number of images, updating dates, publishing news items, correcting contact details | Rewriting the whole site, designing a new page template, large document uploads, heavy image sourcing |
| Software upkeep | WordPress core, theme, and plugin updates; routine compatibility checks; checking for obvious issues after updates | Major rebuilds caused by old custom code or unsupported plugins |
| Security hygiene | User access reviews, backup checks, update reviews, spam cleanup, basic anomaly checks | Incident response for a serious compromise, forensics, or a full security audit |
| Performance | Spotting slow pages, replacing oversized media, flagging plugin or layout issues, keeping the site reasonably usable | Deep performance engineering, custom server work, or platform migration |
| Support communication | Defined response times, update logs, scope confirmation before extra work starts | Unlimited on-demand requests without approval or prioritization |
If you only remember one sentence from this section, let it be this: support is for repeatable care, not unlimited change. Once the work changes the structure, functionality, or design system of the site, it usually needs a separate quote or a separate block of time.
Security & updates: what “kept current” should mean for you
“Kept current” should never be a mystery phrase. For a non-technical client, it should mean a short, practical routine: software updates are reviewed, backups are checked, access stays limited to the right people, and obvious issues are investigated rather than ignored.
- WordPress, theme, and plugin updates are reviewed on a routine schedule. That does not always mean instant updates the second a release appears, but it does mean they are not forgotten for months.
- Backups exist and are recent. A backup that nobody has checked is more of a hope than a plan.
- User access is kept tidy. Old staff, volunteers, freelancers, or agencies should not quietly keep admin access forever.
- Post-update checks are part of the job. Someone should confirm the key pages, forms, and front-end layout still behave after changes.
If you want a simple benchmark for what solid maintenance practice looks like, the Hardening WordPress guidance is a useful reference. You do not need every technical detail in that documentation. You do need the provider to translate it into a plain checklist you can understand.
A practical question to ask is: what happens after an update if the site looks wrong? A good support scope should explain who checks, what gets tested first, and how rollback or follow-up fixes are handled.
Content help: editing pages, adding news, updating events
For many artists and charities, content support is the part that matters most in daily life. You are not usually changing the whole website. You are keeping the live information accurate enough that visitors can trust it.
- Editing event, exhibition, or campaign dates
- Updating biographies, trustee lists, venue details, or contact information
- Publishing short news items, announcements, or project updates
- Replacing a featured image or adding a small number of new images
- Refreshing call-to-action wording on key pages
This section is where scope boundaries matter most. For example, “add our autumn fundraising campaign to the home page” might be a normal support task if the layout already exists. “Create a new campaign landing page with donation pathways, downloadable resources, and segmented sign-up forms” is closer to project work.
It also helps if the provider explains what they need from you before an update starts. The basics are usually enough: the page URL, the exact wording change, any new image or document, and the date it needs to go live. If the update includes a form, MDN’s forms guide is a good reminder that even simple form changes deserve careful testing because they affect real visitor actions.
Performance & backups: what you should expect to be handled
Most support agreements will not promise advanced performance engineering, and that is fine. What they should promise is sensible stewardship: large images are noticed, obviously slow pages are investigated, and backups are part of the routine rather than an emergency-only conversation.
- Performance monitoring in plain English: noticing when key pages have become slow, unstable, or awkward to use, especially on mobile.
- Backup handling in plain English: making sure recent recoverable copies exist, checking the backup process, and knowing who owns restoration responsibility.
- Escalation in plain English: if a page is suddenly heavy, broken, or timing out, support should say whether that is included investigation or separate engineering work.
For a practical performance reference, web.dev’s performance guide is useful because it turns “speed” into observable issues such as heavy media, layout shifts, and slow loading on phones. Your provider does not need to send you lab scores every week. They do need a habit for spotting the obvious declines before visitors complain.
Design tweaks vs. new features: how to tell the difference
This is where many support agreements go fuzzy. A tweak is a small change inside the existing pattern of the website. A new feature changes what the website does or how it is structured.
| Request | Likely category | Why |
|---|---|---|
| Change button text, swap one image, tighten a paragraph | Support tweak | It uses the existing layout and content structure |
| Add a new news item or update an event listing | Support tweak | It is repeatable editorial work |
| Redesign the home page hero and add new content sections | Borderline project | It affects layout, messaging, and design decisions |
| Add donations with receipts, integrations, or custom workflows | New feature project | It changes site functionality and testing requirements |
| Create a member area, portal, searchable archive, or booking flow | New feature project | It introduces new logic, privacy concerns, and user journeys |
The easiest way to stay out of trouble is to ask one direct question: does this request stay inside the current page structure, or does it create new functionality? If it changes functionality, integration, or template logic, it should be scoped separately before work starts.
Support response times: what to ask for and how to set expectations
Not every issue deserves the same response speed. A clear support scope should separate urgent problems from normal queued work. Otherwise, every request arrives with the emotional tone of a fire drill.
| Type of issue | Reasonable expectation | Example |
|---|---|---|
| Critical outage or broken contact path | Same day acknowledgement, urgent triage | Site down, form not sending, donation or enquiry path broken |
| Time-sensitive content change | Agreed turnaround based on deadline | Event page needs tomorrow’s venue update |
| Routine editorial edits | Queued in the normal support cycle | Bio refresh, image swap, headline cleanup |
| Ideas for new layouts or features | Discovery first, implementation later | New campaign microsite or searchable archive |
Ask for response times in two layers: acknowledgement and resolution. A provider may acknowledge a request quickly but resolve it later depending on severity, access, and approvals. That is normal. What you want to avoid is silence.
If search visibility matters to your enquiries or campaign traffic, the same principle applies there too. Google’s SEO Starter Guide is still a useful outside reference because it reinforces the basics: clear pages, sound structure, and content that matches real visitor needs. Support should help preserve those basics, not complicate them.
Seasonal planning: aligning updates with launches, exhibitions, and campaigns
The easiest support to deliver is planned support. Artists often know when exhibition dates, portfolio updates, submissions, and seasonal promotions are coming. Charities usually know the shape of fundraising periods, annual reports, volunteer drives, or event seasons. Bring that calendar into the support conversation early.
- Six to eight weeks out: confirm whether you need a new page, new messaging, or just updates to existing sections.
- Three to four weeks out: gather approved copy, dates, links, images, and contact details.
- One to two weeks out: publish and test the public path on mobile, including forms, tickets, maps, or donation buttons.
- After the event or campaign: decide what gets archived, rewritten, or reused so the site does not keep advertising old deadlines.
This kind of planning does not need heavyweight project management. A shared note or monthly check-in is often enough. The point is to move important updates out of the last-minute category whenever possible. Reliable support is partly technical, but it is also calendar management with better boundaries.
Questions to ask before you sign: a short checklist you can copy and paste
If you are comparing support options, copy this list into your notes and use it as your baseline. Plain answers are usually a good sign. Vague answers are useful too, just not in the way anyone hopes.
Website support scope checklist 1. What recurring tasks are included each month or quarter? 2. How many content edits are included, and what counts as one edit? 3. Are WordPress, theme, and plugin updates included? 4. Are backups checked, and who is responsible if a restore is needed? 5. What checks happen after updates or fixes are applied? 6. What is the response time for urgent issues versus routine requests? 7. What counts as a design tweak, and what counts as a separate project? 8. How should we send update requests so nothing is missed? 9. Do you test forms, donation paths, or ticket links after changes? 10. How are deadlines handled for exhibitions, launches, or campaigns? 11. What happens if a plugin, integration, or third-party tool causes a problem? 12. How will extra work be approved before charges appear?
If the answers feel calm, specific, and easy to repeat back, the scope is probably in decent shape. If the answers rely on broad reassurance without examples, keep digging.
A clear next step
Website support does not need to feel technical to be solid. It needs a visible routine, a clear line between maintenance and project work, and realistic response expectations. That is what helps artists and charities avoid the expensive surprise of discovering the real scope only after the invoice arrives.
If you are reviewing your current setup, start with the scope questions above, then compare them against your actual calendar of updates. If you need a practical next conversation, the Support page and Contact page are the best places to gather the details before reaching out.