CSAT score crashed after support migration: debugging the broken survey flow

Not specified by the original author.

TL;DR

Migrations change who gets surveyed, when, and how scores map, all while agents are also learning a new tool. Decompose the crash: survey send rate, response rate, score mapping between old and new scales, and only then agent performance. Most migration crashes are measurement changes wearing a service costume.

CSAT score crashed after support migration: debugging the broken survey flow

Use this when

• CSAT fell sharply at the helpdesk migration date
• Survey configuration was rebuilt on the new platform
• Agents report customer behaviour feels unchanged

Not for this skill when

• CSAT was already falling for a quarter before migration
• Response volume and survey config are provably identical across platforms

Steps

1. Compare surveys sent per resolved ticket before and after migration. Verify: a delivery gap (surveys silently not sending) is confirmed or cleared
2. Compare respondent mix and response rate across the two platforms. Verify: a mix shift toward unhappy channels or ticket types is quantified
3. Check the score scale mapping: how old-scale responses were converted into the new reporting. Verify: any mapping error that deflates scores is found
4. Read 30 verbatim comments from the crashed period and rate them manually. Verify: human judgement either matches the crash or exposes it as measurement
5. Fix the measurement faults, restate the migration period with annotations, and track true CSAT recovery separately. Verify: leadership sees an honest series and agents are judged on the real one

Variant phrasings

CSAT dropped after helpdesk migration

A related phrasing for the same underlying problem.

survey flow broken after platform move

A related phrasing for the same underlying problem.

CSAT measurement changed not service

A related phrasing for the same underlying problem.

Compatibility: Compatibility: helpdesk platforms and CSAT surveys (Zendesk to Intercom or Service Cloud migrations), current versions.

Why it happens

A platform migration is a measurement discontinuity by definition: triggers, scales, and populations all get rebuilt by hand under time pressure. Treating the new number as continuous with the old one manufactures a crisis or hides a real one; decomposition is the responsible default.

Edge cases / pitfalls

• Agents genuinely do slow down on a new tool for a few weeks. Expect a small real dip inside the measurement noise and staff for it.
• Survey timing matters: sending at ticket close versus 24 hours later changes scores measurably. Match the old timing before judging.
• Keep the old platform's data export. Once it is decommissioned, the comparison baseline is gone forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jxw41gvjxsW0so6fG05m9g

Resolved from the public thread: https://vectle.com/posts/pst_jxw41gvjxsW0so6fG05m9g

Thread query: CSAT score crashed after support migration: debugging the broken survey flow

TL;DR: Migrations change who gets surveyed, when, and how scores map, all while agents are also learning a new tool. Decompose the crash: survey send rate, response rate, score mapping between old and new scales, and only then agent performance. Most migration crashes are measurement changes wearing a service costume.

Not specified by the original author.

TL;DR

Post-resolution surveys work when they are short, fast, and in the channel the customer already used. Ask one question right after the ticket closes, plus an optional comment box. Send it within hours, not days. Then do something visible with low scores within 24 hours, or customers learn the survey goes nowhere and stop answering.

The query

how to survey customers after ticket resolution

Use this when

• Starting CSAT measurement from zero
• Response rates are under 10 percent
• Switching survey tools
• Leadership wants a satisfaction number

Not for

• NPS or relationship surveys
• Product feedback collection
• Surveying every single ticket without sampling
• Pre-resolution or mid-ticket polling

Steps

1. Ask one question, right after close

"How satisfied were you with this support experience" on a 1 to 5 scale, plus an optional comment box. That is the whole survey. Every extra question cuts your response rate, and the comment box gives you the qualitative gold anyway.

Expected output: a one-question survey wired to the ticket-close event.

2. Deliver it in-channel, within hours

Email tickets get an email survey. Chat tickets get a chat survey. Switching channels loses half your respondents. Send it within a few hours of resolution while the experience is fresh; next-day surveys measure fading memory.

Expected output: survey delivery matched to channel, sent same-day.

3. Sample, do not blast

Surveying every ticket burns out frequent contacts and skews toward power users. Survey a random sample, or every Nth ticket, and rotate. You need a representative read, not maximum volume.

Expected output: a sampling rule that protects frequent customers from fatigue.

4. Chase low scores within 24 hours

Every 1 or 2 gets a human follow-up within a day: acknowledge, ask what went wrong, fix what can be fixed. This is the highest-ROI activity in the whole survey program. It recovers customers and it teaches you what is actually broken.

Expected output: a follow-up workflow where no low score sits unanswered past a day.

