I analyzed SaaS billing dark patterns
quolum.com
quolum.com
"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 all kinds. Having an opt-in to use/abuse your platform for 2 weeks is not always viable. Card up front is not a perfect filter, but it's helpful in turning this noise way down and letting you focus on helping actual prospective customers become successful with your product.
ROFL.
I constantly get free offers on the mails, plus there are services to generate temporary card numbers for throwaway
It's the automated bots that a CC prevents. Even with "free" credit cards or generated numbers, there's a lot of friction in going through that to abuse the service's trial period.
> it is not free to acquire more credit cards
If a user is malicious then they quite probably have access to malicious cards too.
Moreover, you're locking out users who don't want to give you their card just to try a service.
The dark pattern is billing the card without consent from the user, or some weird implicit consent.
Yes, and they bear the cost of the users scared away by the extra step, so it’s sort of self limiting.
> The dark pattern is billing the card without consent from the user, or some weird implicit consent.
Yes, that’s valid to call out as a dark pattern, but the parent quoted the article as saying that requiring the credit card at all is a dark pattern or at least shouldn’t be done, so this isn’t a strawman.
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 abuse was the challenge but we're in a good place with it now. Customers/Potential-customers love it and so do we.
But as GP said, this and other signals require coding abuse detection, and then you must find a way to enforce this.
This is not the kind of activity you want to be involved in while validating a product concept and working toward pmf.
The next step would be an AI system (like the very impressive Stripe Radar (which admittedly is in a different context)) but we're not ready for that, nor would it bring us significant value over our current system. And again - we pipe things to human for things in the grey area.
More effective in initial trial signups or more effective in eventual paying clients?
Free trials can be limited in terms of services. Many times free trials are not necessary. If someone is willing to enter a credit they will pay a small amount.
I much much much prefer a no ties trial, even if you restrict functionality, volume or some other thing which makes it not useable for regular workloads. It’s a trial, I only need to get a feel for if I think this will work for me, then buy or move on.
OK, this is probably a stupid question...but when signing up for a trial of product/service X, why not put a "decide on X" item on your calendar for sometime near the end of the trial?
These days, I have a virtual credit card that allows me to change the CVC on demand, for just these kinds of services, and with that I void the use of this card for dark pattern payments immediately. If I think your service is worthy, I might give you good data.
Cos, that is one more place where the end user have to risk his/her/their PII. This is especially important considering the end user is trying the product out. The person has no idea whether they will invest in it or not. Yet, the person have to worry about their information leaked when he/she/they see this company on the news for a data breach.
Also, another problem is the overhead for the company on managing this data. The security, PR situation if this gets leaked. It's expensive and unnecessary. This is a risky business unless you are a data hoarder who sells them at which point that is again bad for the end user.
Also, anything related to finance is always hot. And this comes back to the same thing I made in the above comment, why should an end user who is just trying it out risk all of this? It's like telling a stranger a secret of yours. You wouldn't just share a secret with a stranger just because they say "trust me", would you?
It is the company who needs the users attention, not the other way around. The users shouldn't be punished for the same.
this risk will always be present. Choosing a well known processor will reduce it quite a bit imho.
If you're asking why a user would take on this risk, i would say that they are getting a "free" trial in return. By having to take on this risk, the user is more conscious of using the product, and cut out the people who would just kick the tyres.
Again, the burden should not be in the shoulders of the end user. There is no reason for the company to ask for credit card other than data sharing, other dark patterns and spam. Like many have mentioned, spam can be dealt with better by other means. These are companies who have tried it out. I don't know what else more to say. :)
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).
> 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 decisions based on that commitment, such as hiring people, or themselves committing to bigger plans with their providers.
Why should they get screwed because you choked? Don't commit to long fixed periods if there is any doubt you won't make it.
Same with "Here’s a similar problem with a different scenario: You sign a one-year contract with a SaaS provider. You start paying immediately. The process to get API access, build integrations, set up the software, and onboard and train your team takes three months.
In those three months, you still paid for a service you couldn’t use yet. In fact, you had to pay to set it up! You had to pay upfront to get the functionality you needed."
Do I generally think that's a bad policy? Sure (depending on whether there are significant resources required on the software company's side for you to build your integration).
If you're told this is going to be the case and agree to it, is it a dark pattern? Clearly not.
Specifically, to the extent that a contract diverges sharply from the general understanding each party has about how the world works, the more the drafting party has an obligation to clearly call out the terms in a manner commensurate with the importance of the contract term.
Legal documents aren’t software code, it’s a classic mental error developers make when discussing them. They are evaluated by humans.
For example, it would not be reasonable to have a single sentence buried in the middle of a 20 page SaaS contract that obligated you to purchase cat food, or signed away the rights to your apartment. Wouldn’t matter how plainly worded the sentence was and if it was duly signed. You’d still have to convince a judge that was a reasonable thing to do. Good luck with that. And regardless of legality it’s obviously not ethical it’s a trick, intended to be deceptive.
Obviously there’s subtlety to this and the exact details matter. But that’s my point. You can’t just fall back on the idea that anything you get someone to agree to isn’t a dark pattern.
The whole point of dark patterns as a concept is that you’re tricking people into agreeing to unreasonable things.
I said: "In general I don't think it's fair to describe anything as a dark pattern this is clearly communicated in a contract."
You said: "or example, it would not be reasonable to have a single sentence buried in the middle of a 20 page SaaS contract that obligated you to purchase cat food,"
I specified that it has to be clearly communicated. You responded with an example of something that very obviously is not clearly communicated.
The examples that OP gave are generally things that are clearly communicated. When you sign up for a SaaS service and agree to pay for a set number of seats for a set duration, it's clearly communicated - after all, it's an absolutely basic part of the agreement and one that always has to be actively discussed between the parties (the SaaS vendor must tell you that you're billed on a per-seat basis, and you must tell them how many seats you need).
What you're describing is all true in theory but not applicable at all to my post or the examples of OP that I cited.
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-ins and ratchet type mechanics. Things like making it easy to create data but punitively expensive to get it out in order to switch products.
Things like making it easy to scale up the service but literally impossible to downsize also can qualify, which was the issue we were both referring to.
Or your example of a setup period could also qualify. Sure if it’s like super clear I guess so, but it’s pretty easy to see that often in that scenario people don’t realize the implications of the “onboarding period” and it’s a bit of a trick.
I’m speaking from personal experience this kind of trickery is rampant in trying to interact with many of these services. I got far into negotiations with a household name marketing platform and notice they never once mentioned the mandatory fees for onboarding. They also never said a word about outbound email limits and data limits etc. I knew only from stories from someone who had gone with them, gotten locked into a year of spending, and discovered in the first week that the service was literally unsuitable for them given their requirements. I was in a similar negotiation with them at the time and they were trying to trap me in a similar way.
Humans have a pretty intrinsic concept of fairness. There’s a cottage industry of SaaS companies that don’t care about that and many of us find it exhausting and not ethical. They use deceptive tactics with customers and anti-competitive tactics to acquire or eliminate competitors so you don’t have choices.
It’s a fucking crisis. Which is why this whole thread is raging with comments.
"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 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."
Again, this is in no way relevant to the examples cited. Telling the customer that any seats they sign up for must be paid for a full year is not an unreasonably gotcha situation. It's a concept that's clearly explained, and one that won't be a surprise to anyone who has any experience purchasing SaaS products, because it's common industry practice.
As to the idea that they don't have a choice to agree, that's virtually never true with SaaS. It is an enormously competitive industry with multiple players in every major area. On top of that, if you're talking about tech companies buying SaaS products, they also have the option to build their own tools if they don't like the options that are available.
"Things like making it easy to create data but punitively expensive to get it out in order to switch products."
Again, this is true but in no way relevant to anything I've said. If it's clearly communicated that you're going to have to pay a million dollars to get your data out, it's a bad business practice but not a dark pattern.
You're applying the label "dark pattern" incorrectly to any SaaS practice you dislike. The phrase has a specific meaning, and any practice that is clearly and honestly communicated up front, even if it's a horrible practice, is not a dark pattern.
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.
I demand Bananas compensate me for my losses. Typical banana dark patterns.
It's arguing that no deal between two parties is unethical as long as both parties are clearly aware of all aspects of the deal and their consequences and neither party is coerced into agreeing to the deal.
For example, requiring a credit card for a free trial is to prevent free trial abuse. A normal person can only get so many valid credit card numbers, assuming you can detect burner cards (which for the most part the CC companies will happily help you do).
Yes, a good company will notify you that a trial is going paid, and a great company will require an affirmative action on your part, but the main goal isn't to trick you and hope you forget.
Also, the part about not prorating costs if you use less resources. Usually you get a discount for paying up front. The reason you get a discount is because it allows the company to do more efficient resource planning, a savings they pass on to you. If they allowed you to cut back, you haven't upheld your part of the deal. A big company can absorb the loss, but a small one can't.
Yes, some companies do these are dark patterns to increase their profits. But most have some pretty good non-nefarious reasons to act like they do.
So maybe Stripe knows which burner providers have their own restrictions and treat them differently?
Requiring 3D secure may.
Depending on the product and audience, the prevalence of virtual cards may be extremely low. Outside of hackernews, the payments industry, and business cards nobody uses virtual cards like privacy.com
Not trivial to detect something like privacy.com or for that matter any virtual card product.
Blacklisting such cards is a Hobson's choice [1] for the SaaS merchant. A lot of legit users with legit reasons use virtual cards and flagging them could be loss of revenue.
They didn't accept my ID and I wasn't able to stop the service and the recurring payment. Fortunately I registered my payment with a prepaid credit card, so was easy to empty the card and let them billing into the void.
Since then, I always use a prepaid card for recurring payment. It saved my ass in a way.
One of the largest dark pattern is also having a poor customer service.
Many vendors have now optimized their billing flow to reduce write-offs. They start charging on the first of the month for the upcoming use, and then cancel the account if the auth continues to fail.
Let them sue over it. They'll just love how the courts would rule in favor of a customer who clearly tried to recover their account in good faith and tried to cancel the billing in good faith and, failing both, canceled the billing in the only remaining way since the company provides literally zero customer-friendly options.
Infact, when disputing such charges with the issuer, the customer always wins if there was an attempt to cancel the service.
I remember many people on HN defending this pattern saying that they are not interested in people who don't want to provide their CC details, that they are bad customers, they just want a free ride, and they are not sorry for setting it up like this. Oh well. I guess with time more people get burned and will finally learn the hard way this is just one of many grey patterns.
At most it could be a signal that a business intends to be a douche, but that’s only because douchey companies ruined it. Just like duchey free customers ruined that for everyone.
My employer probably thinks payroll is a “grey” pattern by this logic.
I probably wouldn't move forward as a potential customer myself once the credit card requirement pops up unless I'd already done my research and was pretty sure I wanted to use that product.
They could lose potential customers, but they also probably eliminate a massive amount of customer support... which maybe they just can't afford yet. Customer support isn't free.
But you need to factor this in. Nobody forces you to offer free trial. But if you do, you need to accept the fact that there are people who are going to use your product for free to the maximum available capacity.
In the old days, it wasn't much of a problem: you basically gave away pieces of software that stopped working after a certain period usually with limited functionality. There were many variants of this model: demo, trial, shareware. These free users didn't incur any direct costs for you (often someone else would do that for you, like computer magazines). Now, with SaaS, you need to provide computing resources for them - but this is your marketing cost. This is the problem of the model, not the customers. If you tell them they can use it for free for 2 weeks, they have the full right to use it and stop, period. They are not duchey unless they abuse the system by doing something clearly wrong, e.g. exploiting a bug in your software.
You have to weigh the pros and cons. In some cases the cons might outweigh the pros and so you further qualify your free users, for example by requiring a Credit Card.
This can be a big problem in freemium (and open source) type products.
That seems like a reasonably balanced transaction on both sides, not sure it fits into this framework. There are so many far far worse practices out there.
I see your point but there are many problems with this approach.
1. First, I'm not sure if I'll actually pay. It will happen only if your product manages to convince me it is what I need, that there are no bugs, that the support quality is good enough etc.
2. For core functions related to my business, if available, I'll always choose non-SaaS solution over SaaS-based to avoid vendor lock-in and unnecessary dependence. So, the conclusion of (1) and (2) is that you need to convince me to try it and stay. You will increase your chances by making the CC data part skippable.
3. I burned a few times in the past (with shady cancellation polices). Even if you are a honest business, I have no idea what expect. Why don't you let us get into a closer relationship instead of putting your hand in my pocket before we even got properly introduced?
4. Very often I just need to understand what the project is about. Sorry, most marketing descriptions are utter garbage and the exceptions are quite rare. So I really need to try to even consider the purchase. And I do pay - I pay with my time and attention that I give to your project. If you block this possibility, you lose, not me.
For certain types of customers, it is surprising and annoying to have to fill out CC info at the end of a trial. The customer gets the notice the trial is ending soon, but ignores the part about adding CC info to keep using after the trial. Then the day comes, we get them on the phone to ask if they will stay with us, they say yes but the person who has control of the CC is gone for the day. You’re not really going to turn it off are you? Sorry, but we have to.
So the easy solution is to make the credit card form recommended but skippable. Skippers just need to know that the trial won’t be extended if they can’t pay. In either case, they still need to give the OK to charge at the end of the trial.
My favorite recent one was a renewal if you don't cancel by a deadline that's months ahead of the actual end of the contract period and it also had a substantial rate increase and all the language that we supposedly agreed to wasn't actually present in the contract we signed.
Those terms were in one of those "incorporate by reference" clauses where it says this contract incorporates terms and conditions that are at the following URL and it's 45 pages into the fine print of that URL. I mean supposedly, since it's their URL and could just change the terms whenever they want and lie about it.
Which by the way wasn't clickable in the Docusign. Basically it was in an unlit basement behind a sign that said beware of the leopard.
It's not ethical. It's just exhausting to deal with some of these companies. I think we all know who they are, they tend to be concentrated in the field of SaaS companies that cater to the sales and marketing functions.
Lately I've had what I've found to be a fairly clever solution however. We wrote up a standard document that contains our terms and conditions for SaaS providers.
The key clauses basically say "We hereby give formal notice that we do not consent to any automatic term renewals, any automatic price increases, any charges to credit cards made 'on account' without our specific consent as to the date and amount charged. To the extent our agreement requires advance written notice of any of the above this letter serves as that notice." and so on.
Then we send it certified mail to the company's corporate HQ address and keep the tracking number. We do this on the same day we sign any software contract, it's basically an automated process at this point.
So whenever it comes around, and it has, we just say sorry we've already given formal written notice we don't consent to that. Here's a scan of the document and the USPS receipt maybe work on your internal communications.
The fact that we have to do this is apalling but hey it's better than the alternative.
But in real life what it really does it get them to back off and go back to having a normal negotiation about what we do want to do for renewal instead of the bullshit attempt to mislead and trap us.
Needless to say if there's any viable alternatives to companies that do this we take them but in some categories all the options suck.
If the contract says you must give a non renewal notice by X date or you agree to a renewal then the letter is written notice. The trick is making it the same day you sign the deal and making it all inclusive.
It doesn’t change the existing contract it abides by it.
I think the original contract is enforceable at the time it was originally agreed to. Coming up with additional terms, even if they were on the same day, wouldn't not change the original contract. Imagine signing up for a credit card offer and then sending a certified letter to the bank informing them that you will only pay a lower interest rate that you designate.
I think the stronger argument is the "incorporated by reference" argument, given the fact that those could be changed at a later time. The terms of a contract need to be clear, and any ambiguity would likely be settled in favor of the party to be charged.
I have always been suspicious of the "Click to Agree" box at then end of a long contract that no one, including the company offering it, has ever read. The problem is that there are so many (generally unlikely) contingencies that have to be accounted for. What other choice is there when there may be substantial liability in question?
It’s about required notices. Basically the contract has opt-out provisions that they hope you either won’t notice or will forget to opt-out of.
The idea is simple, you just reverse this dynamic by immediately and pre-emptively opting out of every optional element of the contract that could cause you to incur additional financial obligation.
But isn't there a risk that if the company that gets your certified mail, reads it, and then cancels your account?
As a practical matter though I don't think there's much to worry about. These guys don't have a process to field letters like this.
The joy comes from the elegance of it all. If they want to play a game of exploiting the fact that people don't read the fine print then they should be prepared for a fair contest.
:clap:
Which they will the decline to sign and require you instead to sign there standard, cleared-by-their-legal consent to treatment form before providing any services.
If you could afford the kind of providers that would be willing to even consider a nonstandard agreement, this probably wouldn't be a concern you would have in the first place.
I’ve also repeatedly been asked to sign one of those electronic signature pads as the signature to a document that I am not actually seeing. Which is a ridiculous thing to even consider as a workflow. When that happens I just sign the words “not shown document” instead of my name and move on.
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 mark an AWS account, or org, or maybe individual services/resources, as "experimental" and have it auto shut off after some reasonable amount of time, with clear warnings during use (as much as possible) that this is an unsupported experimental service.
Hell, if the time limit/capacity limit was low enough, I feel like these could be a permanent free plan with cloud providers.
The question is: are these customers worth designing features for? I could see why they might not be, although I think it would be beneficial to the industry.
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.
Even in the cases where you're allowed to cancel on the last day of the subscription, we as humans are very prone to forget to do that, particularly for longer-term contracts. Tracking contracts and subscription deadlines is a damn profitable habit that I wish I had acquired much earlier.
Not sure about credit damage, but in case of a loss in such a suit, I'd also have to cover the expenses for the other side, so it's a risky proposition.
With my wife we did consider it for a while, but then decided it's better to do focus on solving that problem with software and thus started working on contrax.app (shameless plug!).
> As a result, ended up writing a small PWA to keep track of my contracts and subscriptions.
You can provide this as a yearly service where if by the ninth month they don’t cancel, they must use it for another year ;)
Edit: oh you already do sans the contract terms
Those who run a SaaS will know what I'm talking about (for example, the difference between no-credit-card-required trials and credit-card-required trials is about support costs, not about secretly charging that first fee). They will read the article, conclude that it's ridiculous, and skip it.
For those who do not currently run a SaaS themselves, please critically read the article and do not immediately conclude that all SaaS businesses are immoral and use "dark patterns".
I will _never_ provide a credit card for a free trial because some companies will charge you at the end of the trial and I don't have time to figure out whether you're one of those.
I will _never_ provide my phone number for "security reasons" because a load of companies used that excuse to get the phone number then used it for marketing or for correlating it with other personal data.
I say that as a failed SaaS co-founder. Being ethical was no part of the reason the SaaS failed.
The word "ethically" implies a strong moral judgment.
We can discuss ethics of course. For example, why would you think that charging at the end of a free trial is a problem, if this is clearly stated when signing up, notification E-mails are sent before any charge happens, and refunds are provided with no questions asked when necessary? What exactly is "unethical" here?
But my point was that many of these decisions are made not because of evil approach to making more money, but because of very practical and down-to-earth things. For example, requiring credit card information before a free trial reduces your signups considerably, leaving only the most serious potential customers. That lessens your support and onboarding load, because you do not spend time supporting non-customers that would not pay you anyway. Obviously this is not a clear-cut decision, but I'm trying to point out that the basis for making those decisions has nothing to do with morals, ethics or "dark patterns".
That kind of "dark pattern" conspiracy thought implies a lack of understanding of how a SaaS operates. It's very naïve to think that a SaaS business would care about charging for the first month through "dark patterns". If you run a SaaS, you care about long-term customers, retention, LTV and MRR. New signups are often actually a loss over the first months. So grabbing someones $49 through a "dark pattern" makes no sense: it actually lowers your important metrics, and makes you lose money, because that customer will usually contact support.
You make these decisions for these reasons, and others do it so they can charge me at the end of a free trial. I don't have time to figure which one of these companies you are.
That being said, if I got redirected to a CC company website so they could verify my identity and give you a token, so you can prevent free trial abuse, I'd be down with that.
Only recently did I discover GSuite has an FAQ for getting out of reseller agreements. Going to have to act on that.
We have a SaaS product, and we see that as well. Usually our sales folks will have a look every now and then and see if there's a lack of activity.
Almost always it's the result of someone quitting or losing their job, and our software gets lost in the handover of responsibilities. I've heard of several cases where sales has effectively re-sold our software more than 3-4 times to the same division in a company over the years.
> That’s eight months of paying for nothing.
You signed up for a service. You stop using the service but don't cancel. How is that anyone else's fault? Furthermore, your accounting is so bad that you didn't notice for months. Making cancellation difficult and other similar things are dark patterns, this complaint though is just disorganised people trying to pass the buck.
> If you’d received an email before the bill hit
That would be nice, and many providers do that (I get an invoice for the dedicated server I don't properly use yet each month, which is a reminder that I should get around to the rest of the things it was intended for or downscale the operation), but you could also set reminders when you sign up for something, or keep an eye on your accounts.
> Unused seats? Still gotta pay for ‘em.
Ask yourself this: if you had customers who agreed to x00 users each and you paid for infrastructure and employed support staff to support this level of user activity, would you be happy to take the hit when half those user accounts don't all end up being needed? I doubt it, so you shouldn't expect other businesses to do so either. Your planning failure is not someone else's problem.
> But what if ... you actually ... wanted to add the seats. Well, the CRM would be only too happy to accommodate!
Again I wonder how much business the writer is willing to give away for free. There are no links to their own policies to suggest that they operate better than what is being complained about here - if such evidence existed I'd expect a noise to be made.
The real issue that is here sometimes is deliberately unhelpful bracketing of payment plans, jumping straight from 20 to 100 to 1000 seats with no provision to pay for a smaller amount of extra seats (perhaps at the 20-plan per-seat cost) because you need 110. But simply expecting to maybe not have to pay at all for the extra is a sign of a distasteful entitlement personality defect.
> I’d love to know if you’ve seen or experienced these dark patterns — or worse!
Ah, the infamous “please gift us free content for our future articles”!
I reached out to a Senior Product person at a very large SaaS vendor on auto-scaling the seats -- based on simple monthly active.
His response: "Our Sales team would never let that happen."
For example, I've yet to find a cloud provider that lets you, say, put a $200 a month spending limit on your account. The best we get is a notification system.
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?
That's not the only thing you can do.
It takes quite a while from non-payment for OVH to take down their clients' services and delete their data, for example. They give customers a month long grace period before taking their service offline, and then there's another waiting period before they delete the data. At any point clients can resume service with payment.
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.
Maybe a % with minimum time and a max on money.
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.
You subscribe for $X/month. That buys you Y credits, which you then spend at different rates depending on your usage. Some services are credits per minute, some are fixed credit amounts.
Not only do you have to guess your capacity requirements, you also then have to translate that into a series of tiered variable costs and fixed costs, and translate from credits to currency (often working through bulk purchasing rates) to figure out how much you'll be billed.
I manage a SaaS contract that bills like this and I'm not sure I've ever accurately predicted our bill. Also one of their fixed credit cost items is clearly 10x more expensive than it should be when you actually work through the numbers to see how much it costs.
Love the software, hate the billing.
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', but thanks for highlighting!
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 ;-)
Others are around legislation, such as the one that came yesterday from FTC on call to cancel being illegal.
Could use alternative methods to prevent spam, like sms etc.
Requiring a credit card is asking for too much trust from the user.
Big yikes.
I'm curious which of these approaches would have the biggest impact on bringing that SaaS waste down.
In the early days AWS EC2 became popular for their per compute per hour pricing compared to hosting providers fixed monthly cost.
I'm not in business to provide services to people who want stuff for free permanently. They complain on forums, raise stink and spend nearly no money. They are not my customers. I always ask for a credit card for a free trial. The fewer non-customers signup, the better it is for me.
1. Whoever tries the service at least theoretically met minimum qualification to be a customer - they have a credit card and can authorize several hundred dollars on it.
2. We get the real lead.
3. We limit the number of people who recycle free trials -- this happens a lot.
Do you ever offer to extend free trial for people who want to cancel, and do you convert them back?
Yes - but that's the sales reps job. If they think we have a decent chance of converting "no" into a sale after they reach out to the customer to find out what, if anything, made the customer decide not to become a paying customer, they can extend the trial.
In my experience the vast majority of the convertable free trial expiration without conversion is lack of time on customer's side -- the customer did not really use the product. So now our sales people actively approach those customers.
Hotels do it, authorize you for N nights during check-in capture/sale during check-out.
You can have an opinion without being dishonest about your interest behind it or its controversy, no?
If you see differences, one reason is that with hourly billing your monthly bills will be different, depending whether it’s a 28, 30 or 31 day month.
Some services will be higher if you don't account for all the costs. You can do the math for an EC2 instance but if you don't account for storage prices and bandwidth prices then the bill will be higher than you expect.
But some service prices will be lower than you expect. If you create multiple EBS snapshots from the same server, you'll notice that the price you pay isn't the sum of the individual snapshot sizes. It's far less because each new snapshot only saves data from blocks that have changed since the last snapshot.
First, supporting desktop/mobile software can be hard. Customers have all sorts of weird things on their machines. iOS cuts down on that, but you still lack access for a lot of debugging and that can cost a lot of money. Support is expensive.
Second, I think there's this idea that desktop/mobile software is a one-off. What happens when Apple removes an API that your program used? Do you tell uses "sorry, your $X doesn't entitle you to a working program anymore?" For better or worse, software requires ongoing investment. If software requires ongoing investment, it kinda requires ongoing payment - or operating on the idea that new users will pay for the improvements required by older users. However, that's a dangerous assumption. At some point, there are a lot more older users than there are new users. Many companies tried to operate pension schemes assuming that new workers would pay for older workers retirement benefits. At some point, there are fewer new workers than there are old workers and it collapses.
Software maintenance is important, but it can be hard to price. Do you tell users "you have a license for 2.0, but you'll need to pay $X to upgrade to 3.0...oh, and 2.0 won't be updated to support iOS 14 so you're basically forced to upgrade"? Do we tell creators "if you don't keep this software maintained in pristine condition for the next 20 years, you're being predatory"? That kinda just demands that they do uncompensated work.
Even if software isn't hosted, there are ongoing costs. Some of that can be priced into the initial purchase of the software. Some of it can't be. It's hard to guarantee that software will continue working for 2, 5, 10, 20 years when you have no idea what that might entail in terms of work. 20 years ago, Apple was shipping Mac OS 9. Since then, I may have needed to upgrade my app from Classic to Carbon, from Carbon to Cocoa, from 32-bit to 64-bit, from PowerPC to Intel, and now from Intel to ARM - not to mention the huge number of APIs that have been broken along the way.
Is the right model something like what JetBrains does where you get a perpetual license to the version you bought, but that version might just stop working given changes around it (like OS upgrades or new machines it isn't compatible with)? That doesn't force you to subscribe, but it does mean that you're likely going to need to upgrade. Programming languages move on and you're stuck with an IDE highlighting things as bugs or that won't launch your program because it isn't compatible.
Subscription-based pricing gives creators an incentive to keep investing in their program and it gives customers predictable costs. No one wants to hear "sorry, this won't run on M1 and we're not going to upgrade it for free for you so here's a $X charge that you have no way around given that Apple is abandoning Intel".
I have Windows desktop software (my product with about 40,000 customers) that I support and I would not call it any harder than maintaining for example backend C++ servers I make for my clients.
>"What happens when Apple removes an API that your program used?"
No idea about Apple as I do not develop for their platforms but my yet another desktop software (uses DierctX 9 and DirectShow) that did release in 2003 and abandoned sometime in 2008 as the revenue had decreased still works like a charm.
>"Programming languages move on and you're stuck with an IDE highlighting things as bugs or that won't launch your program because it isn't compatible"
That DirectX program I just mentioned was developed in Delphi 7 (I use Delphi and / or Lazarus to develop desktop applications). This Delphi 7 still runs and compiles this software on my Windows 10 machine. Latest Delphi which I have compiles it as well with no problem (just checked).
So yes in theory you are right, in practice (as much as it concerns my products) it is however totally irrelevant.
Another dark pattern is switching off your customer's apps remotely as Adobe did to their customers in Venezuela two years ago.
It’s vastly easier, simpler and cheaper to support hosted software.
On the flip side, one of our competitors who hasn't switched has been struggling for years and a recent new version almost killed them off as many customers didn't feel they could justify the $10-20k or so to buy the license to the new version.
A key part of our success is that the subscription price scales linearly with customer activity. There's a fixed base price per active user, and in addition there's a cost associated with certain actions. This means that the subscription price scales with the customers activity and hence income. If they have a slow month they have less income but pay less, if they have an active month they have higher income but they also pay more.
FWIW our software is primarily installed on premise, but we do offer hosted service as well (base cost is different for the two cases).
For the software I buy one time price is often about the same as the annual subscription. With perpetual license however I often do not upgrade for years. So the perpetual licensing is a clear winner for me. I understand that SAAS can make sense for other customers but it is their choice not mine. I just simply do not buy software without perpetual license. It ruffles my feathers in a bad way.
Of course I am not talking about services where monthly payment is a natural state like Netflix.
That of course changes the balance. In our case the annual sum of the subscription is much less than that. More like 2-3 years before intersection, though I forget as we've had this system for over a decade now.
It should be noted that we're also in a segment where customers will need a new version now and then as rules and regulations change.
It's under Paypal so I don't feel surprised at all. Just another enterprisey payment company