Slack Approval Bot: Answer Repeat Requests from Past Decisions

One person on your team answers the same approval question five times a quarter. This answers it from the four times they already did, and refuses when the case is genuinely new.

Every team has a question only one person can answer. Can we make an exception for this account. Can we discount this renewal. Can we ship before legal signs off.

The question is rarely hard for the person who owns it. They have usually decided it before. A CS lead fields the same "can we credit this" three times a month from three different CSMs. A founder gets pulled into the same custom-feature request from four accounts in a quarter. A sales lead answers "how far can I go on this discount" for every rep, one at a time, forever. None of these are difficult calls. They are calls that already exist, sitting in a thread from four months ago that nobody else has any reason to find.

Why writing it down never fixes this

The instinct is always to document the answer. It does not work, for three reasons worth naming.

• "Just write the policy." If the answer could be a rule, it would already be one and nobody would be asking. The questions that reach a single person are precisely the ones the rules do not cover.
• "Build a FAQ bot." A FAQ bot answers from documentation. These answers are not in documentation. They are decisions, and a decision carries a reason and an outcome that no policy page records.
• "Delegate it." You can delegate a rule. You cannot delegate a judgment when nobody else has seen the history it came from.

The gap is not knowledge. It is access to reasoning that only exists as a trail of past calls.

What the approval bot does

Runbear answers the request from the decision-maker's own past calls, shows which one it is following, and stops when nothing matches.

It reads where decisions actually get made. Slack threads, Linear comments, email. Not the wiki, because the real reasoning is almost never in the wiki.

It answers with the call and the receipt. Not "our policy is no," but "this has come up five times, it was refused four of them, here is the February thread, and here is what happened in the two quarters after." The counts matter more than they look: three other accounts asking for the same thing after a refusal is the reason that refusal holds.

And it refuses. When the closest precedents disagree, or when this case has a factor none of them had, it says so and leaves the decision alone. In the clip above, the request is routine until the customer mentions the renewal. No prior decision was made with a renewal on the line, so the bot stops. That behavior turns out to matter more than the answering. An assistant that always produces an answer is one you have to double-check every time, which is the work you were trying to avoid.

Who this is for

• CS and support leads who are the single approver on credits, exceptions, and out-of-policy requests
• Founders past roughly thirty people, where every custom-feature ask still routes to one inbox
• Deal desk and sales leadership answering the same discount-floor question rep by rep
• Anyone whose team stalls when they are offline, which is the honest test: if work waits on you in a way that has nothing to do with difficulty, this is the shape of the problem

Setting it up

1. Sign up at Runbear.
2. Connect Slack, plus anywhere else decisions land, like Linear, email, or Notion.
3. Point it at the channels where the calls actually happen, not at the wiki.
4. Give it outcomes rather than policy: what was approved, what was refused, and what happened afterward.
5. Put it in the channel where people already ask, so nobody has to learn a new place to go.
6. Tell it when to stop, so a case with no precedent gets escalated instead of guessed at.

What changes

The repeat questions stop reaching the approver. The same volume of asks arrives, but the ones with a settled answer resolve in the channel with the precedent attached, so the asker can check the reasoning instead of taking the bot's word for it.

The genuinely new ones still land on the approver's desk. That is not a gap in the system, it is the system working. What changes is that they arrive already labeled: here is why this one is different from the five before it.

The second-order effect is the one teams tend to notice later. Once past decisions are being cited back, inconsistency becomes visible. Two calls that contradict each other stop being invisible history and start being a question someone has to answer.

Try it

Setup takes about ten minutes, and you will know inside a week whether the same question stopped reaching you.