+972 52-548-6969
A User, an Account and SaaS
Users are almost always the simplest entity in your application. I mean, they usually just look like this:
How complex can something like that be? The answer is that as simple as something like that is, people still get it wrong, and quite often they get it horribly wrong.
Just to set the proper context, I am talking about applications that provide Software as a Service. For example, we may be building an Accounting SaaS system.
A user logs into the system, and gets to see his invoices, outstanding bills, etc. This sounds simple enough to do, so what is the reason for this post? The reason is that while this may sound simple, it is also wrong.
The User Is The Account
Let us introduce a few other semantics into the mix. I don’t want to do accounting, so I get Pkida to do that for me. But, since my data is tied to my user account, I would have to provide her with my username and password. Now, I am willing to let Pkida do my accounting, but I am not going to give her my credentials.
This is usually the first stumbling block for systems where “user is an account” model. You want multiple users to manage the same account. A good example of a system that for a very long time failed to handle this properly is Amazon AWS platform. For a long time, there was your AWS Account and your username, and they were pretty much one and the same. Consider the case of an IT department that wanted to use Amazon AWS. Until as recently as May 2011, they didn’t have any way to have multiple people manage the account, because they would need a single user/pass for the entire thing.
That is a huge problem for most scenarios. Sharing user/pass means that you lost control on the account:
- You don’t know who of the people who have access to the account made a particular change (no auditing).
- You can’t use standard approaches for detecting fraud.
- It is much harder to change the password.
Accounts Owns The Users
The next step is to ask what happen when you have something like this:
Now we have a way to have an account, and it can have multiple users. And all is good in the world, right?
Not so fast. What happens when it turns out that Pkida isn’t just working for me, but actually manages the accounting for several companies, each of them is using the SaaS accounting package. In order to use the software, Pkida would now have to have a separate user account for every customer she manages. That sucks:
- It may mean that you charge her for each account (she will go to a competitor).
- Some users would show very little activity.
- The amount of information you will have to do things like cross selling or targeted offers would be far reduced.
- It is annoying for the users.
A much better option is a total separation of Users and Accounts. A user can have several accounts (usually with a default one selected), and they can use a single login to access each, and each account may have multiple users associated with it.
This brings to question how you are going to handle charging people, but that is an issue for another post, and another day…
Comments
Ayende, I have to say you bring up an interesting topic that I really have not give any thought to. I have never used AWS but am surprised that they would go with a User is the Account model. It just seems so obviously wrong.
To date all SaaS applications that I have designed or worked on have used the second model you describe; the Account owns the users. For the most part this has always worked well except for case were we had a head office wanting move all their franchisees to our system and have one employee of the head office have access to all franchisee accounts. Having gone with your second model that required the employee to have different credentials for each franchisee account. Certainly not ideal. Although allowing users to belong to multiple accounts adds complexity to user management and billing it is alot easier to tackle in the early stages rather than 2 years after launching and having lots of customers on the system.
Great post!
Very insightful post, Ayende. You bring up an interesting point, but I would have to say that for most SaaS offerings there's no issue of a user having multiple accounts they're managing, since most commercial SaaS products seem to be targeted at solutions for a single company with a subset of users; having the notion that one user can belong to multiple companies is appropriate for certain scenarios,and not for others.
For instance, I'm going to be creating a SaaS product designed to be a very light CRM and appointment system for businesses like lawn care, carpet cleaning, plumbers and the like. In this case, the second model is sufficient in essentially all business cases as chances are slim to none that John Smith of Acme Lawn Care is going to also be doing work for Great Lawns Inc and will need to see both accounts. I could see the need in some fringe cases where somebody views themselves as a "serial entrepreneur" and has several different businesses, but those are the exception and not the rule.
Wayne, That only holds water until you have the Efficiency Consultant came to a business and NOT recommend your product because he doesn't want to remember another password.
@Wayne,
Here's what you call a fringe case, but is daily reality for me. We have an enterprise with several legal entities. One of those legal entities operates as a department in our offices, but has its own products, marketing strategy, targets, etc. This department for all intents and purposes operates entirely separately from the rest of the business, but certain services are shared, such as IT, Finance and HR.
In IT, I need to be able to log onto both "orgs" (Salesforce speak), and I would preferably want to do this with one account. Inability to do so will effectively prohibit such things as AD integration and single sign-on.
There is another overlapping scenario. A large organization may have multiple corporate accounts into the same Saas system. It might be desired to have some users to have access to only their home account. Then it might be desired to have some other users to have access to their home accounts (as default), and other accounts. Then you might have the requirement that if your home account is X, you have full access, but you may or may not have read only access to other accounts.
My general experience with SaaS developers is, that time is VERY rare. If you want to ship to the market, you'll have to concentrate on the interesting bits that create value for MOST of your customers. Since most people won't ever consider running two accounts with one user, you should ask yourself: "Is it really worth creating a more sophisticated, but complex user-account system?"
Ayende, it normally takes 10 or more experienced developers to build something like RavenDB within 3 years. I'm sorry, but you are not qualified to answer this question in a way that could be useful for normal developers. :-)
Users are trained to behave this way most of the time i.e. working around the technicalities. How do you fix a problem that for most users have become a natural habit stemming from previous SaaS failures that don't capture reality into their systems?
Daniel, You are missing the chance of losing users who are highly valuable. When you are doing this up front (thinking about it), this is much easier than trying to retro fit things. And users with multiple accounts tend to be the ones that you want to keep, they will bring you additional accounts
Good post. Similar problems exist for contact management which I guess is really the same problem expressed in a different domain.
Interestingly most of the negative comments seem to be saying either "this is too hard for me" or "I can't be bothered"!
Comment preview