Survey deliverability and the gates that filter invites

Ochre is conservative about sending surveys. The point is signal, not noise. A survey that reaches a customer who didn't actually have an interaction worth rating is worse than no survey at all: it confuses the customer, hurts your sender reputation, and corrupts the dashboard with garbage ratings.

To prevent that, every survey runs through a set of deliverability gates before sending. This page documents them.

The gates

A survey is sent only if all of these are true:

1. The master CSAT toggle is on

If the workspace master kill switch (csat_enabled) is off, no surveys send anywhere. Per-channel switches are no-ops in this state.

2. The per-channel toggle is on

For the relevant channel, the channel-specific toggle (csat_email_enabled, csat_chat_enabled, csat_slack_enabled) must be on. See CSAT per channel.

3. The conversation is closed

Surveys only go out after the conversation moves to a closed state. Open conversations never trigger surveys.

This is to make sure customers rate their final experience, not their experience halfway through.

4. The conversation has at least 2 messages

If a conversation has just one message and is then closed, no survey. This filters out:

• Empty inbox messages a customer sent and immediately deleted.
• Bot-generated noise that auto-closes.
• Test messages from your own team.

The "2 messages" rule means at least one inbound and at least one other (inbound or outbound). In practice this almost always means "the customer wrote and someone replied."

5. No prior survey for this conversation

A conversation can only generate one survey. There's a unique(conversation_id) constraint on survey_invites that enforces this — even if the conversation reopens and closes again, no second survey will fire. This prevents survey fatigue and double-counting.

6. The customer's email is deliverable

Email-channel and Slack-channel surveys (when there's no Slack thread to fall back to) require a deliverable email address. Synthetic addresses are filtered:

• Anything ending in .slack.local (synthetic Slack-channel placeholders generated when there's no real email).
• Anything ending in .invalid or .local.
• Empty / missing email.

Widget-channel surveys don't need a deliverable email — the survey renders as a system message inside the widget itself.

7. The conversation has the right channel context

For Slack-channel conversations, the survey posts into the original Slack thread. We need either a usable Slack channel ID and thread timestamp on the conversation metadata, or a fallback deliverable email. If neither is present, no survey.

NPS-specific gates

NPS adds a few more conditions on top of the above:

• The customer must have at least one conversation in the last 90 days for your workspace.
• The customer must not have already received an NPS invite this quarter.
• The customer must have a deliverable email (NPS sends only via email).

See NPS overview.

Debugging "no surveys are going out"

If your invites-sent count is lower than expected, walk through the gates in order:

1. Master kill switch. Check the CSAT settings page.
2. Per-channel switches. For each channel you care about, confirm the switch is on.
3. Closed-conversation count. Check /analytics: how many conversations actually closed in the period? If the closed count is low, surveys will be low.
4. Deliverable email rate. If your inbound traffic is mostly synthetic Slack senders or anonymous widget visitors, those go through the channel-specific path; they're excluded from email-channel surveys by design.

For NPS specifically, also check that the customer has had a conversation in the past 90 days and hasn't already been invited this quarter.

Reading send rates

A reasonable invite-send rate is 30% to 60% of closed conversations. Below 30%, deliverability gates may be filtering more than you'd like. Above 60%, your customer base is unusually clean.

The CSAT card on /analytics shows invites sent for the selected period.

When deliverability fails downstream

Even if a survey is sent, it can fail to reach the customer due to email deliverability issues outside Ochre:

• Bounce rate on outbound mail. High bounce rates indicate domain reputation issues.
• Spam folder reports. Customers occasionally report finding surveys in spam. Configure SPF, DKIM, and DMARC for your sending domain. See Custom domain email.
• Specific corporate spam filters. Aggressive corporate filters sometimes drop survey emails. Not much to do beyond keeping your sender reputation high.

Related

• CSAT overview
• CSAT per channel
• Survey tokens
• NPS overview
• Custom domain email