DRAFT: Comparing On-premises and SaaS users
If you are considering migrating from On-premises to SaaS, this article describes the different users.
(ask-customer-partner-experience 26 march thread)
On-prem customers historically tend to have a lot of Main Users because they were cheap back in time / our on-prem packages came with a large number of Main Users.
Main Users translate to Editor Users in SaaS and as far as I understood, the rights of these two user types are the same or nearly the same.
Main users in OnPrem can be given permission to do the same as Editors in SaaS. This is a big hurdle for larger onprem to even consider to go to SaaS, as they are used to that all users can be given the needed permissions. The Editor license is very expensive compared to what the Main was/is in onprem. We should consider to enhance the Consumer in SaaS to be closer to Main in onprem, to be able to move more into the cloud. Not site admin-ish but at least metadata-editing, some workflow actions.
The main thing consumer in saas can do today, is upload with metadata, download and crop'n download.
I personally like consumer, they can consume data and that is it.
Except for police that has packages, I do not think I have seen any customer buy the same number of Editors as they had main users. They rather lack the functionality of users being able to add metadata, than pay for a very large number of Editors.In a perfect world I think I would have changed the following (might need some detailed though). Additional consumer permissions, but not so good as main for example change metadata on single file and integrations. Editor would have workflow possibilities (Actions, Pro interface with multi-file metadata changes).A limitation with the current license model is that we loose stickiness. Customers count each Editor user instead of being able add valuable metadata. In addition customer are deciding not to do integrations because the cost per Editor license is to high (Equinor and Universitet i Stavanger). On some customers we have "special priced editor license" that is a consumer with the right to use the integration (NSF and NHO).
(Try to explain that to the customer....this is a Editor, but this is another Editor) :face_with_raised_eyebrow:I think a clearer strategy on license model between main/consumer and Editor would be good. Larger clients with lots of users find it hard to understand that a user can upload, but not editor metadata. We are probably raising sales price per installation (ARR) short term, but over time I believe we will lose some customer (and new sales) because the Editors are too expensive and consumers can do to little.
As you say Main on-Prem is like editor on SaaS and Pro on-Prem gives you the pro interface and a couple of extra action features, Pro interface can be purchased separately on SaaS, but there is no way to set pro to a specific editor.Why not make the SaaS licenses consumer = Main and Editor = Pro, this way the Editor user gets the pro interface and this can now be managed.Then like in on-prem systems, The Site administrators can assign users/groups permissions based on the archive permission settings which gives them much greater control and provides functionality for users, while adding further stickiness.
Example:
"this user1 is part of this group1, with a Editor license therefore can be given all access in a archie and have all features, but this other Editor licensed user2 is part of group2, have a limited feature set. They are both "editors" with the same license, but you as a customer are not allowed to give usergroup2 (or user2 users) access to these features and functions....even thought it is nothing stopping you".I think it is easier on all parties if we give them a certain amount of Editors to a lower cost, or fixed packages like we do with police customers.
Having inconsistent user licenses and product features is only good in theory.