Most small care providers have one. The person who knows how to reset a carer’s app login, why the rota does not match the payroll export, and which report the local authority actually wants. Often they were never appointed to the role. They were simply the one who was curious, or willing, or on shift the day the system went live.

They are usually brilliant. They are also a single point of failure.

What it looks like when they are away

When the system person is on leave, the signs are quiet. Problems wait for their return. A carer who cannot log in writes notes on paper “just for today”. A manager who cannot find a report rebuilds it by hand in a spreadsheet. Nobody decides to abandon the digital system; the service simply drifts back to what people know will work.

If they leave for good, the drift can become permanent. The licences are still paid for, but much of the value walks out with the person who understood how to get it.

Why it happens

It is rarely anyone’s fault. Small providers often buy systems with little time set aside for implementation, so training tends to focus on getting care delivered rather than on running the system. Whoever picks up the configuration, the troubleshooting and the supplier relationship becomes the expert by default.

Busy teams also reward speed. Asking the system person is quicker than reading a guide or raising a support ticket, so every quick fix teaches the organisation to rely on them a little more, and nobody else learns how.

Building for resilience instead

The aim is not to make the system person less important. It is to make sure the service still runs when they are not there.

  • Name a deputy: someone who shadows the routine tasks and covers leave, not just emergencies.
  • Write down the common fixes: login resets, missing visits, report exports. A single page covering the ten things that go wrong most often is worth more than the supplier’s full manual.
  • Share the supplier relationship: at least two people should hold admin access and know how to raise a support request.
  • Use leave as a rehearsal: next time the system person is away, note every question that waited for their return, then close those gaps.
  • Recognise the role: if someone is doing this work, put it in their job description and give them time for it, rather than squeezing it between other duties.

None of this needs new software or a big project. It needs someone to notice that resilience is part of digital adoption, not an afterthought once the system is live.

A question to take away

If your system person handed in their notice tomorrow, which three tasks would nobody else know how to do? Write them down this week, and pick one to teach to someone else before the month is out.