There's one person on your team who's been running your ATS for 5 years. Or your HRIS. Or payroll.
They're the one hiring managers email when something breaks. They're the one who knows why the odd exception in the approval workflow got configured back in 2022. They're also the one who fixes the reports Finance runs every quarter, before anyone notices the reports were broken.
Then, they hand in their notice and they’ll be out in a few weeks.
The exit interview covered handover. They'll write documentation, the team lead will shadow them, HR has been informed. Everything looks under control.
The pattern after they leave is consistent across most organizations. The system runs fine for the first month, it just stops improving after that. Six months in, hiring managers start complaining that things used to work better.
The single-person risk lives on every HR system
Payroll has one. The ATS has one. The HRIS has one. The performance management tool has one, usually a different one, and they only overlap at the awkward integrations.
This is the operating model most HR functions default into by accident. Risk registers rarely include it, and it only shows up on anyone’s radar when the config debt starts compounding after the super user has already left.
The structural causes:
- Super users are cheap. One person doing the config work of a small team looks like efficient staffing. It also looks like efficient staffing right up until they leave.
- Documentation is always next quarter's project. Every super user knows they should document more. Urgent work outpaces important work every week.
- Systems evolve through undocumented decisions. "Why is this workflow configured this way?" has a good answer, but it lives in the head of the person who made the decision. Once they're gone, the answer becomes "we don't know, and we're afraid to touch it."
- The system runs fine while the super user is there. Which makes the risk invisible to anyone who doesn't manage HR ops directly.
What breaks after they leave
The failure mode is gradual. Six things degrade in a predictable sequence.
- New requests stop getting answered fast. The old super user could triage in their sleep. Their replacement can't. The queue grows.
- Small bugs stay small bugs longer. The 5-minute fixes take a week to route to someone who can do them.
- Custom logic starts drifting. The workarounds built to handle edge cases don't get maintained. Business changes, and the workarounds no longer fit.
- Vendor conversations get lighter. The super user knew what to ask for. The replacement doesn't yet. The vendor stops volunteering upgrades or improvement suggestions because the sharp questions have stopped coming.
- Reports start returning stale numbers. The org changes since the super user last touched them haven't been reflected. The numbers still compute, but they're no longer describing the current state.
- Configuration debt compounds. By month 9, the system has 6 months of unmaintained changes on top of a config only the outgoing super user fully understood.
The audit to run now, whether or not anyone's leaving
If your risk registers don't have "single-person system dependency" on them, this audit fills the gap. Six questions to answer, per system.
- Who is the primary owner of this system? Not the name on the org chart. The person who actually does the configuration work day-to-day.
- What percentage of the config knowledge exists only in that person's head? Ask them. They'll usually give you an honest answer if you frame it as a risk audit rather than a performance question.
- When was this system's config last documented in a form someone else could pick up? "Documented" means another qualified person could take over in 2 weeks. A wiki page that hasn't been opened since 2023 doesn't count.
- What are the top 5 recurring pain points the super user has been meaning to fix? The ones the team hasn't got round to logging as tickets. This list tells you what work has been deferred off the record.
- What does the vendor relationship look like in practice? Who calls the vendor when something breaks? Who knows the roadmap? Who has the login for the vendor support portal? The vendor relationship is often the least-documented piece.
- What's the recovery time if this person left tomorrow? Be specific: how many days until new joiners could still be onboarded? How many weeks until reports would be reliable? How many months until the config would be fully understood?
Output: a one-page risk profile per system, ranked by criticality (how bad the failure would be) and exposure (how single-point-of-failure the current state is).
The handover playbook, if the notice has already landed
The standard handover plan won't cover the gap. Here's what usually needs to happen alongside it.
- A recorded config walkthrough per system, done live. The super user walks through every non-obvious configuration choice, explaining why. 4 to 6 hours of recording per system, indexed by topic. Written docs are useful; a recording is what someone actually watches.
- A structured shadowing period. Two projects the replacement runs while the super user watches, and two projects the super user runs while the replacement watches. Give it 8 weeks. Passive shadowing (sitting next to them for a month) doesn't build capability.
- A vendor relationship handoff meeting. Get the outgoing super user on a call with the vendor CSM to introduce their replacement. Email introductions get filed and forgotten; a live three-way call sticks.
- A documented list of "things I've been meaning to fix". Every super user has this list. Get it before they leave, prioritise it, and either work through it or make peace with deferring it consciously.
- A named backup contact from the vendor. Vendors often have a support engineer who has worked on your instance and knows the config. Ask for their name and get an introduction. This is the person who fills the gap if your replacement gets stuck in month.
When to bring in managed support
Sometimes the right answer is to stop trying to replace the role in-house. If your ATS has been managed by one senior person for 5 years, replacing them with an equally senior person may not be commercially viable, or the market rate for their replacement may be well above what you've budgeted for.
Managed support fills the gap. A partner or a specialised HR ops service takes ownership of the configuration work, with a named team rather than a single person, and with continuity that survives individual turnover on their side.
A word on Udder here. Assist is our HR ops managed service, which is exactly this. We don't lead with it in most conversations, but the super-user-leaves scenario is one of the situations where it usually earns its place, so it's worth naming in a piece that talks about the underlying problem.
The choice between rehiring and managed support is a continuity decision more than a cost decision. A managed service that costs slightly more than a full-time senior hire pays back in the reduced probability of ending up in exactly this situation again in 3 years.
The math on this is simple
The single-person risk in your HR systems is the most under-priced risk on the HR ops side. It sits below the radar because the system keeps working while the super user is there. It only surfaces as the config debt compounds after they've gone.
The audit costs a week of your team's time, and the handover playbook costs about eight, but either is cheaper than the 12-month drift that follows a bad handover.
Losing your super user, or worried you might be?
If your ATS or HRIS has been running on one person for a while and you'd like a second pair of eyes on the risk (or on the handover plan if the notice has already landed), that's the conversation we're having most often this quarter. Udder runs Assist, our HR ops managed service, and we've built an opinionated view of what a good handover looks like across the systems most mid-market HR teams operate.