Delegation of authority for a small team: who approves what at each dollar limit, and the row for the AI agent in Slack
If you run a firm of 5 to 100 people on Slack, you are probably the default approver for every purchase, refund, discount, contract and hire, because nobody ever wrote down who else may approve what. A founder-led company tends to work this way by default, and the cost shows up two ways: requests queue behind you, or, when you are away, people spend without sign-off. A delegation of authority table fixes both. This guide gives you a three-tier table sized for a small team, the rules that stop it decaying, how each tier runs through an approval in a Slack thread, and one extra row for the AI agent in your workspace. The amounts are made up for illustration, so copy the structure and replace the numbers.
The one-page answer
Write one table with three tiers, a limit in every cell, and a named person and a named backup for every tier. Then apply five rules:
- Tiers are cumulative: whoever sits higher may approve everything the tier below may, plus more.
- Nobody approves their own request.
- A limit measures the total commitment over twelve months, not one invoice or one month.
- Delegation passes one level, in writing, with an end date.
- Some rows have no dollar limit at all: they always go to a named person.
The sections below give the reason for each rule and show it running in a Slack thread, where your approvals already happen.
Try Kipwise Agent free in Slack: mention it once in a thread and it does the repetitive work, with your permissions.
Why founder-approves-everything happens, and why the usual guides do not fit
A delegation of authority (DoA) matrix is a documented schedule of who may approve what, up to which limit. It is also called an approval matrix or a signing authority table. It comes from internal control, where authorizations and approvals are a standard control activity and the people who authorize, record and handle a transaction should be different people, a point Rework's guide takes from a university's summary of the COSO framework. The Journal of Accountancy, the AICPA's magazine, summarizes COSO's guidance for smaller public companies and advises its readers to have managers separate cash payments from access to inventory, purchases and fixed assets.
The guides that rank for this phrase are built for companies with a team lead, department manager, director, VP, CFO and board. Tallyfy's sample tables give a team lead $500 for office supplies and let a CFO approve capital spend up to $1M. AutoPayables starts at $1,000 for a team lead and ends above $250,000 for the CEO. If your firm has twelve people and one operations lead, you have at most three real tiers, and a six-rung ladder tells you nothing about who approves a $1,800 software renewal on a Tuesday.
The same guides share a second gap. They say a matrix fails when nothing enforces it, and AutoPayables and AptlyDone point to workflow software as the fix. None of the four mentions Slack, which is where a firm your size actually approves things. A rule that lives in a PDF while the decision happens in a thread loses to the thread every time.
Build the table from the last three months of approvals
Do not start from a template. Open the last three months of things you approved: Slack threads, emails, card statements. Sort them into five groups: spend, refunds, discounts, customer contracts and hires. Rework suggests three or four levels is enough for a company below 100 people, and that thresholds should come from the real distribution of past approvals, so most routine items fall under the lower tiers and you only see the minority that matters. AutoPayables warns about the opposite mistake: limits set so low that senior people spend their week on small items and stop reading them, which leaves evidence that a review happened when none did.
Here is a made-up starting table for a firm of about 25 people. Every number is illustrative. Replace each one with what your own three months show.
| Decision | Budget owner | Operations lead | Founder |
|---|---|---|---|
| Software and operating spend, total over 12 months | Up to $500 | Up to $5,000 | Above $5,000 |
| Refund to one customer | Up to $100 | Up to $1,000 | Above $1,000 |
| Discount off list price | Up to 10% | Up to 20% | Above 20%, or any free period |
| Customer contract, standard terms, annual value | Not allowed | Up to $10,000 | Above $10,000 |
| Customer contract, non-standard terms | Not allowed | Not allowed | Always |
| New hire inside the approved budget | Recommends | Approves | Approves senior roles |
| New vendor, or any change of a vendor's bank details | Not allowed | Not allowed | Always, with a callback |
A limit measures the commitment. Measure every limit against what the purchase commits you to over twelve months, because a monthly fee that looks small is the real size of the decision. AutoPayables makes the same point: a $4,000 monthly retainer is a $48,000 annual commitment that nobody formally approved. Rework gives the same example: a $9,000 monthly subscription is not a $9,000 decision. At small-firm scale the same trap shows up with a $150 a month tool. It looks like a budget owner's purchase and it is an $1,800 decision for the operations lead.
Some rows have no dollar limit. A small contract that grants a customer exclusivity can be riskier than a large one that does not, so Rework recommends risk triggers on top of amounts. The last row follows AutoPayables' reasoning: changing a vendor's bank account is not a spend decision, but it is among the most dangerous actions in the payment process. Give it senior approval plus a callback to a phone number you already had on file, never one from the email that asked for the change.
The top tier needs a named person. If the founder is the only one in the third column, the table needs a named backup, which the next section covers.
The rules that keep the table from decaying
Tables decay in four predictable ways. Each has a one-line rule.
Split purchases. The moment you set a $500 limit, someone submits two $450 requests. Rework calls it the classic way matrices get gamed, and AutoPayables calls it the loophole every matrix creates. The rule: approve against cumulative spend with the same vendor over twelve months, and let the approver ask "is this the second one?" Make that a standing question on every request.
Self-approval. A request and its approval must come from different people. If the operations lead buys a tool for $4,000, the founder approves it, and the other way round. Rework asks for this rule, plus a second signature at the top tier.
Absence. When the approver is away, a delegate is allowed one level only, in writing, with an end date, and never for approving their own expenses. Tallyfy's example rule sends a request to the next level when the primary approver has been unavailable for 48 hours or more. Copy the idea without the automation. Put the backup's name in the table next to each tier, and decide who reroutes a stuck request. For the clock on a silent approver, see our guide to approval requests for a small team.
Informal exceptions. AptlyDone points to an exception process that runs on email and verbal approvals with no audit trail as a leading sign of a failing program. Give urgent spend a defined path: someone at the right tier approves it first, and a named person reviews it afterwards.
How each tier is carried by a Slack thread
The table does nothing until a request in a thread points to it. Here is the thread, with a made-up request:
> Maya: Can I renew the design tool for $1,800 a year? Category: software. Tier: operations lead. Approver: Sam.
The message states the amount as a twelve-month figure, writes the tier next to it and names the approver. Write the tier on the request itself, because a person, not the agent, has to decide which tier an amount falls in. Nothing in the Kipwise agent's documented behavior picks a tier from an amount, so this article does not assume it does. Maya reads the table, finds the row, and states her tier. Sam's first check is whether she read it correctly. If she wrote "budget owner" for $1,800, Sam sends it back, and the mistake costs ten seconds instead of an audit finding.
The Kipwise agent's request desk can make a request wait for someone's approval first. The approver gets a private card in their own chat with the agent, with Approve and Reject buttons. The first press decides, the requester is told in a line under their request card, and anyone who presses later is told who decided. A lost card comes back from the "Send me the approval again" button in the approver's App Home. When a request is about to miss its deadline, misses it, is escalated, or nobody has picked it up, the team sees one line in that request's thread. Kipwise sets up request types, queues and deadlines with your team, so bring the table to that setup and ask how your tiers map onto request types.
This article does not claim that the agent reads the dollar amount and chooses the approver, enforces a limit, or executes a payment. The table is your control. The thread and the card are the place where it gets used and recorded. For the wording of the request itself, our posts on approval requests and on who approves each bill cover the details this table does not.
The row for the AI agent
AptlyDone says an AI agent that can initiate purchases, approve exceptions or execute payments needs the same rigor as any human actor: explicit limits, time-bound authority and an audit trail. It stops short of giving a limit or an approval step. Here is a concrete row, and the reasoning behind it.
| Agent row | |
|---|---|
| Own dollar limit | $0 |
| Acts as | The person who asked, inside that person's own row |
| Every write to a connected account | Waits for an Approve card that only the person who asked can use |
| Never decides | Anything above the asker's tier, a new vendor, a change of bank details, anything a customer will see |
Give the AI agent no dollar limit of its own: it works as the person who asked, so its row in the table is that person's row, and its Approve card is a confirmation, not a sign-off by the tier holder. This is a recommendation, built on how the Kipwise agent is documented to work: it uses each person's own access in a connected tool, and before it changes something in a connected service or posts a message it shows an Approve or Deny card that only the person who asked can use. The card expires after 30 minutes, and a denied or expired card means the action is not run.
If Maya asks the agent to do something that spends money and she presses Approve, she has confirmed the write. She has not obtained the approval the table requires from Sam. Those are two different presses by two different people, and a firm that treats the first as the second has put a self-approval loophole back into the table, with an agent in the middle. So the sequence is: the request carries its tier, the tier holder approves it on the request, and only then does the person who owns the request ask the agent to carry out the write and press Approve on that card.
A second recommendation follows: make the roles people hold in your connected tools match their rows. In the tools that use each person's own access, the agent can only do what the asker's own access allows, so a budget owner whose accounting login can pay any bill has a larger limit in practice than the table says, and the agent inherits it. The table sets the policy. The permissions in each tool decide what is possible. Check that they agree.
Handle failure and edge cases
- The founder is the only approver at the top and is away. Name a second person for the top tier for stated periods, in writing, with an end date. If you have nobody to name, the table should say that above-limit requests wait, and why.
- A request lands in the wrong tier. Sending it back is the correct outcome. Count these. A rising count means the table is unclear, not that people are careless.
- A refund or discount is urgent. As a recommendation, allow the lower tier to act with a retrospective approval inside two business days, written into the table, so people do not invent their own path.
- A card is lost or an approver never answers. Use the resend button in App Home for a lost card, and the person you named as reroute owner for a silent approver. Do not let the requester pick a different approver.
- The agent is asked to act above the asker's tier. It cannot raise that person's limit and neither should anyone else in the thread. The asker goes back to the tier holder.
What stays with a person in every case: every decision above the owner-set limit, every new vendor, every change of bank details and every customer-visible action. The agent can look things up and carry out a write once the person who asked has approved it. It does not decide those.
Verify it works
Run a ten-minute review once a month for the first quarter, using the last twenty approved requests.
- Does each one show an amount, a tier, an approver, and a different person as the requester?
- Was any approved by someone below the required tier?
- Are there clusters just under a limit from one vendor or one requester?
- How many requests went back for a wrong tier?
- How many reached you, the founder? If you still see most of them, the lower limits are too low. If you see almost none and are uneasy, they may be too high.
Also watch the people. A limit is working when the budget owners stop asking you whether they can renew something small, and when you can leave for a week without anyone spending outside the table. For a pilot, apply the table to one request type, such as software spend, for two weeks and adjust from there. Our guide to adding human approval to agent workflows covers the approval gate for an agent's own actions in more depth, and the RACI chart guide covers who owns each recurring job, which is a different question from who may approve spending.
One part is unproven. The one practitioner thread on agent authority behind this guide is a single Ask HN post from a person who reports that companies give authority to human roles, sometimes written into bylaws, and asks how that works for an agent. It has no replies. The agent row above is reasoned from how the product works, not from a body of field reports, so treat it as a starting position to test.
What to do next
Open the last three months of things you approved and sort them into spend, refunds, discounts, contracts and hires. Fill in the first row of the table above with your own three limits, name a backup for each, and post the table in the channel where requests happen. If you want to try the request desk against it, the Kipwise agent's trial is $2 for 7 days without a card, or $10 for 14 days with a saved card or a paid Slack plan, and it costs $10 per user per month afterwards with a minimum of 3 users, as set out on the Kipwise pricing page.
