Someone’s leaving Friday. Emily already knows what they forgot to hand over.

The operational problem

Most handovers are a rushed document written the night before someone leaves, from memory, under pressure. It lists what they could remember — not what the business actually depends on them for. Then the person is gone, the questions start, and the team spends the fortnight reconstructing context from threads and guesswork.

What Emily watches

• Open tasks and deadlines that fall inside the absence window
• Approvals that will be requested while the person is away
• Invoices sent, expected or overdue on their projects
• Documents referenced in recent threads that nobody can locate
• Work with no confirmed owner once they leave
• Client commitments made in email or messages but not yet scheduled

What Emily produces

• A handover briefing built from the actual state of the work, not memory
• A named owner, or a flagged gap, for every open item
• Daily cover notes for whoever is holding the fort
• Drafted follow-ups and chase messages, held for approval
• A return briefing: what changed, what was decided, what needs them first

The working view

What remains human

• Nothing is sent without a person approving it
• Ownership is proposed, never assigned automatically
• The person on holiday decides what escalates to them, and what waits

Indicative implementation

A configuration like this begins with an audit of how the work actually moves, followed by a focused build against the systems involved, then ongoing care as tools and people change. Scope and timeline depend on the systems, access and approval rules of the business.

How the three stages work →