Feature Highlights

Improving PLG playbooks for B2B SaaS through relationship properties

Yves Delongie
Yves Delongie
April 19, 2023
Improving PLG playbooks for B2B SaaS through relationship properties

In modern SaaS platforms, a single user can be a part of different accounts through one single login. Once signed in, he/she can simply switch from one account to another. Some other platforms even combine user-based and account-based subscriptions, allowing users to be a part of 0, 1, or multiple accounts. GitHub would be a perfect example of such multi-account-multi-user (MAMU) environment.

To run a product-led growth (PLG) strategy in a MAMU environment, it is imperative that conversion, expansion, and retention playbooks support any possible scenario, thereby needing to act on what users are doing individually in certain cases, as well as in function of one specific account in others.

While most (better) PLG platforms nowadays allow you to collect events, screen and page views that are associated with 1 user, or 1 account, or a unique combination of 1 user and 1 account, there is often a problem residing on the data scheme level. Indeed, most data schemes are created to only support properties for users and for accounts (and sometimes also for workspaces and organizations)… but very rarely for unique specific relationships between users and accounts. Yet, this is exactly what aforementioned PLG playbooks require.

Why are relationship properties so important for a B2B PLG motion?

To better understand the importance of relationship properties, let's take a step back and summarize what it takes for B2B companies to run a PLG motion:

  1. Vendors need to collect all user activities, potentially also mapped to the account they were in when performing these activities.
  2. For both users and accounts, a machine learning process identifies PLG signals based on properties, events, screens and pages. These signals contribute to identifying product-qualified-users/-leads (PQLs) and -accounts (PQAs), as well as expansion and churn candidates.
  3. For the sake of our reasoning, let's focus on PQAs in a B2B context. Once PQA signals are defined, each account will receive a PQA score reflecting its likelihood to convert... as an account!
  4. Now that we know which account is most likely to convert, we need to determine which user (account-PQL) within the account we should engage with:
    a. We will look at each user's activity within that specific PQA. At this point, we only care about what users did in the given PQA, not in any other account they may be part of.
    b. Equally important, we need to know each user's specific relation to the given PQA. To start, what 'Role' does each user have within the given PQA? Do other important relationship property values match given account-PQL signals?

To further illustrate the importance of relationship properties, let's examine above property named 'Role'. Suppose you have a multi-account-multi-user platform where Elon Musk is creating three accounts: Twitter, Tesla, and SpaceX... (and soon X.AI ;-) However, since he has limited time to manage everything, he designates himself as the owner of the Twitter account, as one of many admins of the Tesla account, and a mere user in the SpaceX account. It is clear that if all 3 accounts were PQAs, you would reach out to Elon only in case of Twitter and maybe Tesla where he is owner and admin, but not for SpaceX where he’s merely a user. (At least, purely in terms of Role. He might still be a power-user ;-).

Elon being part of 3 accounts, has different roles within each account.

Now, where should we store Elon’s roles?

  • On user level? No, since unlike his name or date of birth, Elon’s role differs from account to account he is part of.
  • On account level? Well, since each of Elon’s accounts has several users, that's obviously not possible neither.
  • On unique relationship level between one user and one account? Absolutely!

...And that's why today, journy.io is introducing Relationship Properties!

Which impact do Relationship Properties have on the journy.io PLG platform?

Changing a platform’s base data scheme have quite significant consequences to the entire platform. But as previously explained, for very good reasons. The introduction of relationship properties provides following improvements:

Data intake

The first step in introducing relationship properties, is to collect them. Our data intake is achieved through either implementing our native SDKs, either by connecting the Segment customer data platform, either by connecting your data warehouses, yet also through Segment.

We have changed our native APIs/SDKs to support these changes.

When using Segment, developers should add the following to their group call.

Other intake connections, such as CRMs and marketing automation platform, won’t add any relationship properties, unless specifically supported. To date, unfortunately, none provides support for such properties. That’s why we’ve build our own playbooks, so we can trigger engagement sequences from within journy.io.


The relationship property definitions are presented in journy.io’s data catalogue, in between user and account properties. We support all types of properties, with a default text property ‘Role’ being populated at creation.

Relationship Properties, in between user and account properties.

Next to the relationship property definitions, you can obviously see its values when browsing users and accounts. Each user and account has respectively a list of related accounts and users where relationship properties can be shown.

Detail of an account in journy.io, clearly showing its users with relationship properties (marked with ↔)


Reflecting above use case (with Elon Musk in a multi-account-multi-user environment), we created ‘User Actions’ in Account-based playbooks.

The principle is that account conditions are created to define which accounts are to enter a playbook, to then define actions that will be performed for specific users. To select which users to engage with, you can specify conditions on both general user properties ...AND: relationship properties against the current account in the playbook.

