Also, people who say so-and-so company (usually Google) is hard to contact for support, or that they require expensive support contracts before they'll talk to you, have likely never tried sending email to the appropriate mailing list for the product.
It's amazing how often doing this completely bypasses any corporate first-line-support structure in the way, and just puts the email right into the inbox of the line engineers working directly on the product. It's also amazing how quickly those line engineers reply. (It's as if they treat "replying to random messages on the product mailing list" as their highest-priority job. Or maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked.)
It's a great concept in theory, but in practice...find me the email list for Google Photos. Or Google Keep. These are two Google products that I use daily (including paying for one!)
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.
I've more than once had one of the core developers of Elixir or Phoenix answer a question almost right after asking it in the Slack or IRC channel. I often felt a bit embarrassed to take up their time considering how 'basic' these questions were.
I've had similar experiences in other language/framework communities. It's amazing how helpful some of these very productive people can be to random chat visitors :)!
The trick is to remember that they're almost certainly working on that stuff because they enjoy making users happy, so they're also doing support for the same reason.
I do feel a little bit embarrassed if it turns out they're reading the docs to me, but I feel embarrassed about that whether it's an expert or a fellow n00b ;)
It depends on your issue. We got good support emailing with the TF Lite team on a neural net bug. I think if you’re interacting with open source in a value add way google support is often quite good. If you’re looking for support for integrating for sales or classic customer support it can be terrible to non-existent.
> If you’re looking for support for integrating for sales or classic customer support it can be terrible to non-existent.
> Maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked.
Integrating sales or classic customer support is boring.
I mean, I get that it pays the bills, but when I've got a million priorities, boring work that I don't really get credit for goes to the bottom of the pile.
no. there is a big difference between having support and having someone that is passionate about something helping you out.
support should be there and should be available from
the simplest issues to the most complicated things about A PRODUCT.
you will not get much traction if you ask the same things to the people expert person on a mailing list.
I guess I've never needed "support" in that sense.
I almost always solve problems with the products/services we use myself — up to and including forking the vendor's codebase to fix their shit for them — because it's almost always the fastest way to do things. I've already been working with their product for a while, and I already know exactly what my own problem is. Provided I also know the language their code is written in, that translates to being able to code a patch myself, faster than I can get someone on their end to comprehend the problem I'm having.
That applies up until the point where there's a problem surface that's just plain inaccessible to me (i.e. the inside of a proprietary mobile app or SaaS service), at which point I have to reach out to tell them that it's broken / missing something on their end. (And even then, if I have a spare hour and access to the offending binary, I'll reverse-engineer it a bit to see if I can hotpatch it while waiting for them to get back to me.)
I suppose, for people who don't think this way, there can be value in "support." But IMHO there's more value in just hiring some DevOps engineers who do think that way. Then all the easy "support" requests get handled in-house, and so you'll only ever need the kind of "support" that involves direct bug reports to the engineers from the vendor who built the thing.
you are by definition a power user. if your product is for power users that’s fine.
if your product is targeted to everyone but only power users can figure it out when there is an issue... well you have a problem.
also, being able to figure something out != you should figure it out. your time is limited and the complexity of remembering all those things that you figured out (even if you have the time) will quickly overwhelm you. unless it’s literally your job to support the product you should care about the interface of the product and what guarantees it makes
re: hiring devops engineers. i’m sorry, what? if my email suddenly does not work I’m supposed to hire a devops engineer now?
I mean, if I know that some service is using e.g. Redis under the covers, and the problem is in Redis itself, then submitting a patch upstream to Redis; waiting for it to get upstreamed; and then telling the cloud host to update their Redis version to solve the problem — is usually a pretty reliable path.
But otherwise, like I said, that's when "the problem surface is inaccessible."
It's amazing how often doing this completely bypasses any corporate first-line-support structure in the way, and just puts the email right into the inbox of the line engineers working directly on the product. It's also amazing how quickly those line engineers reply. (It's as if they treat "replying to random messages on the product mailing list" as their highest-priority job. Or maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked.)