Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well, yeah, there does have to be a public mailing list.

My point was that there are often public mailing lists, where engineers with real engineering problems could discuss those problems with the engineers responsible for the product/service; and yet the engineer with the problem nevertheless doesn't even think of using the mailing list to reach out, but instead decides to go through regular customer-service support channels to get their problem solved.



I've also got serious problems (as in, the service we're paying real money for is totally broken) solved by contacting a friend who worked at $BIG_COMPANY and the friend escalating internally.

The point is that I shouldn't have to bypass the official channels that way. These organisations are operating at the level of ad-hoc individual heroics, which is the lowest tier in terms of organisational maturity. In a start-up where everyone has to do everything and no-one has worked anything out yet, that's completely understandable. In a many-billions-of-dollars business with enough influence that someone's quality of life or the viability of some other business could be profoundly affected if the giant screwed up, we should be demanding better by now.


What I've seen so far is that companies in general don't get better at this as they grow. They add process over process and each level makes tackling 90 percent of support requests more efficient (for them) but the more difficult requests just don't make it to the person who could help.


That is certainly one pattern we see repeating, but I don't think it's what is happening with many of the big tech companies. They're opting for the alternative where tackling 90% of support requests is highly efficient because those requests are simply routed to /dev/null.

In one sense, it's hard to blame them. After all, if no-one who matters to their revenue stream is actually going to change behaviour because of that dismissive policy, it saves them all the overheads of providing useful support and costs them practically nothing. It's just good business, right?

What is strange is how they've got away with it for so long and most people still don't seem to be switching to alternatives, even as the tech giants casually squash them without even noticing. At some point around here, the words "competition" and "regulation" enter the room.


>Well, yeah, there does have to be a public mailing list.

Imo, this is not scalable or sustainable, and mailing lists are not a replacement for adequate customer support.

The only reason sending emails directly to mailing lists for specific Google products works is precisely because those mailing lists are not public and not flooded with bajillions of emails from the general public. So those who send the emails are already somewhat pre-screened in a way, because if you know that mailing list email address in the first place, you are very unlikely to send something like "my cousin couldn't remember password to their google photos account, can you fix this please". That's why everything there ends up being read and addressed. If those mailing lists were public, then they would be just as useless and ineffective as the current customer support routes currently are for Google.

Tl;dr: mailing lists for specific products are a nifty workaround for the time being, but they aren't a good sustainable solution for shitty customer support. Making those mailing lists public will not only not help solving the problem, it will just make those mailing lists as ineffective as the current customer support. There is no "one weird trick" to solve the customer support adequacy issues with Google,it has to be an actual customer solution that won't be easy and will take time.


I'm confused about what you mean about "public." I'm just a regular guy with no connections to Google, other than being a GCP customer. I found the mailing list addresses for each GCP service listed directly in the support documentation. Literally anyone who has GCP problems would end up finding those addresses, if 1. they clicked on the "help" button and went through the workflow presented, and 2. didn't first pay for extended white-glove support and then immediately reach for it for any problem that came up.

By my thinking, that's a "public" mailing list. They're not hiding it from you. The opposite, really — they're trying to get everyone to know and use it, by making it free to any GCP customer, while the actual CSR kind of support requires paying for a subscription to a higher support tier. The mailing list, presented in Google Groups format, is literally what GCP calls their "support forum." It's supposed to take on all comers, including dumb customer asks.


I think the disconnect here is that Google engineers are much more likely to answer the low volume of technical "nerd-snipey" questions from other developers than the high volume of non-technical questions they'd get from the general public for something like Gmail.


Lately, I've seen a few open source projects go this way: GitHub issues, this gets unwieldy so they create a Discord, this descends into chaos so they nominate a community volunteer, issues are then filtered by thier preferences, etc.

I like Discord, especially in the early days, you can reach out to the principal dev, etc. But it soon seems like they either disappear to get work done (good) or spend all thier time on it (bad). Either way you end up with chaos.


Our company has a Discord, but we employ a professional Community Manager for it. When community members bring issues up:

1. they're encouraged to do so in public, so that other community members can help if possible, and/or so bots can reply with suggested FAQ answers;

2. the Community Manager will answer with the company line for questions the company has set answers to (e.g. "when are you releasing X?" or "why is [abusive DoS-like pattern of requests to your service] not working?");

3. otherwise, if the Community Manager knows the answer for sure off the top of their head, they'll give the answer;

4. and if not, the Community Manager relays the question to an engineer in our Slack, where we either have an answer off the top of our heads, or we file it as an issue.

Seems to work just fine for us so far.

Some of the engineers are also sometimes in the Discord (and we're all registered to it), but other than the Community Manager, it's not our job to be in there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: