I wonder how flows like that happen.

Is Support just completely disconnected from Engineering? Do they not have a way to report issues and indicate that many customers are having a specific issue?

Does the company believe that giving a customer a runaround will make them less upset than saying "Sorry, this is a known issue. We're working on it but do not have a timeline"?

Certainly at some point, some support person is going to be like "Huh, we have a lot of customers complaining about an issue, and our usual flowchart script doesn't seem to resolve it" and try to work it up the chain, right? Or does it get to their manager who says "Meh, that's an engineering problem, not a support problem. Get back to your tickets!" and never pass it up?

> I wonder how flows like that happen.

This is the usual response when a companies customer numbers start to scale up so far that the volume of users like the ones in Vegenoid's parent comment start to overwhelm the support staff. Keeping up the good/decent customer support that you could give to your first few hundred or perhaps even few thousand users eventually becomes ludicrously expensive or even impossible.

Then the original article's "Keeping this running and supported is shit. People are idiots and time wasters! Automate all the things!" stage kicks in.

So "first level support" is created, who's main objective is to get rid of support requests with the minimal effort by the least skilled staff possible. So everything is written into a script that call centre employees are required to follow. Low skill minimal wage staff are required to ask stupid things like "Have you tried reinstalling Windows?" and getting a confirmation that they have - before any support request is passed on to even a junior or intern developer. At this stage nobody gives a damn about users who need help, and they outsource that work to other users on the "community forums" and the entire support team is fired.

(Google, of course, being a world leader in both webtech and customer acquisition, completely skipped the "provide decent customer service" stage and went directly to the "don't give a damn about users" end game.)

If you're working with a large company, Support is outsourced to a bunch of people reading scripts in Manila/Bangalore, and the external company employing them is actively incentivized to never resolve the root cause of any issue, because doing so would mean less tickets and less billable hours.

In my first job in a software maintenance project, I was overenthusiastic and was closing issues left and right. My manager called me to his office and told me that if I solved all the issues, the project will need much lesser people when they renew the contract, which might lead me, the junior most person, to be sent to the bench until they get a new contract.

You were not overenthusiastic, you were sane.

Sounds like something that could be turned into an opportunity. Immediately start looking for a different job, and on the interview explain “I left previous job because I was too efficient at solving problems. After X time, there were no outstanding issues so I was no longer necessary. I’m looking for the next place where I can make a difference”. There are plenty of places that see fewer issues a positive.

I left to pursue further studies after that.

> I left previous job because I was too efficient at solving problems. After X time, there were no outstanding issues so I was no longer necessary.

And so I was fired and could no longer support myself or my family, that's why I'm applying to a position with the lowest pay grade,

It's the capitalism, not a red cross

To give you the other side of this, I have had service providers obviously do this to us. It didn’t result in more billable hours at renewal. We just systematically moved teams leadership to a competitor - we have found that mixing companies of origin in teams keeps everyone more honest - and removed developers we thought were not meeting the productivity standard we were looking for.

Cheating your customer is a dangerous game. They are not dumb.

It’s not that we were inefficient, we got some 80+ tools to support without any knowledge transfer or documentation. We got regular issues, and I was digging to find the root cause and solve them for which apparently we weren’t paid.

Yes. Engineering time is expensive. Support exists to resolve problems without needing engineer time except when the company thinks that the problem is worthy of being addressed.

The tendency to wall off engineers is often taken to a counterproductive level.

Silo your engineers from reality and hire a few BAs and a PM to interpose.

(Don't actualy do this unless you want to burn money)

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)

> Is Support just completely disconnected from Engineering?

Support is almost always tiered because $$$. In an ideal situation (hello GitLab!) tier 1 they are friendly and competent triage artists that can redirect lost customers and handle the common basic cases. Tier two is essentially an experienced and skilled tier 1. It's not until you get to tier 3 that you reach an engineer, usually one dedicated to support. That engineer is the one who reaches out to the operational engineering team if needed.

I think sometimes the company doesn't know what to do or doesn't care. But they have to make some response. So they just ask you to do a load of busywork, to keep you out of their hair for a while.

The other side of the coin is that support gets an ocean of lazy/unrelated/confused support requests that the engineer cannot help with, and responding and explaining that eats up a huge amount of time. I don't know that I agree with putting up barriers to reach support, but they are trying to address a real problem and I get where they are coming from

i remember we had similar issues at my 2nd to last job a bit ago. we would often times try to reduce the friction, but it built up and built up until, one day, there was zero chance of reaching anyone worthwhile. i wish we had gone back and really focused on providing as much support as we provide in product!!

sometimes we're aware of an issue and management has decided its not worth the effort to actually fix it, but also management doesn't want support to straight up tell people we wont help you, so they basically obfuscate

Because most people's problems are they don't have the router's power cord plug in followed by the coax / ether / fiber cord.

The amount of times the software doesn't work because the HASP key [1] is plugged into a different machine is so many.

You just can't trust that they've done any basic troubleshooting and so have to start from a completely blank slate.

[1]: https://en.wikipedia.org/wiki/Software_protection_dongle

