Live data from Hacker News

I analyzed SaaS billing dark patterns

quolum.com

171–180 of 190 posts

Re: I analyzed SaaS billing dark patterns

#171
post #168

Earlier quoted context omitted.

I still disagree with your premise. You’re saying that as long as the terms are clearly communicated they’re not a dark pattern, aka unethical. I think if you’re using your superior understanding of the dynamics of using your product to create unreasonable gotcha situations that customers would not have agreed to if they had any choice then that’s dark patterns. There are lots of examples but most revolve around lock…

The problem is that you're not defining "dark pattern" reasonably. "You’re saying that as long as the terms are clearly communicated they’re not a dark pattern, aka unethical." You're saying that something being unethical makes it a dark pattern, and that's wrong. If I rob you at gunpoint, that's definitely unethical, but it's not a dark pattern. "I think if you’re using your superior understanding of the dynamics of…

I think we are well into semantics now but my understanding of dark patterns as a concept is things that only succeed due to trickery or intentional obscuring if what’s likely to happen that aren’t actually illegal.

They’re technically OK but we perceive them to be unethical and unfair. Which is why they get a special name.

If they were not technically allowed they’d just be fraud. Much like your robbery example isn’t a “dark pattern” because it’s a felony. We already have words for illegal stuff.

Re: I analyzed SaaS billing dark patterns

#172

Earlier quoted context omitted.

I would say it's dark because the platform does not usually place any emphsasis in letting you know it's still there or not. There are no built in safety rails (like a check fuel light) that can help. These platforms are designed to be obtuse.

I'd challenge these being "obtuse", I think it's more likely that they are designing for a different type of customer. As an engineer working on a production system, everything in code, etc, I don't really want an alert saying "Are you sure you still want to be running your database?". This isn't really a feature that most production systems need. What I'd like to see is features for experimental work – being able to…

That's a good point(s). I don't need lots of obvious messages about what my system is doing if I already understand it. However, I'd like to see a "verbose" or "-vvvv" or "DEBUG=9" for any service.

I think I might be speaking from bias because I only use about 8~10 AWS services, but perhaps if I jumped into their ML stuff I wouldn't know wtf is going on. So maybe a beginner-billing mode switch would be helpful.

While most new programmers don't like to RTFM (at all!) and expect a quick search of stackoverflow to solve everything, I think the number of complaints of stealth billing are SO high on HN that it appears systemic. That's not good.

Re: I analyzed SaaS billing dark patterns

#173
post #88

Of all the nasty things somebody can do with billing, I'm surprised the author leads with card-upfront trials. "Free trials should not require a credit card." This is opinion presented as fact. This is not a dark pattern. Totally unrestricted free trials are wonderful, you've invested a ton in your product and you want a prospective customer to experience everything. But there are legions of abusers and bad actors of…

We have tried both trials with and without CC - the latter is obviously more effective. On the back-end however, this forced us to spend weeks developing an intelligent automated approval process to limit abuse (which is common). After that, monitoring systems alert humans to suspicious trial activity for further review. So it continues to be a lot of work. Financially, we love the idea of a true "free" trial. The ab…

> We have tried both trials with and without CC - the latter is obviously more effective.

More effective in initial trial signups or more effective in eventual paying clients?

Re: I analyzed SaaS billing dark patterns

#174

Earlier quoted context omitted.

Imagine the issues on something like AWS, Google Cloud, Digital Ocean, Rackspace, etc. Imagine if a company sets a limit. One that allows for burst and growth. Then they forget to update it, and then one day, all their servers, data and everything else is gone. Even if things are offline, they accrue costs, so the only thing to do when a limit is reached is destroy everything. What’s the balance?

I'm implementing this in my cloud hosting platform ( https://primcloud.com ) and how we plan to do it is email triggers when certain thresholds are met, and if no action is taken, give a grace period before taking stuff offline. Yes they will be charged for that grace period, but setting a limit of $200 and being charged $250 sure beats getting a random $1,000 charge.

Definitely.

