Introduction

As more and more sales teams launch product-led sales motions, one of the first challenges a RevOps team will tackle is how to enable your sales teams with product data—specifically by giving them access to said data from where they work—the CRM.

Although it may appear straightforward, getting a clear picture of how your customers interact with your product through your CRM system can be quite the challenge. While, there are many pitfalls in why companies need more than a CRM to architect this system – this is a common conversation we come across.

In this post, we will walk you through each step on how to surface product data within your CRM. The overarching goal here is to attempt to unify your customer data from product constructs (e.g., workspaces) with the business constructs that exist in your CRM (e.g., accounts):

In this example, we’ll be using a common tech stack as our demo environment: BigQuery (data warehouse), Segment (CDP), Hightouch (rETL), and Salesforce (CRM)—and the end result will look a bit like this:

1. Generate models in your Data Warehouse

We’ll start by generating models in your data warehouse that will serve as the base data that you’ll be syncing to your CRM. This is easily the most technically complex step in the process as it involves writing a decent bit of SQL. If you’re new to SQL, Mode provides some great tutorials to get you started.

Once you’ve identified where your product data lives—in this example, BigQuery—you’ll be writing SQL to build out the datasets that will act as the models that are sent over to your CRM via rETL. In this case, we’re focussed on generating two models that combine both dimensional data, and relevant metrics.

Workspaces

Workspaces—also commonly referred to as organizations or teams—are logical groupings of users within your product.

Domains

Your domain model should be 1:1 with the Accounts in your CRM. We refer to it as a domain model because a 1:1 account to domain model has become the go-to modeling approach for B2B SaaS companies.

Considerations

• CDP data can serve as a basis for your models, but it’s quite common to have “blessed” tables available internally that serve as a more reliable data source.
• In the case of a CDP like Segment, you’ll typically grab dimensional data from the `identify` (users) and `group` (workspace) tables. Metrics will be summarized from the `tracks` table.
• Workspace domain is commonly determined by either the domain of the workspace owner, or the most commonly occurring domain within the workspace
• Exclude high cardinality domains (e.g., gmail.com) when possible—this is a readily available data point when using a 3rd party enrichment provider
• When using enriched firmographic data, you’ll likely want to respect arrays of domains (e.g., amazon.com, amazon.co.uk)

A notable omission here is representing your product users in the CRM. This tends to get quite a bit more complex—especially in the case of many-to-many relationships between workspaces and users. We’ll cover users in more detail in the future 😉

2. Establish the appropriate schema in your CRM

The next step is to prepare the CRM to ingest the data from the models we just created. Most popular CRMs include the idea of custom objects—which allow you to represent data related to an Account/Company, but aren’t necessarily 1:1 with a company.

In the case of Salesforce, you’ll simply create a custom workspace object (e.g., workspace__c) with a lookup field to the account object. At that point, you’ll simply add the fields you’re interested in syncing to the respective objects, and you’re good to go!

Considerations:

• In Salesforce, consider using lookup rather than master-detail relationships for added flexibility.
• Be considerate of data types to ensure your data syncs succeed, and are appropriately actionable after post-sync
• Ensure uniqueness on Domain when possible
• Enrichment providers frequently provide a framework for parent account relationships based on the parent domains

3. Configure automations for CRM entity linking

We’re using flows in Salesforce to link the entities that will be generated and updated by rETL to the right accounts. While the complexity of your instance may vary, here are a couple example flows that will get you started:

Considerations:

• These relationships can easily be managed in the data warehouse, but can be subject ETL latency from Salesforce to your data warehouse
• Depending on the sophistication of your existing salesforce implementation, consider augmenting existing flows, rather than creating net new flows
  

4. Sync & schedule models via rETL

Now that we have our models, and have prepped the CRM, it’s time to start moving data via rETL! We’re doing so with Hightouch, and the process is quite straightforward:

1. Connection your data source (BigQuery), and destination (Salesforce)
2. Create your workspace and domain models and based using the previously crafted SQL
3. Create a sync for each of the models, and map the model fields to the newly created Salesforce fields
4. Run your syncs, and schedule them to run on a regular basis

Considerations

• This can be accomplished without rETL—such as syncing data directly to Salesforce via Segment, or creating a custom API connector. The downside in those approaches is decreased flexibility and increased maintenance—hence my preference for a rETL based approach
• Consider using sequences to ensure that objects land in the appropriate order. In this case, it’s best to sync the Accounts (via the domain model) prior to the Workspaces (via the workspace model)

5. Surface data in your CRM

Now that you have your data in Salesforce, it’s time to make it available for your reps! Here are a couple examples of you might do so:

Considerations

• When surfacing aggregate data, it’s often helpful to link out to other reporting tools for additional detail about a given domain or workspace
• This data is also very actionable from an automation standpoint (e.g., create and assign lead/account in the case of more than x account workspaces)

Conclusion

This is obviously a simple—but fully functional—implementation, but hopefully it’s a helpful framework in terms of how you might consider representing product data in your CRM.

Want to see us walk through it live? Check out the Endgame Labs episode on Youtube.

Next time, we’ll build on this example, but with a focus on users—which comes along with a number of complexities as you consider the many-to-many relationships that often exist in SaaS products. Here’s a little preview: