7 Enterprise Use Cases for Pendo at Scale
What large organizations need to accomplish across dozens of apps, thousands of users, and multiple regions, and how their teams use Pendo to do it.
Ask what Pendo offers at the scale and maturity of a modern enterprise and you’ll usually get a list of features like analytics, in-app guides, Data Sync, regional data hosting and role-based permissions. This list is accurate, but it won’t help much if you’re the leader responsible for making Pendo work across 50 applications, a dozen product teams, and a hard-nosed legal department.
Over the years we’ve helped enterprises in healthcare, HR, insurance, industrial services, and more run their product analytics programs with Pendo. The pattern is that scale always boils down to a short list of jobs the organization needs to get done. Pendo plays a big part in each one, but the rest requires decisions about ownership, standards, and data that only your team can make.
Below are the seven use cases we see most often, and what the teams executing them well have in common.
1. Follow one customer across dozens of apps
Many enterprises grow by adding or acquiring new products. When this happens, each app often gets instrumented on its own schedule by its own team. One team identifies users by Salesforce ID, another by email, and another by a homegrown hashed ID. So when the same user logs into your billing portal and then your service app, they appear to be two strangers.
Pendo handles this through its subscription and application structure. Apps whose users move between them can share a subscription, and a shared visitor and account ID connects their activity into one journey.
To get this right, you have to make a call on identity before the first install. One public safety technology company we work with had about 30 products spread across six subscriptions. Its governance group standardized visitor and account IDs and began merging everything into a single subscription, keeping only EU data in its own instance.
Two rules of thumb apply.
- Use a stable ID (e.g. GUID) as the visitor ID and keep email as metadata, since email addresses change.
- Keep apps in separate subscriptions only when they have different users, different owners, or a hard data requirement (more on that below).
2. Put product data next to revenue
At some point the CFO or CRO will ask, “do customers who use the product more also renew more?” Answering this question means getting usage data into the same data warehouse as the revenue, support, and marketing data.
Pendo’s Data Sync exports behavioral data to warehouses like Snowflake, where it can sit next to CRM and finance data. A global HR software company we work with syncs Pendo data into its cloud warehouse and has mapped thousands of pages to product SKUs. Now it can compare what each customer bought with what they use.
But to achieve this, you first have to decide what data to actually send to the warehouse. That same HR company cut its visitor metadata fields down by over two thirds, with naming prefixes and an owner for every source. Meanwhile, a global industrial company settled on just three fields that every app must send (email, account ID and account name) and then let individual product teams add their own on top.
The split we recommend is to use metadata for who someone is (e.g. role, region, account) and use track events with properties for what they’re doing in the moment, (e.g. which customer sites a field rep is viewing). Start with just 10 fields that everyone needs before branching out to more.
3. Let many teams talk to users without overwhelming them
Once enterprise teams realize how easy it is to build in-app guides, suddenly they all want one. Product wants to announce a feature while marketing wants to promote a webinar and support wants to ward off a common ticket. When you don’t coordinate this, your user logs in and gets bombarded with three pop-ups stacked on top of each other.
Pendo gives you the controls to manage this. Custom roles separate who can create a guide from who can publish it. Staging environments let you test guides before they go live. Guide throttling limits how often a user sees an automatic guide (e.g. once per 24 hours), and guide ordering determines which one shows first.
One company we work with has almost a hundred public guides, but just one person who can publish them. This is on the stricter side, and it does create some key person risk. But it also guarantees that their users see an intentional, strategic sequence of messaging.
The best-run orgs follow a two-step rule for guide governance:
- For any guide to be approved, require a goal, a hypothesis and a success metric.
- Send every new guide to a small test group before it goes to everyone. If it doesn’t impact the metric you picked in step one, fix it first.
4. Keep your data trustworthy
Data quality tends to erode at scale. When one person tags an “Add New” button on one page, but someone else tags a different button with the same name on another page, the report can conflate the two features. At the HR tech company, a mis-tagged feature once made it look like over 2,000 customers were using a new AI capability, when in fact adoption was still quite low. False positives like this can misdirect product decisions and damage your team’s trust in the data.
To combat this erosion, Pendo gives you naming conventions, product areas, a “Verified” label for segments, and the Rule Builder for writing more specific tagging rules. The process you implement around those tools is what keeps the data clean:
- A naming convention like Page > Location > Action for every tag
- A manual spot check of each segment before marking it ‘Verified’
- A quarterly audit (at minimum), plus monthly reviews of active guides
- A development standard requiring unique element IDs
A tag with zero views over 90 days usually means a page changed or a feature was retired. Either way, you should audit it.
5. Meet data residency and privacy requirements
Every enterprise product analytics program eventually runs into the legal, security, and procurement teams. Regional data laws, customer contracts, and internal privacy policies all shape what data you can collect and where it has to live.
Pendo supports this with regional data hosting, role-based access, and the option to run separate subscriptions for groups with stricter rules. A few examples we’ve seen in the wild:
- An HCM company runs one product suite in an EU instance to meet specific data residency requirements.
- An insurer’s business unit serves state government clients whose contracts prohibit offshore data access. It launched in its own subscription, gave the central product ops team read-only visibility, and kept the option to merge later after a formal security review.
- An HR software company replaced user names and company IDs with GUIDs and added an in-app consent prompt before its legal team approved go-live.
The pattern across all three is to bring legal in before you install, send only the identifiers you need, and choose identifiers that don’t reveal anyone on their own.
6. Get customers using what they already bought
For companies with a subscription product, this ties straight to renewals. A customer buys an add-on but never turns it on, and one year later the renewal conversation goes awry.
The HCM company saw this with an AI add-on. Of over a hundred customers in one product line who had purchased it, far fewer were both live and had turned it on for end users. The CSM email campaigns were getting open rates above 40%, but nobody could tell whether those readers were taking the next step.
Pendo closes that loop with segments built on entitlement and behavior, in-app guides served at the moment of need, and analytics that show whether a guide achieved anything. Using these tools to address the above roadblock, the HCM company chose to prompt customer admins to enable the add-on for themselves first, then trigger follow-up guides based on whether they did. They also saw adoption for a particular module rise 11% after they paired an in-product campaign with a webinar.
The key is to target by behavior, and be specific. A healthcare client aimed a refresher guide only at office schedulers who hadn’t used a popular feature in 30-60 days, since this range was the right balance between avoiding message fatigue and preventing disengagement.
7. Guide employees through software you don’t own
While AI coding tools are rapidly expanding the use of custom in-house software tools in modern enterprises, most tools are still SaaS products made by an external vendor. Field reps still work in Salesforce, your dev team still lives in Jira, and all your people still log into Workday. But when a required process isn’t getting done, you can’t always fix this with training alone. One industrial company described its action log, mandatory for certain employees to maintain, as “easy-to-use and bug-free,” but reps still weren’t filling it out.
To solve this, IT can deploy Pendo as a managed browser extension across employee devices, with identity provided by whatever system you already use (e.g. Okta or Azure AD). That puts in-app guidance and usage data inside third-party tools without touching their code.
Two things to remember when rolling this out:
- Since IT Security owns the deployment, they belong at the table from day one alongside the business owner and whoever runs your Pendo program.
- The visitor ID, metadata, and list of features to track should get settled before rollout. Revisiting these after thousands of employees are live means reworking reports and segments, so plan this one more carefully than a typical install.
Only you can decide how to run your org
Each one depends more on a decision than on a setting. Someone has to pick the ID standard, own the guide queue, run the audit, and align with legal. Pendo gives you the tools for every one of them, and we know firsthand that the enterprises getting the most from it made those calls early, documented them, and named the owners.
If you’re planning the next phase in your product analytics program, start with the use case causing the most pain today and work backward to the decision it depends on.
