Obviously, not every support ticket requires engineering attention. I would wager at least 90% don't. In the case of B2C businesses, likely 99.99% don't, considering 80% are customers that simply need a password reset and can't figure out how to do the most basic Reset Password -> Open E-mail -> Click link -> enter new password flow.
But there's a line SOMEWHERE. The few tickets that DO need engineering time REALLY NEED IT, and it's completely asinine that in some corporations, it's impossible.
If, for example, 100 people are talking to support for the exact same crash, and people in support are able to reproduce it, it needs to go to Engineering, rather than support telling customers "Have you tried formatting your drive and reinstalling everything from scratch?" when they already know it won't fix anything.
The best place I ever worked had fairly sophisticated, formal channels for noticing when a cluster of related-looking problems happened repeatedly, and escalating that to engineering for a fix. It also had open Slack channels with engineers and product managers in them, and some informal understandings about what type of problem was appropriate for support or professional services to bring up, there.
That combination kept the customer-frustrating bugs quite low, while still allowing engineering to keep developing new features at a fairly rapid pace.
(and then we got purchased by a PE firm and dismantled)
But there's a line SOMEWHERE. The few tickets that DO need engineering time REALLY NEED IT, and it's completely asinine that in some corporations, it's impossible.
If, for example, 100 people are talking to support for the exact same crash, and people in support are able to reproduce it, it needs to go to Engineering, rather than support telling customers "Have you tried formatting your drive and reinstalling everything from scratch?" when they already know it won't fix anything.