5 ms·

Enterprise customers can ask for different payment terms (bank transfer instead of credit card, 30/60/90 day payment goals), legal and security review, differen

by mtmail 2y ago

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.

supafastcoder 2y ago
Is there a solution out there that manages all this paperwork and custom requirements/contracts?
mtmail 2y ago
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!).
- Terretta 2y ago
  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.
  - nlitened 2y ago
    Those who really need SSO are willing to pay extra — why not charge them more for something that is useful for them?
    - kuschku 2y ago
      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.
      - nlitened 2y ago
        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.
        kuschku 2y ago
        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?
        nlitened 2y ago
        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.
flessner 2y ago
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?
- mbesto 2y ago
  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...
  - Terretta 2y ago
    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 ...
    - mbesto 2y ago
      > 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.

by mtmail 2y ago

supafastcoder 2y ago

Is there a solution out there that manages all this paperwork and custom requirements/contracts?

mtmail 2y ago

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!).

Terretta 2y ago
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.
- nlitened 2y ago
  Those who really need SSO are willing to pay extra — why not charge them more for something that is useful for them?
  - kuschku 2y ago
    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.
    - nlitened 2y ago
      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.
      - kuschku 2y ago
        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?
        nlitened 2y ago
        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.

flessner 2y ago

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?

mbesto 2y ago
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...
- Terretta 2y ago
  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 ...
  - mbesto 2y ago
    > 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.