A Coverage Plan for a Twelve-Person Team (Template)

Twelve people is the size where coverage stops being obvious and starts needing a plan. Below that, everyone knows who does what. Above it, you have structure. At twelve you have neither, which is why most teams this size have a coverage spreadsheet that has not been opened since January.

"Coverage is a spreadsheet nobody opened since January."

Why the coverage spreadsheet dies

Three reasons. It lives in a file, so consulting it requires a deliberate act at a moment when someone just wants a quick answer. It is too detailed, usually attempting to describe responsibilities rather than route questions. And it is not used in the ordinary course of a week, so its errors are only discovered during an absence, which is exactly when nobody has time to fix them.

The fix is to make it a table small enough to live in a channel topic or a pinned message, and to make it about routing rather than about roles.

The table

Person	Area	Questions go to	Decisions go to	Limit
Ana	Payments	Her StandIn, then Marek	Marek	Refunds to 500 EUR
Marek	Platform	His StandIn, then Ana	Ana	No new dependencies
Priya	Data	Her StandIn, then Tomas	Tomas	Schema changes, not deletions

Three rows shown; you need twelve. Five columns is the whole plan, and it should fit on one screen without scrolling horizontally, because that is the version people actually read.

The column most plans miss

Standard coverage plans have a backup column and nothing before it, which means every question during an absence goes to a human. That human then spends the fortnight answering things about someone else's work, most of which are retrieval, as covered in covering for someone on leave.

Adding a first route changes the arithmetic. Each person confirms a ninety-second brief at the end of their day, mostly pre-drafted from the work they already did. While they are off, their StandIn answers questions from it in their words, with a source under every answer, clearly labelled, and never guessing. When the answer is not in the record it says so and names the human backup, which is exactly the escalation the second half of the cell describes.

Written out as "her StandIn, then Marek", the routing is obvious to anyone reading the table under pressure, and the human backup only hears about the things that genuinely needed them. See retire your out-of-office.

Writing decision limits that work

Limits must be specific enough to apply without a conversation. Two rules: use numbers wherever numbers exist, and describe the boundary rather than the permission.

"Refunds to 500 EUR" works. "Can handle routine refunds" does not, because nobody knows what routine means and the backup will ask, which is the interruption the limit existed to prevent. Where a number is not available, name the category: "schema changes yes, deletions no".

Also write what happens beyond the limit. "Above 500, it waits and the customer gets a date" turns an unresolved item into a managed one, and stops the backup from either exceeding their authority or leaving a customer in silence.

Keeping it current

Do not review it quarterly. Review it on two triggers: when someone books leave, and when someone joins or changes area. Both are moments when the plan is actually being used or invalidated, which is when a review has a chance of happening.

One extra practice pays for itself. Once a quarter, pick a row and have that person take a day off without announcing it in advance. Then see whether the routing in their row actually worked. It is a cheap test and it finds the rows that are aspirational.

Common Questions

What should a team coverage plan include?

Five columns: person, area, where questions go first, who decides, and the decision limit. Keep it to one screen. Longer plans describe responsibilities, which is a different document nobody reads during an absence.

Where should the coverage plan live?

In the channel topic or a pinned message, not in a file. The moment consulting it requires opening something, people will ask a colleague instead and the plan stops being the routing mechanism.

How often should coverage plans be reviewed?

On event rather than on schedule: whenever someone books leave, and whenever someone joins or changes area. Calendar-based reviews get skipped because nothing is visibly broken at the moment they fall due.

What about a twelve-person team across time zones?

Add the time zone to each row and check that no area has all its coverage in one zone. A backup who is asleep during the asker's working day is not coverage for that half of the day.