An absence cover arrangement defines who takes over a task and for how long. It does not answer the decisive question: how that task is actually carried out. That is where cover arrangements fail — not for lack of a name in the calendar, but for lack of knowledge about the real execution.
Standing in for someone is one of the oldest organisational questions and one of the most consistently underestimated. It gets settled in the calendar, in the org chart, and sometimes in an email before a holiday. What none of that settles is the actual problem: the person covering doesn’t know how the person being covered really does the job.
Every time Maria is on holiday, something goes wrong. She does it differently from what we wrote down — but nobody knows how.
That sentence describes precisely what happens weekly in many companies: cover rules exist on paper. The knowledge about actual execution lives exclusively in the head of the person who isn’t there.
Why absence cover rules alone aren’t enough
A cover arrangement answers two questions: who takes over, and for which tasks. It doesn’t answer: how is this task actually done?
If the process is properly documented and that documentation matches what is actually done, cover is manageable. The new person reads, executes, asks when something is unclear. If the documentation is outdated — or doesn’t exist — all that remains is informal knowledge. The stand-in asks colleagues, searches internally, tries to reconstruct a workflow from emails. Or improvises.
The result is predictable: errors, delays, unhappy clients, rework.
The real problem: roles aren’t documented per step
Most process documentation describes what has to be done. It rarely describes who performs each step — and more rarely still in a form a stand-in can actually work from.
A process step called “check and approve invoice” implicitly contains: who checks? Against what criteria? Which system gets opened? What happens if the invoice is wrong? Who does it escalate to? What are the exceptions?
For someone who does this daily, these aren’t questions — it’s automatic behaviour. For the stand-in doing it for the first time in months, it’s an ambiguous situation with several branches.
Absence cover planning with and without a system
| Without a system | With documented processes | |
|---|---|---|
| Handover | Depends on the memory and availability of the absent person | Structured, from current process documentation |
| Error risk | High — deviations from the documented state are unknown | Low — work follows the actual state, not an outdated version |
| Ramp-up time | Days per cover situation | Hours — process steps with role assignment available immediately |
| Key-person dependency | Critical — the knowledge sits with whoever is away | Low — process knowledge is externalised |
What handover-proof process documentation contains
Documentation that enables cover differs fundamentally from documentation that merely satisfies a compliance requirement. For each step it contains:
Responsibility
Who performs this step? Who covers? Is there a second line of cover?
Concrete execution
Which system, which path, which input screen. Not “open the CRM”, but the actual click path to the right view.
Exceptions and escalation
What happens when the standard case doesn’t apply? Who does it escalate to? What is the exception rule?
Change status
When was this step last changed, and by whom?
The difference between documentation that contains these four points and documentation that doesn’t determines whether cover works or gets improvised.
Three steps to reliable absence cover
Identify the critical gaps
Which processes regularly go wrong when a particular person is away? These aren’t weaknesses of those individuals — they’re knowledge gaps in the system. Note the five most critical ones. Which tasks structurally depend on single individuals is what Skill Audit makes visible.
Document the actual state, not the target state
Have the person who performs the process daily document it themselves — not as it ought to be, but as it actually runs. That is the only way to get documentation that holds up when it matters.
Test the documentation with a real stand-in
Give it to someone who doesn’t know the process. Can they execute it? Where do they get stuck? Those points get added immediately. A process that fails an internal test will fail a real cover situation too.
Who keeps the documentation current?
Documentation nobody maintains diverges from reality over time — and in a cover situation that’s more dangerous than having none, because people rely on it. Why this happens and how to prevent it systematically is covered in our article on process documentation.
For absence cover itself, Lars, one of Kollegia’s Digital Colleagues, takes on the tasks nobody otherwise tracks: it points out processes with no cover assigned, flags steps whose responsible role has changed, and assembles the relevant process descriptions for handover when an absence is scheduled.
Three principles
- Permission intersection — a digital colleague never sees more than the person it works for. Process documentation often contains sensitive internal workflows; access follows existing permissions exactly.
- Fail-closed — when in doubt, nothing happens. If it’s unclear whether a change is correct, it’s submitted for review rather than applied automatically.
- Audit trail — every change is logged: when, by whom, on what basis. That keeps it traceable which version a stand-in actually followed.
Absence cover as a leadership task, not a calendar question
Knowing which people genuinely command which processes means cover can be planned rather than distributed. That overview is also the basis for deliberate competence development: it shows not only who can step in today, but where a backup still has to be built. The skills matrix provides the underlying data.
FAQ
Source: ISO 9001:2015 – Quality management systems, Requirements, ISO.
Handover-proof process documentation describes each process step in enough detail that an unfamiliar person can execute it without asking questions. It contains not only the activity, but the responsible role, the specific system, the decisions to be made and the contacts for exceptions. The decisive difference from ordinary process descriptions: it reflects the actual current state, not what was written down at some point in the past.
With current process documentation, a structured handover for one process area shouldn’t take longer than 30 to 60 minutes. The documentation provides the foundation; the conversation only covers exceptions and current specifics. If a handover takes hours or days, that’s a reliable signal of missing or outdated documentation.
Prioritise by frequency and criticality. Processes that run daily and have direct client impact when they go wrong come first. Then processes with long lead times — compliance-relevant workflows, for instance — where an error only becomes visible weeks later but is harder to correct by then.
No. The org chart answers the question of responsibility, not execution. It says who steps in — not how the task actually gets done. Together the two make cover work; the org chart alone merely moves the problem to a different person.