Account entry conditions for a playbook
In the account playbook, add a user action with conditions based on Relationship Property ‘Role’

Above screenshots illustrates a playbook in which account ’The Beatles’ will enter, where only users with ‘Role = User’ (being John Lennon in previous chapter) will be added to a HubSpot list to start receiving emails.


While it's now possible to trigger engagement sequences in third-party software, a problem remains: these platforms cannot process relationship properties on their own. To address this, we have built a Personal Messages editor that can include relationship properties alongside native user and account properties.

For example, imagine you want to send a HubSpot task to an Account Executive to reach out to Elon within the context of Twitter. HubSpot already holds all relevant information on the user (contact) and account (company) levels through real-time syncing with HubSpot. But what about Elon's "Role" or other relationship properties? To solve this, we allow including relevant properties in the task being created.

Personal Messages editor, where user, account and relationship properties can be inserted.


To conduct a correct B2B PLG motion, you need to act on both accounts and users. First, proper product-qualified accounts (PQAs) must be identified, to then engage with the best possible users (PQLs) from within these specific PQAs.

To determine which account users best to engage with, you need context of each user within their each account, namely knowing what events they triggered, which screens and pages they’ve looked at... and what specific relationship data they hold.

In our journey to market a best possible PLG platform for B2B SaaS, and seeing this as the only remaining missing piece to conduct a proper PLG motion, we are now introducing Relationship Properties. Feel free to try it out here.

Keep reading...

Built for B2B & B2C SaaS, simultaneously

Changing the way you do business, case by case.


Detect which signups are most likely to buy. Sell more with less effort.

Automatically surface product qualified leads.

Prioritize PQLs call lists and engage with quick actions.

Add tasks and full PQL context to existing CRM and other engagement tools.

Automated sales playbooks and collaborative inbox.


Onboard. Monitor. Get expansion signals. Reduce churn, proactively.

Automatically detect churn & expansion candidates.

Accelerate onboarding and product adoption.

Align activities around 360° customer view, with health and onboarding scores.

Automated CS playbooks and collaborative inbox.


Build revenue workflows, based on how people use your product.

Use machine learning to uncover new sales opps.

Add slow accounts to nurturing campaigns.

Optimize engagement playbooks for maximum conversion.

Leverage any data without needing engineering.


See which impact your product features have on revenue, expansion and churn.

Analyse feature importance, usage and impact.

Build key product metrics without SQL, nor coding.

Easily create customer segments based on any product interaction.

Comply to GDPR and CCPA.

Check out our use cases
Build revenue playbooks based on how people use your product
Stop crunching CRM records and data sheets once a month, to find risks and opportunities. Organise your workflows around real-time PQL signals, playbook actions, and customer data from across your stack.

Work in the tools you already know and use
Give easy access to product data
PQL intelligence and actions, the moment it happens
All point'n'click, no SQL or coding needed
Check out our use cases
Share Customer Data
Detect which leads are hot. Sell more with less effort.
Stop wasting time on unqualified leads. Look out for promising product qualified leads that trigger specific buying signals, and make more meaningful calls, knowing which features they're interested in.

Get prioritized call lists, sorted by likelihood-to-buy
See unified view of each account and their users
Get cases with follow up tasks in your team inbox
Get tasks and product data in your existing CRM
Check out our use cases
health score
Easily test new PLG strategies and improve conversions
Try out new PQL conditions, assign different engagement variations, and monitor how conversions progress over time.

See which features are most frequently used
Quickly test new PQL conditions and actions
Prove which engagement playbooks work best
All point and click, no code required
Check out our use cases
PQL Experiments
Onboard. Monitor product usage. Reduce churn, proactively.
Keep track of each individual user and account at scale, and get notified on expansion and cross-selling opportunities. Identify those who are at risk of churning, and pro-actively reach out to them.

Get notified on churn risk and expansion opportunities
Get cases with follow up tasks in your team inbox
See all account and user activities in one place
Collaborate with sales and marketing thru quick actions
Check out our use cases
journy.io customer success use case
Convert more through hyper-personal automations
Target the right audience at the right time with the right message. Your existing automations get power-boosted with customer engagement metrics.

Automatically add PQLs to engagement automations
Get product usage data in your existing marketing tools
Lower customer acquisition costs
Check out our use cases
journy.io marketing use case

Set up journy.io
in under one hour

Create your free account and start driving a product-led growth strategy with the tools you're already using.

Get Started 
journy.io white logo
© journy.io BV 2023 — All rights reserved.
The names and logos of third party products and companies shown on the website and other promotional materials are the property of their respective owners.