Approval requests for a small team: what each one must say, a named backup, and a clock for the approver who goes silent
A teammate DMs the owner: "OK to renew the design tool?" There is no price, no date and no word on what happens if the owner is traveling. The owner means to answer on Thursday. By Monday the requester has chased twice, the renewal has lapsed, and the only record is a thumbs-up emoji that may or may not have meant yes. For a 5 to 100 person firm, that is the whole approval process, and it costs days.
This guide gives you an approval request that carries what the approver needs, a named backup for each type of request, and a clock that moves a stalled request to someone who can act.
The short answer
Three pieces, in this order:
- A four-line request. Every approval request says what is being asked, how much it costs, by when a decision is needed, and what happens if nobody answers.
- An approval matrix. Each type of request has one named approver and one named backup, written down before the first request arrives.
- A silence clock. One reminder at about 75 percent of the window, a hand-off to the backup at the deadline, an exception owner after one more business day, and a written cancel if that owner cannot decide either.
Everything below fills in those three pieces and shows what to run in Slack and what stays with a person.
Why approval requests stall at a small firm
Most guides on the approval workflow teach you to build the buttons. Slack's own write-up of Workflow Builder branching shows up to five buttons per message, with Approve, Reject and Escalate as the example, and a chain from a manager to a finance director to a procurement channel. Slack's Request Time Off tutorial sends the manager a message with Approve and Deny buttons and deliberately keeps them live until one is pressed. Both are good at the moment of decision. Neither describes the moment when nobody presses anything, and that moment is where a small team loses its days.
Three things cause the stall:
- The request lacks the facts to decide. An approver who has to reply "how much?" or "by when?" has just made the request cost two messages instead of one. Vendor guidance on writing a request for approval lists the usual parts: who should review it, a clear subject line, the context, supporting evidence, a deadline and a way to reach the requester.
- The deadline lives in the requester's head. If the request never states a date, the approver cannot tell a Tuesday-morning favor from a Friday-afternoon emergency, so everything waits for a quiet hour that does not come.
- Nobody owns the request after the silence. Chasing is social work. The requester does not want to nag the owner, the owner does not know the request is stuck, and no one else has the authority to decide.
A thumbs-up is also a weak record. It does not say what was approved, at what amount, or whether the approver saw the second message with the corrected price. The rules below fix that by making the request itself the record.
The four-line request
Make the shape fixed, so a teammate fills it in without thinking and the approver reads it in ten seconds. Here is a template you can paste into a pinned message or a canvas:
APPROVAL REQUEST: <one-line title>
1. What: <exactly what you want to do or buy, and why in one sentence>
2. How much: <amount, or the access, or the scope. Link the quote or doc>
3. By when: <date and time you need the answer by>
4. If there is no answer: <what happens at that time>
Approver: @name Backup: @nameLines 1 to 3 cover the context, the evidence and the deadline from the vendor guidance above. Line 4 is not on that list, and it does the most work.
Fill the fourth line with a real outcome, not "I will follow up". Good outcomes are specific: "the backup approver decides", "the quote lapses and I will request a new one", "the request is cancelled and I will refile". A line 4 that says "I will assume yes" is the silent-approval trap. It teaches approvers that ignoring a request is a safe way to approve, and it breaks the first time the request was wrong.
Write what happens on silence into the request itself, because the requester and the approver should both know the outcome before the clock starts, and silence should never count as a yes. This is a recommendation, not a finding from a source. The effect is practical: an approver who sees "no answer by Thursday 3 pm means Dana decides" has a reason to look at it now, and a requester who sees the same line has a reason not to chase before Thursday.
Add one more habit: the approver answers in the thread of the request, not in a DM. An answer in the thread is findable by the next person and by you at month end. If you want the longer version of the same discipline for money specifically, the purchase order process post shows two approval bands and the fields for a purchase request.
The approval matrix
The matrix is a table with one row per type of request. It is short on purpose. For a firm of 5 to 100 people, five or six rows cover nearly everything, and each row has exactly one approver and one backup.
The numbers below are made up for illustration. Set your own from what a wrong decision costs and how often your approvers are reachable.
| Request type | Approver | Backup | Decision window | If nobody decides |
|---|---|---|---|---|
| Software or subscription spend under $500 | Operations lead | Owner | 2 business days | Backup decides |
| Spend over $500 | Owner | Operations lead | 2 business days | Backup decides, owner is told |
| Access to a system | System owner | Operations lead | 1 business day | Request is held, requester told |
| Customer discount | Head of sales | Owner | 4 business hours | Backup decides |
| Refund over the limit | Owner | Operations lead | 1 business day | Backup decides |
| Time off | Direct manager | Operations lead | 3 business days | Backup decides |
Three rules keep the table honest.
One approver per row. A row that says "owner or ops lead" has no owner. When two people can approve, each assumes the other will, which is exactly the stall you are fixing.
The backup has the authority to say yes. That means yes for this type of request when the approver is away or silent. If your backup cannot approve a $2,000 purchase, they are not the backup for that row.
The window follows the cost of waiting, not the importance of the approver. A customer discount that lapses with the customer's quote deserves hours. Time off can wait days.
Name the backup approver for each request type before the first request is filed, because choosing one while a request is already stalled turns into a negotiation. Again, this is a recommendation. A stalled request is already a source of friction, and asking "who else can say yes?" in the middle of it invites the approver to feel overruled. Decided in advance and written in the matrix, the hand-off is just the rule applying.
The matrix does not need to restate the details of each job. When the request is a discount, the tiers and the six fields are in the deal desk post. For a vendor bill, see who approves each bill. For refunds, see the refund policy post. This post covers what those have in common: the request shape and the silence.
The silence clock
A reminder and an escalation are different things. A reminder asks the current owner to act. An escalation changes who owns the decision. A vendor guide on approval escalation rules draws that line clearly and describes a ladder that moves from a single reminder to a backup, then to an exception path, with each step firing once. The structure is useful for a small team even though the vendor's example is an IT purchase queue and its timings are only examples.
Here is the same ladder, scaled to a firm that has no workflow software and a small number of requests. The clock starts when the approver receives a complete request, not when the requester first thought about it. If the requester has to add information, pause the clock and restart it when the request is complete.
| Step | When | What happens | Who acts |
|---|---|---|---|
| 1. Reminder | About 75 percent of the window | One nudge to the approver, with the deadline and the line-4 outcome | Requester or exception owner |
| 2. Backup | The deadline | The backup is named in the same thread and decides | Backup approver |
| 3. Exception owner | One more business day | A named person (usually the operations lead or owner) takes the request | Exception owner |
| 4. Written cancel | After the exception owner cannot decide | The request is cancelled, with a note, and the requester refiles if it still matters | Exception owner |
A reminder works once and only when it is followed by a hand-off to a different named person, because a second reminder to the same silent approver adds noise without changing who can decide. The vendor guidance above makes the same point from the other direction: do not keep the reminder loop running forever. A second nudge goes to the person who ignored the first. If the approver is away, it never arrives. If the approver is busy, it competes with everything else in their DMs. Moving the decision to the backup is the only step that changes the outcome.
Step 3 is the one that small teams skip, and it is the reason requests rot. If the backup also does not act, someone must own the request. Name that person once, for the whole firm, and write them down next to the matrix. Their job is to make sure every request ends in a decision, including "no".
A request that stays open forever stays a quiet obligation. A written cancel closes the loop: the requester knows the answer is "no for now", the record shows why, and the approver is not haunted by a message from three weeks ago.
A worked example
This one is made up, to show the shape. A firm of 12 people uses one request channel. A designer needs a $320 annual license for a font library before the old license lapses on Friday.
The designer files:
APPROVAL REQUEST: Font library annual license
1. What: Renew the font library for the design team, used on every client deck
2. How much: $320 for the year. Quote linked
3. By when: Wednesday 9 am, because the license lapses Friday
4. If there is no answer: Priya (backup) decides at that time
Approver: @Marcus Backup: @PriyaThe matrix says spend under $500 has a two business day window, so a request filed Monday at 9 am is due Wednesday at 9 am. On Tuesday evening, at about the 75 percent point, Marcus gets one reminder in the thread. He is traveling and does not answer. On Wednesday at 9 am, the thread names Priya, who reads the four lines and approves in the thread in two minutes. The designer renews that day, two days before the lapse. Nobody chased, and the thread holds the whole history.
Now the same example with the request desk in the Kipwise agent. Per the product description, a request can need someone's approval first. The approver receives a private card in their own chat with the agent, with Approve and Reject buttons. The first press decides, and the requester is told in a line under their request card. Anyone who presses later is told who decided, so a backup acting after the approver has already pressed does not create a second decision. A card that gets lost comes back from a "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 for a while, the team sees one line in the request's thread in the triage channel, naming who asked and who holds it.
That covers the visibility half of the clock: the team can see which request is late and who holds it. The documented behavior does not include the agent reminding the approver at a percentage of the window or assigning the backup automatically, so those two steps stay with a person for now. In practice the exception owner reads the "about to miss its deadline" line, nudges the approver, and, at the deadline, tells the backup to act. Keep that handoff in your written rule so it does not depend on who happens to notice. For the agent's own tool calls, which follow a different control, see human approval for AI agent workflows in Slack and the page on approvals in Slack automation.
Handle failure and edge cases
These cases come up at a small firm.
- The approver answers after the backup. Say in the matrix which decision stands. The simplest rule: the first recorded decision stands, and a later answer is noted but does not reverse it. The request desk behaves this way for its own cards, where the first press decides.
- The requester changes the request mid-clock. Treat it as a new request. Restart the clock, and tell the approver what changed, because an answer to the old amount is not an answer to the new one.
- The approver and the backup are both out. This is why step 3 exists. The exception owner can decide or can cancel, and the request does not wait for a vacation to end.
- A confidential request. Time off, a pay question or a performance matter should not appear in a shared channel. Keep it between the requester, the approver and the backup, and keep the clock rules the same.
- The approver rubber-stamps. An approver who sees thirty requests a week starts approving without reading. A developer-audience launch thread on Hacker News has a commenter warning that a reviewer who rarely sees a problem stops reading the requests, and the founder replying that he lets Cursor write wrong code and does not review it as he should. That thread is about approvals of AI agent actions, so these are author reports from a different audience. Treat them as a warning, not a statistic. The practical response is the matrix: keep small requests below a threshold out of the owner's queue so the approver reads what they approve.
- A request that should never have needed approval. If one row of the matrix fires ten times a week and is always approved, lower the threshold or give the requester that authority. An approval nobody ever refuses is the first one to remove.
What stays with a person is the decision. A tool can remind, route, record and surface a late request. It should not decide for the approver, and it should never treat silence as approval.
Verify it works
Run the rule on one request type for two weeks before you extend it. Pick the type that causes the most chasing, usually software spend or time off. Then check four things, once a week, in five minutes:
- Requests with no decision past their window. The target is zero. Any request on this list shows a gap in the rule, usually a missing backup.
- Time to decision by type. Compare it with the window in the matrix. A type that always decides on the last day needs a shorter window or a different approver.
- How many requests reached step 2, step 3 and step 4. A few at step 2 means the clock is working. Many at step 2 for the same approver means that person is the bottleneck and the matrix should change.
- Requests that arrived without all four lines. If a teammate keeps skipping line 4, the template is too long, or the channel has no reminder of it. Pin the template at the top.
Count notifications per completed approval as well. The vendor guide on escalation suggests it, and the point holds without the product. A process that sends five messages for every routine decision has moved the work instead of removing it.
What to do next
Today, write the matrix for the one request type that you chase most. Give it one approver, one backup, a window and the line-4 outcome. Paste the four-line template into a pinned message in your request channel and use it for the next real request, yours included.
If you want the request desk to carry the cards and the late-request lines, the Kipwise agent includes it with the install once a Kipwise admin turns it on, at $10 per user per month with a minimum of 3 users. File one real approval request through it and see where the clock still needs a person.
