Roles and Task Handoff Template — Mohamad Charafeddine

Why do tasks fall between people?

Most delays in small teams are not caused by laziness or lack of skill. They come from grey areas: a task everyone assumes someone else is handling, a file waiting for a review nobody knows they own, or a colleague who is away for a week and takes everything in their head with them. These problems repeat because roles live in people's heads, not on paper.

This template puts three things on paper: who owns each task and who reviews it (the responsibility matrix), how work moves from one person to another without losing context (the handoff note), and what someone does when they are stuck (the escalation path).

The core principle: every task has exactly one owner. Many people can help and others can review, but the person who gets asked "where are we?" is one person.

Part one: the responsibility matrix

The matrix is a table with one recurring task per row, defined by six elements:

Task: written as an action and a result, such as "publish the week's posts", not "social media".
Inputs: what must reach the owner before they can start, and where it comes from. Half of all delays come from missing inputs.
Owner: one person who does the work or makes sure it gets done.
Reviewer: who approves before the work goes out. If there is no review, write "none" explicitly.
Completion criteria: when do we call it done? A checkable description, not an opinion.
Backup: who takes over if the owner is away.

Add a frequency column (daily, weekly, monthly) if useful, and a "keep informed" column for people who need to know the result without being involved.

Steps to build the matrix

Collect the recurring tasks. Ask each member to list everything they did in the last two weeks. Merge the lists and remove duplicates.
Rewrite each task as action plus result. "Design" is not a task; "deliver the week's post designs" is.
Define inputs for each task. Ask: what must be in front of me before I start, and who gives it to me?
Put one name in the owner column. If you wrote two names, you have not decided yet.
Set the reviewer and completion criteria. A third person should be able to check the criteria.
Name a backup for every critical task, and walk the backup through it at least once before the team needs them.
Check the distribution. Does one person own half the tasks? Does a customer-facing task have no reviewer?
Review the matrix every three months or whenever someone joins or leaves.

Matrix template

Task	Frequency	Inputs (and source)	Owner	Reviewer	Completion criteria	Backup
[action + result]	[..]	[..]	[one name]	[name / none]	[checkable]	[name]
[action + result]	[..]	[..]	[one name]	[name / none]	[checkable]	[name]
[action + result]	[..]	[..]	[one name]	[name / none]	[checkable]	[name]

Part two: the handoff note

Handoffs happen in three situations: leave or absence, someone moving to a new role, or work moving between stages (from writer to designer, for example). The risk is always the same: the file moves but the context does not. A good note answers one question: can the receiver carry on without calling me?

Task handoff note

Handoff note — [task or file name]
From: [handing over]   To: [receiving]   Handoff date: [..]   Until: [return date / permanent]

1) Current status
   Done: [...]
   Remaining: [...]
   Next key deadline: [date + what must happen]

2) Where everything is
   Files: [link or folder]
   Accounts and tools: [tool + who grants access — never write passwords here]
   Open conversations: [with whom + last thing said]

3) Decisions already made — do not reopen
   [decision + who made it + why]

4) Waiting on others
   [what] — from: [..] — since: [..] — follow up on: [..]

5) Watch out for
   [risk, sensitive client, recurring error, exception]

6) Receiver's authority
   Can decide alone on: [...]
   Must check with [name] on: [...]

7) Contact while I am away
   Please contact me only if: [specific cases]   via: [channel]

Receiver confirms: I read the note and asked my questions on [date] — [name]

Never put passwords or access codes in a handoff note or any message. Give the receiver access in their own name from inside the tool, and remove it when it is no longer needed.

Part three: the escalation path

Escalation is not complaining and not failure. It is an organised way to move a problem to someone with the authority to solve it before time runs out. The trouble is that people either escalate everything at once or wait until the deadline has passed. An escalation path sets when, and to whom.

Escalation levels

Level	When	To whom	Time before moving up
0 — solve it yourself	A blocker you can solve or find the answer to	You, with a colleague if needed	[e.g. half a working day]
1 — direct lead	A blocker needing a decision or input beyond your authority	[team lead]	[e.g. one working day]
2 — decision owner	Affects budget, a final deadline, a client or the organisation's reputation	[manager / owner]	[e.g. same day]
Emergency	A public error, a data leak, a serious public complaint, risk to people	[decision owner directly, by phone]	Immediately

