This RACI matrix template separates doing the work, answering for the result, giving input, and receiving updates. Use the filled publishing example to inspect a conflicting row and a separate row with two people doing the work.
Keep the role legend beside the work
Atlassian's RACI guidance describes the roles and recommends reviewing gaps and overlaps with the team. Use these meanings in this example:
| Letter | Role | What it means here |
|---|---|---|
| R | Responsible | Does the assigned work. More than one role can contribute to a deliverable. |
| A | Accountable | Answers for completion and guides the relevant decision. This example requires exactly one A per deliverable. |
| C | Consulted | Provides relevant knowledge or advice before the work or decision that needs it. |
| I | Informed | Receives the information needed to stay aware of the work or outcome. |
The example's row convention is exactly one A and at least one R. These are the rules its local check applies. Confirm your organization's convention and the actual decision authority before adapting the matrix. A letter typed into a page does not assign authority by itself.
Read a filled deliverable-by-role matrix
The original fictional example concerns a small publisher preparing an essay collection. The four roles and assignments are proposed teaching material. No release or role agreement has occurred.
| Deliverable | Managing editor | Copyeditor | Designer | Production lead |
|---|---|---|---|---|
| D1 · Manuscript brief | A | R | C | I |
| D2 · Copyedited text | A | R | I | C |
| D3 · Cover proof | A | C | R | A |
| D4 · Release package | C | R | R | A |
The copyeditor prepares D1's brief under the managing editor's accountability. For D2, the copyeditor does the text work, while the production lead provides input relevant to preparation for production. The different assignments should reflect the actual work each row names.
D3 deliberately contains a conflict: both the managing editor and production lead have A. D4 has a different pattern: the copyeditor and designer both have R, with the production lead as the single A. Under this example's convention, D4 can have two contributors doing different parts of the work.
Select D4 · Release package to inspect its assignments. Before using a real version, describe the copyeditor's and designer's contributions so “both Responsible” does not hide a handoff between them. An agreed matrix still benefits from an actual task description.
Resolve the conflicting row with the team
Choose D3 · Cover proof, then choose Check row. The example identifies the two A assignments. It should name the managing editor and production lead so the team knows which arrangement needs discussion.
For this teaching exercise, a proposed revision makes the managing editor the single A and changes the production lead to I. The designer remains R and the copyeditor remains C. Select Load proposed revision to see that row, then check it again.
The revised row satisfies the stated count convention. It remains a proposal. In a real project, ask whether the managing editor has the relevant authority and whether production needs to contribute before the cover decision. If production advice is needed, C may describe that work more accurately than I. Agree that distinction with the people involved instead of letting the template choose it.
You can also change the selected row's proposed letters yourself. Remove its R assignment and check it to see the missing-doer warning. Editing an assignment clears the previous check result, so an earlier result cannot describe a different row state.
Discuss the matrix in both directions
Read across each deliverable first. Who does the work? Who answers for completion? Whose advice is needed before that decision, and who needs to hear the result?
Then read down each role's column. A person shown against many deliverables may need to discuss capacity and timing. The number of letters alone does not measure workload: reviewing a short brief and assembling a release package can require very different effort.
Keep consultation purposeful. Give a consulted person the question and the point in the work when their answer is useful. Being consulted does not make them an additional approver. Likewise, an informed recipient is not assumed to have accepted responsibility or approved the outcome.
Once the team agrees the assignments, connect them to the actual task and decision records. Use the matrix to clarify those arrangements, while keeping completion evidence and work scheduling where the team maintains them.
Copy a prompt for your own responsibility matrix
Create one complete HTML RACI responsibility matrix.
Project and bounded deliverables: [PASTE]
Roles and the actual authority each has: [PASTE]
Proposed assignments by deliverable and role: [PASTE]
Our R/A/C/I definitions and row convention: [PASTE]
Questions, unresolved assignments and team-review arrangements: [PASTE]
Use my supplied assignments and definitions. Do not infer a person's
authority from a title or turn proposed letters into an agreement.
Show the role legend beside the matrix. Distinguish consultation
from approval and information from responsibility. Keep stable
deliverable and role IDs. Explain gaps using the convention I supply.
Include this separate original fictional publishing example:
A small publisher is preparing an essay collection.
Roles in column order: Managing editor; Copyeditor; Designer;
Production lead.
D1 Manuscript brief: A, R, C, I.
D2 Copyedited text: A, R, I, C.
D3 Cover proof: A, C, R, A.
D4 Release package: C, R, R, A.
All assignments are proposed teaching material, not team agreement.
Definitions for this exercise:
R does assigned work; several roles may do different parts.
A answers for completion and guides the relevant decision.
C supplies relevant knowledge/advice before work or decision.
I receives relevant information about the work/outcome.
Exercise convention: exactly one A and at least one R per row.
Multiple R is allowed; do not flag D4 as invalid for having two R.
Provide a selected-deliverable control and labeled assignment
controls for its four roles, with Unassigned, R, A, C and I choices.
Show the whole matrix and selected row explanation. Check row must
name every issue under the exercise rule: no A, multiple A, no R.
Report the accountable roles by name when more than one A is set.
Do not silently change assignments to make them pass.
Edits must update that row and clear stale check feedback.
Load proposed revision applies only to D3: A, C, R, I.
It must remain labeled proposed, even when it satisfies the rule.
Restore example restores all four original rows and clears feedback.
Include a blank scaffold for my actual project. No approval button,
automatic owner choice, messaging, integrations or completion claim.
Use at least 16px body text, native labeled controls and visible focus.
Keep role and deliverable labels readable at 720px; at 360px use
labeled records without horizontal page overflow. Keep CSS and
JavaScript in the file, no external assets, network or storage.
State that changes to this open example are temporary. Return the
complete HTML and the responsibility questions the team must settle.
Try a row with two A assignments, a row without R, and the supplied D4 row with two R assignments. The checks should explain the first two problems and allow D4 under the exercise rule. A successful count check still needs a conversation about the actual work and authority.
Give contributors the work description as well as the letters
Put the HTML matrix in your NOS workspace when contributors need to read the assignments beside the legend. Ask the managing editor and production lead what decision D3's A actually covers before accepting the proposed revision.
If “Release package” means different things to the copyeditor and designer, clarify its static description in visual editing mode. Save the wording so both can reopen the existing link and read the same definition. Changing a description does not reassign work in a separate task system or change the example's programmed assignment controls.
Record the agreed roles in the team's maintained plan, then tell contributors which handoffs and decisions belong to them. Return to the matrix when the deliverables or decision authority change.