It might seem simple, but getting visibility into how your customers use your product from within your CRM system can be a huge operational challenge.
In the age of the empowered customer, Product-led Growth (PLG), and Usage-based Pricing, the risk of not having product data in your CRM is too high.
In this post, we'll go through the challenges involved in getting product data in CRM software, the use cases in which having that data is imperative, and how you can get product data into your Customer Relationship Management system without the kinds of headaches that most people have to go through.
The Customer Relationship Management System (CRM) is often associated with the Sales team. While this is true - CRM systems like Salesforce and HubSpot are the most critical tool for sales organizations - CRMs are also the single source of truth for most Go-to-Market teams.
These days, what people do inside your SaaS product is a more significant indicator than any amount of white paper downloads.
From acquiring net new revenue via a trial->paid motion to capitalize on expansion revenue opportunities based on in-product behavior, incorporating product behavior with the data that lives in your CRM is crucial.
Let's look at the various use cases that require product usage data in your CRM.
Marketers want to be able to send the right content, at the right time, to the right person. While "traditional" marketing focuses mainly on filling the top of the funnel with leads, more and more companies are relying on marketing to convert free users to paid users.
In addition, Lifecycle and Customer Marketing have become more prominent, focusing on marketing to existing customers or users in the hopes of revenue expansion and churn reduction.
"Product-Qualified Lead" (PQL) has grown in importance for marketers, on track to replace Marketing-Qualified Leads as the primary lead qualification metric for marketers.
PQLs use demographic data - company size, industry, etc. - and product usage data to score an account.
Then, when the account reaches your arbitrarily defined threshold score, it will be marked as "PQL."
To track the critical behavioral signals for PQLs - Adoption and Activation - marketers must capture this data from the product and have it live on both the customer and account records in their CRM.
Companies often create a one-size-fits-all approach to customer onboarding - x emails over y days, with a few trial expiration reminders sprinkled throughout.
But an email cadence that has the same messaging for a user who has quickly self-onboarded and one that has barely accessed their account is a recipe for failure.
A more effective strategy for onboarding communication would be to tailor the messaging to the stage and level of adoption a new user/customer has reached.
If they are flying through "jobs to be done," it might make sense to include more "advanced" tips and education.
If they aren't reaching milestones, providing more reasons *why* taking the necessary onboarding steps provides value would be more helpful.
Behavioral signals are a critical tool for identifying expansion opportunities.
And expansion revenue is one of the defining characteristics of the fastest-growing SaaS companies.
The fastest-growing companies are getting more of their revenue from expansions.
Data on product usage from the account and individual user levels is critical for building and acting on expansion signals. However, combining that data with other vital data from your CRM, billing, and subscription management systems is also required.
Companies can no longer rely exclusively on explicit feedback to understand whether customers will likely churn.
While they may express satisfaction on various surveys, their behavior in your product tells the true story.
Having product usage data in the CRM is critical to identify these red flags, alert the right manager, and provide them with the tools to take action.
Customer feedback can come in many forms. Whether it's a request to fill out a Customer Survey - CSAT, NPS, etc. - or soliciting a review for a site like G2, requests for feedback must be sent to the right user at the right time.
If a customer has reached all activation milestones, is growing in their usage, and seems to be getting value out of the product, it might be a good time to reach out to solicit a customer story or product review.
If a customer has been hitting a wall in the product or hasn't been seen in a while, having them fill out a survey might help elucidate the reasons for their challenges.
These scenarios are only possible with product usage data available in your single source of truth for customer data.
Today's CRMs were built when business needs were different than they are today.
In that world, there was no expectation that a customer's product usage would be important once a sale was made and a contract was signed. Product data was interesting to a product manager and pretty much no one else.
Let's take a step back to understand what CRMs are and how they work.
A CRM is a database that holds information about people and companies. It tracks customer relationships, interactions, communications, and transactions.
Most CRMs are built around an account structure where each person or company has a record within the system; each record contains basic information such as name, address, phone number, email, etc.
However, the CRM only holds a little besides contact information, and the schema they are built around was never meant to support the kind of product data tracking that is so crucial today.
The behavioral segmentation needed to track product usage better and combine that with the traits in the CRM record is just not possible with an out-of-the-box CRM instance.
While some up-and-coming platforms out there that bill themselves as a "PLG CRM" rarely are as powerful as mainstream CRMs and often become yet another platform and dashboard you need to access daily.
While CRMs don't have product usage tracking built-in, companies that require this data in their CRM - businesses with a Product Led Growth motion, Usage-Based Pricing, or any sort of tiered pricing model that's based on usage - often have to tap their internal technical resources to hack together an operational CRM for this purpose.
If you've found your way here as a result of Googling some variation of "How do I get product data into my CRM," you may have come across a few articles that left you with a feeling of deep dismay.
Tray.io, the Integrations as a Service tool, has a super in-depth article on how to do it. While it begins innocently enough, you quickly discover that what they are proposing is far more complex than the "better way" they are proposing.
Here are a few ways companies are getting actionable product usage data into their CRMs today.
PS: Read all the way through to the end because there is another option!
Most companies have the insights and data they need live in the data warehouse connected to their product. These databases are usually massive and complex and are built to be used by engineers and data scientists.
To get this data into some readable form and sync it to other systems, some companies leverage a "Reverse ETL."
Reverse ETL takes data from a central data warehouse, normalizes it, and copies it to other operational tools.
ETL stands for Extract, Transform, and Load and generally refers to taking data from multiple sources and moving them into a single database.
Reverse ETL is the opposite process.
Databases for SaaS today generally fall into two categories: SQL and NoSQL. The differences between these two structures are not really relevant for this post, but I will use a SQL-based database for this example.
Let's say you use a SQL-based database to capture customer data from your web application. To operationalize your CRM for growth, you want fields about feature adoption, contract utilization, and access frequency regularly synced from the database to your CRM.
First, you will have to learn SQL and write the query necessary to access this data, ensuring you have the correct information on both the individual user and account levels.
Once you've taught yourself SQL and written the queries you need - and you very well might need different queries for each of the data points you want to sync - you now have to find the unique identifiers between the user record in your database and the contact record in your CRM, as well as the account record in your database and the company record in your CRM.
You then have to set the sync cadence, keep track of errors, and identify the source of those errors.
Because of the difficulty involved in querying a database through a Reverse ETL, many companies opt for using a Customer Data Platform (CDP). The most well-known of these systems is Segment, which was purchased by Twilio in 2020 for over $3 billion.
A CDP differ from Reverse ETLs as they track in-product behavior in real-time rather than querying a database that has already captured this data. CDPs are more flexible because they capture all behavior and give the end-user the power to choose the most important data without touching the central data warehouse.
While CDPs like Segment offer greater autonomy and flexibility, they are often misrepresented as not requiring much technical knowledge.
Unfortunately, this is not the case.
To connect your CDP to your CRM application, your engineering team will need to add the CDP tracking pixel to your product. This is pretty standard and will likely not create a significant level of friction.
Once that is done, you'll be able to see a wall of incoming data that looks a lot like the Matrix for the non-technical folks among us.
To find any sort of signal in this noise of data, you will need to have your product and engineering team tweak your products' code to track the identities of users and the actions you would like to track.
This part creates a significantly higher level of friction to get done and is often where a CDP implementation dies on the vine.
If you can power through these challenges and have gotten buy-in from your product and engineering teams to manage the technical aspects of the CDP, you can now start tracking important events.
You will have to become familiar with JSON data because CDP tracking data will often be in this format.
This isn't a technical term, but one that I think works well.
At a basic level, companies will often rely on someone non-technical. Still, they can use some of the "no-code" and "low-code" tools that have sprung up in the last few years to take data from disparate tools and send them to the CRM through systems like Zapier and other Integration Platform as a Service (IPaaS) systems.
Often, the workflows created to accomplish this are "hacked" together, and the person who set them up might not even be able to tell you how exactly they work. For now, they seem to capture the bare minimum (if that) needed.
As you can tell, the challenge of getting product data in your CRM tool is Kafkaesque in its complexity.
I hear you. In previous roles, I've dealt with all of the above in attempting to get this data into my CRM. This is one of the fundamental challenges that Parative was built to solve.
Five major use cases are important to today's go-to-market and customer-facing teams that can't be done well without product data in your CRM:
As an industry, SaaS companies tend to be solely focused on "net new" as their primary driver of revenue growth.
This is a fundamental error.
Research by Profitwell shows that at least 30% of a SaaS company's revenue should come from expansions via upsells, cross-sells, and the like.
According to this research, companies that grow faster get more revenue from expansions than those that are growing slowly or not.
In addition, the acquisition cost for a new customer can be up to 4-5x higher compared to expanding existing customers.
Check out some other stats:
Suffice it to say that identifying and acting on expansion opportunities is critical for SaaS companies.
And yet, as is so often the case, companies struggle with this because the insights needed to signal whether an expansion opportunity exists are disconnected from the daily tools that customer-facing teams use.
Most SaaS businesses structure their pricing tiers around volume - the number of seats, amount of storage, number of users, tracking events, or API calls.
These tiers often have more complexity, with different usage levels for various aspects and volumes for different usage variables.
Expansion opportunity signals can be found in the utilization of these contracted volumes.
Including expansion opportunities in your CRM requires having fields to track the following:
Your CRM should be able to show the level of utilization of a customer's contract and a scoring model to indicate if their utilization is happening on a healthy timeline.
You should be able to leverage this data to create account segments based on subscription tier or product line, track each account's utilization rates, and score that utilization against a model you have made.
Most importantly, the data needs to be actionable and readily available to the teams that need it to capture expansion revenue.
When the subscription-based SaaS model was first championed, a Go-to-Market motion emerged that became the gold standard.
A lead is generated via some sort of content or event (eBook, White Paper, Webinar, etc.). Then, the lead is nurtured through email automation and scored based on how engaged that lead is.
Once the lead reaches a specific threshold score, they would then be marked as a "Marketing Qualified Lead" or an "MQL."
In this model, the user's behavior within the product plays no part in lead scoring.
That model no longer reigns supreme.
Today, the product itself plays a more prominent role in qualifying a lead, especially for companies that have embraced a "Product-Led Growth" model.
For PLG companies, the "Product Qualified Lead" has replaced the Marketing Qualified Lead as the critical qualification threshold in which a lead is passed off to the sales team for a sales rep to begin reaching out.
A product-qualified lead (PQL) is a lead who experiences significant value using your product. Generally speaking, PQLs are utilized t qualify leads in a freemium tier or free trial.
The scoring model for PQLs usually takes into account two main variables:
Most CRM systems (for example, Salesforce Sales Cloud, HubSpot CRM, and Microsoft Dynamics CRM) and Marketing Automation tools have properties meant to capture lead scores. Unfortunately, these fields are usually based on the "traditional" scoring model that tracks customer interaction and engagement outside the product.
As mentioned earlier, PQLs are generally calculated based on Product Activity + ICP Fit. While many models include additional factors, these are the basic building blocks.
To track PQLs in your CRM, you'll need the following data from your product synced with both the contact and account objects associated with the user:
For most SaaS products, a set of core features that a user in a trial period should adopt for them to be considered "activated." To track PQLs in your CRM, you'll need fields that correspond to these features and have them updated as the features are utilized. The fields can be binary - include something like a true/false to indicate if the contact or account has used this feature - or it could be a count of how many times this feature was used.
Whether or not a user has logged into their account in the last week while in a trial or freemium tier is a critical signal when determining their product qualification status. Ideally, there should be a field on both the contact and account records to track this. It can be time-based - "days since the last login, for example - or binary (has accessed account in the previous week). This field must be synced regularly with product data to be helpful when scoring for PQLs.
Free trials or freemium tiers often come with a limited set of users. If, for example, a free trial user has invited their co-workers and their account now has the maximum of users, that is a blinking green light that this account has opportunities to expand revenue.
These fields and product information will need to be combined with CRM data to create a scoring system for your freemium and trial users.
In addition, you'll want to have events, such as "tried to access gated feature," trigger immediate actions in the other tools you use.
Understanding the "health" of a given account is complex. There are so many variables involved, from feedback to behavior, that looking at each as any leading indicator is just not plausible.
Creating a high-level customer health score will help customer success, and support teams keep tabs on the overall customer experience.
A customer health score is a scoring model leveraged by customer-facing teams to assess whether a given account is "at-risk" of churn or healthy. The structure of this scoring model differs from company to company but usually involves signals from financial activity, product usage, customer sentiment, and other elements.
Generally speaking, a customer health score will be calculated by these variables:
The result you are looking for is a simple score, often based on colors (red=at-risk, yellow=neutral, green=healthy), that lives in an accounts company record in your CRM.
There are two ways to approach this.
The first is to have all the fields in the calculation synced with your CRM and then run the calculation from within your CRM.
The second is to have this scoring done outside of your CRM and have the score itself be synced.
Let's break down each element of a customer's health and the signals involved.
As mentioned earlier, your most significant opportunity to increase your Net Revenue Retention exists within your existing customer base.
While expanding revenue on these accounts is essential, it's equally important to ensure you keep your customers.
For customer success teams, churn is the thing that keeps them up at night.
While your interactions with a customer may seem positive, some signals go unnoticed in their product usage.
Tracking churn risk relies heavily on the customer health score of an account, but not exclusively. To predict and successfully intervene on a customer at risk for churn, you also have to be able to track events in the product that historically signal preparation for churn.
For example, if a customer is 60 days from their renewal date and they go into their account to export all their data, that's a good indicator that they intend to churn.
The best way to predict and reduce churn is to capture those kinds of events, combine them with CRM data, and alert the manager in charge of the account so they can take immediate action.
No matter how many tools, platforms, or dashboards different teams have to log in to every day, the CRM is the most widely referenced resource when looking for data.
You often hear, "if it's not in the CRM, it doesn't exist."
Because of this, creating a true "single source of truth" for customer data in the CRM is something many companies dream of.
If you've made it this far (thank you!), you know how vital product usage data is in your CRM.
You also know how complicated a process can be to make that happen.
The good news is that Parative was built to deal with this seemingly paradoxical situation.
The Parative Customer Behavior Platform differs from the other solutions cited earlier - CDPs, Reverse ETLs, IPaaS - in that it's meant to be used by non-technical teams.
Parative is designed to exist entirely within your current tools. No need to log in to yet another dashboard for siloed data.
Parative is customizable for simultaneous use by Sales, Success, & Marketing and is not priced on a per-seat model.
Parative is usable without ongoing support from technical teams or tools.