Last updated: 3 August 2026. View change log.

This Schedule forms part of the Web Development Master Services Agreement and describes the scope, responsibilities and limitations that apply to Website Maintenance and Support.

It applies where your Order includes Website Maintenance (sometimes called a care plan, support plan or maintenance agreement) for a website or web application we deliver, host or manage.

1. Scope of Website Maintenance

  1. Website Maintenance exists to keep your website working as it was delivered and accepted.
  2. Depending on your Order, it may include:
    • fixing things that stop working (incidents);
    • answering questions about the site (information requests);
    • applying updates to the platform, CMS, plugins or dependencies where a supported update path exists; and
    • security patching, monitoring and backups for sites we host or manage.
  3. Your Order lists which of these are included. If it is not in your Order, it is not included.

2. What maintenance covers: incidents and questions

  1. We classify website tickets the same way as our Service Desk tickets:
    • Incidents – something that worked no longer works as it should: an error, a broken page or feature, or a fault introduced by an update. Maintenance covers these.
    • Information requests – questions, advice and guidance about the site. Maintenance covers these.
    • Service requests – requests to change or add something. These are development work, not maintenance (see section 3).
  2. The test is simple: restoring something that used to work is maintenance; making the site do something new, different or better is development.

3. Service requests are development work

  1. Changes and additions – new features or functionality, content or design changes, new pages or sections, integrations, and alterations to how the site behaves – are not covered by maintenance, however small they seem.
  2. We handle them as development work: through the Change Control Process (Annex C), against a retained allowance (Schedule 3) where you have one, or as a Project (Schedule 1) for larger pieces. They are estimated or quoted before work starts.
  3. We will still respond to a service request within our normal service levels – responding, clarifying and quoting are covered; building is not.

4. Supported browsers and devices

  1. Maintenance keeps your website working on current, vendor-supported technology: the current stable releases of the major evergreen browsers (Chrome, Edge, Firefox and Safari) on operating systems their vendors still support, as those browsers update.
  2. Maintenance does not extend to:
    • browsers or browser engines that no longer receive vendor updates;
    • fixed or embedded browser versions, such as WebViews or kiosk builds pinned to an older engine;
    • devices or operating systems that are out of vendor support; or
    • the particular hardware constraints of a specific audience or device estate.
  3. We do not bug-fix backwards. Making a site work on technology its own vendor has stopped supporting needs investigation, workarounds and testing that go well beyond keeping a healthy site healthy – it is development work. Where you need it, we will scope and quote it separately, and we will be honest about whether it is worth doing at all.

5. Ageing platforms and end of life

  1. Websites age. The frameworks, CMS versions, plugins and language versions underneath a site all reach end of support eventually, and beyond that point maintenance becomes progressively harder, riskier and more expensive.
  2. Where a site’s platform is at or approaching end of life, we may:
    • recommend a modernisation or rebuild project;
    • limit maintenance on the affected parts to reasonable endeavours; or
    • decline to renew a maintenance agreement where we can no longer maintain the site responsibly.
  3. We will always tell you before we take any of these positions, with reasonable notice and a clear explanation of the options.

6. Requesting support and valid channels

  1. Maintenance support runs through our Service Desk, using the channels we give you during onboarding: the service portal (where provided), the support email address, or the Service Desk telephone number.
  2. These are the only channels that create and update tickets. They feed the queue our whole team works from, they carry your service-level clocks, and they keep an auditable record of what was asked and agreed.
  3. Messages sent another way – personal messaging apps such as WhatsApp, SMS, social media, or messages to individual members of our team – are not support requests. They do not create a ticket and do not start any service-level clock. If something reaches us that way, we may ask you to resubmit it through a support channel; the clock starts when the ticket exists.
  4. The same applies to instructions and approvals: a decision that changes scope, cost or behaviour is only effective when it is recorded on a ticket or agreed through the Change Control Process. An informal message is not an instruction we can act on, or a commitment by either of us.

7. Prioritisation and service levels

  1. Website tickets are prioritised P1–P4 by impact and urgency, and classified by type, on the same model as our Service Desk SLA (Annex A of the IT Master Services Agreement). Unless your Order says otherwise, the same target service levels apply.
  2. Incidents and information requests carry those service levels end to end. For service requests, the service levels cover our response – acknowledging, clarifying and quoting – while the development work itself is scheduled as agreed in the estimate or quote.