A meeting can end with everyone nodding and nobody holding the same picture of responsibility. One person heard “Maya will lead.” Another heard “Maya will draft.” A third assumed the legal review was already assigned. The notes may contain all three interpretations without showing which one was actually accepted.
A responsibility matrix is a compact way to turn those role signals into a record the team can verify. The purpose is not to force every project into a rigid acronym. It is to make five things visible: the work, the primary owner, the people who contribute, the person who reviews or approves, and anyone who must be kept informed.
This workflow applies only to notes you are permitted to use. Remove unnecessary personal, confidential, or sensitive details before sharing a matrix beyond the original working group.
Start with work, not job titles
Job titles describe a position. A responsibility matrix describes who does what for a specific piece of work. Atlassian’s roles-and-responsibilities guidance separates roles from responsibilities and recommends documenting agreed roles, finding unassigned work, and resolving overlap. The GOV.UK Service Manual likewise describes different responsibilities for product, service ownership, delivery, research, content, design, and development roles. The practical lesson is simple: do not assume a title proves ownership of a task.
First list concrete outputs or decisions. “Newsletter launch” is too broad. “Draft launch email,” “approve claims,” “configure send,” and “review results” can each have different owners.
Use a five-column evidence pass
| Field | Question to ask | Good evidence in notes |
|---|---|---|
| Work item | What observable output or decision is being assigned? | “Prepare the final launch email.” |
| Primary owner | Who accepts responsibility for moving it to completion? | “Maya owns the final draft.” |
| Contributor | Who supplies input or does part of the work? | “Jon will provide product screenshots.” |
| Reviewer | Who checks or approves before release? | “Legal reviews the claims before scheduling.” |
| Informed | Who needs the outcome or a status update? | “Support receives the final send date.” |
If the notes do not provide evidence for a field, write unconfirmed. Do not fill the gap with a familiar org-chart assumption.
A fictional example
The following notes are fictional and exist only to demonstrate the method:
“Maya can pull the launch email together. Jon has the approved screenshots. Priya wants to see the claims before anything is scheduled. Let support know once the send date is locked. We still need someone to check the audience segment.”
A first pass might produce this draft:
| Work item | Owner | Contributor | Reviewer | Informed | Status |
|---|---|---|---|---|---|
| Final launch email | Maya | Jon: screenshots | Priya: claims | Support | Needs confirmation |
| Audience segment check | Unconfirmed | Unconfirmed | Unconfirmed | Maya | Role gap |
The matrix does not pretend the second row is solved. It makes the gap visible before the team treats the task as assigned.
Separate a proposal from an accepted role
Modal language matters. “Maya can,” “Maya could,” and “Maya will” are not equivalent. A note that proposes a person is evidence of a candidate, not proof of acceptance. Add a confirmation state to every row:
- Confirmed: the named person accepted the role.
- Proposed: the notes nominate someone, but acceptance is absent.
- Disputed: two interpretations or owners conflict.
- Unassigned: the work is visible but no owner is named.
This is especially important when meeting summaries compress uncertainty. If you first need to distinguish statements from requests and constraints, use the stakeholder-notes classification workflow before assigning roles.
Run four conflict checks
- Two primary owners: decide whether the work should be split or one person should become the single coordination owner.
- Owner and reviewer are the same: confirm that self-review is acceptable for this risk level.
- Reviewer appears after the deadline: move the review checkpoint earlier or change the plan.
- No one accepts the work: keep it unassigned and name the person responsible for resolving the gap.
A matrix should expose disagreement, not bury it. If the group made an actual choice about responsibility, record the rationale and date in a decision log.
Keep the source trail
Every row should link back to the permitted note, transcript segment, or follow-up where the role was stated or confirmed. Store only the minimum source context needed to understand the assignment. A useful source field contains the meeting date, the relevant section or timestamp, and the confirmation message when one exists.
When a role changes, preserve the previous state and add the new owner, effective date, and reason. Replacing the old name without history makes later review harder.
Copy-ready responsibility matrix
| Work item | Primary owner | Contributors | Reviewer/approver | Informed | Source | Confirmation | Next check |
|---|---|---|---|---|---|---|---|
| [specific output] | [one owner or unconfirmed] | [names and contributions] | [name or unconfirmed] | [people/groups] | [date + section/timestamp] | [confirmed/proposed/disputed/unassigned] | [date + person] |
Keep the matrix close to the work. Review it when scope changes, a named person becomes unavailable, a deadline moves, or an unassigned row blocks progress.
A 10-minute closeout routine
- List the concrete outputs and decisions mentioned in the notes.
- Extract only explicit role evidence.
- Mark uncertain assignments as proposed or unconfirmed.
- Run the four conflict checks.
- Ask each named person to confirm or correct the row.
- Assign a follow-up owner for every unresolved gap.
Try it now: take one permitted meeting note, build one responsibility row, and ask every named person to confirm or correct it before the work is treated as assigned.
