Getting product data into your CRM is one of the biggest operational challenges for a product-led, SaaS business. It may not sound like a big problem on paper, but if you have ever tried to make this happen, you understand how frustrating it can be. In this post, we'll explain why this so challenging and how to build a system to get product data into your CRM.
Why do you need product data in your CRM?
Before we get into the details of making this happen, let's understand why it is so important.
Product engagement data is the lifeblood of every SaaS business - especially product-led SaaS businesses. The success of the entire business model is based on whether or not users are engaging with the product. If trial users aren't engaging with the product, they aren't going to buy it. If existing customers don't continue to engage with the product, they aren't going to continue to pay for the product (and they certainly aren't going to expand their account value).
This means that the teams charged with selling to and managing these accounts - across the various stages of the customer journey - need to know how users are engaging with the product in order to do their work effectively. They need access to product engagement data or they are essential working in the dark. And they need this data in the tools in which they work (ie - their CRM).
But why is it so hard to get product data into a CRM?
It's hard to get product data into a CRM because, well, CRMs weren't built for this kind of data. CRMs aren't built with the infrastructure to process product data and their data schemas aren't designed to be compatible with product data. Sure, most CRMs allow you to send in product data via their APIs, but (a) they will charge you a fortune for these calls; and (b) their systems don't give you the flexibility to manipulate the data in a way that makes it useful. If you have ever tried to create segments or workflows based on your product data in a CRM, you have felt this frustration.
CRM data structures are based on properties (some call them attributes, some call them properties, some call them traits) that live on the Contact (ie - Person) and/or Company (ie - Account) records. These properties are the data points that describe either a Contact or Company. These can be simple demographic or firmographic descriptors like:
...or they can be more specific to their status with your product
These properties are the main segmentation elements in a CRM. It is how you define lists, workflows, etc. But CRMs are not built to handle typical product events. You can't create behavioral segments based on behavioral rules as you would in a typical analytics tool. You can't create a list of users who have signed up for a trial in the last 30 days, created two reports, but never invited a team member.
The key to being able to use any product data in a CRM is to convert this data into traits that live on the Contact and Company records.
Which leads to....
How to translate your product data so that you can use it in your CRM
Believe me, I wish this weren't the case, but if you are a product-led business, CRMs just weren't built for you. They weren't built with the idea that how a user or account was engaging with your product was going to become an important part of your account management processes - both pre and post-sale.
And this means that you are going to need something that sits in-between your product and your CRM. This can be an internal system that you build or a product that you hire (😉,😉).
If you are considering building a translation engine for your product data, here are some suggestions:
Everything needs to be a property. As mentioned above, CRMs work off properties attached to Contact and Company records. As you build a translation engine remember that any data that goes into your CRM (if you want it to be useful) needs to be recorded as properties that are attached to the Contact or Company records. Don't think of just streaming a filtered list of product events to the CRM and expect your team to be able to make use of it.
User AND Accounts. This is super, super important. Product data has traditionally been handled at the user-level only. But user-level data only tells half the story for a SaaS business (maybe even less than tat). SaaS businesses are account-based businesses - and your go-to-market teams certainly operate at the account level. This means that any translation engine you build will need to be able to record data at both the user and account-level.
Create calculated metrics. This is related to point 1 above, but in order to pass product data to a CRM in the form of properties, the engine you build must be able to calculate some simple engagement metrics. This is the real crux of the "translation". All that colossal product data...in a few simple metrics. What metrics you ask? Great question. You should spend some time with your go-to-market teams to figure out what they will want to see, but here is a list of our recommendations:
Engagement score (normalized): Think of this as a credit score for your users and accounts based on how much they are using your product in a time period (weekly? monthly?). Here are some tips on building that kind of scoring model, but however you do it, you should make sure to normalize all scores in a way that make them easy to understand for your team (ie - use a scale between 0-100).
Engagement trend: An engagement score is good, but often the change in engagement over time is even more important - more actionable. Knowing that an account has an engagement score of 50 is good, but knowing that an account has a score of 50, but is down 25% over the previous week is a different story...
Activation rate: This is an essential metric that your teams will need to determine which trial accounts to reach out to. It is essential for a proper onboarding operation - and can even be used for forecasting!
Last active date (which can be converted to a "days since last active" metric)
Created at date: This should be recorded for every user and every account. This data can be used to calculate the tenure of your user base.
Adoption rate: How many of your features have your users used? This is something you should be able to calculate in any time frame as well (adoption rate in last 30 days; last quarter; all time).
Frequency: How often your users are using the product (4 out of last 7 days, etc)
Number of Active users (for accounts)
Segments, segments, segments. Pushing key engagement metrics to a CRM will allow for some valuable segmentation in the CRM, but your team will still need some more flexibility to create segments based on your product events. They will need to create segments like, show me which users/accounts have signed up in the last 30 days, but haven't connected a Gmail account, but have created more than three templates. This kind of segment will be important as your team build more workflows or messaging programs driven from the CRM. This means, your translation system will need a way to not only build segments, but to record the segment presence of each user/account so that it can be passed to the CRM as properties.
Connect to and update the CRM. Obviously, the last piece you will need to build is a system for connecting this data - the calculated metrics and segmentation information - to the CRM. Most CRMs have some kind of open restAPI that will allow you to push data there. Some are easier than others, but most have this kind of API to make this happen. Few things to think about when building this piece:
Identity matching for Contacts and Companies. You will need a way to match the ids for your Users to your Contacts; and your Accounts in your product to the Company records in the CRM. Matching Users to Contacts is easier - you can generally match on email addresses. Matching Accounts to Companies is a bit trickier. You can match on a company name that you set in both places or create a unique account ID that you can pass to the CRM and use for matching. You can also try to match on company domains. However you do it, you will need to insure that this matching is a core part of the system.
Frequency. You will also have to make some decisions about how often you update your CRM with this data. This is not just a decision you'll need to make as a concern for your own infrastructure, but also to insure you are staying within any API limits of the CRM. You might want to update the data on an hourly basis, every four hours, every six hours, etc. We do recommend you update the data more than once per day - which might be your instinct. Your teams will need this data to be updated more frequently than that. But it is not necessary to handle this connection in realtime.
What data to update. Along with how often you update the data, you will want to consider which data to update. It it not necessary to update every single user and account record with every data sync. This will create a lot of extra, unnecessary calls. Therefore, we would recommend only updating records for users or accounts whose metrics have changed since the last run. This will require you to have a way to compare current metrics to previous metrics in your system so that you can limit the updates you'll need to make in the CRM.
If building this kind of system to populate your CRM with your product data sounds like a big task...that's because it is. And that's why we built Sherlock.
How we built all this into Sherlock
From a technology perspective, we see Sherlock as, essentially, a translation engine for product data - as we've been describing it. Some more detail on the Sherlock system:
Built to process product data: Sherlock's infrastructure was built as an analytics infrastructure. Which means it was built to handle product data in a way an analytics tool would - not like a CRM.
User and Account-based by design and for everyone: Since day one, we have been committed to operating at both the user and account level with everything we do. Every Sherlock gets this out-of-the-box - we don't hold "account-based" back as a premium feature. We understood the essential need for insights at both of these perspectives for any SaaS operation, so everything we track and calculate is done at both of these levels. Was it more to build? Of course. But it is very important.
Calculated metrics: This is where Sherlock shines. As a translation engine, we were built to calculate essential metrics derived from your product data that exist as traits on all your user and account records as you connect Sherlock with your CRM. For more detail of all Sherlock's calculated metrics, go here. But here is preview of our calculated metrics:
Engagement score: Engagement scoring is our bread and butter. With just a few clicks, Sherlock users can configure an engagement scoring model for their product. Once configured, Sherlock calculates and engagement score for every user and account using the product. These scores are normalized between 0-100 so that they are easily understood by anyone using them.
Engagement trends: Very often, how a score changes over time is more important than the score itself. Our system was built to calculate engagement scores overtime so that users can identify essential engagement signals.
Activation rates: Next to engagement scores, Activation rate is the most important metric for a SaaS business - especially a product-led SaaS business. With Sherlock, users can define an Activation criteria for their product and Sherlock will calculate an Activation rate showing how far an account is toward full activation.
Adoption rates: We also calculate an Adoption rate for every user and account. Adoption rate is defined as the percentage of key events that have been triggered in a period (last 7 days, last 30 days, all time).
Frequency: Frequency is a metric that tells how often a user or account uses the product. 4 out of the last 7 days. 10 out of the last 30 days, etc.
Last active: The last time a user or account was active with your product is an important time stamp, but Sherlock also converts this date into a "Days since last active" metric that can be key for segmentation.
Tenure: Tenure is a metric that tells you how long a user or account has been with the product. This is a calculation based when an account is first created in the product.
Segmentation: One of the most important elements of the Sherlock platform is the segmentation engine. Sherlock users can create robust segments of users or accounts based on any Sherlock metrics, engagement history, or traits. These segments are not just important for analysis (show me how many of my new accounts have reached 50% Activation), but also for triggering actions. Sherlock tags every user and account with the segments of which they are a member. These segments become tags on a record that gets passed to other tools. Which leads us to...
Connection to other tools: And this is the last piece of the puzzle. Sherlock was built to get data into the key tools in your stack (mainly CRMs). All the Sherlock calculated metrics (as well as segments) are transformed to traits so that they can be effectively passed along to the CRMs of the world. These traits live on the People and Company records in the CRM where they can be used to create lists or trigger specific workflows.
Viola. A (almost) perfect translation engine for your product data
Want to see for yourself? Book a demo today!
Thanks for checking out the Sherlock archives.
The knowledge you get here is what Accoil is built on.
Want to build your own product engagement scores?