A good escalation message

Escalation message

Escalation — level [1/2/emergency] — [task name]
The problem (one sentence): [...]
Impact if unsolved: [deadline / client / budget affected]
What I have tried: [...]
Exactly what I need from you: [decision / approval / input / contact with someone]
Options I propose: (a) [...] (b) [...] — I lean towards: [..] because: [..]
I need a reply by: [time]

Worksheet

What are the five most frequent tasks in your team? Write them as action plus result.

Which task has more than one owner today, or none? Who should own it?

Which tasks reach customers or the public without review? Who should review them?

If your most important team member were away for a week, what would stop? Who is the backup?

Write your team's escalation levels: who is at each level, and what is the time limit?

Completed example

Illustrative example

Context: Mina Language Centre (مركز لغات الميناء), a small language school in El Mina, Tripoli. The marketing and registration team has three people: Hala (marketing coordinator), Jad (part-time designer) and Nadine (registration officer). The decision owner is the centre's director, Walid. Hala is preparing for two weeks of leave in the middle of registration season.

Responsibility matrix

Task	Frequency	Inputs	Owner	Reviewer	Completion criteria	Backup
Publish the week's posts	Weekly	Calendar from Hala, designs from Jad	Hala	Walid (only posts that show prices)	3 posts live on schedule and logged in the calendar	Nadine
Deliver the week's designs	Weekly	Copy from Hala by Sunday	Jad	Hala	Files in the required sizes in the shared folder by Tuesday	None (ready templates are used)
Answer registration enquiries	Daily	Approved course schedule and prices	Nadine	None	First reply the same working day	Hala
Update the course schedule on the page	Monthly	Schedule approved by Walid	Hala	Nadine	Published schedule matches the approved one exactly	Nadine
Weekly registration report	Weekly	Registration log	Nadine	Walid	Registrations by course and source sent on Monday	Hala

What the check revealed: Hala owns three of five tasks and is backup for two more, so her absence puts pressure on Nadine. Decision: two weeks of posts are prepared and scheduled before the leave, so Nadine's job becomes monitoring only.

Handoff note (short version)

Status: two weeks of posts are designed and scheduled. The "last chance to register" post waits for confirmation of the English course start date.
Where everything is: the shared "Marketing — Autumn" folder. Nadine has been given scheduling-tool access in her own name, to be removed when Hala returns.
Decision not to reopen: no discounts this season (Walid's decision, since classes are nearly full).
Waiting: English course date from Walid, since Thursday; Nadine follows up on Monday.
Watch out: if anyone asks about the children's French course, it is not approved yet; give no dates.
Nadine's authority: decides alone on moving post times. Checks with Walid on any text with a new price or date.
Contact: only if the files cannot be reached, by text message.

Escalation path

Level 0: Nadine tries for half a day (for example, a post failed to publish, so she reschedules it).
Level 1: not available during Hala's leave, so go straight to level 2.
Level 2: Walid, same day, for anything involving prices or dates.
Emergency: a post with a wrong price or a public complaint — Nadine hides the post immediately and calls Walid.

Common mistakes

Mistake: two names in the owner column "to collaborate". Fix: one owner; the other is a helper or reviewer.
Mistake: completion criteria like "nice designs". Fix: criteria a third person can check: files, sizes, deadline, location.
Mistake: a matrix written once and forgotten. Fix: review it every three months and whenever the team changes.
Mistake: handing over with "everything is in the folder". Fix: a note covering status, open items, decisions and authority.
Mistake: sending passwords in the handoff note. Fix: grant access in the receiver's name inside the tool and remove it later.
Mistake: escalating late out of embarrassment. Fix: a written time limit per level, after which escalating is a duty, not a choice.
Mistake: an escalation with no proposal. Fix: offer at least two options and say which you lean towards.

Completion checklist

Every recurring task is written as action plus result.
Every task has exactly one owner.
Inputs and their source are defined for every task.
Every public-facing task has a named reviewer.
Completion criteria can be checked by a third person.
Every critical task has a backup who has done it at least once.
No single person carries an unreasonable share of tasks.
The handoff note answers: can the receiver carry on without calling me?
No passwords in any note or message.
Escalation levels, time limits and people are written and known to all.
The next matrix review date is set.