Maybe a % with minimum time and a max on money.

Re: I analyzed SaaS billing dark patterns

#175

Of all the nasty things somebody can do with billing, I'm surprised the author leads with card-upfront trials. "Free trials should not require a credit card." This is opinion presented as fact. This is not a dark pattern. Totally unrestricted free trials are wonderful, you've invested a ton in your product and you want a prospective customer to experience everything. But there are legions of abusers and bad actors of…

I provide a free trial for my product even without asking for an email address, customers can just download and test it.

From what I can tell, this works pretty well, a good amount of the ones who test the product and up purchasing (after 7 days you are prompted to purchase to continue using it).

Re: I analyzed SaaS billing dark patterns

#176

> Your company needs a CRM, so you sign a year-long contract for, say, 50 seats on your chosen SaaS CRM. Then — yikes! After six months, half your team is laid off. Will the CRM let you adjust and pay for 25 seats for the remainder of their contract? > That’s a big NO. Unused seats? Still gotta pay for ‘em. (It’s called “SaaS waste” for a reason.) You committed to paying for 50 seats for a year. The CRM may have made…

It helps to observe how symmetrical something is, to understand how equitable it is. In this case, if you want more seats, they'll happily give them to you and charge more, so it would seem fair that they should also be happy to reduce the number of seats and charge you less or refund you. If they only accept increases and not decreases, it's not particularly equitable.

Re: I analyzed SaaS billing dark patterns

#177

Of all the nasty things somebody can do with billing, I'm surprised the author leads with card-upfront trials. "Free trials should not require a credit card." This is opinion presented as fact. This is not a dark pattern. Totally unrestricted free trials are wonderful, you've invested a ton in your product and you want a prospective customer to experience everything. But there are legions of abusers and bad actors of…

If getting the card upfront is about filtering free trial users, that doesn't support the usual behaviour of charging the user immediately after the trial ends. You can use a credit card as a filter without doing that.

Re: I analyzed SaaS billing dark patterns

#178
post #143

I run a SaaS service and noticed we did a couple of these 'dark patterns', but not intentionally! I've now added to our short term roadmap changes that will resolve these problems. 1. Emailing account holders a couple of days before billing to give them an opportunity to cancel. 2. Emailing account holders whenever a change to their account occurs which would affect billing. This wasn't us being 'dark' more 'lazy', b…

:clap: :clap:

Lovely. Most of the time it is software complexity that goes into the way or prioritization of features.

Hope your sales team do not start hating you for some of these changes ;-)

Re: I analyzed SaaS billing dark patterns

#179

Earlier quoted context omitted.

I'm implementing this in my cloud hosting platform ( https://primcloud.com ) and how we plan to do it is email triggers when certain thresholds are met, and if no action is taken, give a grace period before taking stuff offline. Yes they will be charged for that grace period, but setting a limit of $200 and being charged $250 sure beats getting a random $1,000 charge.

Definitely. Maybe a % with minimum time and a max on money.

This is tricky.

We have alerts from AWS for monthly threshold, but most of the time it is ignored until the $$$ becomes large enough for the Engineerin Manager to get worried.

Re: I analyzed SaaS billing dark patterns

#180
post #171

Earlier quoted context omitted.

The problem is that you're not defining "dark pattern" reasonably. "You’re saying that as long as the terms are clearly communicated they’re not a dark pattern, aka unethical." You're saying that something being unethical makes it a dark pattern, and that's wrong. If I rob you at gunpoint, that's definitely unethical, but it's not a dark pattern. "I think if you’re using your superior understanding of the dynamics of…

I think we are well into semantics now but my understanding of dark patterns as a concept is things that only succeed due to trickery or intentional obscuring if what’s likely to happen that aren’t actually illegal. They’re technically OK but we perceive them to be unethical and unfair. Which is why they get a special name. If they were not technically allowed they’d just be fraud. Much like your robbery example isn’…

Thanks for emphasizing about the line between illegal and dark. Makes total sense.
Post reply on HN