Perhaps removing a pricing scheme so complicated that it literally can't be modelled usefully by the customer would be even better?
Also, I'm a big fan of "contact us for pricing." It's annoying for users who are window-shopping and want a quickie ballpark, but it helps you identify cases where standard pricing (or pricing which can't easily be described online) can be negotiated, and which the user would have otherwise overlooked. This doesn't work for things like most ecommerce, of course.
I have opposite feeling about them. They are like open invitation to give the sales guy a window of opportunity to look up your company website, and markup the price accordingly.
My biggest issue with these: when introducing a new tool/solution, we often don't know how much we want to use it. In particular, it will usually be introduced in a minor application first, and if it feels reliable and useful it moves to bigger systems and more critical roles.
Contact for pricing requires us to explain all our internal politics, budget management, which systems we have etc. upfront to random strangers, who are also incentivized to just onboard us first and push the sunk cost fallacy button from there.
I kinda feel this works best for companies that don't really care about comparing products and will buy whatever give them the best numbers on the contract (which is common for enterprise software, it's just not my personal cup of tea as a small fish in the game)
I make most of the buying decisions for tech tools for my company. And it is exceptionally rare for me to ever contact somebody for pricing. I usually move on to the next vendor with transparent pricing.
You can get away with it, if you are targeting a very small market with your product and none of your competitors offer transparent pricing. My own company does not offer transparent pricing and we can get away with it for the above reasons.
> The article states that the biggest factor was user misunderstanding of the options, not so much the number of different options.
(Emphasis mine)
It seems to me that you are in agreement with the GP :-/
When a significant portion of the target userbase cannot understand something presented by the software, the problem is rarely the users.
More developers should read Donald E. Norman's "The Design of Everyday Things"; even if you forget specifics in that book, the general takeaway is that the default position must be "It is not the users' fault!".
There must be significant evidence that the user is to blame before the user actually is blamed. The more users' that have that problem, the larger the body of evidence required to prove that this is a user problem.
More than 10% of target users have problem $FOO? Then you better have a mountain of rock-solid, beyond a shadow of a doubt evidence that the software/interface is correct!
Don't underestimate those kinds of customers.
For example, an ad for custom tile showers showed up in my feed. I just wanted to "window shop" the price, so I could get an idea if it was something I wanted to do, and plan when to do it.
I filled in the form with a "I'm just looking for a ballpark number, please don't call me."
No response.
Salespeople just don't understand how irritating phone calls are when you're collecting data: Whatever I'm doing at any given moment significantly more important than dropping what I'm doing to answer the phone. This is especially important if all I need to know is a ballpark number to know if I'm interested in having such a phone call.