Feature requests in support threads die in two places: a Slack thread nobody tagged, and a backlog entry with no customer words attached. What follows is a record, a counting rule, reply wording, a handover to product and a notification policy.
Support captures, product decides
Support owns four things: the record, the evidence, the counts and the status messages back to the customer. Product owns the decision and the schedule. Write that split into the handover doc. When a customer asks “when”, the answer comes from the product owner, not from whoever is in the thread.
Product tools hold the backlog, votes and roadmap, and support feeds them. As of 2026-11-11, Canny’s pricing page lists a Free plan at $0 with 25 tracked users, a Pro plan that starts at $79 / month billed yearly, and a Business plan under “Let’s talk” with no list price. Productboard’s pricing page describes contributors as colleagues who “submit feedback, tag insights”, and shows no USD seat price, so ask its sales team for a quote before budgeting.
Until you have a product tool, a Slack List is enough. Slack’s help article says new lists come with four task-tracking fields (Completion, Name, Assignee and Due Date), that the feature is “Available on paid plans”, that Pro and Business+ allow 1,000 items and subtasks per list, and that Enterprise Grid allows 5,000. Frontline Members can’t create lists, so if your reps are Frontline Members, a teammate who isn’t must create the list and its columns.
The same article says a list is visible to the people or channels you share it with. Share it with an internal support channel only. The record holds exact customer quotes, seat counts, contract value and sometimes candid notes about other accounts, and sharing the list into a Slack Connect channel would show all of it to that customer.
The record
Every request gets one record, short enough to fill in during a thread.
Request (product's words, one line):
Customer's words (exact quote, personal details replaced):
Source (Slack Connect channel, email, call, ticket, in-app):
Thread link:
Account (account record, not email domain):
Requester and role:
Distinct accounts asking (last 90 days):
Mentions (count and dates):
Seats affected (from billing or CRM):
Contract value at stake (USD, only if billing or CRM has it):
Blocking? (yes: work stops / no: workaround exists)
Workaround today:
Status (logged / under review / planned / shipped / declined):
Support owner:
Next review date:
Last customer update (date):In a Slack List, use Name for the one-line request, Assignee for the support owner and Due Date for the next review date. Don’t use Due Date for a delivery date, because customers read it as a promise.
Two fields do most of the work. “Customer’s words” is a quote, not your paraphrase, because product tends to reframe a request into the solution it already has in mind. “Distinct accounts asking” counts accounts, because one enterprise team posting the same request five times is one signal, and five small accounts is another.
Check your contract and privacy terms before quotes travel. This is not legal advice, but a sensible default is to replace names, email addresses, phone numbers and account IDs with [person] or [account], and to keep a quote out of any customer-facing roadmap or changelog unless the customer agreed to it in writing.
Capture from every channel
When a message in a shared channel contains a request, the support owner creates the record in the same session and replies in the thread. A reaction is not a record.
Calls, tickets and in-app feedback use the same record. For a call, write the quote from your notes the same day and put “call, from notes” in the source field, since it isn’t verbatim. For a ticket or in-app message, paste the link. Then apply one dedupe rule:
- Same request, same account, two channels: one record, two links, one account counted.
- Same request, two accounts: one record, both accounts counted.
Worked example: on Monday a Slack message from Northwind asks for bulk export of thread history. On Wednesday a Northwind admin emails the same ask. The second message adds a link, and the count stays at one account.
Counting demand: accounts, seats and mentions
A request is a pattern when it meets one of two thresholds in a 90-day window. They are working thresholds, so tune them to your volume.
- Three or more distinct accounts asked for the same outcome.
- One account where the request blocks its work and there is no workaround.
Worked example: three accounts asked for bulk export of thread history to CSV. Their seats were 140, 45 and 20, so 205 seats, with 12 mentions in total. That is a pattern. Mentions show how often the pain surfaced, which helps rank a fix, but they say nothing about how big the fix is.
Use seats as the tiebreaker between two requests with the same account count. Mention counts never break a tie. Use contract value only when billing or CRM provides it, and leave it blank otherwise, because an estimate will be quoted back to you.
What to say when you log it
Reply in the thread on the same day. Every first reply contains the word “logged” and the phrase “I can’t promise whether or when it gets built”:
“Thanks, I’ve logged this as a request for the product team. I can’t promise whether or when it gets built, but I’ll post here if product decides to plan, decline or ship it.”
Don’t write “we’re building that” or “it’s on the roadmap” until product has decided. At each later status change, use the wording the product owner approved:
- Under review: “The product team has this on its review list. There is no date yet.”
- Planned: “The product team has planned this. I don’t have a release date. I’ll update this thread when I do.”
- Declined: “We’ve decided not to build this for now. Here is the reason, and here is a workaround that may help.”
- Shipped: “This shipped on the date below. Here is how to turn it on: [steps].”
Declined wording needs a real reason from product. If product can’t give one, the request isn’t ready to be declined.
The handover to product
When a record crosses a threshold, send product one summary per request:
Request: bulk export of thread history to CSV
Accounts: 3 (Northwind, Contoso, Fabrikam), 205 seats, last 90 days
Mentions: 12, first on [date], latest on [date]
Blocking: 0 of 3 accounts (Northwind: monthly audit takes about 2 hours by manual copy)
Workaround: manual copy, about 2 hours per audit
Quotes: 3 exact quotes, personal details replaced
Links: [record] [3 thread links]
Decision needed by: [date of next review]The loop is a fixed two-week review. Support sends summaries the working day before, a named product owner (usually the product manager for that area) attends, and each request leaves with one decision that maps to a status:
- Needs more information: stays “logged”, with a question for support to ask the customer.
- Accepted for evaluation: “under review”.
- Committed: “planned”, with the owner’s approved wording.
- Released: “shipped”.
- Not building: “declined”, with a reason.
If the owner returns no decision in two reviews, escalate to the product lead instead of letting the count climb.
Where AI agents fit
Put the boundary in writing before an agent touches a customer thread.
- An agent may create the record from the thread, copy the exact quote with personal details replaced, count accounts from the records, and draft the logged reply.
- An agent may not say “planned”, “on the roadmap” or any quarter, decline a request, count accounts by email domain, or post a status change that product hasn’t approved.
- If the customer asks “when” or “will you build it”, a person answers the same day. If the request describes a production or billing blocker, a person takes over the thread.
For response-time metrics, our first response guide says only a human reply that addresses the request stops the clock. Under that rule a logged reply sent by an agent alone doesn’t stop it, so have a person send or approve it.
When customers hear about a status change
Canny’s help article says staff see an option to notify associated users when a status changes, and that only users with access to the board will be notified. Its email overview says the status change email is sent for a post the person voted on, and that staff can choose not to send it. Neither page describes a Slack Connect customer with no board access who hasn’t voted, so assume that customer gets nothing and the thread post is their only update.
The rule we use:
- Logged: reply in the thread the same day.
- Under review: no push. Answer if the customer asks.
- Planned, declined or shipped: post in the thread within one business day of the decision. If product marks a request planned on Tuesday at 10:00, support posts the approved wording by Wednesday at 10:00.
To close the loop on a decline, send the reason and workaround in the thread, then date the record. If the account churns before a decision, keep the record and its count, mark the account “churned” and send no message; the demand evidence stays valid.
Failure modes and fixes
- The request is in Slack and nowhere else. The support owner creates the record in the same session. A request without a link is not logged.
- Counts go up but nobody decides. Hold the fixed review, and make each request that arrives leave with a decision.
- Customers hear “planned” and ask for a date. Use the planned wording above and give no quarter unless product has committed to one in writing.
- Account counts are wrong because one team uses two domains. Count by account record, and merge duplicates before the review.
- The active Slack List is filling up. Our recommendation, not a Slack limit: once it passes 800 of the 1,000 items, move declined and shipped records to an archive list.
- You outgrow the list. Export it to CSV, keep the thread link, account and quote columns intact, and import them into Canny or Productboard with the link in the description, so product can still reach the original conversation. Run both for one review cycle, then freeze the list as read-only history.