Website support and maintenance

A defined route for fixes, updates and deliberate improvements after the first launch.

Ask about website support
A website support and maintenance workspace shown on a tablet held in two hands
What the service covers

Good support makes change controlled, not difficult.

What does website maintenance and support include?

Website maintenance and support provides a controlled route for keeping a live service current, secure and useful. The agreed plan can include request triage, dependency and platform updates, technical repairs, content and design changes, accessibility and performance improvements, release checks, change records and separate scoping for larger features.

Websites and products collect new content, changing priorities, software updates and occasional faults. A support plan gives that work a visible queue, an approval route and enough quality control to stop small changes slowly weakening the service.

01

A clear request route

People know where work is submitted, what information is needed and how urgent issues are separated from ordinary improvements.

02

Safer releases

Changes are reviewed, tested and recorded in proportion to their impact instead of being made directly and forgotten.

03

Useful momentum

Maintenance, fixes and improvement work can be prioritised together so urgent noise does not replace the longer-term plan.

What support and maintenance can include.

The plan is shaped around the platform, pace of change and level of cover required. It defines the workflow as carefully as the list of tasks.

01 / Requests

A queue with context

Requests are captured and triaged so the right work is understood before time is spent changing the live service.

  • Defined request and escalation route
  • Impact and urgency triage
  • Scope, estimate and approval where required
  • Priority and allowance tracking
  • Change history and status communication
02 / Maintenance

Keep supported software current

Routine technical work reduces the risk created by neglected dependencies, expiring services and unreviewed configuration.

  • Dependency, runtime and platform updates
  • Security advisory and patch review
  • CMS, plugin and integration health checks
  • Compatibility and deprecation review
  • Domain, certificate and service-expiry checks
03 / Improvements

Make useful changes deliberately

Content and product improvements are handled as part of the same system, with larger ideas separated into sensible phases.

  • Content and page updates
  • Design and interaction refinements
  • Accessibility and usability improvements
  • Performance and search-foundation work
  • New feature and integration planning
04 / Release

Check the change, not only the ticket

The release route reflects the risk of the work so a small copy edit and an important technical change are not treated identically.

  • Staging or preview review where appropriate
  • Regression and responsive checks
  • Backup or rollback preparation
  • Deployment and post-release verification
  • Release notes for meaningful changes
Hands reviewing a website update against a release checklist and change history

Maintenance protects the decisions already made.

A digital service can lose quality one rushed update at a time. A controlled support route keeps content, design and code moving together while making security and compatibility work part of normal operations.

  • Requests sorted by impact and urgency
  • Updates reviewed before release
  • A visible history of meaningful changes
  • Larger improvements separated into planned work

Support with boundaries people can actually use.

The written plan defines what counts as support, how requests are prioritised and what happens when work falls outside the allowance.

Scoped improvement

A contained piece of work

For an existing service that needs a review, repair or improvement phase without an ongoing retained arrangement.

  • Technical or experience review
  • Prioritised remediation scope
  • Quoted implementation phase
  • Testing and release plan
  • Handover or route into retained support

Response windows, working hours, emergency cover, included allowance and exclusions are agreed in the support proposal. Unused time, rollover and out-of-scope rates are also stated there rather than assumed.

A practical path from request to release.

The support workflow protects time on both sides: enough information to act, enough approval to control cost and enough checking to release with confidence.

01 / Submit

Capture the need.

Record what is happening, who it affects, the desired outcome and any deadline or business impact.

02 / Triage

Set the real priority.

Separate incidents, routine requests, maintenance and larger improvements so the right route is used.

03 / Approve

Make the change understood.

Confirm the approach, allowance or estimate and any dependencies before work that affects scope begins.

04 / Check

Review the affected states.

Test the change in proportion to its risk, including nearby journeys, responsive behaviour and rollback needs.

05 / Release

Close the loop.

Deploy, verify and record the outcome so the live state and remaining backlog are clear.

The practical questions.

Can you support a website or product you did not build?

Potentially. We begin with a technical review covering access, ownership, dependencies, current condition and known issues. That review determines whether the service can be supported responsibly.

What counts as an urgent issue?

Urgency is defined in the support terms using impact, not only the word used in a request. A live outage or security incident is treated differently from a content correction or planned improvement.

Are new features included?

Small improvements may fit within an agreed allowance. Larger features are defined and approved separately so they can be designed, tested and released with the attention they need.

Do you apply every update immediately?

Updates are assessed according to security risk, compatibility and service impact. Critical issues may require a faster route; other updates may be staged and checked before release.

Can support be added after launch?

Yes. It can be agreed with a new build or added later after a short review of the live service, its platform and the level of cover required.

Bring us the unfinished thought.

You do not need to arrive with the whole brief worked out.

Ask about website support