Trigger the survey when a case moves into a closed status, send it once to the case contact, save the answer on the Case and Contact, and give every low score an owner. That's the whole pattern. The work is in six small decisions you make before you build. This guide walks through each one, then shows a go-live checklist you can run in a sandbox.
Why case close is the right moment
CSAT (customer satisfaction) measures one interaction. The best time to ask about one interaction is right after it ends, while the customer still remembers the details. In a service org, that moment already exists as data: the case status changes to closed. You don't need a calendar, a list export or a manual send. The record change is the trigger.
Asking at the moment also makes the answer useful. A score tied to a specific case tells you which queue, which product and which agent it was about. A quarterly survey can't do that.
The six decisions to make first
Write these down before you open any setup screen. They become your test plan later.
| Decision | What to decide | A sensible default |
|---|---|---|
| 1. Trigger | Which status values mean "closed" in your org | Every closed status that means the customer was helped |
| 2. Scope | Which record types, queues or channels are in | Start with one queue, then expand |
| 3. Exclusions | Cases that should never get a survey | Spam, duplicates, merged and internal cases |
| 4. Recipient | Who gets the survey | The case contact, if they have an email address |
| 5. Questions | What you ask | One CSAT rating and one optional "why" question |
| 6. Follow-up | What a low score does, and how fast | An owner reaches out within one business day |
1. Pick every status that means closed
Many orgs have more than one closed status, such as "Closed – Resolved" and "Closed – Duplicate." List them all, then decide which ones should send a survey. A duplicate case closing is not a moment to ask the customer anything.
2 and 3. Set the scope and the exclusions
Start small. One queue or one product line is enough to prove the loop works. Exclude cases that were never real customer contacts: spam, auto-replies, merged cases and cases your own team opened for internal work.
4. Send to the case contact
The person who asked for help is the one who can rate it. Make sure the case contact has an email address, and skip the survey when it doesn't. If one customer opens many cases, add a cadence rule so the same person isn't asked again within a set number of days. That one rule does more for your response rate than any wording change.
5. Keep the survey to two questions
Ask one rating question ("How satisfied were you with how we handled your request?") and one open question ("What's the main reason for your score?"). Keep the scale the same across every queue so you can compare them. Short surveys get more answers, and the open text is where the fixes come from.
6. Agree what a low score does
Before go-live, agree who owns a low score and how fast they respond. A common choice is the case owner's manager, within one business day. Write down what "done" means: the customer was contacted, the issue was fixed or explained, and the outcome was recorded on the case.
Send it once, not on every edit
This is the most common mistake. Closed cases still get edited: an agent fixes a typo, a field is updated by automation, a comment is added. If your trigger only checks "status is closed," every one of those edits can send another survey.
The fix is to fire only when the case changes into a closed status. Salesforce's own Flow training covers the same idea for record-triggered flows: the option "Only when a record is updated to meet the condition requirements" runs the automation once, when the record first meets the conditions, not every time it's edited afterward. Whatever tool sends your surveys, test this before you go live: close a case, edit it, and confirm only one survey went out.
Where the answer should land
The response belongs on the Case it's about, and on the Contact and Account it rolls up to. That way the agent sees the score on the case, the account owner sees it before the next call, and you can report on it with standard Salesforce reports. Map the score and the comment to fields you can filter and group on. If answers live in a separate tool, they don't get read.
Test it in a sandbox
Build the whole thing in a sandbox first. Then run the checklist below with a test contact you control. Every line should pass before you repeat the setup in production.
What to watch in the first month
- Response rate by queue. A queue with very few answers may have missing contact emails or the wrong exclusions.
- Duplicate sends. Any contact who got two surveys for one case means the trigger fires on edits.
- Low scores followed up on time. This is fully in your team's control, so it's the best early measure.
- Top reasons in the comments. Group low-score comments by theme once a month and give each theme an owner.
Doing it with NPS Survey CX OS
NPS Survey CX OS by SalesHub runs inside Salesforce. Its AppExchange listing describes sending NPS, CSAT and CES surveys automatically on Case close, with no code needed, from 70+ survey templates and 40+ branded email templates. Responses link to the Account, Contact, Case and Opportunity, and the data stays in your org. The listing also says you can send your first survey in about 10 minutes.
In practice, you pick a CSAT template, set the trigger to the case's closed status, map the score to fields on the Case, and turn on routing so a low score reaches an owner. The Learning Center has the full getting started guide, a glossary and an NPS calculator.
Sources: Salesforce Trailhead, "Build a Record-Triggered Flow"; NPS Survey by SalesHub on Salesforce AppExchange (accessed October 26, 2026).
Close the loop on every score
NPS, CSAT and CES surveys that send themselves, land on the record and give every unhappy customer an owner, 100% inside Salesforce.
Start the free trial →Book a demo →