How to tell customers their request shipped

Find everyone who asked for it

The same request rarely arrives once. One customer writes it in the widget, another emails support, a third asks in a call that someone types up later. If you only tell the person who sent the most recent message, you miss most of the people who wanted the change.

Start by listing every item that matches. Work through the inbox filtered to the product, search for the key words, and read each result. A request for "a monthly export" may appear as "month by month", "per month report" or "a file for accounting". Read the message, not just the title you would have used.

Use search, then the internal notes

Search covers the text of each message. It does not cover tags, because Escuta Produto has no tags. Use the internal notes for the rest. When you triage a request, write a short note with the feature name, such as "monthly export", so a later search finds it without guessing the wording.

If you passed metadata when the feedback came in, use it too. A value such as a feature name in the metadata can narrow the list fast. Metadata lives with the item, so it is also what you read when you decide who to tell.

Export the list when it grows

When a request has twenty or more items, a spreadsheet is faster than the inbox. Export the product's feedback as CSV. The file is UTF-8 and opens in Excel and Google Sheets. Check the column headers first, then filter the message text for your key words and keep only the rows that have an email address. You need the sender email and the message for each reply.

Keep the exported list as a working file. Mark who you told as you go. Delete the file when the work is done, because it contains customer email addresses.

Write the shipped message in three lines

The best shipped message is short. Use three parts: what shipped, where to find it, and thanks for the request. Here is a template you can adapt:

Hi Ana, the monthly CSV export you asked about is live now. You can find it in the export menu of the product, and it covers any month you choose. Thanks for the request, it is the reason this shipped.

Do not oversell. If the feature does a bit less than the request, say so: "It covers monthly totals, not daily rows, so tell me if you need more." Customers forgive a smaller change that works. They do not forgive one that was described as more than it is.

Send it from your own email

Escuta Produto does not send emails to customers, so the message goes out from your own address. Write it in your mail client and send it to the email saved on the feedback item. Use a plain message, not a newsletter layout. A personal note gets read, and it invites a reply if the feature is not quite right.

If several customers asked, send each message on its own, not as one message with everyone in copy. Copying a list exposes their addresses to each other, and it reads like a broadcast.

Choose the timing

Send the message after the change is live for users, not when the code is merged. If you have a changelog post for the release, send the message the same day it goes up, so the reader can click through to the details. For a small change, a same-day message works best. For a larger release, wait until the first users have the change, which usually means a day or two.

Do not send a message before the change is available. The first customer who tries it and finds nothing is more annoyed than one who never heard about it.

Record who you told

The record is the point. Add an internal note on the item: "Told by email on the release date." Set the status to done once the change is live. The note stops a second person from sending the same message, and it tells the next triage what has already been closed.

For a long list, keep the count in the note or in your spreadsheet, not in your memory. A list of forty names, half sent, is easy to lose.

Handle the customer who asked for something else

Some customers read the shipped message and reply that the change is not quite what they wanted. Treat that as new feedback. Thank them, ask what was missing, and log the reply as a new item or as a note on the existing one. Do not argue that the feature matches the request. If the gap is small, plan a follow-up. If it is large, say honestly that it solves a different problem and explain what you will do next.

Finding and notifying requesters in Escuta Produto

Start in the product inbox and filter to the status that holds the request, usually planned or in progress. Search the key words, then open each match and read it. Use the notes to find the items you already grouped. Export the rest as CSV if the list is long.

When you send each message, use the email on the item. Record the send in an internal note. Then set the item to done. For the rules behind the statuses, see how to design a feedback status workflow. For the changelog entry that goes with the release, see how to write a changelog customers read.

If someone asked through a form that did not collect an email, there is nothing to send to. Do not guess an address from the name. Record that the request is done, and mention it in your changelog so the next person who asks sees the answer. New requests reach your team's Slack or Discord channel as they arrive, as described in the notifications docs, so you can spot a request before it goes stale.