Support & operations · Practice guide

Choose a release time with the right support available

Illustrative situation

A planned website change overlaps with a major campaign launch and the only available support engineer's leave. The technical task is small but recovery support is limited. A small change can still be difficult to recover from if it launches during a busy campaign or when support staff are unavailable. Choose the release time around business impact and the ability to respond, not only development completion.

Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What this means for your practice

Schedule releases according to operational impact, dependencies and the ability to respond. Make the release owner and fallback contact explicit.

An example to discuss with your team

Assume the release fails near the end of the chosen window and identify who can diagnose, decide and restore service.

Healthcare website maintenance with infrastructure, a status panel, tools and an operational checklist.
Monitor the useful journey, not just whether a server responds.
Healthcare backup and recovery illustrated by storage copies, an archive folder and a restoration route.
Test whether a backup can restore a usable service.

How to review the arrangement

Ask what happens if the change fails near the end of the proposed window. Who can investigate, decide and restore service? Check dependent work and staff availability. A named release owner and backup give the practice a clearer expectation than an informal promise to keep an eye on the launch.

Plan the people as well as the time slot

Check whether the change coincides with a campaign, an important booking period or work by another supplier. Confirm who can approve the release, who checks it and who can help if something fails. The most convenient time for development is not always the best time for the practice to absorb disruption.

Walk through a fictional failure close to the end of the proposed window. Can the team still investigate and restore the intended service, or would the next available support person arrive much later? Agree what would cause the release to be postponed and how that decision reaches the practice. Keep the initial checks focused on the affected visitor tasks, with a named person to confirm the result. For a change involving several providers, make the order and handovers clear. A sensible release window includes enough practical support to respond to the outcome, not merely a calendar entry saying when the update will start.

How to check the result

Measure releases with confirmed recovery coverage during the agreed window.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore support & operations services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.