A CSAT survey for a shared Slack channel is one rating question and at most one open question, sent once per request. This page gives the wording and the send rules. What the score means and how it is calculated is in the CSAT glossary entry.
The rating question and its five anchors
Paste this as the rating question, in Slack and in email:
“How satisfied are you with the help you got on this request?”
Use these labels, in this order:
| Score | Label |
|---|---|
| 1 | Very dissatisfied |
| 2 | Dissatisfied |
| 3 | Neutral |
| 4 | Satisfied |
| 5 | Very satisfied |
Keep the neutral label. Without it, a partly solved request has to land on 2 or 4. My expectation is that more of them land on 4, which inflates the satisfied share. That is a prediction, not a measured result. If you already run a survey without a neutral label, compare the share of 4s before and after you add it.
Five points is the common shape. Zendesk’s CSAT article shows a 1-5 scale where 1-3 is bad and 4-5 is good. Intercom’s conversation rating shows five options, grouped as two positive, two neutral and one negative. Whatever cut-off you report with, write it on the dashboard and keep it fixed.
The open follow-up, and when to ask it
Send one open question, and only when the score calls for it:
- Score 1 or 2: “Sorry this one fell short. What went wrong? One line is enough.”
- Score 3: “What would have made this a 5?”
- Score 4 or 5: send nothing more.
Keep the text box optional. Route every 1 or 2 to the request owner the same working day. If your tool can create a task from a survey answer, assign it to the owner with a due date of that same day. If it cannot, a daily filter on scores of 1 and 2 is the minimum.
If your email survey cannot branch on the score, show the open box after every rating, labelled optional. You will get some text from 4s and 5s, and you can ignore it.
Slack and email wording
Slack. Post this as a message in the request’s own thread, with the five labels from the table as buttons under it:
“Quick check on this one. How satisfied are you with the help you got on this request?”
When the score is 1 or 2, the open follow-up goes into the same thread as a reply, using the wording above.
When someone taps a button, Slack sends a block_actions payload to your app. The Slack docs say the app must respond within 3 seconds of receiving it. If it misses that window, the Slack user “will see an error message”. So acknowledge the tap first and write to your database afterwards. Then update the original message through response_url with replace_original set to true, and replace the buttons with “Thanks, that is recorded.” The buttons disappear, so nobody taps twice.
Email. Subject line: “How did we do on [request name]?” Body: “One question: [link]”. The link opens the same rating question, the same five labels and the open box described above. Keep the body to that one line.
Slack buttons or email link
Send the survey on the channel the request came in on. If it arrived in the shared channel, post the Slack prompt. If it arrived by email, send the email link. Do not send both for one request.
| Slack thread | Email link | |
|---|---|---|
| Who sees the request and the answer | Everyone in the shared channel, and any of them can tap | The recipient |
| Effort for the customer | One tap | Open a link, click, maybe type |
| Open follow-up | A reply in the thread | A text box in the survey |
| Typical risk | A customer may not want to rate in front of colleagues | The survey is never opened |
The Slack docs I read do not say whether app buttons behave the same for guests in a Slack Connect channel. Test that with a guest account in one channel before you roll it out.
I do not have a verified response-rate benchmark for either channel, so I would not quote one to a board. Count surveys sent and answered per channel for 30 days. Then compare the score distribution by channel, not only the average.
Who gets it, and what counts as solved
Four definitions come before any timing rule works:
- Solved: the request status is set to solved, or to the closed state your tool uses. A message that says “should be fixed” is not solved.
- Human reply: a message written by a person on your team, after the customer’s last message. Messages from bots, AI agents and auto-replies do not count.
- Recipient: in Slack, the person who opened the thread. By email, the requester on the ticket. If several people from the customer side are in the channel, survey the opener only, and count the 14-day limit against that person.
- Who tapped: the buttons are visible to the whole channel, so a colleague may rate the request. Record the tapping user if your tool does. If it does not, say in the report that the rating may come from someone other than the opener.
If an AI agent or a bot closed the request, send nothing until the customer has written again after the close. Otherwise the survey rates the close, not the outcome.
When to send
- Slack: post the prompt in the thread 10 minutes after the request is solved, if it is still solved and the customer has not written in that time. The 10 minutes is my starting rule, and no vendor documents it. Intercom works differently. Its docs say a short delay of approximately 10 seconds comes before a rating is dispatched, and if the conversation leaves the closed state inside that window, the scheduled delivery is cancelled for that closure. That window catches accidental closes. The hold on your side lets a quick follow-up from the customer arrive before the prompt lands.
- Email: one day after the request is solved. Zendesk’s article gives this timing for email tickets, and it does not tie the timing to a plan. The same article says the CSAT survey is not active by default, so it has to be switched on.
- Holidays and working hours: the timer sets the earliest send, and the working-day rule only moves it later, never earlier. Example: a request solved on Friday afternoon, where the email timer lands on the customer’s Saturday. The email waits for their first working morning, in their local time. The same applies to the Slack prompt. If the 10-minute hold ends outside the customer’s working hours, the prompt waits for the next working morning. The holiday rule wins over “right after”.
- Still-broken check, before every send: read the customer’s messages from 24 hours before the solve up to the send moment. If any of them says the problem is still there, suppress the survey and log “still broken”. Searching for “still”, “again” and “not working” is a start, not the whole check. Read the hits. A suppressed request gets no survey later, even if it is solved again.
How often, and when not to send
- One survey per request, and never two in the same thread.
- Per customer contact: a starting limit of one survey every 14 days, across all requests. A contact with three requests solved in one week gets the survey for the first one. Log the other two as “recent survey”.
- I expect the scores on a contact’s third survey in a week to be less careful. That is a guess. Check it by comparing first and later surveys for the same contacts.
- Reopen: a reopen never triggers a second survey. If the request reopens before its survey goes out, cancel the pending survey. If the survey has already gone out, it stands, and the reopen goes to the owner as the signal.
- Reminders: do not send one. Count a survey with no answer as no response after 14 days, which matches the contact limit, so a late answer is not mixed up with the next survey.
- Opt-out: if a contact has asked not to receive surveys, or has unsubscribed from your support email, do not send them the email link, and log it. This is an operating rule, not legal advice. Check your own contracts and local rules.
Do not send when:
- The only reply was automatic. A bot closing a request after two days of silence, followed by a 1, tells you nothing about your team.
- The customer’s last message says it is still broken. The still-broken check above covers this.
- There is an open escalation on the account. Hold the survey until the owner closes the escalation. A 1 tapped in the middle of one turns the thread into a second escalation.
Log every suppression with one reason: “recent survey”, “still broken”, “no human reply”, “open escalation” or “opt-out”. Leave suppressed requests out of the surveys-sent count, so the response rate reflects the surveys you actually sent.
Reading the results
Report the positive share as positive answers divided by all answers received, and show the count next to it. For example, “24 of 30 positive” tells the owner more than a share on its own. Report the response rate as answers divided by surveys sent, per channel.
| What you see | Likely cause | Fix |
|---|---|---|
| Almost all 5s, few answers | Only happy customers answer, or the survey arrives late or is too long | Compare sent to answered by channel; send earlier; drop the open box for 4 and 5 |
| Many 3s | Neutral reads as “fine” to customers | Reword the 3 label to name the outcome, for example “Partly solved” |
| Low scores with no reasons | Customers skip the open box at 1 or 2 | Keep the box optional; route every 1 and 2 to the owner the same working day |
| Scores look good, churn does not | The survey measures the thread, not the outcome | Add ticket status and time to resolution to the same report |
Change one thing at a time. If you change the wording and the send timing in the same week, you will not know which one moved the number.