A satisfaction rating is the only direct signal you get about whether support actually helped. It's added as a step in a workflow, normally one triggered when a conversation closes.
Add the rating step and write the question. Short and specific works better than a survey — “Did we solve your problem?” gets answered; “How would you rate your experience with our support team today?” gets skipped.
You can add a message alongside it, which is where a thank-you belongs rather than in the question itself.
By default, a rating counts for the person the conversation was assigned to. There's a setting to credit whoever wrote the last message instead.
Which is fairer depends on how you work. If conversations are assigned and stay put, the assignee is right. If they get handed around and whoever is free finishes them, the last responder is closer to the truth — an assignee who did the hard part and handed over still shouldn't take a bad rating for someone else's closing line, so consider which pattern your team actually has before changing it.
A rating request can be given a number of days after which it stops being answerable. That keeps the data meaningful: a rating submitted three weeks later describes a memory, not the conversation.
When the request goes out by email, you can override the subject line and hide the conversation history from the message.
Hiding the history is worth considering. It keeps the email short and focused on the one thing you're asking, and it avoids sending a full transcript to an address that may be shared.
Ask immediately after closing, while the outcome is fresh. Ask once. And ask only where a rating means something — sending one after every automated exchange trains customers to ignore them, and then the requests that matter go unanswered too.
