Enterprise Ready SaaS Feature Guides
enterpriseready.io
enterpriseready.io
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()) {}
if (user->permission == 1) {}
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.
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).
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.
> 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?
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.
For example, Prospective Customer Corp doesn't use the term "Manager", but instead uses "Team Leader" or "Coach" and wants all references to that to match their internal language.
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.
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...)
As for easy branding, do you think that only applies a "must have" if the application has some sort of end-customer/consumer facing interface (ie Zendesk, Readme.io etc)? Or do you think that is equally important for applications that are used exclusively internally by employees.
It's more about being consistent with other processes and applications that an enterprise already has. If your product is about generating reports, they'll want the button to say 'Generate TPS report' rather than 'Generate report'.
It's also very easy to implement, so why not?
Auditing remains the killer though, if you build it in from the beginning then it can be effectively free because of how it affects your architecture. If not it can become a big maintenance headache.
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
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.
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/ (we run a company that helps other companies do just that).
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.
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.
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.
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.
* Except security. Always be thinking about security.
* 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.
In my reading he was referring to negotiations that SaaS product companies have with customers; saying that sometimes customers will request features that "sound like a good idea" but aren't necessary or fully thought out.