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.