3 ms·

How goes the work to improve customer service and support? Thinking about https://news.ycombinator.com/item?id=14359801 https://news.ycombinator.com/item?id=14

How goes the work to improve customer service and support? Thinking about https://news.ycombinator.com/item?id=14359801 https://news.ycombinator.com/item?id=14359801, what improvements have you made in the last 139 days that would make us want to build on this?

steego 9y ago
For their own sake, I hope the team gives this question attention and respect. What sets Amazon apart from many other companies is their reputation for relentless customer service. Customers pay close attention to the quality of answer or lack of answers to questions like this one. Every cloud company that asks us to invest our time in their proprietary API is asking us to trust them. If you violate one vocal customer's trust, we're going to notice. If you don't make things right, we're going to notice. Even before I read the article, I first read the comments to gauge the reception because I care more about the perception of trust before I even consider using something like this. Customers don't always stop trusting companies for fair or valid reasons, but that doesn't matter. Trust is much more of a visceral thing than a cerebral thing. So here's my question to other HN readers. What would Google need to do to improve its reputation for customer service? What would they need to do to make that commitment resonate with you on a visceral level?
- techdragon 9y ago
  For me it's pretty easy. I want to start hearing and seeing positive anecdotes about real time communication with Google Cloud support. That is to say, I want to hear people start saying things like "I rang them, and everything was sorted out" ideally with a platitude attached like "it was actually a pretty good experience". I hear this about AWS all the time, and I've even experienced it myself. One client some time ago had an AWS novice who was confident they could handle setting up the auto-scale groups. They made a small mistake, which lead to the scaling trigger being permanently on, and it auto scaling to 1024 ec2 nodes within the first half hour. Immediately after deploying a fix for the scaling trigger, I phone AWS to see if there was anything that could be done about the cost of this accident, and I had a small monthly credit to compensate, and a respectable discount on the next appropriate AWS training course so that the novice could learn more and hopefully avoid future mistakes. THAT is the kind of story I want to start hearing about Google Cloud. "I used it and did not have problems", and "It works and was cheaper than AWS" is just not enough.
