A customer signs, sales sends a message, and delivery waits for a brief nobody agreed to write. The founder steps in, but the same argument returns with the next customer. Everyone knows the job matters. They disagree about who is supposed to move it forward.
A RACI matrix for small teams makes those responsibilities visible. It maps work against four kinds of involvement: responsible, accountable, consulted and informed. Start with one recurring workflow, use the example below to expose gaps, and copy the blank template into a shared document. If agreeing decision rights is the hard part, fractional COO services are one way to discuss help with the operating process.
1. Name the ownership dispute before drawing the matrix
Write the problem as an observable event: delivery receives a signed agreement without an accepted scope, or a launch waits because two people think the other can approve it. Avoid broad labels such as poor communication. The matrix needs to settle a decision someone can recognize.
Choose a start and an end. For a customer handoff, the start might be a signed agreement available for review. The end might be a delivery owner accepting the brief and taking responsibility for the next customer update. Keep prospecting and renewal out of this first map.
List the outputs between those points. Use rows such as prepare the delivery brief, approve an exception and accept the handoff. A row called manage customer is too broad to reveal which action is missing. A row for every message is too detailed to keep current.
Bring the people doing the work into the discussion. Ask what they think they own today, where they wait, and which decisions they cannot make. This is part of growth operations: turning recurring work into an agreed process rather than relying on the founder to interpret every situation.
2. Separate responsible from accountable
Asana's RACI guidance describes responsible as the person executing the task and accountable as the person with decision authority. It also distinguishes people consulted before delivery from people informed about progress. You can use those distinctions without using Asana.
- R, responsible: prepares the output, coordinates any contributors and raises a blocker.
- A, accountable: owns the decision to accept the output and can resolve a disagreement within the agreed scope.
- C, consulted: supplies input needed before the decision. State what input is required and when.
- I, informed: receives a relevant update. Receiving it does not create another approval gate.
For this template, use one accountable person and one clear responsible lead per row. Other people can contribute, but the row should still answer who moves it next. This is a working convention for a small team, not a claim that every organization uses identical RACI rules.
Responsible versus accountable becomes clearer when work is rejected. The responsible person revises the brief. The accountable person explains the acceptance decision and resolves the scope question. Neither letter means blame for every upstream problem. A person also needs the access, capacity and authority to fulfill the role.
3. Copy this small-team RACI matrix example
Hypothetical example: a founder, a sales lead and a delivery lead handle a new customer. These are roles, not claims about an actual client. A blank cell means no standing involvement is required for that row. R/A means the same role performs the work and accepts the result.
| Output or decision | Founder | Sales lead | Delivery lead |
|---|---|---|---|
| Prepare scope and promise record | I | R/A | C |
| Decide an exception to standard scope | A | R | C |
| Accept the delivery handoff | C | R/A | |
| Send the agreed kickoff update | I | R/A |
Read each row aloud as a sentence. Sales prepares the promise record, asks delivery for feasibility input and keeps the founder informed. Delivery accepts the handoff once the required information is available. The founder decides only the scope exception, rather than approving every routine handoff.
Copy this blank version for your own workflow. Replace each blank with a role assignment, or deliberately leave it empty. Keep a separate role-to-person key so the team can identify the current person behind each column.
| Output or decision | Role 1 | Role 2 | Role 3 |
|---|---|---|---|
| [First output] | [R/A/C/I or blank] | [Assignment] | [Assignment] |
| [Acceptance decision] | [Assignment] | [Assignment] | [Assignment] |
| [Exception decision] | [Assignment] | [Assignment] | [Assignment] |
Add a short note beneath your copy: workflow name, start event, end event, matrix owner, role holders, backup arrangements and review date. Keep deadlines and acceptance criteria alongside the workflow instructions. The letters alone cannot explain when an output is ready.
4. Resolve missing owners and overlapping approvals
Find rows with no R or A
Ask who will do the work and who can accept it. Assigning everyone as consulted leaves both questions unanswered. If nobody has capacity, record the resourcing decision instead of hiding it behind a letter.
Split decisions that need different authorities
If sales and delivery both appear as accountable, check whether one row contains two decisions. Commercial scope acceptance and delivery readiness can be separate rows with separate accountable people.
Combine roles deliberately
A founder may also be the sales lead. Use R/A where that person does and accepts the work. Do not invent another approver merely to fill a column. Preserve any real requirement for independent review.
In the hypothetical handoff, suppose sales marks the brief complete but delivery cannot schedule work because a promised custom feature is unresolved. Keep the handoff unaccepted, route the exception to the founder, and record the decision in the brief. Do not silently treat a sales update as delivery approval.
Also scan columns. If the founder is accountable for every row, ask which decisions actually need founder authority. Change authority explicitly before changing letters. A matrix cannot delegate a decision the founder still expects to make privately.
5. Connect responsibilities to the actual handoff
Put a link to the matrix where work starts. For each row, document the trigger, required input, acceptance evidence and escalation route. The sales-to-success handoff guide covers the customer context that must travel between owners; the matrix assigns responsibility for preparing and accepting it.
Use the SOP writing template for the procedure itself. RACI says who participates. The SOP says how the task is done and what good completion looks like. Keeping those documents connected avoids competing instructions.
Agree what happens if a consulted person is unavailable or an accountable person is away. Name a backup and explain which decisions the backup can make. Do not turn silence into approval unless the team has explicitly agreed that rule for that decision.
When ownership is clear but a step still fails, examine the work itself. Missing information, incompatible systems or an impossible dependency may need process improvement. Reassigning a letter will not repair a broken input.
6. Review the map when the work changes
Walk a real work item through the proposed matrix before adopting it. Ask each role holder what they would do next, what evidence they would expect and where they would escalate a disagreement. Revise any row that produces different answers.
After use, review unaccepted handoffs, disputed decisions and work that still needed the founder to intervene. These observations show where to inspect the process. They do not prove that RACI caused a performance improvement.
Revisit the map when a role changes, the offer changes or an exception becomes routine. Keep one current copy and a brief change note. If the workflow has only an obvious owner and no approval or consultation ambiguity, an owner-and-backup list may be enough. Maintain the smallest map that answers the team's actual questions.
Start with one disputed workflow. Give each output a responsible lead and an accountable decision owner, distinguish input from updates, and agree how exceptions move. Then connect the matrix to the procedure people use.
FAQ
What is a RACI matrix for a small team?
A RACI matrix maps a workflow against team roles. Each row names who does the work, who accepts the result, whose input is needed and who receives an update. Use it for a specific ownership problem rather than every task in the business.
What is the difference between responsible and accountable?
Responsible means doing the work and moving it forward. Accountable means owning the decision that the result is acceptable. In this working approach, each row has one accountable person and a clear responsible lead.
Can the same person be responsible and accountable?
Yes. Mark R/A when one person both performs the task and accepts the result. Use a separate reviewer where your actual approval or control requirements call for one, and make that requirement explicit.
Can a RACI matrix have two accountable people?
For this template, choose one accountable person per row. If two people must approve different decisions, split the row into those decisions. Where a real joint approval is required, document the approval sequence separately.
When is RACI unnecessary?
An owner list may be enough when everyone already knows who acts and no consultation or approval dispute exists. Use RACI when the confusion involves several kinds of participation, and keep the scope small enough to maintain.
Need help agreeing who owns the next step?
Bring one recurring handoff or approval problem. We can discuss the ownership gaps, the decisions involved and whether a focused operations engagement would fit.
Book a Call