Enterprise customers can ask for different payment terms (bank transfer instead of credit card, 30/60/90 day payment goals), legal and security review, different termination periods, amendments to the standard contract, sometimes different currency. So it starts a discussion of their requirements. Some companies won't even tell you their requirements before signed NDAs were exchanged. Others require you to create an account at their finance system (SAP, Cisco, Oracle Financials and such).
Then depending how formal the customer is the reply can be a text email with a quote, a formal quote that looks almost like an invoice (PDF), or even a 10 page draft document for further discussion.
This might sound like a lot of extra work, something that can't easily be automated, but those companies are used to long sales processes. The product manager needs to liaison with their legal department, then with their accounting department.
"Request for quote" and "contact sales" are essentially the same.
Oh, I didn't answer the "How do you come up with the pricing" part.
Pricing is usually the same only scaled higher. We have an Excel spreadsheet that's an extension of the public pricing page. Then we look if something is complicating the contract (but we might only insist on minimum contract length, not higher price) or making it easier (they need less features which actually cost us less money and we can give discounts).
That's for an established SaaS. I assume any new SaaS only few months old will just make prices up on-the-fly (we did!).
It's not the price. It's the stupid insistence on putting "SSO" -- which even a single dev should be doing, preferably using OIDC so nobody does any work! -- behind that button.
OIDC is the only way to get proper 2FA into all services without adding tons of friction. Friction reduces acceptance and usage of 2FA.
Every service that puts SSO in an enterprise tier is a security risk and shouldn't be touched with a 10 foot pole.
Go ahead and put Kerberos and SAML and maybe even LDAP SSO in Enterprise tier, but if you put OIDC in enterprise tier, you're responsible when your customers will get inevitably hacked.
If an organization made a deliberate choice of not paying 5000 USD/mo for extra security, then security is less important for them than this amount of money — so they get what they pay for, and it’s their responsibility.
By that same argument, you could also make security patches exclusive to the enterprise version for a certain amount of time after they've been released.
Only big corporations need security, after all, if a small company gets hacked, well, they should've paid more?
What kind of late-stage capitalism is that? You're knowingly selling an insecure version and somehow it's the customer's fault they didn't buy the "actual security" addon?
I am ready to agree with you if you’re not being hypocritical here. Surely you’re doing only the best work for your employer, and spending your own unpaid leisure and sleep time on honing your non-marketable but company-demanded skills, undergoing psychotherapy to get along better with your manager, and thinking of all the opportunities to save your employer more money.
It would be a shame though if you demanded unpaid work from others, but didn’t live by the same rule yourself.
I've forked quite a lot of open core projects to add enterprise tier SSO support to the open version, with my forks published under AGPLv3. I'm true to my word.
As a customer that process makes sense if I had those extra requirements, but why do so many SaaS lock SSO (Google/Microsoft) behind their Enterprise offerings?
I get that it's for differentiation between plans, but as a customer it feels weird to walk into this pricing black hole just for SSO. Maybe you have some experience with that?
Most SaaS companies will tell you that they would rather not lock this important security feature behind enterprise. But the reality is that it is one of the few things enterprise will pay for and gate on and as such it’s become very effective as a differentiator. The edict to gate everything behind SSO is powerful in large enterprises and as such they will absolutely pay to be able to do that, making it a very easy internal sales tactic. The market has spoken, for better or worse.
I read your comment as saying that SSO is denied to “regular” (non-enterprise) customers because enterprise customers would buy the regular product if it was included there, thus pointing out that all the other “enterprise” needs (terms, etc) aren’t real?
Most enterprise features are nice-to-haves. SSO is a must-have for companies with enough security or compliance ceremony, which includes most enterprises.
Small companies don't need sso because when an employee leaves, they just go into all their sass and remove the user or change the password. A large company can't work without SSO because in an org with hundreds of users they can't login to each SASS and disable and enable everyone coming and going at the company, which is many per month in some cases.
This is very much correct, and quite self-evident: they live without, therefore they don't need it. Wanting something != needing it. Companies that actually need SSO are the ones that have internal or external compliance requirements, and/or for which managing users without SSO becomes prohibitively expensive. Turns out, at that point, they're willing to pay through the roof for it.
> quite self-evident: they live without, therefore they don't need it
Lots of people live without things others observe they need. Doesn't make going without a good idea.
> Companies that actually need SSO are the ones that have internal or external compliance requirements...
This logic is backwards.
Why do you think SSO is a "requirement" that security certifications or compliance policies look for? Why did that come to be? Who does SSO benefit? Are those personas relevant for only large companies or small ones too?
Do beginning drivers not “need” seatbelts or brakes? Or are these devices only needed to avoid tickets and pass inspection?
One thing worth pointing out. If you don’t mind using GitHub or Google you can get “SSO at home” for a lot of things, since most
SaaS provide Google/Github login in their lower priced tiers. It will usually be OIDC based and not SAML, but it’s definitely possible to use these providers up to a quite significant scale.
Why? You use SSO in your personal life all the time. Why would you not want to continue doing so in your business?
If anything, small companies need SSO more than any others - those companies usually outsource a lot (SaaS vs a dedicated hire), managing credentials is annoying.
SSO has lots of other benefits. MFA primarily. This is non negotiable these days, even for the smallest company. I’ve not seen many services supporting this without SSO.
Don’t get me started on the services that have their own smart ideas on what constitutes a safe password. Max 8 characters with no repeated letters and of which 4 must be an emoji, with automatic logout every 12 minutes. Yes those still exist.
Password policies are things you want control over in your IdP to avoid all this BS. SSO really should be standard.
> This is non negotiable these days, even for the smallest company.
Says who?
In reality, users don't care. Regulators, however, sometimes do, which leads to certifications and compliance requirements - and only then SSO and MFA become non-negotiable.
I work with a variety of small companies (5-25 FTEs) that are increasingly facing strict MFA requirements in order to maintain insurance. SSO isn’t an explicit requirement, but there are a myriad of general access requirements that they struggle to follow without some level of centralization via federated identity/SSO.
Because SSO outside of the OAuth2 happy flow [0] can be a pain in the ass to develop for and support.
Some customers use Okta; great! But some of those customers have Okta configured in ways that don't work with your auth service. Some customers use Okta as a downstream to their _actual_ IdP, which could be Keycloak (a million different ways to configure that) or, god forbid, some custom thing they wrote. You've gotta support that.
Some customers (the ones that will pay the REALLY big bucks) use Active Directory Federated Services and SAML-based auth. SAML is XML/SOAP. Gigantic pain. Gotta support it.
Some customers want LDAP/LDAP-S based auth. Gotta support that.
Given all this, it makes much more financial sense to lock that behind customers who are willing to pay the big dollars for enterprise-y features AND support instead of dealing with infinitely long support tickets.
[0] There is no such thing as a happy OAuth2 flow.
In my experience SSO is high-touch. Sure there are self-service portals and control panes but big company IT departments are ticket processing machines, and it becomes a game of broken telephone to make changes. When something doesn't work, what do you do?
Offering SSO as part of an enterprise SKU offering implies there is a high-touch relationship out of the gate, and that there is a higher chance of success and adoption, including getting SSO set up right.
Furthermore many large behemoth corporations have strange SSO configurations and it's not unusual to require bespoke configuration let alone debugging time.
People are currently implementing a simple self-service for common SAML and OIDC providers, like O365 and such. This will be free and recommended for all customers to use, because I believe in providing actual security for our customers.
And then you can order a consulting project on top to figure out a good way to import user groups, user identities and such into the platform, and ideally to integrate our preferred group structures with a customers existing approval and group structures. This also includes help to initially connect us to the IDP. This is priced at a relatively cheap consultant level.
And then there is a second tier of consulting projects if the customer is using a non-standard IDP and can't do it on their own. Like, we have one customer that has an in-house developed SAML provider, but the original people who worked on it aren't there anymore. That was an interesting project and I learned way more stuff about SAML than I ever wanted, and also fixed a bug in their SAML provider code. This is priced right between "subject matter experts" and "no".
That's what I consider a very fair split. Simple SSO for everyone, especially on standard providers. And if you want to save a day or two of your identity and authentication teams, you can hand us some cash to do so. Smaller customers generally won't need this, they usually just have 1-2 groups they want to push and that's easy to do, but large customers with complex directories and many users in different departments like these projects a lot.
Go ahead, make SAML, Kerberos, LDAP, whatever custom solution paid. But OIDC should be free, ideally even with my own Keycloak. Go ahead and put all the customizations in the paid tier, again, fine. If I want user/role mapping, I can set it up in keycloak.
But it's silly paying more than a FTE's salary just for the SSO tax when you've got 5 people.
> why do so many SaaS lock SSO (Google/Microsoft) behind their Enterprise offerings?
"Price discrimination" is a pricing strategy where very similar products are sold at different prices in different market segments.
Imagine you've invented an amazing silver bullet that makes software developers 30% more productive.
For the likes of Google who pay developers $200k/year, getting 30% more productivity would be a great deal even if you were charging them $10k per user per year, because that productivity boost is worth $60k.
For unpaid students, casual users, open source projects and cash-strapped micro-businesses - a 30% improvement in $0 is still $0 so they can't afford much. Maybe $50/user/year, and they'll still complain like hell about it. But it'll help your tool spread and build word-of-mouth.
So how do you price your product - $50 or $10,000?
With "price discrimination" you can do both. Offer a cheap tier for home users and micro-businesses, and an enterprise tier with features Google desperately wants, at a much higher price.
By having prospective customers call for pricing, your sales folk can research each customer and figures out whether they're the kind of place that pays their developers $200k/year or more like $30k/year - allowing them to figure out how much the product is worth to that particular customer.
I don't have experience with SSO. It's a typical feature SaaS tries to charge extra for (https://www.enterpriseready.io/#features). Maybe they don't have an add-on feature in their billing app.
I tell you why: SSO means I'm going through a qualified purchasing route, which means getting finance/procurement and then subsequently IT involvement. SSO implies I'm using the product company wide, versus a group of 2~10 people in the marketing group. As others have mentioned, there is a very justifiable reason to have a relationship between sales and procurement/IT.
Unpopular opinion - you may like to call it an SSO tax, but I think it's perfectly reasonable from both sides. The reality is - if you're a 10 person startup and the "SSO tax" is annoying, then simply don't do the SSO version...you have 10 people in your company, you can get them all to use a password manager with MFA. If you're worried about security then fine, don't you think it's worth paying a little more?
If people's issue with the "SSO tax" is that the SaaS software provider is making incremental money for very little effort/investment, then I would love to explain how the economics of most SaaS tenancy models work with regards to infrastructure spend...
Having been an infrastructure provider for 30 years, this answer is largely unjustifiable.
It's a bunch of handwaving to try to get price discrimination for a "how the Internet is supposed to work" standard everyone, even a single dev client of the SaaS, should be using.
And that the SaaS provider should be pushing so they don't have the liability of subscriber credential database protection ...
> even a single dev client of the SaaS, should be using.
Having assessed 600+ software companies (many of which are 5-50 employees), I'd say about half of them use MFA consistently across their business. And it's not a budgetary issue, but more of a logistic/IT/prioritization one.
10 person startup -> that is a strawman if I ever saw one. There are many 100 person scale ups that are pre-profit for who the hassle of managing separate accounts for X SaaS tools for 100+ people is justifiably too much to ask but who can also not justify paying literally 50x as much as the highest non Enterprise tier
This is literally not the case. The pricing is nowhere near 50x - in fact if you negotiate the rates are only marginally higher than the tier below it.
FWIW - the sentiment I get here is that the gripe isn't necessarily the pricing (you notice how no one has quoted specific increases?) but that they have to pick up the phone to talk to someone for what they believe to be such a small feature.
> There are many 100 person scale ups that are pre-profit for who the hassle of managing separate accounts for X SaaS tools for 100+ people
So you're telling me that a company is complaining that they have to pay extra money for features that reduce their administrative burden and limit their risk, thereby costing them less money? Explain that one to me...
> There are many 100 person scale ups that are pre-profit
Also, put yourself in the seat of the owner of a software provider, would you rather win the sales opportunities of 10,000s of businesses that aren't pre-profit or the hundreds of businesses that match your criteria? I know who I'd be marketing to...
Then depending how formal the customer is the reply can be a text email with a quote, a formal quote that looks almost like an invoice (PDF), or even a 10 page draft document for further discussion.
This might sound like a lot of extra work, something that can't easily be automated, but those companies are used to long sales processes. The product manager needs to liaison with their legal department, then with their accounting department. "Request for quote" and "contact sales" are essentially the same.