Connect to IntercomThe customer is asking for a refund outside the policy window. You have three options.
Say no and risk churn. Say yes and risk setting a precedent. Or get a manager involved - which usually means leaving Intercom, opening Slack, and waiting.
When a customer asks for something outside policy, the worst outcomes come from agents deciding alone - the best ones come from a fast, structured path to a manager. Here's how to handle it without the context-switching.
What counts as an off-policy request?
An off-policy request is any ask from a customer that falls outside what your standard policy authorises an agent to approve unilaterally.
Common examples in Intercom teams:
- Refund requested outside the policy window
- Credit above the agent's approved threshold
- Comp for a situation not covered by standard guidance
- Discount on a renewal that isn't a standard offer
- Exception for an enterprise account that needs a custom answer
- Return of a product the policy doesn't cover
What makes it off-policy isn't always the dollar amount. Sometimes it's the situation - the customer is churning, or they've had a genuinely bad experience, or the policy just doesn't fit the case in front of the agent. The agent knows something needs to happen. They're not sure they're the one who should decide it.
Should agents decide off-policy requests on their own?
Saying no is the safest move for the agent and often the worst move for the customer. A policy-correct denial on a borderline case - especially for a long-term or high-value customer - is a fast path to churn. The agent followed the rules. The customer left.
Saying yes without a sign-off has the opposite problem. The agent did right by the customer in the moment, but there's no record, no manager awareness, and no way to know whether the same agent is making the same call fifty times a month. Over time, agents who default to yes train customers to push back - because it works.
Both options leave the agent carrying a decision that probably shouldn't be theirs to make alone. For the process behind this, see How to build a refund approval workflow for your support team.
The context-switching problem
The right answer is manager involvement. The problem is how it usually happens.
The agent leaves the Intercom conversation, opens Slack, types out the situation - customer name, what they want, why it's off-policy, what they're thinking of doing - and waits. The manager is in a meeting. Thirty minutes pass. The customer sends a follow-up. The agent sends the manager a nudge. The manager replies. The agent goes back to Intercom, applies the decision, responds to the customer.
Nothing in this process is wrong, exactly. But it's slow, it breaks the agent's focus, it fragments the manager's day, and the whole exchange leaves no record beyond a Slack thread that nobody will find in three months.
The context is also at risk at every step. By the time the manager sees the request, the agent has summarised a conversation from memory. Details get dropped. The manager is making a decision with partial information.
How do you handle exceptions in Intercom?
The better path keeps the agent in the Intercom conversation and sends the context to the manager structurally, not from memory.
With the Supportman panel inside the Intercom inbox, an agent dealing with an off-policy request can send an approval request without leaving the conversation. They specify the request type, add the customer context, and send. The request posts to the dedicated #intercom-approvals channel in Slack with enough information for the manager to decide - without the manager needing to open Intercom.
The manager approves or rejects with a reason. That decision flows back to the Intercom conversation. The agent sees it, acts on it, and the customer gets an answer.
The whole exchange is in the Slack channel. The reason is attached. The record exists.
For step-by-step product setup, see How to use Approvals: request and approve support decisions from Intercom to Slack.
What the manager needs to decide quickly
The quality of the manager's decision depends on the quality of the request. An approval request that just says "can I refund this?" forces the manager to ask for more information before they can decide - which adds another round to an already slow loop.
A good off-policy request gives the manager four things:
What the customer is asking for. Specific: "refund of $120, outside the 30-day window" not "they want money back."
Why it's off-policy. One sentence: "Purchase was 47 days ago, policy covers 30."
The customer context. Anything that's relevant to the decision: tenure, account size, the situation that led to the request, whether there's churn risk. The manager shouldn't need to open the conversation to understand the stakes.
The agent's read. Optional but useful - "I think this is worth approving, long-term customer, first complaint" gives the manager a data point. Agents closest to the conversation often have the best instinct on these.
Four fields. Thirty seconds to fill in. Enough for the manager to make a good call without a back-and-forth.
The response that unblocks the agent
The manager's response has two parts: the decision, and the reason.
The decision unblocks the agent. The reason is what the agent uses to respond to the customer - "I've checked with my manager and we're happy to make an exception in this case" - and what goes into the record for future reference.
A denied request with a clear reason is also useful. "Outside policy window, no exceptions this quarter" gives the agent something to work with when they go back to the customer, rather than leaving them to deliver a no with no explanation.
The conversation shouldn't wait
One practical consideration: if the agent is in an active conversation and needs to get an approval before they can proceed, the customer is watching the clock. It's worth the agent sending an interim response - "I'm just checking with my manager and will come back to you shortly" - before sending the approval request. This keeps the conversation alive and sets an expectation, so the customer isn't sitting in silence while the escalation happens.
The approval process adds a step. The good version of that step is invisible to the customer. The bad version is silence.
Supportman Approvals handles the request, routing, and record for Intercom and Slack teams.
Frequently asked questions
What is an off-policy request in customer support?
An off-policy request is any customer ask that falls outside what standard policy authorises an agent to approve without escalation - a refund outside the policy window, a credit above threshold, a comp not covered by standard guidance, or any exception that requires a judgment call above the agent's authority.
How should agents handle off-policy requests in Intercom?
The best path is a structured escalation that doesn't require the agent to leave the inbox. Using Supportman Approvals, agents can send a request from the Intercom inbox directly to a manager approval channel in Slack - with the context attached - and get a decision back without context-switching. The alternative is a Slack DM, which is slower, unstructured, and leaves no record.
What information should an off-policy approval request include?
Four things: what the customer is asking for, why it's outside policy, relevant customer context (tenure, account size, churn risk), and optionally the agent's own read on whether to approve. Enough for the manager to decide in thirty seconds without opening the original conversation.
How do you stop off-policy requests from slowing down the customer?
Send an interim response before escalating - "I'm just checking with my manager and will be back to you shortly." This keeps the conversation live and sets a clear expectation. A well-structured approval process should deliver a decision within thirty minutes; a good interim response buys that time without leaving the customer in silence.
What should happen when an off-policy request is denied?
The manager should include a reason with the denial. The agent uses that reason to frame the response to the customer - a clear "no with an explanation" is a better customer experience than a no with no context, and it gives the agent something to work with rather than leaving them to improvise a rejection.