Zendesk's Native Ideas Board as a Feedback Backlog
Short answer: Zendesk's native ideas board, the Product Feedback area of Zendesk Gather, is good enough to collect suggestions and let customers vote on them. It is not good enough to be the actual backlog your engineering team works from, because nothing in it connects a "Planned" idea to the Linear issue or GitHub PR that ships it, and a vote from a free-tier account counts exactly the same as a vote from your biggest customer.
Zendesk's own public feedback board is the reference implementation, and it's a fair one, with thousands of requests, status labels, an intake template, and real product managers replying in threads. It also shows the ceiling. Zendesk runs that instance on Gainsight, a third-party community platform, not on the Gather feature it sells to its own customers to run on their Help Center. What you'd actually turn on is the same idea in a smaller package, and it has the same gap between "captured" and "actioned."
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat the ideas board actually does
Gather is a real feature, not a form bolted onto a help center. Once it's turned on for a Help Center, customers can post into topics, one of which is typically product feedback, and other customers can vote and comment. Zendesk's documented set of community post actions gives moderators a working toolkit, letting them move a post between topics, pin it, feature it, close it for comments, and change its status to Planned, Not Planned, Completed, or Answered. There's also a Convert to Ticket action, which turns a post or comment directly into a support ticket.
Zendesk's marketing page for the feature adds detail worth taking at face value. It lets you "escalate posts to your support agents when one-on-one help is needed", rewards contributors with badges, and supports multiple communities for different audiences or brands. None of that is thin. A small team can genuinely run intake through this for a while. The community's own submission template has five short sections, an overview, a problem statement, business impact, current workarounds, and an ideal solution, and forces a requester to say more than "please add this."
That's the toolkit as Zendesk ships it. Running on it day to day is a different question, and the gap shows up fastest at the account level, not the feature level.
What happened when Owen ran the board alone
Seventy-odd veterinary clinics run their scheduling and records on Barkline, and for most of this year the company's product feedback lived on one Zendesk Gather topic that Owen Baptiste, who runs support there, checked every few days. He'd turned the topic on back in April to pull requests out of scattered tickets and into one visible list, and for a while that was enough: customers voted, Owen tagged the top ten in a spreadsheet each month, and engineering picked from that list.
The board started drifting in July. By vote count, the top request was letting front-desk staff reschedule a recurring appointment series in one action instead of editing each visit separately, sitting at 34 votes. Nine votes down the list sat a post from Northgate Veterinary Group, Barkline's largest account, six locations, with a renewal due in six weeks: an audit trail of who changed a patient's medication record and when, because their compliance officer wanted one in place before signing again.
Owen knew which request mattered more. He'd been on the renewal call. But a vote count has no way to know which account sits behind it, so forty votes from forty free clinics outrank six votes from six paying ones on the edge of churning, and nothing on the board itself corrected for that. He marked the audit-trail post Planned, opened a Linear issue by hand, and pasted the post's URL into the issue description as the only link between the two systems. The feature shipped in August, and the Linear issue closed automatically through Barkline's git integration, but Gather had no way to know that had happened. Northgate's admin, checking the board again ahead of the renewal call, saw "Planned" on a feature that had already been running in production for eleven days.
What a manual system buys you, and where it runs out
That's on top of the ordinary problem of duplicate posts splitting one request's votes across several separately worded threads, since Gather has no merge action for community content, a failure mode we've covered in more detail, including a case where a support lead's spreadsheet had to make up for it by hand, in duplicate feature requests and split votes in Zendesk.
Short of adding another tool, a workable version of this looks like tagging your top accounts in a private note, cross-referencing vote leaders against that list before you promote anything, writing the tracker issue by hand with the community post linked in the description, and putting a recurring reminder on your calendar to sweep Planned posts against issue status weekly. It's the same kind of manual reconciliation we describe for Zendesk's ticket-side reporting in why Zendesk Explore can't tell you which companies asked for a feature, and it holds up for as long as someone is willing to be the join between two systems that don't talk to each other.
That's sustainable for a couple dozen live ideas and one person doing the reconciling. Add Slack threads, sales calls, and plain support tickets on top of the board, and the account-weighting check and the tracker sync both have to happen across four surfaces instead of one, and a weekly sweep can't keep pace with that surface area.
That's the point where a team adds something that reads every source, attaches the account behind each request automatically, and keeps the tracker issue linked without someone pasting a URL by hand. That's what Modem does. It connects to Zendesk tickets, Slack, email, and call transcripts, dedupes mentions of the same request into one counted topic with the accounts attached, and links each topic to the Linear issue or GitHub PR that resolves it, so the topic's status reflects the actual work instead of a label someone forgot to flip. Zendesk's community posts and their votes sit outside what that sync reaches today, though a post someone runs through Gather's Convert to Ticket action lands inside Modem's reach the normal way, the same as any other Zendesk ticket. For everything that stays a post instead of a ticket, Gather's board still needs the manual weighting check above. We build Modem, so factor that in as you weigh the alternatives in best tools to mine feedback from Zendesk tickets. Below a couple dozen live ideas, Gather plus the manual habits above is genuinely enough.
Where to start this week
If you're already running Gather, write down which accounts count as your top tier, and check that list against your current vote leaders before you promote anything from the board. If a lower-voted post has a renewal-risk account behind it, that's the one that goes to engineering first, whatever the vote count says.
