Most teams set up a Pendo product feedback workflow in an afternoon. One guide, one open text box, one destination. Then the responses start arriving, and everything a customer types lands in the same place. Bugs, feature ideas, a note about a broken link, someone asking where the export button went, a complaint about billing that nobody in product can do anything about.
You are probably thinking the problem is volume, not structure. That adding more queues just creates more places for feedback to sit unread, and you already have a backlog nobody has opened since spring. I thought that too, for longer than I should have. It turns out to be backwards. The pile does not go unread because it is big. It goes unread because there is no rule for what happens to any single item in it, so reading it never produces a decision. Splitting the intake is what makes the reading worth doing.
The pattern shows up in most accounts we work with. Feedback intake gets built once, usually by whoever had Pendo access that quarter, and then never revisited. A year later there are a few thousand responses, three people who feel vaguely responsible, and a product team that has quietly stopped trusting the queue. The responses themselves are usually good. Reading through a batch of open text responses is almost always humbling. The problem is that nothing downstream is built to receive them.
Here is the version that holds up.
Open your feedback guide and look at the first screen. If it says something like “tell us what you think,” you are asking one question and getting two kinds of answers back.
Add a branch before the text box. Two options, in plain language: something is broken, or something is missing. That single click does more work than any amount of tagging you do later, because the person submitting is the only one who knows for certain which one it is. Broken goes to support. Missing stays with product. Same guide, two paths.
While you are in there, attach the product area at the point of submission instead of sorting it out by hand a month later. That only works if your tagging is stable enough to trust. If you are not sure it is, the signs that your product experience platform needs governance are usually easy to spot from the inside.
Ask yourself where an idea lives between the moment it arrives and the moment someone decides to build it. In most companies the answer is “the engineering backlog,” and that is the root of the mess.
An engineering backlog that holds every idea anyone has ever submitted is a hardware store with one aisle. Everything is in there. Good luck finding the screw you actually came for.
Keep the two things separate. Pendo holds the thinking: the request, who asked, how many others asked, what those accounts are worth, whether it fits the roadmap. Your engineering tracker holds committed work only. When something gets accepted, it moves across, once, in one direction. Nothing syncs back except status. Engineers get a clean board. Product keeps the full picture, including all the ideas that were considered and passed over, which is the part that disappears when you dump everything into Jira and hope.
Pick a request from three months ago and try to answer this: does the customer who submitted it know what you decided? Does the CSM who passed it along know?
If the answer is no, your queue is going to dry up, and it will dry up quietly. People stop submitting when submitting feels like dropping a note down a well. They do not complain about it. They just stop.
The fix is not complicated. Statuses a human can read, visible to whoever asked, updated when the status actually changes. Even “reviewed, not planned” beats silence. This is also the single biggest reason your customer success team ignores Pendo, because if nothing visible happens after they route a request, routing requests stops being part of their job.
Name a person and a time. Not a team, a person. Thirty minutes every two weeks, on the calendar, tied to your sprint cadence so the decisions land somewhere they can be acted on.
I have built the wrong version of this. Years ago I stood up a feedback guide for a team, watched submissions come in for six weeks, and felt good about the response rate. Nobody had been assigned to read them. The volume was the number I was proud of, which in hindsight was the least useful number available. What fixed it later was not a better guide. It was a standing half hour and one named owner.
Once that half hour exists, the output has somewhere to go. A short voice of customer report every two weeks turns the queue into something leadership reads instead of something product defends.
Feedback does not die from lack of volume. It dies from lack of an address.
Two queues instead of one sounds like more work. In practice it is less, because the sorting happens at the moment of submission, done by the only person who knows the answer, instead of in a two hour cleanup session someone dreads every quarter. The engineering board stays honest. The product team keeps a record of what was asked and what was decided. The customer hears back. None of that requires new software.
Open your feedback queue and read the last twenty submissions. Sort them by hand into broken and missing. If the split is anywhere close to even, you have been running two workflows through one pipe, and you now know exactly which change to make first.
The feedback queue holds requests that have not been decided yet, along with the context that makes them decidable: who asked, how many asked, and what those accounts are worth. The engineering backlog holds work someone has committed to building. Keeping them separate is what stops the backlog from filling with ideas nobody ever intends to start.
They can use the same guide, but not the same path. Ask the submitter one question first, whether something is broken or something is missing, and branch from there. Broken routes to support, missing routes to product. The person submitting always knows the answer, so asking them is faster and more accurate than sorting it out afterward.
Every two weeks is enough for most teams, and it should be one named person on a standing thirty minute block rather than a group that shares the responsibility. Tie the review to your sprint cadence so the decisions have somewhere to go. Reviewing more often rarely helps if nothing downstream is ready to receive the output.
Only for work that has actually been accepted, and only in one direction. Mirroring every submission into Jira recreates the same undifferentiated pile in a tool your engineers depend on being clean. Send items across when they are committed, and let status be the only thing that flows back.
If you want a second set of eyes on how feedback moves through your Pendo instance, I offer a free 30-minute Pendo strategy session. No deck, no pitch. Bring your setup and your open questions and we will look at it together. You can grab a time on my calendar.