Connect to IntercomFinance asks who approved last month's credits. You don't have an answer.
Not because you don't care - because the answer is somewhere in a Slack DM from two months ago, or a verbal yes in the office, or a message from a manager who's since moved on. There's a number on the spreadsheet and a gap where the reasoning should be.
What is a support approval process?
A support approval process is a structured path for decisions that fall outside your standard policy. Any time an agent needs to issue a refund they're not sure they should issue, a credit above their threshold, a comp that isn't in the playbook, or an exception to a rule - there should be a defined way for that request to reach someone with authority to decide, and a record of what was decided and why.
Most teams don't have one. What they have is the shoulder-tap.
Why most support teams rely on the shoulder-tap
The shoulder-tap is fast and it feels trustworthy. Agent and manager know each other. The judgment call happens in ten seconds. Nobody fills out a form.
It works well enough when the team is small and the volume is low. What you don't see until later:
Inconsistency. Two agents, same customer situation, different managers, different answers. One customer gets the refund. Another doesn't. Neither knows why, and you can't find out either, because there's no record.
Over-giving. Agents who want to be helpful - or who don't want the friction of a "no" - tend to ask for approval on borderline cases and quietly lean toward a yes when they're uncertain. The path of least resistance is generosity with someone else's money, and a shoulder-tap culture enables it.
Under-giving. Cautious agents ask for approval on everything. The manager's attention is fractured all day. Customers wait longer than they should.
No trail. When the question comes - and it always comes - the decision lives in someone's head, in a DM you can't find, or with a person who no longer works there.
The shoulder-tap doesn't fail dramatically. It fails slowly, as the inconsistency accumulates and the costs add up, until the finance spreadsheet catches it.
"Use your judgment" is not an approval process
The alternative many teams default to is blanket autonomy: trust the agents, give them discretion, let them use their judgment.
This sounds like empowerment. In practice it's a policy vacuum.
Without a threshold - a dollar value, a deviation category, a customer tier - "use your judgment" means every agent is making a different call, for different reasons, with nothing recorded. The generous agent builds warm customer relationships but costs more. The cautious agent protects the budget but loses customers. From the outside, you can't tell which approach is right because you can't see what anyone decided or why.
Giving agents autonomy is right. Doing it without a framework isn't empowerment - it's ambiguity dressed up as trust. And it's the thing I see most often when support teams can't answer the finance question.
What a support approval process actually needs
It doesn't need to be complicated. It needs three things:
A threshold for what requires approval. Not every refund needs a manager sign-off. Define the line: by dollar value, by policy deviation, by customer situation, by request type. Below the line, agents act. Above it, they request. The threshold can evolve - but it has to exist somewhere other than people's heads.
A structured way to request. The request should include what the agent is asking for, the customer context, and the specific ask. It should not be a DM. It should go somewhere the manager can actually see it, with enough information to make a good decision without opening three tabs.
A record of every decision. Approver name, decision, reason, timestamp. Somewhere retrievable - not in a Slack thread archive that requires forensic searching, not in someone's memory. When the finance question comes in three months, the answer should take thirty seconds to find.
How to build one
Start simple. Write down the threshold - what requires approval. Share it with the team. Create a place where approval requests go that is not DMs, with a format that is not "hey, can I?" and a commitment that every decision gets a reason attached.
For teams running Intercom and Slack, we built this into Supportman as Approvals. The agent requests from inside the Intercom inbox - specifies the type (refund, credit, comp, exception, off-policy reply), adds the context, sends. The request lands in a dedicated Slack channel. The manager approves or rejects with a reason, and the decision flows back to the Intercom conversation. The record stays in the channel - searchable, exportable, available to finance when they ask.
You don't need our tool to build an approval process. But if your team is already in Intercom and Slack, it's the fastest path to one.
The record is the point
The approval decision matters. The record of it matters more.
A proper approval process means you know what was decided, who decided it, why, and when. You can find it in thirty seconds. You can export it. You can spot patterns - which agents request most often, which exception types are trending, whether your threshold is set right.
Without the record, you have a process that works until someone asks you to account for it.
That's the question finance is going to ask. The answer should already be written down.
Frequently asked questions
What is a support approval process?
A support approval process is a structured path for decisions that fall outside standard customer support policy - refunds, credits, comps, exceptions, or off-policy replies. Instead of agents making these calls unilaterally or requesting them via DM, a formal process routes the request to a decision-maker, captures the approval or rejection, records the reason, and keeps it retrievable.
Why do most support teams not have a formal approval process?
Because the informal alternative - a Slack DM or a quick verbal ask - works well enough at small scale. It breaks down as the team grows, as exception volume increases, or as accountability requirements tighten. Most teams don't formalise until they've already had the "who approved this?" conversation with finance.
What decisions should require manager approval in customer support?
The right threshold varies by team, but common triggers include: refunds above a set dollar value, credits issued outside the normal policy window, comps that aren't in the standard playbook, exceptions for high-value or enterprise accounts, and any off-policy reply that commits the company to something non-standard.
How do you create a support approval process for a team using Intercom and Slack?
Define the threshold for what requires approval and write it down. Create a dedicated Slack channel for requests - not DMs - with a consistent format that includes request type, customer context, and the specific ask. For teams wanting this built in, Supportman Approvals handles the request, routing, decision, and record automatically from the Intercom inbox.
What should an approval record include?
The requesting agent, request type, customer context, the approver's name, the decision (approved or rejected), the reason, and a timestamp. The record should be retrievable without a Slack search - ideally exportable to a spreadsheet so finance can pull it without asking you.