One-click CSAT in a resolved-ticket email: what to ask and skip
A one-click CSAT email asks one question, counts a rating only after a human confirms it, and sends replies to a real inbox, not a no-reply address.
On this page(9 sections)
- What should a one-click CSAT email ask?
- What should you skip?
- Why do one-click ratings get phantom clicks?
- How do you make the rating survive scanners?
- Should a CSAT email come from a no-reply address?
- When should the survey go out, and to whom?
- How should you read the results?
- Checklist before you turn it on
- Bottom line
A one-click CSAT email is a short message sent when a support conversation is resolved, with the rating choices as links so that one click is the whole survey. It works best with exactly one question, a rating that is only counted after a person confirms it, and a sender address that actually reads replies.
Most advice on customer satisfaction (CSAT) surveys covers wording and timing, and our post on measuring customer satisfaction in email support covers that. This one is about the email itself: what goes in it, what to leave out, and one technical trap that quietly corrupts your scores.
What should a one-click CSAT email ask?
Ask one question about the conversation that just ended, with two to five rating links, and nothing else required. Everything beyond that costs you responses.
A workable layout:
Subject: Did we sort this out? (Re: Invoice shows the wrong plan)
Hi Priya,
We marked your conversation as resolved. How did we do?
[ Good ] [ Okay ] [ Not good ]
Reply to this email if something is still wrong. A person will read it.
Notes on each piece:
- The subject names the issue. A subject that matches the original thread is recognizable; a generic "We'd love your feedback" looks like a newsletter.
- Three options are enough. Finer scales add little for a small team and raise the cognitive load on a phone screen.
- The comment is optional and comes after the click. Put it on the page that opens after the rating, never as a required field in the email.
- No ticket history, no logo banner, no tracking pixels beyond what you need. The recipient knows what the conversation was.
What should you skip?
Skip multi-question surveys, rating scales of ten, "recommend us to a friend" questions, and anything that asks for the customer's account details again. Those belong in a separate relationship survey, not in a resolved-ticket email.
| Skip | Why |
|---|---|
| Five or more questions | Completion falls as the survey grows, and a support email is not the place for research |
| NPS-style "would you recommend" | It measures the product and brand, not this conversation |
| Required comment | Turns a two-second action into a chore |
| A second survey on reopen | Customers who reopen are already irritated; one survey per conversation is enough |
| Sending after the first reply | The conversation is not finished, so the rating is of a half-finished experience |
Why do one-click ratings get phantom clicks?
Because many mail systems fetch links automatically. Security scanners open the URLs in a message to check for malware or phishing, sometimes before the message reaches the inbox, and a rating link that records its answer on a plain GET request records the scanner's visit as a vote.
Microsoft documents this behavior for its own product: Safe Links in Defender for Office 365 scans and rewrites URLs in inbound email and checks them again when a user clicks. Other gateways and some mail clients behave similarly. You cannot tell from your side which recipients sit behind one.
The symptoms are recognizable:
- A cluster of ratings for the same option (often the first link in the email) arriving within seconds of the send
- Ratings with no later comment page visit
- Scores that drift toward whichever option you list first
The first-link pattern is a hint, not proof. Compare timing against your send log before concluding anything about your own data.
How do you make the rating survive scanners?
Treat the click as a request to open a page, not as the answer. The rating link should load a small confirmation page that shows the choice and a button, and only the button, a POST request, should record the rating.
- The email contains one link per rating, such as
/rate/<token>?score=good. - A GET on that link records nothing. It shows "You chose Good. Add a comment (optional)" and a "Send" button.
- The button sends a POST that saves the rating once for that token.
- A repeat visit shows the saved answer and does not create a second one.
It costs the customer one extra tap but it keeps automated visits out of your numbers. The same principle applies to account confirmation links, and we cover it in confirmation links that survive security scanners. It is also why the standard for one-click unsubscribe, RFC 8058, requires a POST rather than a GET; our explainer on one-click unsubscribe has the details.
If you accept the tradeoff of recording on GET anyway, such as a very low volume team that reads each rating by hand, at least log the user agent and timestamp so you can spot and discard scanner visits.
Should a CSAT email come from a no-reply address?
No. The email invites a reply, and a no-reply sender discards the most valuable answers: the customer who writes "No, it still doesn't work."
Send the survey from your support address, or set a monitored Reply-To, so that replies land in the same inbox as the original conversation. We explain why in the case against noreply@ addresses. Practically:
- Replies to a CSAT email should reopen or reattach to the conversation, not start a new unrelated thread.
- In a shared mailbox, make sure someone owns triage of these replies, since a "still broken" answer to a survey is a live support request.
- Use a recognizable From name, such as "Support at Example", not the name of a single agent who has since left.
When should the survey go out, and to whom?
Send it once, shortly after the conversation is resolved, to the person who wrote in. Suppress it in three cases: the customer already replied angrily within the last day, the conversation was an abuse or spam report, and the customer received a survey recently.
A simple frequency rule is enough: at most one survey per customer per 30 days. Choose the window that fits your volume; the number is a judgment call, not a standard.
How should you read the results?
Read them as a signal to investigate, not a score to optimize. With small volumes, a handful of ratings can swing a percentage wildly, so read the actual comments and the "Not good" conversations one by one.
- Review every low rating within a day or two; reply to the customer if it makes sense.
- Tag the reasons (slow, wrong answer, policy disagreement, product bug) and look for repeats.
- Never use individual CSAT as a pay or ranking metric; it rewards avoiding hard conversations.
Checklist before you turn it on
- One question, three options, optional comment after the click
- GET shows a confirmation page; POST records the rating
- Sent from a real, monitored address
- One survey per conversation, with a frequency cap
- Low ratings reviewed by a human
- Test it through a mail system with link scanning, such as a Microsoft 365 test mailbox, and confirm no rating is recorded before you click
Bottom line
A one-click CSAT email asks one question, records a rating only after a person confirms it, and comes from an inbox someone reads. Do those three things and the numbers mean something. Skip the scanner protection and you will be reading ratings that nobody gave.
If your support mail runs through a shared mailbox on your own domain, the replies to a survey arrive alongside every other conversation. See the support inbox playbook with Claude and Koltrix for a setup where an AI assistant can help sort and draft while a human reviews and sends.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