> Support just completely disconnected from Engineering

Yes.

Unless you want to drive engineering insane / waste a ton of money.

As mentioned in another comment, support shouldn't be entirely disconnected.

If a customer seems to have discovered a legit bug in the software, there needs to be a path from support to engineering for the bug to get reported.

At the very least, support staff should be willing and able to attempt to recreate a bug that a user is reporting, rather than asking them to completely wipe their device and install everything from scratch for something that is easily reproduced.

Let's take a very simple example. Imagine you've got this Chess app, and whenever someone creates a checkmate involving two bishops, the game crashes, 100% of the time, but only in cases involving two bishops. Sure, maybe the first ticket you get, you go through the workflow of reinstalling, etc. But by the time you've got 100 tickets all saying their game crashed on a checkmate involving two bishops, that should have been escalated to engineering. At the very least, support should be saying it's a known issue. Honesty is going to be a lot less frustrating than to be told to take steps that both sides knows won't fix the issue.

> I wonder how flows like that happen.

These flows are intended to dissuade problem reports, because the business is too big to care.

I once reported a ui bug to Discord(the game chat). This is how it went.

- me wrote an elaborate email and screenshots of the problem with step-by-step guide to reproduce it

- support responded me by asking build version, my os version, device type

- me screenshot all the requested details + manually wrote down in response email so someone can also copy-paste somewhere directly from my email

- support responds by asking me to clear my iphone cache(sending me a guide for Android's App data cleaning process) and see if issue persists

- me respond that it is not Android and since I knew what they will ask, I have uninstalled, reinstalled, logged-out, logged in and documented the whole process by recording my screen while doing it

- support, please try to logout, then uninstall and reinstall again

- me begrudingly do it again(record screen), send them everything

- support, could you try updating your device OS? - me check for updates, iOS says it is latest, me send screenshots

- support, can you try disconnecting and reconnecting to your network or rebooting your device?

- me follow the steps(by recording my device using another device) and send it back

- support, can you try factory resetting your device

- me get pissed off, I mean c'mon, the issue is that, the client is incorrectly handling the on-screen keyboard events and has nothing to do with my device, but giveup anyways and write on twitter that I tried to report an ui bug, is there some engineers I can reach out to?

- twitter official DM me and what do you know, it was the same person who was responding to my emails and tells me, if I tried resetting my device to factory default, else they'll close my ticket as not reproducible

I just gave up and uninstalled discord. I mean, sure there are lot of useless problem reports, but when your user goes on to extreme lengths to document an issue and cooperates, please take it seriously.

In most cases, the whole script is intended to deter the less patient consumers/users and not actually solve any problems. In some cases, the support is just an outsourced team with no connect/contact with actual team or the product.

I have had that experience. Or variations of it.

This is me almost every time I interact with ISP support.

Except… recently I completely misdiagnosed something. So while I was getting politely frustrated with the support clerk, he was stepping me through a set of irrelevant seeming procedures which, indeed, resulted in identifying that a piece of hardware was broken.

In this case it was the fiber to Ethernet adapter my ISP uses. He needed me to verify that, at every step of the way, pieces of my infrastructure were not the cause of my flaky connection (they weren’t). However, as a final step he had me reboot the adapter and it didn’t start back up. Turns out this is a rare failure mode and the flaky network I’d been seeing was an early, year long, symptom of this issue.

I did the even more dumbass version of this once.

I had DSL with a router and modem. I never had problems with it, never required reset etc. Over the years somehow I forgot and thought it was a combo router and modem.

Then when I finally had a problem, I insisted to customer support I had done many power cycles already. They scheduled a tech to come out, but I realized my mistake before it went that far at least.

A power cycle fixed the modem, of course.

I went as far as going out to one of the local metro offices for my ISP in the city, to demonstrate some bizarre problem that I was experiencing with my combo router / modem.

I was actually able to demonstrate the issue in person, and everyone was scratching their heads trying to figure out what was going on.

I decided to try factory resetting it as a hail mary... and instantaneously I got a perfectly functioning ADSL connection.

It would have been far less embarrassing for me to have thought to try that and make the effort at home. lol

What do you do if you are incorrect? It has happened many times that a customer calls certain they know what the issue is and even if the customer is well versed in that field he may be wrong.

I hop on video and do screen share. It probably takes less aggregate time, they think they get special treatment when really I'm just saving time and I know how my stuff is being used more.

I have had great experiences with Schneider electric support for their automation platforms, and switchgear

Me: Hi, my ADSL isn't working, I have line sync but no data.

ISP Support: Hi do you have a dial tone?

Me: No we don't have a land line phone at all and haven't for years

ISP Support: Can you please check your land line phone and let me know if you have a dial tone?

Me: I. HAVE. LINE. SYNC.

ISP Support: Yes but your line might not be connected yet. I need to know if you have a dial tone.

Me: ...

Me: drives 5km to the nearest shop that sells telephone handsets

Me: <twhoo hoours layter> YES. WE. HAVE. A. DIAL. TONE.

ISP Support: Okay so it looks like there's an outage in your area which is affecting your connection.