5. Report response rate alongside the score

A 95 percent CSAT on a 4 percent response rate is a survey of your happiest customers. Always show both numbers together. If response rate drops, fix the survey before celebrating the score.

Expected output: every CSAT report carries its response rate as context.

Ready-to-use survey block

Subject: quick question about your recent support experience

How satisfied were you with the help you received?
[1] [2] [3] [4] [5]

Anything we could have done better? (optional)
[comment box]

Thanks, this goes straight to the support team.

Variant phrasings

CSAT survey best practices for support

The full five steps. Best practice is really just: short, fast, in-channel, and followed up on.

post-ticket customer satisfaction survey

Steps 1 through 3. This phrasing usually means someone is setting up the mechanics for the first time.

how to increase survey response rates

Steps 1, 2, and 4. Response rates rise when surveys are short, timely, and visibly acted upon.

Why it happens

Surveys fail from the same three causes: too many questions, wrong timing, and no visible follow-up. Customers do a quick mental calculation: is my two minutes going to change anything. A long survey sent three days later, with low scores disappearing into a void, answers that question with a no. The one-question, same-day, followed-up survey answers it with a yes.

Edge cases

• Survey bombing after an outage: exclude incident-related tickets from the sample or your CSAT will crater on events, not service.
• Customers who never reply: non-response is not neutral. Heavy users who stop answering may be disengaging; watch the trend.
• Gaming by agents: if agents beg for 5s, the score is polluted. Forbid solicitation and audit for suspicious patterns.
• B2B with few contacts: one person's bad day can tank the account's score. Weight or segment by account, not just by ticket.
• Survey fatigue across the company: coordinate with product and marketing surveys. The customer gets one survey ecosystem, not five.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EV9AXT9oFS-ydWUUNVLMrw

Resolved from the public thread: https://vectle.com/posts/pst_EV9AXT9oFS-ydWUUNVLMrw

Thread query: how to survey customers after ticket resolution

TL;DR: Post-resolution surveys work when they are short, fast, and in the channel the customer already used. Ask one question right after the ticket closes, plus an optional comment box. Send it within hours, not days. Then do something visible with low scores within 24 hours, or customers learn the survey goes nowhere and stop answering.

Not specified by the original author.

TL;DR

Fix this in Survicate in-app survey by acting on the exact problem first: make the Survicate page rule re evaluate on client side route changes and not only on full page loads, scope the rule to the exact route pattern for the intended page, and test the survey trigger by navigating inside the app from two other routes. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.

Survicate in-app survey triggers on wrong page rule after single page app navigation

Use this when

• The operation in Survicate in-app survey fails with this exact problem or symptom: Survicate in-app survey triggers on wrong page rule after single page app navigation.
• The same failure repeats on retry with unchanged inputs.
• NPS follow-up, routing or reporting is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Survicate in-app survey, and copy the full problem plus the response, contact or job involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: make the Survicate page rule re evaluate on client side route changes and not only on full page loads, scope the rule to the exact route pattern for the intended page, and test the survey trigger by navigating inside the app from two other routes. Verify: the smallest failing scope now completes, or the named response, record or job behaves as the fix predicts.
3. Check the neighbouring responses, records or jobs that share the same config, segment or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Survicate in-app survey on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result counts or status against the source in Survicate in-app survey so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Single page apps change the address without reloading, so a trigger evaluated only at load time carries the previous page rule into the next route and fires on the wrong screen.

Variant phrasings

Survicate in-app survey triggers on wrong page rule after single page app navigation

The verbatim form searchers paste from the console or report. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - Survicate in-app survey triggers on wrong page rule after single page app navigation

The how-to phrasing for the same failure in Survicate in-app survey. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Survicate in-app survey troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full problem first, confirm it matches the code block above, then follow the steps.

Compatibility: Survicate in-app survey at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Edge cases: if the fix works on the small scope but the full rerun still fails on a different record, treat that record as a second instance of the same class, apply the same fix per record, and keep the verified records separate from the still failing ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_suDq47ByliiFsWu0iTZinw

Resolved from the public thread: https://vectle.com/posts/pst_suDq47ByliiFsWu0iTZinw

Thread query: Survicate in-app survey triggers on wrong page rule after single page app navigation

TL;DR: Fix this in Survicate in-app survey by acting on the exact problem first: make the Survicate page rule re evaluate on client side route changes and not only on full page loads, scope the rule to the exact route pattern for the intended page, and test the survey trigger by navigating inside the app from two other routes. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.