Connect to IntercomA refund approval workflow routes agent exception requests to a manager for a decision, captures the reason, and stores the record - so every credit or refund can be traced back to who approved it and why.
You don't need a tool to build one. You need four things defined and written down. This is how to do it.
If you want the case for why this matters before you build it, start with Why customer support teams need an approval process.
Step 1: Define what requires approval
Start here, because everything else depends on it. Without a threshold, you don't have an approval workflow - you have a vague instruction and a lot of Slack messages.
The threshold answers one question: which decisions can agents make unilaterally, and which ones need a sign-off?
Most teams define this along one or more of these lines:
Dollar value. The simplest threshold. Agents can approve refunds up to $X without escalating. Anything above requires a manager decision. Pick a number that feels right for your team's risk tolerance and adjust it as you learn.
Policy deviation. Some decisions are within policy and some aren't. Agents handle within-policy decisions; anything that requires bending a rule goes to approval. This works well for teams where dollar value alone doesn't capture the risk.
Request type. Some categories always require approval regardless of size - credits for churn-risk accounts, comps on SLA breaches, goodwill offers to enterprise customers. You can define approval by category rather than amount.
Customer tier. High-value or enterprise accounts might warrant manager involvement for decisions that would be routine elsewhere.
Most teams use a combination. The point isn't to be exhaustive - it's to give agents a clear line they can apply in the moment without having to ask themselves "is this one I should escalate?"
Write it down. Share it with the team. Revisit it quarterly.
Step 2: Create the request path
Once you have a threshold, you need a place for requests to go. Not a DM. Not a verbal ask. A dedicated channel or queue with a consistent format.
The format matters as much as the location. A request that just says "can I refund this?" forces the manager to open a tab, read the conversation, and reconstruct the context before deciding. A well-structured request gives the manager everything they need to decide in thirty seconds.
A good approval request includes:
- Request type - refund, credit, comp, exception, off-policy reply
- Amount (if applicable)
- Customer context - what happened, why this is outside normal policy
- The specific ask - exactly what the agent wants approval for
That's it. Four fields. The manager can read it in a Slack message and respond without opening Intercom.
The channel should be dedicated - not #general, not #support, a channel that exists only for approval requests, so the manager can see everything at a glance and nothing gets lost.
Step 3: Make the decision fast — with a reason
The workflow fails if managers don't respond quickly. An agent blocked waiting for approval is an agent who can't help a customer. Set an expectation: approval requests get a response within a defined window. For most teams, thirty minutes is achievable and sufficient. For time-sensitive cases, fifteen.
The response needs two things: the decision, and the reason.
The reason is the part most teams skip. It feels like extra effort. It isn't - it takes ten seconds to write "one-time exception, customer has been with us four years" or "outside policy window, declining." And those reasons are the most valuable part of the record. They're what tells you, three months from now, whether your policy is calibrated right.
A decision without a reason is just a number on a spreadsheet. A decision with a reason is a data point.
Step 4: Get the decision back to the agent
The approval response should land somewhere the agent can see it without having to check a separate channel. Ideally it flows back to the original conversation - the agent sees "approved" or "denied, reason X" and can respond to the customer immediately.
This is the step where informal approval processes most obviously break down. The manager replies in a DM. The agent misses it. The customer follows up. The agent follows up with the manager. It becomes a chase that costs everyone time. The decision should land where the work is.
Step 5: Keep the record
Every request, every decision, every reason - stored somewhere retrievable.
At minimum, this means the Slack channel itself, if you're routing through Slack. The full thread is there. The decisions are timestamped. Finance can search it.
Better than that is an export. A spreadsheet or CSV you can pull monthly that shows: date, agent, request type, context, approver, decision, reason. This is what you bring to a finance review. It's also what lets you spot patterns - which agents are escalating most, which request types are trending, whether your threshold is set at the right level.
The record isn't bureaucracy. It's the feedback loop that makes your policy smarter over time.
Putting it together
The full workflow looks like this:
- Agent reaches a decision that falls above their threshold
- Agent sends a structured request to the approvals channel - type, amount, context, ask
- Manager responds within the agreed window - decision plus reason
- Decision flows back to the agent and is logged
- Monthly: review the log for patterns, adjust threshold if needed
For teams on Intercom and Slack, Supportman Approvals handles steps 2 through 4 - the agent requests from inside the Intercom inbox using the Supportman panel, the request posts to #intercom-approvals in Slack, the manager approves or rejects with a reason, and the decision flows back to the conversation automatically. The log is in the channel, and there's a CSV export for finance.
Step 1 - the threshold - is yours to define. It's the only part that requires judgment. Everything else can be structured.
Once you're ready to set up the product side, see How to use Approvals: request and approve support decisions from Intercom to Slack.
Frequently asked questions
What decisions should require manager approval?
Define a threshold - a dollar value, a policy deviation type, a customer tier, or a combination. Decisions within the threshold are made by agents; decisions above it go to the approval flow. Common triggers include refunds above a set amount, credits outside the policy window, comps not in the playbook, and exceptions for high-value accounts.
How do you set approval thresholds?
Start simple: a dollar amount is the easiest threshold to communicate and apply consistently. Add request-type or customer-tier rules as your team grows. Write the threshold down, share it with agents, and revisit quarterly based on approval patterns in your log.
What should a refund approval request include?
Request type, amount (if applicable), a brief summary of the customer situation and why it's outside policy, and the specific ask. Four fields. Enough for the manager to decide without opening a separate tab.
How quickly should managers respond to approval requests?
Set an expectation and publish it. For most teams, thirty minutes is achievable during working hours. Faster for time-sensitive situations. The approval workflow fails if managers treat it as low priority - agents blocked on a decision are agents who can't help customers.
How do you record approval decisions?
At minimum, the decision and reason should be captured in a dedicated channel where the thread is preserved. Better: a structured log or CSV export you can pull for finance reviews. The record is also how you improve your policy over time - patterns in approvals tell you whether your threshold is set right.
Do you need a tool to build an approval workflow?
No. A dedicated Slack channel with a consistent request format and a manager committed to responding with a decision and reason is a working approval workflow. Tools like Supportman Approvals automate the request, routing, and record for Intercom teams - but the process itself can be set up without any new software.