Support & operations · Practice guide

Recognise failures in the website journeys that matter

Illustrative situation

A form stops accepting enquiries, but the initial ticket is treated as a minor content request because the homepage still loads. A homepage loading does not establish that enquiries or bookings work. Staff need a simple way to report failures in the journeys that matter and have their impact assessed. An important form failure should not be treated as a cosmetic edit.

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

Classify incidents by impact on important journeys, not just whether the server responds. Give frontline staff a clear route for reporting a suspected service failure.

An example to discuss with your team

Report a fictional failure where the homepage works but enquiries cannot be submitted. Check that the initial assessment recognises the effect on reception and prospective patients.

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

Rehearse a fictional report where the site opens but submission fails. Ask who establishes the affected service, priority and next action. The initial report needs enough information to start investigation, not a technical diagnosis from reception. Track the delay before the business impact is understood.

Report the effect before guessing the cause

Reception should be able to say what someone was trying to do, which page was involved and what happened instead. Include the approximate time and an appropriate screenshot where useful, avoiding unnecessary personal details. Staff should not need to identify a server or software fault before a report is taken seriously.

Agree who assesses the effect on the service and decides the next priority. A broken enquiry form, an unavailable download and a minor visual issue can have different consequences even when the site remains online. Use fictional examples to check that the reporting route recognises those differences. Ask what temporary options staff may offer and who approves them. Keep the report connected to later updates so the person who raised it knows whether the original problem was checked. This helps the support process follow the visitor's difficulty rather than closing the issue solely because one technical availability check passed.

How to check the result

Measure time from the first credible report to impact assessment.

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.