Getting Product Usage Data to the People Who Need It Most
Your account management and customer success teams know which accounts are coming up for renewal. They know which ones have been escalating.
But, if they can tell you whether those accounts actually used the product last month, they are probably logging into a separate system to find out. Most customer-facing teams, believe it or not, have no visibility into usage-based account health at all. No adoption signal. No telemetry tied to renewal risk or expansion potential. Just relationship history, gut feel, and whatever made it into the CRM notes.
That gap is costing us renewals and growth opportunities. And right now, with gross retention under more pressure than it has been in years, it is a gap that SaaS companies can no longer afford to leave open.
Renewals have always been the heartbeat of a subscription business. But the environment has changed. Buyers are scrutinizing spending more carefully. Finance teams are asking harder questions about ROI at renewal time. The companies that are holding their NRR together are the ones where account management and success teams walk into every customer conversation already knowing what value they got from the product.
The rest are still hoping the relationship is enough.
Retention is proactive. Increasingly it is predictive.
For most B2B SaaS companies, product usage data is a strong leading indicator of renewal risk. A customer who logs in regularly, adopts key features, and spreads usage across their team is far more likely to renew and expand than one who goes dark for 60 days. What's changing with AI is the ability to act on these signals at scale, automatically, before humans have to make judgment calls.
The retention operating model that is emerging in the best-run organizations runs on three layers working together.
The first layer is the signal layer. This is where we detect and sense what is happening with the customer based on what the data is telling us. Which accounts logged in this week. Which ones did not. Which users dropped off after onboarding. Which features are being adopted and which are collecting dust. Product telemetry is the raw material. Pendo is where most of it originates. But the signal only has value if it reaches the people and systems that can act on it.
The second layer is the autonomous action layer. These are the actions our systems can take automatically, without a human deciding or noticing. When a customer has not logged in for 21 days, or when a new user was provisioned but never completed a key workflow, the system sends an in-app guide, a targeted email, or a personalized nudge. Pendo's Orchestrate product does this natively. AI-powered tools like Pendo Predict take it further by surfacing accounts that changed behavior in the last 30 days, flagging the ones that dropped below a usage threshold tied to historical churn patterns, and drafting outreach before the rep even opens their CRM. The campaign is only as smart as the signal feeding it, which is why the first layer matters so much.
The third layer is human intervention. For strategic accounts, a well-prepared conversation with a senior account manager or CS leader is still the highest-leverage move. The goal of this layer is to arm the humans in the loop with more powerful, prepared, and informed conversations. That means knowing, before the call, exactly where the customer stands in their adoption journey. Which modules they are using. Which users went inactive. Which workflows they purchased but never deployed. That context turns a check-in call into a consultative conversation, and it turns a renewal negotiation into a value review.
All three of these layers depend on product telemetry getting to the people and systems that need to act on it. And for most GTM teams, that means CRM, namely Salesforce.
Why Salesforce is the integration target that matters
Account managers and CS teams live in Salesforce or systems connected to it. They build pipeline there, manage renewal opportunities there, and log every customer interaction there. Asking them to open Pendo (or a Looker dashboard or any other system) before every customer conversation is asking them to adopt user workflows that are cumbersome and time consuming.
The goal is to surface the right signal in the system where the team is already making decisions and where they can drive automated campaigns and outreach. A usage summary on the account record. A risk classification on the renewal opportunity. A flag when a key user goes dark. The data needs to show up where the team already lives.
Six techniques for getting Pendo data into Salesforce
So how do you get data from Pendo into the CRM to reduce this end-user complexity? There are several ways to do it. None of them are magic. Each involves a tradeoff between effort, flexibility, and data timeliness. Here is what each one looks like in practice:
1. Native Account / Visitor Report Sync
The most accessible starting point is Pendo's native Salesforce integration. You configure an account or visitor report in Pendo, map the fields to custom objects on the Salesforce account or contact record, and Pendo syncs the data on a scheduled basis. Field-level data like last visit date, total event count over 30 days, days active, and NPS responses all move over cleanly. For most account management and CS teams, this alone is a meaningful upgrade. A rep opens an account record and sees a snapshot of product activity without ever touching Pendo.
The limitation is that Pendo sends raw field values. If you want a derived score, a health grade, or a classification like "power user / active user / at-risk user," that math has to happen somewhere other than Pendo before or after the data moves.
2. Metadata Upload
One clean way to handle this is to treat Pendo as a "relay." Build your health score or user classification outside Pendo, whether in a spreadsheet, a data warehouse, or a dedicated health scoring tool, import the result back into Pendo as custom account metadata, and let the native Salesforce sync carry it across to Salesforce. The logic lives outside. Pendo passes the value through to Salesforce.
3. External Calculation Layer with API Write-Back
For teams that want to automate the calculation itself, the more robust pattern involves pulling Pendo data out via the API, running the logic in an external tool (Google Sheets works for lighter use cases; Databricks or a proper data pipeline tool that can handle scale), writing the result back to Pendo as account metadata via the API, and then letting the Salesforce sync deliver it.
One of our engineers used this technique with an account to deliver scores on a 24-hour automated cycle. The Pendo API write-back is key, because it allows you to compute anything externally and still have it surface natively in Salesforce through the standard integration.
4. Segments as Boolean Fields
For teams that want to represent Pendo segment membership in Salesforce, for example tracking which accounts fall into a "talent module at-risk" segment or a "no logins in 45 days" segment, the pattern is to create an account report scoped to that segment and push a true/false field to the Salesforce account record.
For tiered risk classifications, you create one report per tier and one field per tier. An account manager looking at the record sees a clean set of indicators without needing to know how they got there.
5. Session Replay + Pendo Listen Native Tabs
The two integrations that feel most natural from a rep experience standpoint are Session Replay and Pendo Listen. Both add a tab directly on the Salesforce account record. An account manager opens the account and sees the most recent session recordings for that account's users, or the most recent feedback submissions from Listen, without any context switching.
For CS leaders who have spent years trying to get their teams to log product context into CRM notes, this is the path of least resistance.
6. Pendo Predict
For organizations serious about the predictive renewal and expansion sales modeling and forecasting, Pendo Predict is worth a dedicated conversation. Predict functions as a scoring engine built on Pendo telemetry, CRM data, and other available data sets such as support ticket, call transcripts, billing, etc.
Predict is designed to push risk scores and recommended actions directly into Salesforce, and even take action on those signals. It removes the external calculation layer entirely. Predict requires its own license, but for a company where renewal rates are closely tied to feature adoption patterns, the question is what a one-point improvement in gross retention is worth to the business.
Netting it out
Aside from Predict, the scores, classifications, and risk grades that make product data useful for an account management or CS team have to be computed somewhere outside Pendo before they can be useful in Salesforce. This is the architecture, and accepting it early makes the integration work.
The companies that build this well start with a business question, e.g., What does an account manager need to know about this account before the renewal call? What signal should trigger an expansion conversation? What automated action can we take here? What does healthy adoption look like for this product, at this customer size, at this stage of the contract?
Once those questions have answers, the integration becomes a delivery mechanism. You know which fields matter, where the calculation lives, and what the Salesforce record should show when someone opens it.
Companies that struggle start with "let's get Pendo data into Salesforce" as the goal. That is the wrong starting point. The goal is an account management and customer success team that shows up to every customer conversation already knowing where the customer stands, already knowing what automated campaigns are running in the background, and already knowing which accounts need a human touch before the quarter closes.
That is what a modern retention operating model looks like. And product telemetry, routed to the right places, is what makes it run.
How is your team currently using product usage data to drive retention and expansion conversations? I am curious where the signal is coming from and where it lives in your workflow.