Survey the tickets where a human client interacted with a human technician and can reasonably judge the outcome. Suppress everything else. That single rule solves most of the "our CSAT is meaningless" and "our response rate is terrible" complaints at the same time, because both problems usually trace back to the same cause: the survey is firing on tickets nobody remembers having.
If you close 900 tickets a month and 400 of them are RMM alerts, auto-closed non-responses, and internal admin tickets, you're mailing 400 surveys to people who have no idea what you're asking about. They ignore them, your response rate collapses, and the handful who do respond are answering out of confusion rather than experience. Cut the send list to the 500 real human interactions and your response rate goes up without you changing a single thing about the survey itself.
RMM and monitoring-generated tickets. Disk space alerts, failed backups, patch reboots. Even when a tech does real work, the client contact was never involved. Surveying them asks a question they can't answer.
Auto-closed "waiting customer" tickets. If your workflow closes a ticket after three business days of client silence, that client already didn't engage. A survey is a second email into the same void — and occasionally it wakes someone up angry that you closed their ticket.
Internal and administrative tickets. Onboarding checklists, project tasks tracked as tickets, license changes, documentation cleanup, tickets your own team opened against a client account. None of these have a client-side experience attached.
Duplicates and children of a bulk event. When an ISP outage generates thirty tickets across one client, surveying all thirty is how you turn one bad afternoon into thirty negative data points — or thirty ignored emails. Survey the parent, suppress the children.
Most survey platforms let you filter after the fact. Filtering at the workflow rule is better, because the suppression logic then lives next to the rest of your ticket automation and is visible to whoever maintains it.
The practical setup: your survey notification fires from a workflow rule on ticket status change to Complete. Add conditions so the rule only runs when the ticket meets your "real interaction" test. The fields worth conditioning on:
Then add a second rule for the auto-close path so the closure notification and the survey are never the same email.
The other half of the problem is frequency. One contact who opens fifteen tickets a month should not get fifteen surveys. In the MSP environments we see, a cooldown of roughly 7 days per contact keeps the heavy users engaged without materially reducing how much feedback you collect — the tickets you skip are usually from the same person about the same theme anyway. If your tooling supports it, make the cooldown per contact rather than per company, so one loud user doesn't block feedback from the rest of their office.
The exception worth carving out: escalations and P1s. If a ticket breached SLA or got reassigned twice, survey it regardless of cooldown. Those are the ones you most need to hear about.
Expect two things. Response rate goes up, often meaningfully — a one-click rating embedded directly in the closure email typically lands somewhere in the 25–40% range once you've cleaned the send list, versus single digits for a "click here to take our survey" link sent to everything that closes. And your CSAT score may drop a point or two, because you've removed a pile of automated tickets that were quietly collecting easy positive ratings from clients who assumed things were fine.
That second effect is a feature. A 99% CSAT built on a denominator full of RMM noise tells you nothing you can act on. A 94% built on actual support interactions gives you real signal about specific techs, specific clients, and specific recurring problems — which is the only version that survives contact with a QBR.
We built InsideLoop around the embedded one-click rating in the Autotask closure email for exactly this reason: the trigger conditions and the survey mechanics have to be tuned together, not bolted on separately.
If you're setting this up from scratch, this is a reasonable default to argue with:
Suppress Survey UDF checkboxRun it for a month, then pull the list of tickets that did survey and read fifty of them. If any of them make you think "why did we ask about that one?", you've found your next condition.
InsideLoop embeds a one-click satisfaction survey in your ticket-close emails, writes ratings back to the ticket, and alerts you the moment a client is unhappy.