
Enterprise Ready SaaS Feature Guides - tortilla
https://www.enterpriseready.io/
======
ejcx
If you are a startup that is building a product you should consider these
future wants when writing code.

Audit logging, different roles, teams, permissions, auth mechanisms etc.

Believe me when I say it is a lot easier to add these things in the future if
you consider these future wants when building your abstractions. This may
sound like a lot of work and accounting for unknown unknowns, but doing things
like

    
    
        if (userHasPermission()) {}
    

instead of

    
    
        if (user->permission == 1) {}
    

will make your life much simpler down the line.

------
NeutronBoy
I love this site. Change Management is a super important one that often gets
missed. Enterprise customers will have strict workflows around migrating
changes from Dev, to Test, and then into Prod. They'll need warning about
upcoming changes so they can plan and train users as well, which is often
overlooked.

A good example is a government client I recently worked for. For major
application upgrades and changes (which they needed to apply to keep their
SLAs in place with the vendor), they needed at least 12-18 months notice,
because if they needed to re-train 15,000 users, that takes time and lots of
money. And if they needed lots of money, they needed to submit a business case
to the government and get funding in the next financial year.

~~~
ohstopitu
but how does that work out for a SaaS app? (especially a startup that's always
adding in new features?)

I mean, one idea is to create sub domains - each running a different version
of your app...but at that point, you kind of loose control and companies would
love to stick to an older version (and you'd have to support an older
version).

~~~
NeutronBoy
The same way that Salesforce does it - allow you to flick a switch and
transition to a new interface, or turn on a new feature, or whatever.

In terms of remaining on older versions, vendor typically restrict this
through SLas - For example, you might only get your Tier 1 SLA response
(acknowledgement of a serious issue within 1 hour, for example), if you're on
the current version, or the previous version. Once you're on an older version
those SLAs often don't apply, and large organisations mostly aren't ok with
that.

~~~
ohstopitu
Thanks for the reply!

> Once you're on an older version those SLAs often don't apply, and large
> organisations mostly aren't ok with that.

Won't that just mean they'd not like the rate of progress (say daily updates
for bug fixes, weekly updates for minor changes, and monthly updates for major
changes), and just leave?

~~~
NeutronBoy
Ahh, now you're really getting into the world of B2E services!

They might just leave - but if it's a core service they need, it's a huge
amount of effort to migrate users, data, implement a new system, rewrite all
their process and documentation, helpdesk manuals, etc. They generally won't
mind with general fixes and updates, but if you're changing existing workflows
or features, or adding new capabilities in, they'll probably want control
about how they roll that our to their users.

Enterprises generally don't sign up to SaaS services through a webform and a
manager somewhere punching in their Amex (although it does happen sometimes).
There'll be a proper contract, with lawyers, and negotiations, etc. There'll
be clauses in the contract that most enterprises don't want and they'll try to
negotiate away - for example, under what circumstances can the vendor (you)
terminate the service? If the Enterprise has spent heaps of money to move onto
your service, they'll want assurances that you can't terminate the contract
because you feel like it - and if you do, that they can sue you for damages.

As you can see it's definitely a conscious decision that you'll need to make
if you want to target these Enterprise customers - it's a big investment, and
often (particularly in government or if your service is going to be a core
platform) you'll get contracts that commit you to 5+ years of service, but the
flipside is that now you've locked in 5+ years of revenue from that customer.

~~~
grantlmiller
I love this conversation. @ohstopitu thanks for asking great questions &
@NeutronBoy thanks for providing great answers.

------
dmode
This is a great guide. It also underscores why it is so difficult for young
startups to unseat big incumbents like Oracle in Enterprise. Not only you have
to compete with every corner case features, but also have all the other stuff
done. Other things I would add to this list are: Accessibility and RTL
readiness, configuration / implementation guides, Text replacement guides

~~~
grantlmiller
Thanks & you're right these are all the things that are easy to overlook when
eyeing up an incumbent. Accessibility - great call - did this at our last SaaS
company (for mobile too!). A few questions... I'm unfamiliar with RTL
readiness, can you elaborate? Same with text replacement, are you referring to
internationalization?

~~~
dmode
As the poster said below, text replacement gives customers the flexibility to
brand things differently internally. For example, the app label says "chat",
but customers want to re-label that and say "conversations". This is at the
basic level. You also have to think about internationalization - can you
replace chat in Spanish with conversation in Spanish.

RTL = Right to Left. If the customer has operations in Middle East, they would
need to display Arabic or Hebrew text, which unlike English, goes from Right
to Left. Which means your screen orientation should be changed as well. If you
have a screen with a picture on the left, for an Arabic user, the picture
needs to move to the right.

I also should have added internationalization to my original comment. Asian
characters, especially Japanese, can cause a lot of challenges.

~~~
grantlmiller
Thanks for clarifying. Text-replacement makes sense in that context,
definitely related to both white label & internationalization.

RTL... most browsers have some sort of RTL support, correct? `dir="rtl"` (I'm
not an expert on RTL... I'm confident that given a piece of paper with Hebrew
text on it I will still rotate it 3 times before realizing that it is not
upside-down English).

