Most of the Pendo problems we see were never really Pendo problems.
Over the last few weeks I’ve been on a lot of calls with product and customer success teams who all bought the same tool for the same good reasons, and are stuck in remarkably similar ways. Different products, different industries, same five patterns. None of them are exotic. All of them are fixable.
If your team is paying for Pendo and quietly not trusting it, one of these is probably why.
Everything in Pendo hangs off two values: the Visitor ID and the Account ID. If those aren’t globally unique and stable, your data is corrupted at the source. Users get merged together, accounts get split apart, and no dashboard built on top of that foundation will ever be trustworthy.
This is the least glamorous part of a Pendo implementation and the most consequential. It usually goes wrong because the snippet install got handed to an engineer as a ten-minute ticket, with no conversation about identity strategy. Fixing it later is painful. Getting it right up front takes one meeting.
If you do nothing else after reading this, go confirm your Visitor and Account IDs are unique, stable, and documented.
Open a mature Pendo instance that’s had a few different owners and you’ll usually find the same thing: hundreds of feature tags, a large share of them duplicated, broken, or pointing at UI that no longer exists. Three people tagged the same button three different ways. Nobody knows which one the dashboard uses.
The result is that every number comes with an asterisk. Someone asks “how many customers used this feature last month,” three tags give three answers, and trust in the whole system erodes.
The fix is governance, which sounds bureaucratic but isn’t: a naming convention, a rule for who creates tags, and tags built on stable identifiers rather than fragile page structure, so they survive UI changes. Then an honest cleanup pass, deleting the redundant tags instead of archiving the problem.
The default failure mode of product analytics is the dashboard nobody opens. It got built for an exec review six months ago, it shows everything and answers nothing, and it’s not connected to anyone’s actual job.
The pattern that works is the opposite. Build views scoped to the person using them. A CSM shouldn’t look at a company-wide usage dashboard; they should open a view filtered to their accounts, showing the handful of signals that mean “this customer is healthy” or “this customer is drifting.” Then push the few metrics that demand action into the systems where people already work, like your CRM, so a usage drop shows up next to the renewal date instead of in a tab nobody checks.
A dashboard is only working if you can name the decision it changes.
In-app surveys and feedback tools are easy to launch, which is exactly the problem. Teams turn on NPS or a feedback widget, collect a pile of unstructured comments, and discover months later that nobody can do anything with them. Feature requests, bug reports, and sentiment all land in one bucket, and the loudest comment wins.
Before launching any feedback mechanism, we push teams to answer one question: what decision will this data inform? Feedback about missing features should route to the product backlog. Sentiment about a specific workflow should be captured in that workflow, with a question narrow enough to act on. If you can’t name what you’ll do with the answers, don’t launch the survey yet.
This one is the quiet killer. In a lot of companies, Pendo works because one admin cares. They know why every tag exists, which reports matter, and how the data model fits together. Then they change roles or leave, and the instance starts to decay. A year later a new team inherits a tool nobody trusts and the “Pendo isn’t working for us” conversation begins.
Tools survive turnover when the knowledge lives in the system, not the person: documented naming conventions, clear ownership, a data model written down somewhere findable. That’s the difference between an implementation and an asset.
None of these are software problems. They’re system problems: identity, governance, ownership, and connecting data to decisions. Pendo does what it’s told. The teams getting real value from it are the ones who told it something coherent.
The encouraging part is that every one of these is fixable in weeks, not quarters, and the order matters: IDs first, then tags, then dashboards and feedback. Trustworthy data has to come before anything built on top of it.
One more thing that stalls installs before any of this starts: the approval queue. If your snippet is still waiting on IT, here is how to get through a Pendo security review without losing a quarter.
If you’re not sure where your instance stands, we do a free 30-minute Pendo strategy session where we look at your setup together and tell you plainly what’s solid and what needs work. No deck, no pitch. Grab a time here.
Related reading: 5 signs your product experience platform needs governance and getting the numbers and the stories together in Pendo dashboards.