Collecting feedback after a support ticket closes

Separate product feedback from support satisfaction

A support ticket closes with a question that is about the agent: was the answer helpful? The product feedback question is different: what should we change in the product? Mixing them produces answers that are hard to use. A customer who liked the agent but hated the feature will rate the ticket highly and say nothing about the feature. A customer who was happy with the feature but waited three days for a reply will rate the ticket low and mention the wait.

Decide which question you are asking before you write the message. If you want to measure the support team, use your help desk's own satisfaction rating or a short internal review. If you want to learn about the product, send a product feedback prompt that is clearly separate. This guide covers the second case. Keeping both channels apart means each one tells you something you can act on.

Escuta Produto is not a help desk. It has no ticket inbox, no agent view and no integration with support tools, so it will not replace your support software. Its job is to collect product feedback and keep the context attached to each item.

Decide when the ask goes out

The best moment to ask is shortly after the ticket closes, while the customer still remembers the problem. A day or two later, the answer is usually already in the customer's mind, and the reason they wrote in is fading. Do not ask on the same minute, because the customer may still be reading the final reply.

Only ask customers who had a product question. A ticket about a billing address, a password reset or an account transfer rarely has product feedback in it. A ticket about a confusing screen, a missing option or a bug is a much better candidate. Tag the ticket category in your help desk and filter on it before you send anything.

Do not send the ask more than once for the same ticket, and do not send it to customers who asked you to stop contacting them.

Carry the ticket id as metadata

The reason to attach the ticket id is simple. When a product message says "the export is confusing", the ticket shows the conversation, the product version and the steps the customer described. The id connects the feedback to that history without copying the whole ticket into the inbox.

The widget can carry the id because you set it before the form opens. The hosted feedback page cannot, because it does not accept metadata parameters. So use a page in your app that the closing email links to. That page reads the ticket id from its address, sets the metadata and opens the form.

// On a page such as /help/feedback?ticket=TK-1042
const ticketId = new URLSearchParams(window.location.search).get("ticket");
if (ticketId) {
  EscutaProduto.setMetadata({ source: "support", ticketId });
  EscutaProduto.open({ kind: "other" });
}

The ticket id is not personal information on its own, but treat the metadata the same way you treat the rest of the customer record. Do not put the customer's support message into metadata, because the excerpt in the feedback item already shows what they wrote.

If you also want the id to travel from your server, the REST API accepts the same metadata object, so a backend job can create the feedback item directly. Use that only when the customer has already written the product feedback, because the API creates an item without asking the customer anything.

Keep the question short and optional

One optional question is enough. "Is there anything in the product that made this harder than it should be?" is specific, and it points to the product rather than the agent. A rating grid or a multi-question survey turns a resolved ticket into homework.

Do not frame the question as a request for a review. The customer asked for help, received it, and now has the option to tell you something about the product. Make the choice easy to decline, with no pressure or repeated reminders.

Read the answers next to the ticket

When an item arrives with a ticket id, open the ticket in your help desk before you decide anything. The ticket shows whether the product problem was already known, whether a workaround was given and whether the customer had to contact you twice. Those details decide whether the fix belongs in planned work, in the help documentation or in a short reply.

Review the items weekly. A cluster of messages that point to one screen is a product signal, even when each ticket was resolved quickly. The triage routine describes how to move those items through statuses, and the guide to reply templates helps when you answer the customer.

Connect the ticket link to the widget

Add a link in the closing message of the ticket. The link points to the feedback page in your app, with the ticket id in its address. Keep the wording plain: a single sentence that says you would like to hear what would make the product easier to use, followed by the link.

Test the whole path yourself before you turn it on. Close a test ticket, open the link, send a message and check that the item in Escuta Produto shows the ticket id in its metadata. Also check that the page works when the customer is not logged in, because many people open support links from their email client.

How to set up support follow-up in Escuta Produto

Create a product for the app, enable the widget on the feedback page, and set the allowed origins to your app's domain so only your site can submit through the widget. Turn on the product's notification webhook if the support team wants to see product messages right away.

Read the widget docs for the metadata method and the open call. The API docs describe the server route if you prefer to create items from your help desk webhook. Use the reply templates and the status workflow you already have, and keep the support rating in the help desk where it belongs.