I guess that's one way to reduce customer churn.
I guess that's one way to reduce customer churn.
I am so sick of this reality. Endless dark patterns to get your money. Nearly impossible to get out. Why ever make a good product when you can just seek rent and fall into that perfect optimum of cheap-enough that cancelling is not worth the pain.
A site that remains persistently broken has a lot more wrong with it than just some software bugs.
So in this case, yes, there is a lot more wrong.
I'm not saying this is a good thing, but it's so common with paid software offerings that it's no longer a red flag for me; I just assume that blocking issues that can be presented as only affecting a small number of users will not be addressed, especially if they're considered temporary issues. AWS and Azure certainly aren't paying out a ton when they have outages or system errors that for all intents and purposes render the services offered or machines running on their infrastructure whenever they have issues.†
For me it's hard to escape the conclusion that many services are over-subscribing their Systems and Developer staff across too many things presented as a single service; identity management, compute services, storage services, payment processing, free tiers, and so much more under a single service. A systems error or login problem or the classic Google problem of a single flagged account irradiating everything it touches on the platform is all it takes to completely take down your operations.
And the SLAs/TOS/EULA are quite complex on these platforms; it's hard for me to think that most persons can truly understand what they are agreeing to when signing up for these platforms, including the companies offering the platforms; in my own experience dealing with Storage-aaS vendors who provide S3 storage, it's very hard to get straight answers on outages or massive 5xx situations. (Embarrassingly, said Storage-aaS vendors' support teams have said in no ambiguous way that a 5xx error responses is a _client side error_ that needs to be investigated by the maintainer of the client accessing the S3 services...and I maintain it's incorrect for said vendors to use 503/500 as a response for "please slow down" when we have the 504 "Slow Down" response with S3, or the classic 429 HTTP response could be served instead, both of which are actionable for client applications)
The services are too big and doing too much, and not always very well. And ignoring the "small" interruptions that basically prevent the users of the platforms from doing their work is the norm; if the issue doesn't hit at least double-digit percentages of users, my experience is that the platforms do not budge or move since it can be hand waved away. And the user recourse in such situations is basically non-existent; maybe you'll get some credit, maybe you won't, who knows? The platforms sure don't, despite the monstrous EULAs they ask you to agree to.
I don't know what the answer is, but I really cannot consider many of the platforms, regardless of whether its for work or personal social purposes, as reliable. If a platform is going to present itself as a backbone of modern internet/computing, it's really trying to claim it's a utility, but it doesn't want to behave like a utility, it wants to get more spending from the users; as long as this is the case, where the user capture efforts take higher priority than maintaining the services and using plausibly deniable tactics to eschew that responsibility, I cannot get excited or interested in platforms; I will use them as the projects I work on require the platforms, but if it were up to me, I'd not put everything on platforms and diversify as much as possible.
† You can [0] submit a request for credit, but I'm not sure how much credit is being issued this way; I will give AWS a small nod to the fact that at least for me, their SLA Guarantee page is "fairly" easy to read, but my issue is that it looks like they only will offer credit for a fairly small amount of specific situations, and it's unclear how many of these requests are honored. A very brief search for a few terms on how long/often AWS refunds occur returns mostly the official documentation pages without any statistics, and also a few posts from AWS forums with users asking; the first post on the few threads I checked though were mostly "here's what you could have done to avoid this" scenarios; maybe the users indeed were doing something quite wrong, but at the same time it's unnerving to not quickly find stories about the process working well and efficiently.
At almost every step, the system sort of nags you with "Do you REALLY want to do this?" almost with a trolling attitude!
If this is the case with proper big tech capitalist, think what will the scenario be with smaller pleb capitalists like Evernote in this grave recession.
I've found it easy to cancel ... and several times where I forgot to cancel, customer services happily, easily and promptly refunded the charge ...
I'm no big tech Amazon fan ... but never had a problem.
Intentionally (?) breaking the site so that you can't cancel is another story.
Also CC use is declining across the world as more people are realizing the problem of debt trap, they should come up with alternative methods like UPI and bank transfer.
Most likely it's not going to happen. While the card is virtual, payments are done with real money. Risking to lose a customer with real money isn't something most businesses will do.
When Flash was sunset -- they gave a BS reasoning and shutdown this tool as well whithout making an effort to rebuild / replace.
I am surprised there was no big backlash from customers given the increasing online fraud and privacy/security consciousness of banking users.
Which (US) banks currently offer this virtual CC feature? I am a customer of three big banks/CC and none of them have this.
For anyone not jumping ship, you can reduce your price hike to only 78-ish total per year by clicking through the cancelation menus.