The hidden cost of the shoulder-tap — how informal support approvals hurt teams

A shoulder-tap approval is when a support agent informally asks a manager for permission via DM or in person, with no written record of the decision. It feels like trust. It feels like a fast, low-friction way to get things done. What it actually is - measured over months, across a team - is a slow leak.

What is a shoulder-tap approval?

A shoulder-tap approval is when a support agent informally requests a manager's permission for an out-of-policy decision - a refund, a credit, a comp, an exception - through a DM, a quick chat, or a verbal ask, with no structured format, no dedicated channel, and no record of the decision or the reason behind it.

It's the default approval process for most support teams. And the costs of it are almost entirely invisible until something forces you to look.

The costs nobody measures

Manager attention, fragmented all day. Every shoulder-tap is an interruption. The agent is blocked and waiting. The manager is mid-something else and now context-switching. Even if the whole exchange takes two minutes, the cognitive cost is higher - and it happens dozens of times a day across a team of any size. Nobody tracks this. It never shows up in a report. But it's real.

Decisions that slow everything down. A customer is waiting for an answer while the agent waits for a DM reply. The manager is in a meeting. An hour passes. The customer follows up. The agent follows up with the manager. Now it's a whole thing - for what should have been a thirty-second decision. The shoulder-tap optimises for the asker, not the customer.

Inconsistency, compounding quietly. Agent A taps Manager X, who tends to say yes. Agent B taps Manager Y, who tends to say no. Same situation, different outcome, no visibility across either. Over time the team develops different implicit policies depending on who you ask. Customers who push get more than customers who don't. Patterns form that nobody can see because nobody's looking at the aggregate.

Over-giving that nobody catches. Agents who don't want the friction of escalation - or who genuinely want to help - find ways to resolve borderline cases without asking. When they do ask, they ask in ways that are more likely to get a yes. "The customer's been waiting three days - can I just give them the credit?" is a very different framing from "a customer wants a credit outside policy." The shoulder-tap system rewards framing, not merit.

The trail that isn't there. 48% of merchants name refund and policy abuse as their biggest fraud problem - yet even teams that care about this often can't trace their own decisions. When a pattern of over-crediting to a specific customer shows up in the data months later, the question of who approved it, and why, leads nowhere. The evidence is in someone's DMs, or their memory, or it's gone entirely.

Why it persists

The shoulder-tap persists because it does work - in the short term, for individual decisions. The manager gets to exercise judgment. The agent gets unblocked. The customer gets a resolution.

What the system can't see is the aggregate. Nobody's measuring interrupted manager time. Nobody's tracking approval inconsistency across agents. Nobody's building a picture of exception patterns. These things are invisible until a spreadsheet or a finance review makes them suddenly visible - and by then, the problem is already months old.

It also persists because the alternative sounds like bureaucracy. A form. A process. Another thing to fill in. Most support managers have been burned by process overhead before, and they've learned to trust the team and keep things moving. That instinct isn't wrong. The problem isn't having a process - it's having a process that adds friction without adding value.

If you want the broader picture of why informal approvals fail at scale, we wrote about that in Why customer support teams need an approval process.

What replaces it

Not a form. Not a ticket. A channel with a format.

The request goes somewhere specific - not a DM, not a chat, a dedicated place - with enough context for the manager to decide without opening three tabs. The manager responds with a decision and a reason. The decision lands back on the conversation. The record exists.

That's it. The shoulder-tap gets replaced with something that takes the same amount of time but produces a record. The agent isn't more burdened. The manager isn't more interrupted. But the inconsistency is visible, the trail exists, and the pattern data starts to accumulate.

For teams on Intercom and Slack, that's exactly what Supportman Approvals does - the request goes from the inbox to a Slack channel, the manager decides with a reason, and the record stays. No forms, no tickets, no new tools to learn.

The shoulder-tap isn't a trust problem

It's worth saying clearly: the shoulder-tap isn't a sign that your team doesn't have good judgment, or that your managers aren't responsive, or that your agents are trying to get away with something.

It's a sign that you haven't built the infrastructure for trust to scale. A team of three can run on a shoulder-tap. A team of fifteen can't. The moment when the informal system stops working is often the moment when it's been working for too long.

Frequently asked questions