[VladVladikoff]

I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting it to engineering for a more permanent fix.

[jodrellblank]

Always fun to see an exchange on Reddit like:

Person1: "thing doesn't work?"

Person2: "yeah it doesn't work for me either"

Person3: "it's always something I have to work around"

Person4: "I work for <company> as a customer support outreach social media community engagement executive. Can you go and jump through hoops and open a support case?"

Not raising it internally, not getting anything changed or fixed; suggesting the customer do more work to tell the company about the problem. A person who works for the company and is paid to read social media and has read the complaints, is not only apparently ignoring them but annoying the customers as well.

Alternate Person4: "<sigh> I work for <company> as a technical employee and we've been begging to get this fixed for years. As a workaround you can <xyz>. Email me directly if you need more help, and if we get a patch to fix ever, I'll let you know".

[kayodelycaon]

I can relate to Alt 4. Having my work email on something and finding out the person behind the desk is a customer can be unfun.

I haven’t used the products of any company I’ve worked for.

[trevor-e]

You can never rely on support reps to escalate UX issues to product teams for a couple reasons.

First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.

Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.

[hinkley]

Perverse incentives. They are judged by how long the call takes, and every time they escalate a common problem that the devs could fix, now their numbers will go down and they'll get punished for their good work.

Dell at one point pulled the plug on outsourcing their tech support. They spotted this moral hazard partway through the process and decided it was better to keep it in house.

[lavelganzu]

On the opposite side of moral hazard, early in my career I worked for a large web security company in tech support. We were not permitted to escalate to engineering at all. Often this meant the only solution was to apply our own, unofficial code changes!

[ericbarrett]

> We were not permitted to escalate to engineering at all.

I have no words! Except that I really want to know the organizational dysfunction that ended up creating that policy.

[vdqtp3]

At my last job I worked in professional services, and after reporting multiple issues over and over and over through the normal process I finally wormed my way into a friendship with engineering and product leadership. A conversation with someone they trust was THE ONLY WAY to get them to take seriously a Jira report from the field saying "this is annoying/broken at every customer. Yes there is a workaround, but can we get it fixed?"

Product at every company I've worked for only ever cared about prioritizing shiny new features or bugs that have people screaming at them.

[octo888]

This is spot on and echoes my experience (seeing it from the dev side)

[GuinansEyebrows]

speaking as someone who clawed their way up out of the support mud...

sometimes it's a lack of accessible escalation procedure (no, a bug report is not the same thing as "this feature sucks to use and needs to be revisited), and sometimes it's just the unfortunate fact that those support reps most capable of clearly explaining these issues (or better yet, understanding the underlying mechanisms that cause the issues) get promoted out of front-line support roles (hi)... or move on because they're not satisfied with remaining in support (hi).

obviously there are a ton of exceptions to this rule but i've personally covered just about all those bases throughout my career. i would have loved to have seen engineers get involved with the burden of support, but maybe that's just because i came out of dysfunctional shops... not that they're not all dysfunctional in one way or another.

[arp242]

I think this is pretty much it: everyone capable of doing quality support has the skills to double or triple their salary by doing something more interesting (usually dev or sysops).

The way I've typically solved this is by keeping an eye on the support inbox myself. It takes just a few minutes every day and I've caught some pretty low-hanging fruit with this that really does make the product better. Sometimes it's as simple as just adding a permalink somewhere.

[mschild]

I think a mix of both is best. If support can quickly solve a customer issue they should. But they also should make note of it and pass it along.

[Eddy_Viscosity2]

If it was the case the customer support simply knows an undocumented work-around that they can solve the problem and provide that to the customer. I mean that works, but a better solution is for that problem to get back to engineering and be fixed once and for all.

[hinkley]

But after the next release the number of calls per hour the customer support team can answer will drop. Which means no raises for the support people.

[mschild]

Then incentives and (I hate this word) KPIs aren't aligned. That's arguably a somewhat separate problem though.

[mschild]

Yes, fully agree. Like I said: solving a customers problem is top priority but regardless of the solution it should be documented and shared. At minimum it can give pm and engineers insights into common issues and potential improvements.

[ranger_danger]

> don’t seem to ever make it back to our engineering team

Does support have a procedure for this or is it ever part of any training or meetings? Otherwise I hesitate not to call it a management issue, no offense.