How goes the work to improve customer service and support?
Thinking about 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?
Thinking about 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?
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?
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.
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
Of course, there's the other issue of a communication breakdown which they said they're working on.
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).
1b. We rewrote the documentation for our profiler tool which was confusing to many developers (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) We’ve also got extensive pricing docs: https://firebase.google.com/docs/firestore/pricing
I hope this answers your question!
Where can I read about this?
Look for the optimize billing section
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?