## 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.

```text
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