I'll get these all worked into the guide soon (or if you're feeling
enterprisey... it's open source and we'd love contributions:
[https://github.com/enterpriseready/enterpriseready/tree/mast...](https://github.com/enterpriseready/enterpriseready/tree/master/content/features))

------
doublerebel
I really like B2B SaaS. As long as you can show reduction of cost or labor, a
business has a clear reason to make the buy.

Awesome to have so many real-world examples in this guide, and not just
generalized advice.

For another example, here is Sidekiq's Commercial FAQ for customers looking to
decide between 'Pro' and 'Enterprise' subscription levels. It gives some
insight into the tradeoffs that make sense for both sides at the Enterprise
level: [https://github.com/mperham/sidekiq/wiki/Commercial-
FAQ](https://github.com/mperham/sidekiq/wiki/Commercial-FAQ)

This is particularly interesting to me as I previously co-founded a B2B SaaS
and am currently launching a copy of Sidekiq's model for NodeJS.

~~~
grantlmiller
Agree, I moved away from consumer stuff primarily because I think that
enterprise buyers are more rational & logical (not completely... but more than
consumers).

If you're looking to create an enterprise installable version (a la
Sidekiq)... well... read the deployment options post:
[https://www.enterpriseready.io/features/deployment-
options/](https://www.enterpriseready.io/features/deployment-options/) (we run
a company that helps other companies do just that).

------
theluketaylor
I work in a heavily regulated industry and we cannot even consider a SaaS
application until it does nearly all of these things. If an application
doesn't have SAML, SIEM ready audit logs and RBAC it can't even be added to
RFP consideration, let alone bid for our business.

I have sat through a number of startup SaaS pitches where the product looks
interesting and would solve one or more active business problems, but when I
ask about roles or audit logs it hasn't even been considered and I cannot
consider it any longer.

One item lacking from the list is tenant isolation. We don't always require a
fully isolated tenant (though we often do if customer data is going to be
stored in the cloud), but we do require whatever isolation there is be fully
documented and provided.

I'm also noticing a trend among SaaS providers to have what they consider
strong SLAs we find laughably weak. If your SEV1 SLA is more than 30 minute
response time you're not ready to pitch me anything. This isn't beating up on
the new guy; our internal business-critical applications all have 15 minute
response requirements for the internal support teams.

------
Spooky23
One thing that I'd suggest adding is the ability to ship logs to external
destinations.

Platforms like Splunk and SIEM tools are really common these days and analysis
often takes place there for large companies. Coordinating user access activity
in the cloud against employee termination, for example, is something that is
high value and usually cannot take place in a cloud service.

~~~
grantlmiller
Totally agree on that being super important and often overlooked. We tried to
cover that in the section about audit logs being accessible from an API:
[https://preview.enterpriseready.io/features/audit-
log/#key-f...](https://preview.enterpriseready.io/features/audit-log/#key-
functionality) is there additional detail you think we need to add to that
section?

~~~
Spooky23
I somehow missed that section.

That pretty much covers it I think. We have a few services at work that I
thought were sending native syslog, but it turns out we have a daemon pulling
those logs from an API.

------
beat
This is also about enterprise in particular, distinct from ordinary B2B. If
you don't work enterprise, the distinction can be lost. The sales process can
be long and slow, with lots of customization and seemingly arbitrary
requirements.

On the other hand, if you can build an enterprise-worthy product and a sales
team that can handle it, it's an incredible cash cow. Six and seven figure
contracts.

------
mnutt
This is a really good overview of some features that are common in enterprise
SaaS, but I would caution against thinking that they're necessary to be
successful in enterprise SaaS.* My experience has been that if you have a
really compelling core feature set, most everything else is negotiable. Some
are nice to have, some are regulatory, and some are just something someone
added to a list because they thought it sounded like a good idea. Even the
ones you do decide to implement, make sure you do enough customer discovery to
figure out how it relates to your market.

* Except security. Always be thinking about security.

~~~
grantlmiller
I appreciate your level response. You're correct that these features are not
absolutely, always necessary for success. I would caution that even with a an
incredibly compelling core feature set, you still have to negotiate yourself
out of not providing these features. Even when you win you might be creating a
maintenance nightmare for someone down the totem pole within your customer's
org. Part of what we're trying to do with EnterpriseReady is show that many of
the non-core (yet common among many enterprise customers) features 1) aren't
that hard to understand 2) can be built really well in a way that will delight
your users.

* As the OP, when you say: "some are just something someone added to a list because they thought it sounded like a good idea" \- I genuinely hope that I did not do that.

 __100% - Always be thinking about security.

~~~
mnutt
I could have worded that better, I was referring to someone within the client
organization adding on requirements arbitrarily.

~~~
grantlmiller
Ha, makes sense... I didn't really take any offense.

------
gkoberger
This is a really great guide... as a consumer/startup person, I never would
have realized some of these things are features larger companies need (audit
logs, how pricing forms should be laid out, etc)

------
Dawoodi
It is pretty interesting. Nice guide.

