Almost every B2B SaaS application supports the notion of accounts and users. A first user creates a trial account and finds himself the owner/admin of the account. He then invites more people to join the account. One user is bound to one account. We call such setup a single-account-multi-user environment.
Other more advanced SaaS applications are created to support multiple accounts for the same user. E.g. Slack, journy.io, Notion, StoryChief, etc... One user logs in, and finds himself able to switch accounts. Such setup is called a multi-account-multi-user SaaS environment.
The problem you encounter with latter environments is that it’s hard to map data —specific to one user, but several accounts— into a CRM that only knows about one user being part of one account. One user can be a customer (marketing stage: CUS) for one account. Yet, starting a new trial, will you overwrite her/his settings and let her/him become a marketing accepted lead (marketing stage: MAL) again? Or will you keep her/his existing setting and simply ignore her/his new account?
Multi-account multi-user environments vs single-account tools.
To adopt the notion of a multi-account-multi-user environment, in a single-account-multi-user customer app, some work needs to be done and some assumptions need to be made. The first assumption is how to deal with native account-user relationship in the destination app. In the case of belonging to 2 accounts, will you keep the first account as its native account, or the last one? Or maybe that isn’t even that important.
In most of the cases, trials are made on account level, and if one of its users tries out a certain feature, it’s actually the account that is testing out that feature. So, in the destination app, far more information can be stored on account level, and actions can be taken on account level, rather than on user level.
Also, since an account holds multiple users, these user references (email, name...) can also be stored on account level, in custom fields of type ‘user’, ‘email’, or simple ‘strings’. Custom fields of type ‘string’ has the advantage that various information can be stored in one field, while having the option to filter out certain values, through the <contains> operator.
On user-level, there also custom fields to be implemented, indicating a relationship between the user and multiple accounts. In the case someone wants to trigger an user-based automation, you can filter out her/his state for her/his different accounts.
Finally, in most cases, having a build-up view of a user, is the best possible approach. You thereby assume various stages for a user (visitor -> MAL -> MQL -> CUS -> PRO -> churn) and the fact that that user can only progress, until there’s no other option than to regress when churning. If a user is already a CUS in one account, and becomes MQL in another, his status will remain CUS. If in that other account, the user becomes PRO, she/he becomes PRO! If in that same other account, the user churns, she/he than becomes a CUS again, because of his status in the first account...
How journy.io help you solve your mapping problem.
The core value of journy.io is to provide a ‘feeling’ of how an account and its users are behaving on a customer’s website and/or app, by filling in (custom) fields in the tools being used. Those tools can be a CRM for sales, a ticketing system for customer success/support, a financial reporting system for finance people, and finally a marketing automation platform/MAP for digital marketing teams.
Multi-account-multi-user environments are automatically detected and the various relationship parameters as described above can be filled in by journy.io. The way user and account properties in journy.io are sync’ed to destination apps, depends on the capacities of a chosen destination app. And since each app has its own connector, it will try to make the most out of it, taken best-sync-practices into account.