TL;DR: Pendo Guides are pre-authored in-app messages (tooltips, banners, modals, and multi-step walkthroughs) that you build in a visual editor and target at user segments without shipping code. They are very good at orientation, announcements, and feature adoption nudges. They are structurally weak at support resolution, because a Guide is content you wrote in advance for a segment, not an answer to the question a specific user is asking right now. If your goal is ticket deflection rather than onboarding, Guides get you partway and then stop.

Your support queue is full of questions your product already answers somewhere. A user cannot find the export button. Another does not understand why their integration shows a red dot. A third files a ticket about a permission they were never granted. Somewhere in your app there is probably a tooltip, a walkthrough, or a help article covering each one, and none of it got used at the moment it mattered. If you run Pendo, the tool you reach for here is Guides: in-app messages you build and target without a code deploy. Guides are genuinely good at what they were designed for, and they are also why a lot of support leaders end up disappointed with their in-app deflection numbers. Pendo Guides are an orientation and broadcast layer, not a resolution layer, and knowing that difference tells you what to build next.

What are Pendo Guides?

Pendo Guides are in-app messages you author in Pendo's visual designer and display to specific user segments based on rules, without shipping code. They render on top of your product through Pendo's JavaScript snippet and can take several forms: a lightbox or modal, a top or bottom banner, an anchored tooltip, or a multi-step walkthrough that moves a user through a task.

Each Guide has three parts: the content you write, the segment you target, and the activation rule that decides when it fires. Activation can be automatic on page load, triggered by a click on a specific element, tied to feature usage or account attributes, or set to on-demand so the Guide only appears when a user opens it from the Resource Center. Pendo then reports on views, clicks, dismissals, and completion so you can see whether the content was seen and acted on.

The important word in all of that is pre-authored. A Guide is a thing you decided to say before the user arrived. That single design choice explains both its strengths and its ceiling.

How do Pendo Guides actually work?

The workflow is consistent across most implementations: install the snippet, tag your pages and features, define a segment, author the Guide, set activation, test in staging, publish, and measure. Engineering is involved once at the start; after that, a PM, CS lead, or support ops person can ship Guides on their own.

Tagging is the part teams underestimate. Pendo needs to know what a "page" and a "feature" are in your app, and those definitions are tied to URL patterns and DOM selectors. When your front end changes, tagging drifts, and Guides anchored to a moved or renamed element stop appearing or appear in the wrong place. This is not a Pendo flaw so much as the physics of overlaying content on a UI you do not control from inside the tool.

Segmentation is the other lever. You can target by role, plan, account, lifecycle stage, feature usage, or custom metadata you pass in. Good segmentation is what separates a Guide program that feels helpful from one that feels like pop-up spam. It is also real ongoing work: segments have to be maintained as your product, pricing, and personas change.

What are Pendo Guides genuinely good at?

Guides are the right tool whenever you know in advance what you want to say and to whom. That covers more ground than skeptics admit.

• Onboarding orientation. A first-run walkthrough that shows a new user the three things they must do in week one is exactly the shape of problem Guides solve.
• Announcements and UI changes. Moving a button, retiring a feature, or launching a redesign is a broadcast problem, and a targeted banner is a better channel than an email nobody opens.
• Feature adoption nudges. Showing a contextual tooltip to accounts on the right plan who have never touched a feature is a legitimate, measurable growth play.
• Surveys and NPS. In-app polls that fire at the right moment in the workflow get response rates email cannot match.
• Closing the loop with analytics. Because Guides live inside Pendo's product analytics, you can see whether the people who saw a Guide actually changed behavior. Standalone messaging tools cannot do that as cleanly.

If your problem is "our users do not know this exists," Guides are a strong answer. Be honest about that before comparing anything to them.

Where do Pendo Guides fall short for support teams?

Guides fall short wherever the question was not predictable. Support volume is dominated by the long tail: configuration questions, errors tied to a customer's own data, permission confusion, and integration failures that look different in every account. You cannot author a tooltip for a question you did not know would be asked.

Four failure modes show up repeatedly in support-led Pendo programs:

• Coverage gaps. The team writes Guides for the top ten known friction points, which are also the ten things already documented. The eleventh through five-hundredth questions still become tickets.
• Content decay. Guides are a content library, and libraries rot. A walkthrough written for last quarter's UI quietly becomes wrong, and wrong in-app content generates tickets rather than deflecting them.
• Attention economics. Every Guide spends user patience. Ship too many and dismissal becomes reflexive, which degrades the Guides that actually mattered.
• Measurement drift. Guide views get reported as deflection. Views are not resolutions. Unless you are comparing ticket volume for the same issue before and after, you are measuring impressions and calling it savings.

None of this means Guides are the wrong purchase. It means Guides are being asked to do a job they were not designed for.

Why can't a Pendo Guide answer an account-specific question?

Because a Guide has no way to reason about one account's situation. It selects content by matching a user against a segment rule, then displays that content identically to everyone in the segment. It does not know what this customer configured, what their last three tickets were about, or why their sync is failing today.

Take a common example: "Why did my Salesforce sync fail?" The real answer depends on that org's field mappings, their API limits, whether an admin changed a required field, and what the last error payload said. A Guide can point at the sync settings page. It cannot look at the failure and explain it. So the user reads the tooltip, learns nothing new, and opens a ticket, which is the exact outcome the Guide was purchased to prevent.

This is the structural limit. Guides scale orientation: telling many people the same useful thing. Support is mostly the opposite job: telling one person the specific thing that is true for them.

What does AI in-app support do differently?

An AI support layer answers the question rather than routing the user toward where the answer might live. Worknet's approach is to sit in the product at the moment of friction, take the user's actual question in their own words, and resolve it using that account's context, their history, and your documentation, rather than serving a pre-written card. When it cannot resolve something, it escalates with that context already attached, so the human agent does not restart the investigation.

Two other differences matter for support leaders. First, the same engine runs across surfaces, so the answer a user gets in-product is the answer they get in a shared Slack channel, in Zendesk, or through Salesforce. Second, it is configured in plain English and connected through API or MCP, so it is typically live in days rather than becoming a quarter-long tagging and authoring project.

The honest trade-off: Worknet is not a no-code tour builder and it is not a product analytics suite. It will not build you an onboarding walkthrough, will not report feature adoption funnels, and does not replace what Pendo does well. If you need to author flows and analyze usage, you need a DAP.

Should you replace Pendo Guides with AI in-app support?

Usually not. The two solve different halves of one problem, and the useful question is which half is actually costing you money.

Keep Guides as the primary tool if your pain is orientation: new users not activating, features going unnoticed, UI changes catching people off guard, or a need for adoption analytics. That is the job Guides were built for and they do it well.

Add a resolution layer if your pain is ticket volume: a long tail of account-specific questions, agents re-answering things buried in docs, escalations arriving without context, or a deflection number that has not moved despite a growing Guide library. Those symptoms do not get better by writing more Guides, because the bottleneck is not content coverage, it is the absence of anything that can answer.

The clearest failure to avoid is buying a digital adoption platform primarily as a ticket deflection tool. That is the one job it is structurally not built for, and the gap will show up in your queue rather than in the Guide analytics.