The Request That Falls Between Sales, Billing, and Support Belongs to No One

A customer writes in asking to downgrade their plan, but the downgrade would break a custom pricing arrangement their account manager set up two years ago, and the billing change would need a credit calculated against a contract nobody in support has visibility into. Support can see the ticket. Sales owns the relationship. Billing owns the mechanics. None of the three has full context, and none of the three considers this fully their job. The customer, meanwhile, just wants an answer, and doesn’t care that their simple-sounding request happens to sit exactly on the seam between three separate systems and three separate teams. Multiply this scenario across a hundred similar requests a quarter, each one requiring the same improvised coordination, and it becomes clear the seam itself is a real operational cost, not just an occasional inconvenience worth shrugging off as unavoidable friction.

Why These Requests Are More Common Than the Org Chart Assumes

Most support structures are built around the assumption that a ticket belongs cleanly to one function — a bug goes to support, a renewal question goes to sales, an invoice dispute goes to billing. In practice, a meaningful share of requests don’t respect that boundary. A customer’s problem is rarely aware of your department structure; it just needs a coherent answer, delivered by someone with enough context and authority to actually resolve it, regardless of which system that authority happens to live in.

The Ping-Pong Pattern and What It Costs

When a request doesn’t have an obvious owner, the default behavior in most organizations is to route it to whoever received it first, let that person determine it’s “not really” their issue, and pass it along. The next team does the same. Each handoff resets the customer’s context — they explain the situation again, wait again, and start to suspect nobody is actually looking at the whole picture. By the third handoff, the actual problem often takes less time to solve than the routing did, which means the inefficiency isn’t in the resolution — it’s entirely in the indecision about who should own it. Worse, each team that touches the ticket briefly often makes a small, reasonable-seeming decision based on partial information, and those decisions can conflict with each other by the time the request finally lands with someone equipped to resolve it fully.

Naming the Categories That Habitually Fall Through

Some categories of request fall between departments often enough to be predictable rather than exceptional: pricing changes that intersect with a custom contract, cancellation requests tangled up with an open support issue, refund requests that depend on whether a bug caused the problem being refunded, and account access changes that touch security, billing, and support all at once. Once a team can name these patterns instead of treating each instance as a one-off surprise, it becomes possible to build a standing process for them rather than improvising a new handoff every time one appears.

A Concierge Role, Not a Committee

The instinct when a request crosses department lines is often to loop everyone in — a group thread, a shared ticket, three people cc’d. This usually produces slower resolution, not faster, because shared ownership tends to function as no ownership; everyone assumes someone else is driving. A more workable pattern assigns a single named owner for the specific request — sometimes support, sometimes sales, sometimes billing, depending on the case — whose job is to pull in whatever expertise is needed and stay accountable for the outcome, rather than distributing the work evenly across three people who each do a third of it and none of it well.

Building the Handoff Before You Need It

Cross-Boundary Situation	Reasonable Default Owner	Who They Pull In
Downgrade conflicting with custom pricing	Account manager (sales)	Billing for credit calculation
Cancellation tied to an open bug	Support	Sales, only if retention offer applies
Refund contingent on root cause	Support	Billing to execute once cause is confirmed
Access change touching security	Support	IT/security for verification

Having this kind of default-ownership map agreed on in advance, even loosely, removes the moment of hesitation where a ticket sits unclaimed while three people each assume it’s someone else’s.

What the Customer Actually Needs to Hear

Customers navigating one of these requests rarely need the internal handoff to be invisible — they generally understand that different people handle different things. What they need is honesty about what’s happening: a single point of contact who tells them plainly that this touches two systems and will take a bit longer, rather than silence punctuated by a new person restarting the conversation from zero each time. A request that takes two days but comes with one consistent voice throughout tends to land better than one resolved in one day through three disconnected touches that each felt like starting over.

Tracking These Requests as Their Own Category

Because cross-boundary requests don’t live cleanly in any single department’s reporting, they tend to be invisible in aggregate — support’s dashboard shows a ticket that got resolved, sales’s pipeline shows nothing unusual, and billing’s system shows a routine credit. No single report captures how often these situations arise or how long they actually take end to end. Tagging cross-boundary requests explicitly as their own category, even informally, gives leadership a real sense of how much friction this pattern is generating across the business, rather than letting it disappear into three different departments’ otherwise clean-looking numbers.

When to Build a Standing Process Versus Handle It Case by Case

Not every cross-boundary request justifies a formal, documented process — some are rare enough that a case-by-case escalation to a manager who can broker the right owner is perfectly adequate. But once a category shows up often enough to be a recognizable pattern rather than an edge case, it’s worth the investment of writing down who owns it, what information they need from the other side, and how fast the handoff should happen. Skipping this step because each instance “isn’t that common” individually ignores that the category, taken together, may represent a meaningful and recurring share of your slowest, most frustrating tickets — the ones a resolution-time dashboard quietly averages away without ever showing you where the real friction lives.