Skip to content

Feature Request Triage & Deduper

Example prompt: "When a Zendesk ticket comes in tagged 'feature-request', read what the customer is asking for, check our Linear backlog for anything similar, and either link the ticket as evidence to the existing item or create a new backlog item with the customer's context. Either way, reply on the Zendesk ticket with a short acknowledgement."

The Problem

Feature requests arrive through support tickets, and they almost always duplicate an existing backlog item or another customer's request from three months ago. The right move is to count the new evidence against the existing item so prioritisation reflects real demand. The actual move, when the PM has a packed week, is that the support agent pastes the request into a Slack DM, the PM nods, and the request enters the void. Meanwhile, the backlog item that already exists never accrues the second, fifth, twentieth signal that would have pulled it up the queue.

How GloriaMundo Solves It

We build a workflow triggered by a Zendesk ticket being tagged "feature-request". An LLM step extracts the gist of the request — a short title, the underlying job-to-be-done, and any specific examples the customer gave. An integration step searches the Linear backlog for issues with similar titles or descriptions. A conditional decides what to do: if a strong match exists, an integration step posts a comment on the matching Linear issue with the customer's verbatim, a link back to the Zendesk ticket, and increments a "requested by" count in a custom field; if no match, an integration step creates a new backlog issue in the "Feature Requests" project with the gist, the customer's verbatim, and the source link. A final integration step replies on the Zendesk ticket with a short acknowledgement: we've logged it, here's the tracking link, we don't promise a date. Glass Box preview shows the proposed match (or "no match found"), the Linear comment or new issue, and the customer reply before any of it is sent.

Example Workflow Steps

  1. Trigger (webhook): Fires when a Zendesk ticket is tagged "feature-request".
  2. Step 1 (LLM): Read the ticket and extract a short title, the job-to-be-done, and any specific examples.
  3. Step 2 (integration): Search Linear for issues in the "Feature Requests" project with similar titles or descriptions.
  4. Step 3 (LLM): Decide whether the strongest candidate is a real match or whether this is a new request.
  5. Step 4 (conditional): Branch on the LLM's decision.
  6. Step 5a (integration, match branch): Comment on the existing Linear issue with the customer's verbatim, the Zendesk ticket link, and increment the "requested by" count.
  7. Step 5b (integration, new branch): Create a new Linear issue in the "Feature Requests" project with the gist, the verbatim, and the source link.
  8. Step 6 (integration): Reply on the Zendesk ticket with a short acknowledgement and the Linear tracking link.

Integrations Used

  • Zendesk — source of the tagged feature request and where the acknowledgement reply is posted
  • Linear — where the backlog lives and where the request is logged or counted

Who This Is For

Product managers at SaaS companies whose support team is the front line for feature requests and whose backlog suffers from the same idea being filed three times under three different titles. Especially useful where the volume is high enough that a PM cannot eyeball every request but low enough that the duplicate-detection job is tractable for an LLM.

Time & Cost Saved

A conscientious support-to-product handoff takes a PM 5-10 minutes per request: read the ticket, search the backlog, decide match or new, write the comment or issue, reply to the customer. At 30 requests a week that is 2.5-5 hours. The realistic baseline is that most requests fall through and the backlog stops being a representative demand signal. This workflow keeps the signal honest; the PM's time goes into the requests the workflow flagged as ambiguous and the calls about which of the now-properly-counted items to actually build.