Delegation of Authority Matrix: What Your Team Can Decide Without You

You handed your operations manager the supplier changeover three weeks ago, and this morning they asked whether they could accept the new price. A delegation of authority matrix stops that question reaching you, because assigning a task does not give someone permission to make the decisions inside it.

The task moved across to them, but the permission to decide stayed with you. A delegation of authority matrix is a short table that sets out which decisions each role can make, within what limits, and who decides when the usual approver is away. If you hand work over and it keeps coming back for a yes, this guide gives you the matrix, a way to set limits without guessing and a test to check it holds when you are not there.

Why does delegated work keep coming back?

Delegated work comes back for one of two reasons: the person does not know enough to decide, or they know enough but are not sure they are allowed to.

Both arrive on your desk as a question, but they need different fixes. Missing knowledge is fixed with context: the client's history, the last quote, the reason you dropped the previous supplier. Missing permission is fixed with a rule that says this role can decide this, up to here, under these conditions. More context does not help someone who already knows the answer, because they still need you to say yes.

The wording of the question usually tells you which one you are dealing with:

• "What did we do last time?" is missing knowledge.
• "Am I OK to go ahead?" is missing permission.
• "Which one would you choose?" is usually permission as well. The person has the options and a view, but no authority to pick.

Delegation is often treated as a personal skill an owner either has or lacks. Gallup's research on US employer entrepreneurs found that only one in four had high Delegator talent. That framing makes the problem sound fixed. We read it the way we read founder dependency: as a gap in how the business is set up rather than a personal failing, and a gap in permission closes once the permission is written down.

For one week, write down every question that comes back to you and mark each one as knowledge or permission. The permission questions are the first rows of your matrix.

What is a delegation of authority matrix?

A delegation of authority matrix is a table that lists the decisions in your business and, for each one, who prepares it, who approves it and where it goes when it falls outside the limits.

Larger organisations treat this as basic governance. In a 2025 EY study of more than 200 members of the Society for Corporate Governance, nearly 90 per cent of respondents had a delegation of authority policy. Those policies mostly cover spending, contracts and who can sign for the company. In a business of a dozen people, the decisions that stall work are smaller and far more frequent: a refund, a discount, moving a client's deadline, choosing between two suppliers, saying yes to a small extra.

Each decision in the matrix has three roles:

• Prepare: gathers the facts and makes a recommendation.
• Approve: makes the call and answers for it.
• Escalate: receives the decision when it falls outside the limits or fits no row.

Separating the roles is what lets work move. The person closest to the job can prepare almost everything, and once a decision has a named approver other than you, it stops landing on your desk by default. A job description says what someone is responsible for; the matrix says what they can decide.

What should your delegation of authority matrix include?

Every row of a delegation of authority matrix needs five things: the decision type, the authorised role, the conditions, the evidence and an alternate approver.

• Decision type: named so someone recognises it in the moment, such as "refund on a completed job" rather than "client issues".
• Authorised role: a role rather than a person's name, so the rule survives a resignation and does not add to your key person risk.
• Conditions: the limits and circumstances, such as a value, a type of client or whether the request sits inside an existing agreement.
• Evidence: what the approver must have in hand and record, such as the quote, the client's message or the reason for the exception, so the decision can be checked later.
• Alternate approver: who decides when the authorised person is away, unwell or the one making the request.

Conditions and the alternate approver do the most work. Without conditions, a limit is either too tight to use or too loose to trust. Without an alternate, every rule stops working the day its approver is unavailable.

The delegation of authority matrix template

Copy these fields into a shared document or a spreadsheet with one row per decision. They are the five fields above, plus the prepare and escalate roles and a review date.

• Decision type: [The decision, named the way the team would describe it.]
• Prepared by: [The role that gathers the facts and recommends.]
• Approved by: [The role that can make the call.]
• Conditions: [The value limit, and the circumstances in which the approval holds.]
• Evidence required: [What must be attached to or recorded with the decision.]
• Alternate approver: [Who decides when the approver is unavailable.]
• Escalate to: [Who decides when the request falls outside the conditions.]
• Last reviewed: [The date, and who reviewed it.]

An example row

• Decision type: a refund or credit on a completed job.
• Prepared by: the job lead, with the job notes and the client's message.
• Approved by: the operations manager.
• Conditions: up to the value of the original invoice, where the complaint is about our workmanship and the client is not in a payment dispute.
• Evidence required: the job notes, any photos and the client's message.
• Alternate approver: the office manager.
• Escalate to: the owner, for anything above the invoice value, any client in dispute, or any refund that would set a precedent for other clients.

How do you set approval limits without guessing?

Set each limit on the whole commitment a decision creates, not on the first invoice it produces.

A monthly software plan on a two-year term is a two-year decision. A discount given to one client becomes the price the next client asks for. Three checks keep the limits honest:

1. The whole commitment. Count every payment, renewal and follow-on cost the decision locks in, and set the limit on that total.
2. Existing obligations. Check what has already been promised: a client's agreed rates, a supplier's terms, a lease or a warranty. A decision that is small on its own can break a commitment made somewhere else.
3. Risk specific to your business. Ask what it would cost if the decision went wrong, and whether it could be undone. A credit note can be corrected next month; a promise made to a client in writing is much harder to take back.

To find a starting point, look back at the requests you approved last quarter. When nearly all of them went through unchanged, the limit sits lower than it needs to, and you are confirming decisions your team already makes well. Where you changed or refused many, the gap is usually knowledge, and the fix is context before authority.

What happens when the usual approver is unavailable?

A delegation of authority matrix that only works while you are reachable is a list of things to ask you about.

Test the matrix against three situations before you rely on it:

• Exceptions. A request sits just outside a limit or fits no row. The matrix should say who decides and what they record, so an exception does not quietly become the new rule.
• Temporary cover. When you or another approver is away, someone holds those approvals for a set period with set limits. Write down the start date, the end date and the limits, and tell the people who will be asking.
• Escalation. When neither the approver nor the alternate can decide, the request needs somewhere to go and a time by which it will be answered, so the client is not left waiting.

Our guide to a business continuity plan covers how to transfer authority with boundaries while you are away. We call the wider check the two-weeks test: what breaks if you take two weeks off? Approvals are often among the first things to break, because work that needs a yes stops when the only person who can give it is away. If you have come back from leave to a queue of requests waiting for you, you moved the work around rather than handing it over.

Before your next leave, take three real requests from last month, mark yourself unavailable and walk each one through the matrix. Any request that still comes back to you shows a missing row or a missing alternate.

Where should approval rules live?

Approval rules work when they sit where the decision is made, beside the quote, the job or the client record, rather than in a policy folder nobody opens.

Keep one current version of the matrix, dated, with old versions marked as replaced, and link to it from the places where people make the decisions it covers. Review it whenever a role changes. A new hire, a resignation, a promotion or a new service each changes who can decide what, and a matrix that still describes last year's team sends questions straight back to you. When someone leaves, check their rows first, because what they knew and what they were allowed to decide tend to leave together.

Record each decision with the evidence behind it. The next time a similar request arrives, the approver can see what was decided before, under which rule and why. This is the work Catalyst Systems builds for: Clearly captures what happens, connects what the business knows and gives people the context to make better judgements, so the decision and its reason are there when the next person needs them.

Start with the questions that came back to you this week. Sort them into knowledge and permission, write a row for each permission question, name an alternate for every row, and test it with yourself marked unavailable. Your team then decides within clear limits, and you see only the decisions that genuinely need you. Let the matrix answer first.