How-To Guide12 min read
How to Tell Customers the Feature They Requested Has Shipped
Last updated: · By Matt Teixeira, Founder and CEO
On this page
To tell customers the feature they asked for has shipped, start from the requests linked to the work, add anyone who described the same problem elsewhere, and keep only the people who can use the change today. Send each one a short personal note in the channel where they asked, within two business days of their access: what they asked for, what changed, how to try it, and whether it solved their problem. Publish a changelog entry for everyone else, then track how many requesters you told and how many used the change. The loop is closed when the customer knows, not when the ticket moves to Done.
Key Takeaways
- Build the requester list at triage, when you link feedback to the work. By launch, it's too late to reconstruct.
- Close the loop on the problem, not just the request: people who described the pain without naming the feature get a note too.
- Match the note to the fit. Someone the release only partly helps gets a note that names the gap.
- Notify each customer when their account can use the change, and brief support and sales a day or two before.
- Canny and Productboard can email voters and linked requesters (Canny, Productboard), but only the requesters captured in the tool.
- Measure three things: the share of requesters told, how fast, and how many used what they asked for.
What Does Closing the Feedback Loop Mean?
Closing the feedback loop means telling every customer who gave you feedback what happened to it. In my experience, "shipped" is the outcome teams skip most: by launch, the request is months old and sits in a tool the PM no longer checks.
A customer who hears "you asked, we built it" has a reason to try the change and tell you whether it worked. One who never hears learns that feedback disappears.
Step 1: Link Every Request to the Work When You Triage It
Each time a request maps to an issue or project, attach the customer and the source right then. My rule of thumb: whatever isn't linked by the time engineering starts is lost by launch.
Capture five fields per request:
- Who: the person and their account.
- Where: a link to the original ticket, thread, call note, or survey answer.
- What they said: one short quote.
- What they need: the underlying problem.
- When: the date.
In Linear, Customer Requests are created automatically when you create or link an issue from Intercom, Zendesk, or Front on the Business or Enterprise plans (Linear), and you can subscribe from a customer's page to hear when their requested work ships (Linear changelog). For the full setup, see how to link customer feedback themes to Linear issues.
Step 2: Rebuild the Full Requester List a Week Before Launch
Linked requests are a floor, not the full list. A week before release, search support tickets, shared Slack channels, call notes, CRM notes, NPS comments, and churn surveys for the problem in your customers' words: "I export this every Monday," not "scheduled exports." Then:
- Dedupe by person. Someone who asked three times gets one message.
- Group by account. Count unique accounts, not mentions; that is how many customer relationships the release touches.
- Note the channel. You will reply where they asked.
If this search takes more than an hour, your feedback is too scattered to close loops reliably. Fix that first.
Step 3: Sort Requesters by How Well the Release Fits
Never tell someone "you asked for this" when they asked for something else. Sort the list before you write a word:
| Group | Example | Message | Who sends |
|---|---|---|---|
| Asked for this change | "Can we schedule exports?" | Shipped note | PM or support, in the original channel |
| Described the problem | "I pull this report by hand every week" | Shipped note framed around their problem | PM or support, in the original channel |
| Asked for something it partly solves | "Send exports to Google Sheets" | Partial-fit note that names the gap | PM |
| Can't use it yet | Plan doesn't include it, or not in the rollout yet | Hold until they can, or say when | Account owner |
| Key accounts | Top ARR, renewal this quarter | Personal note plus a check-in | CSM or account owner, from a PM draft |
| Churned or lost deals | Cited this gap when they left | Win-back note, if the owner agrees | Account owner |
Leave three groups out, and log why: anyone who asked not to be contacted, anyone whose quote turns out to be about a different problem, and feedback with no identifiable contact. An honest partial-fit note builds more trust than a shipped note that oversells.
Step 4: Write the Changelog Entry First
Write the public entry before any personal note. Every message copies from it, so no note promises more than the entry says. Include:
- A title that names the outcome: "Schedule CSV exports to email," not "Export improvements."
- Who gets it: plans, platforms, and rollout dates.
- How to use it: where to find it, in one or two steps.
- What it doesn't do yet, so support isn't caught out.
Publish it the day the change is available. The changelog is for everyone who didn't ask; nobody on your requester list should learn about the change there first. Deck's own changelog follows this format. Canny's changelog can email subscribers when you publish, on the Pro and Business plans (Canny).
Step 5: Send When They Can Use It, Not When It Merges
"It's live" is only true when the customer can see it. With a staged rollout or feature flags, notify each requester when their account gets access. For a beta, invite the requesters first; the invitation is your first close.
| When | What goes out | Audience |
|---|---|---|
| 1 to 2 business days before | Heads-up with the changelog draft, recipient list, and known limits | Support, success, sales |
| Day it's available | Changelog entry; key-account notes | Everyone; key accounts |
| Within 2 business days | Personal notes and ticket or thread replies | Everyone else on the list |
| Next login | In-app message | Users of that area who weren't on the list |
| 2 to 3 weeks after | Check-in: did it solve the problem? | Key accounts and anyone who replied |
The one rule I would not bend is the heads-up. A CSM who hears about a feature from their customer loses credibility on that call.
Step 6: Send One Note per Person, in the Channel Where They Asked
Reply where the customer gave the feedback: reopen the Intercom or Zendesk ticket, answer in the Slack thread, or email people from interviews and surveys. Send from an address that takes replies, because replies tell you whether the change worked. Describe their request in your own words; leave out their full quote, internal IDs, and internal links.
Shipped note (email, ticket, or thread):
Subject: [Feature] is live. Thanks for asking for it.
Hi [First name],
In [month], you told us [their problem, in your words].
We just shipped [what changed]. You can try it in [where to find it].
[If there is a limit: "It doesn't cover X yet."]
Does this solve it for you? Reply and tell me, even if the answer is no.
[Your name], [role]
Partial-fit note:
Hi [First name],
You asked for [their request]. Today we shipped [what changed],
which covers [the part it solves]. It doesn't cover [the gap] yet,
and I'd rather say so than oversell it.
If [the gap] is the part that matters most, reply and tell me why.
Your answer goes into how we rank the next step.
In-app message (for eligible users who weren't on the list):
Title: [The outcome, in five words or fewer]
Body: [Feature] now [does what]. [Where to start, in one step.]
Button: Try it
CSM brief (internal):
What shipped: [one sentence] | Available: [date, plans]
Your accounts on the list: [account, contact, what they asked, source link]
Talking points: [problem it solves] / [known limits] / [what's next, only if committed]
Send by: [date] | Log replies in: [link]
Keep a send log as you go: person, account, channel, date sent, and whether they replied. Step 7 runs on it.
Step 7: Measure Whether the Loop Closed
"We told people" is a feeling. These four numbers tell you whether the loop actually closed:
| Metric | How to calculate | Rule of thumb |
|---|---|---|
| Loop close rate | People told ÷ identifiable requesters who can use it | Every key account; nearly everyone else within a week |
| Time to notify | Median business days from availability to note | 2 or fewer |
| Reply rate | Replies ÷ notes sent | No useful benchmark; read every reply |
| Requester adoption | Notified accounts that used it within 30 days ÷ notified accounts | Compare with eligible accounts not on the list |
Treat replies as evidence: "this doesn't cover our board report" belongs on the work item for the next iteration. If requesters don't adopt what they asked for, either the note didn't land or the release missed their problem; a two-line follow-up tells you which. To check whether complaints fell after the release, see how to measure whether a release reduced customer complaints.
Worked Example: Scheduled Exports Ship
This example is illustrative. A B2B analytics startup ships scheduled CSV exports by email on its paid plans. The Linear project has 11 linked customer requests, and a pre-launch search for "export every week" across Intercom, shared Slack channels, and call notes finds 19 more. After dedupe, that is 26 people at 18 accounts:
- 12 asked for scheduled exports and get the shipped note in their original channel.
- 8 described exporting by hand and get the note framed around that problem.
- 3 asked for exports to Google Sheets and get the partial-fit note.
- 3 are on the free plan, which doesn't include the feature, so their account owner decides whether to offer a trial.
Support and sales get the heads-up Monday. The feature goes live Tuesday, CSMs at the four accounts renewing this quarter send their notes that day, and all 23 eligible people hear back by Thursday: a 100% close rate inside two business days. Within a month, 9 reply, 2 of them flag missing time-zone settings for the next iteration, and 11 of the 16 notified accounts set up a schedule, against about 1 in 10 eligible accounts that weren't on the list.
Common Mistakes to Avoid
- Waiting for the monthly newsletter. By then the person who asked has built a workaround or stopped looking.
- Promising the rest is "coming soon." Say what's next only if it's committed.
- Naming customers in public without asking. Thank "the customers who asked" in the changelog; name a company only with permission.
- Messaging the same person three times. One personal note each; keep requesters out of the in-app and email blasts.
Tools That Help
A tool can only notify the requesters it knows about, so pick by where your requests already live.
- Spreadsheet plus your own inbox (free): one tab for the requester list, one for the send log. Fine for a few dozen requesters per release; past that, deduping by hand gets slow.
- Canny: when an idea's status changes, including from a Jira, ClickUp, or Linear status change, Canny emails its voters and can notify users tracked through insights, with your message included. Emails come from notifications@canny.io unless you whitelabel on Business, and replies count only through the email's Reply button (Canny). Autopilot, included on every plan, can pull requests in from support and sales conversations, which widens the list (Canny pricing). Pro starts at $79 a month billed annually for 100 tracked users (Canny billing plans).
- Productboard: email a Portal card update to the feature's voters, or to voters plus everyone whose insight is linked to it. The emails can't carry your branding or take replies; without a Portal, export requester emails instead (Productboard). Business is $59 per maker per month billed annually (Productboard).
- Linear with Intercom or Zendesk: when a linked issue is completed, Linear posts an internal note and reopens the conversation or ticket by default, so an agent can tell the customer (Linear Intercom, Linear Zendesk). Linear doesn't message the customer itself.
Where Deck Fits
Deck handles who asked, where they asked, and how the release landed. It does not send the messages.
- Requesters stay on the work: a Deck Project's Related Insights sheet lists each supporting insight with its source, such as an Intercom conversation, Slack message, or survey answer, and names the customer when Deck knows who it is. As feedback arrives from Slack, support, surveys, NPS, interviews, and Gong calls, Deck attaches high-confidence matches (Deck docs).
- One person, one message: unified contacts match the same customer across tools by email, phone, and IDs from Intercom, Zendesk, Slack, PostHog, Salesforce, and HubSpot (Deck docs).
- Know when it shipped: link the Project to a Linear Project or Jira Epic, and Deck refreshes its status and dates daily.
- Hear how it landed: link a Deck Collect widget to the Project, and new responses appear on its Feedback tab, with a Synthesis story once Deck's weekday batch has processed enough written feedback.
- Drafts from your AI agent: with Deck's MCP server connected, the customer follow-up playbook has an agent such as Claude build the recipient list and draft one note per customer for you to approve.
- Limitations: Deck can't send a message or record who was told, so you send from your own tools and keep the log yourself. It has no public portal, voting, or customer-facing changelog. With PII redaction on, customer names and emails are masked for every member, admins included (Deck docs). CRM integration needs the Business plan.
- Pricing: Free is $0 with 200 AI credits a month and 1 integration; Starter is $99 a month ($79 billed annually); Business is $249 a month ($199 billed annually). If your requesters are spread across support, Slack, and call notes, you can start on the Free plan.
Frequently Asked Questions
Sources
- Canny Help: Status change emails
- Canny Help: Changelog emails
- Canny Help: Canny's billing plans
- Canny pricing
- Productboard Support: Close the feedback loop with Portal card updates
- Productboard Support: Spark pricing and billing FAQ
- Linear Docs: Customer Requests
- Linear Changelog: Customer requests on projects
- Linear Docs: Intercom integration
- Linear Docs: Zendesk integration
- Deck docs: Projects
- Deck docs: Unified contacts
- Deck docs: Privacy settings
Sources checked November 2, 2026.