Feature Request Capture
Feature request logged in tracking system with verbatim use case, theme tag, and impact metadata. Linked to source ticket. Customer acknowledged. Product PM notified if criteria met.
Before you start
- Feature-request tracking system (Productboard, Canny, or internal)
- Tagging taxonomy aligned with product roadmap themes
- Product team review cadence
- Customer's feature request from a ticket or in-app form
- Customer context (plan tier, ACV, account size)
- Existing similar requests in the system
The steps
- Acknowledge the request to the customer — Within 4 hours of receiving the request, reply: thank them, confirm you've captured it, set realistic expectations ('I'll log this for product review — we don't commit to dates here, but I'll let you know if there's movement'). Don't promise it will ship.
- Search for existing similar requests — Search the feature-request system for similar asks. If a match exists, add this customer's vote/comment to the existing request — don't create a duplicate. Duplicate requests fragment signal.
- Capture the use case verbatim — Don't paraphrase. Use the customer's words to describe the use case. Product needs the unfiltered request — your interpretation may miss nuance. Add your context (their plan, ACV) as metadata, not as edits to their words.
- Tag with theme and impact estimate — Tag with the relevant roadmap theme (e.g., 'reporting', 'integrations', 'mobile'). Add impact metadata: ACV at stake if the customer is asking, account size, frequency of similar request. Helps product prioritize.
- Link the source ticket — Cross-link: the support ticket points to the feature request, the feature request points to the support ticket. When product moves on the request, support can close the loop with the customer who originally asked.
- Notify product if high-value account or high frequency — If the request comes from an enterprise account or pushes a feature request over a threshold (e.g., 10+ asks), send a Slack notification to the product manager owning that area. Routine requests don't need notifications.
If it goes wrong
Feature request system fills with duplicates
Tighten step 2 — require similarity search before logging. Periodically merge duplicates.
Customer expects status updates that never come
Set expectations explicitly in the acknowledgment. Don't promise updates unless a status workflow exists. If product moves on the request, support proactively closes the loop.
Product team ignores the feature-request system
If product doesn't use it, don't pretend they do. Either fix the workflow with product (turn signals into roadmap inputs) or kill the SOP. Don't waste customer goodwill on signals that aren't read.
All OpenLabor playbooks