vim_wannabe 9y ago
How does customer service work with technical services? There is very little time for developers of a system to use on support, so how do you go about building the baby padding around them? I would imagine at least 97.5% of support requests are a problem on customers end, so just how much support staff would you need for a global service like this?
victorhooi 9y ago
So my reading here is that the main issue is Firebase was undercharging customers, due to a bug. They didn't go back retroactively and ask for back payments, but just started charging them accurately going forward. Of course, that bill caused shock for some people, as they suddenly realised, "Oh s*it, I'm being charged accurately now, my bills are huge!!!" In this customer's case, apparently they were also doing something bad with TLS tickets and not setting keep-alives - basically causing them to spam Firebase with connections: https://news.ycombinator.com/item?id=14357270 https://news.ycombinator.com/item?id=14357270 Of course, there's the other issue of a communication breakdown which they said they're working on.
jamest 9y ago
(Some quick context for those not aware of the initial incident: In May we fixed two bugs in our pricing pipeline that caused some users to see price increases. Bug 1: we under-reported bandwidth (in particular SSL overhead) Bug 2: we were not enforcing quotas for all accounts. For most users, the fixes had little-to-no impact. For a few users who were using the Realtime Database with large volumes of small reads and writes, the impact was large. You could mitigate this impact by updating your client code, but unfortunately a user who had shipped code to their IoT devices couldn’t. This user was also simultaneously forced to upgrade to the Blaze pay-as-you-go plan due to quota enforcement on our $25/mo Flame plan. These combined resulted into a large billing increase for this user. We weren’t quick enough to provide this user with credits due to poor internal communication). To address these we have (1) worked to make billing more transparent on Realtime Database and (2) are working on improving support. 1a. We rewrote our documentation to add more detail on billing mechanics and how to optimize bandwidth (https://firebase.google.com/docs/database/usage/billing https://firebase.google.com/docs/database/usage/billing). 1b. We rewrote the documentation for our profiler tool which was confusing to many developers (https://firebase.google.com/docs/database/usage/profile https://firebase.google.com/docs/database/usage/profile). 1c. We now have better alerting for if/when we find errors in our codebase that can impact their bill (up or down). 1d. We will soon be releasing (spoiler alert) a new monitoring API to let developers directly analyze their database billing and performance data. 2a. We raised the quota on free technical questions from 5 => 10. Questions on accounts/billing/bug reports are still unlimited 2b. We worked to increase Support CSAT. It is up by 15% since the billing issue in May. Finally, the new database we’re launching today, Cloud Firestore, has daily budgets. You can use these to set exactly how much you’re willing to spend per day (more here: https://firebase.google.com/docs/firestore/usage#limits https://firebase.google.com/docs/firestore/usage#limits) We’ve also got extensive pricing docs: https://firebase.google.com/docs/firestore/pricing https://firebase.google.com/docs/firestore/pricing I hope this answers your question!
- Kiro 9y ago
  > You could mitigate this impact by updating your client code Where can I read about this?

steego 9y ago

For their own sake, I hope the team gives this question attention and respect. What sets Amazon apart from many other companies is their reputation for relentless customer service. Customers pay close attention to the quality of answer or lack of answers to questions like this one. Every cloud company that asks us to invest our time in their proprietary API is asking us to trust them. If you violate one vocal customer's trust, we're going to notice. If you don't make things right, we're going to notice. Even before I read the article, I first read the comments to gauge the reception because I care more about the perception of trust before I even consider using something like this. Customers don't always stop trusting companies for fair or valid reasons, but that doesn't matter. Trust is much more of a visceral thing than a cerebral thing. So here's my question to other HN readers. What would Google need to do to improve its reputation for customer service? What would they need to do to make that commitment resonate with you on a visceral level?

techdragon 9y ago
For me it's pretty easy. I want to start hearing and seeing positive anecdotes about real time communication with Google Cloud support. That is to say, I want to hear people start saying things like "I rang them, and everything was sorted out" ideally with a platitude attached like "it was actually a pretty good experience". I hear this about AWS all the time, and I've even experienced it myself. One client some time ago had an AWS novice who was confident they could handle setting up the auto-scale groups. They made a small mistake, which lead to the scaling trigger being permanently on, and it auto scaling to 1024 ec2 nodes within the first half hour. Immediately after deploying a fix for the scaling trigger, I phone AWS to see if there was anything that could be done about the cost of this accident, and I had a small monthly credit to compensate, and a respectable discount on the next appropriate AWS training course so that the novice could learn more and hopefully avoid future mistakes. THAT is the kind of story I want to start hearing about Google Cloud. "I used it and did not have problems", and "It works and was cheaper than AWS" is just not enough.

vim_wannabe 9y ago

How does customer service work with technical services? There is very little time for developers of a system to use on support, so how do you go about building the baby padding around them? I would imagine at least 97.5% of support requests are a problem on customers end, so just how much support staff would you need for a global service like this?

victorhooi 9y ago

So my reading here is that the main issue is Firebase was undercharging customers, due to a bug. They didn't go back retroactively and ask for back payments, but just started charging them accurately going forward. Of course, that bill caused shock for some people, as they suddenly realised, "Oh s*it, I'm being charged accurately now, my bills are huge!!!" In this customer's case, apparently they were also doing something bad with TLS tickets and not setting keep-alives - basically causing them to spam Firebase with connections: https://news.ycombinator.com/item?id=14357270 https://news.ycombinator.com/item?id=14357270 Of course, there's the other issue of a communication breakdown which they said they're working on.

jamest 9y ago

(Some quick context for those not aware of the initial incident: In May we fixed two bugs in our pricing pipeline that caused some users to see price increases. Bug 1: we under-reported bandwidth (in particular SSL overhead) Bug 2: we were not enforcing quotas for all accounts. For most users, the fixes had little-to-no impact. For a few users who were using the Realtime Database with large volumes of small reads and writes, the impact was large. You could mitigate this impact by updating your client code, but unfortunately a user who had shipped code to their IoT devices couldn’t. This user was also simultaneously forced to upgrade to the Blaze pay-as-you-go plan due to quota enforcement on our $25/mo Flame plan. These combined resulted into a large billing increase for this user. We weren’t quick enough to provide this user with credits due to poor internal communication). To address these we have (1) worked to make billing more transparent on Realtime Database and (2) are working on improving support. 1a. We rewrote our documentation to add more detail on billing mechanics and how to optimize bandwidth (https://firebase.google.com/docs/database/usage/billing https://firebase.google.com/docs/database/usage/billing). 1b. We rewrote the documentation for our profiler tool which was confusing to many developers (https://firebase.google.com/docs/database/usage/profile https://firebase.google.com/docs/database/usage/profile). 1c. We now have better alerting for if/when we find errors in our codebase that can impact their bill (up or down). 1d. We will soon be releasing (spoiler alert) a new monitoring API to let developers directly analyze their database billing and performance data. 2a. We raised the quota on free technical questions from 5 => 10. Questions on accounts/billing/bug reports are still unlimited 2b. We worked to increase Support CSAT. It is up by 15% since the billing issue in May. Finally, the new database we’re launching today, Cloud Firestore, has daily budgets. You can use these to set exactly how much you’re willing to spend per day (more here: https://firebase.google.com/docs/firestore/usage#limits https://firebase.google.com/docs/firestore/usage#limits) We’ve also got extensive pricing docs: https://firebase.google.com/docs/firestore/pricing https://firebase.google.com/docs/firestore/pricing I hope this answers your question!

Kiro 9y ago
> You could mitigate this impact by updating your client code Where can I read about this?