exit survey responses not matched to cancelled accounts: survey ID

Not specified by the original author.

TL;DR

The responses are there and the cancellations are there, they simply share no key. Exit surveys only become churn insight when each response joins to the account, plan, tenure, and value that cancelled, and that join needs an identifier carried from the cancellation flow into the survey tool, which is the step that was skipped when the survey was set up in the survey tool alone. Add the identifier to the flow, backfill what can honestly be matched, and the next quarter of exit data becomes analysable instead of anecdotal.

exit survey responses not matched to cancelled accounts: survey ID not passed through the cancellation flow

Use this when

• The survey tool holds responses that cannot be attributed to accounts beyond free text claims
• The cancellation flow and the survey were built by different teams or tools at different times
• Response volume looks healthy, so collection works, only matching fails

Not for this skill when

• Responses are anonymous by deliberate privacy design, in which case segment level analysis is the ceiling and should be accepted
• The survey fires for flows other than cancellation and the matching complaint is really about those flows

Steps

1. Inventory what each side holds. List the fields a survey response carries, timestamps, any URL parameters, hidden fields, and respondent provided details, and the fields the cancellation record holds, then identify any candidate join key that exists on both sides today, even a weak one like a timestamp plus plan, to size a possible partial backfill. Verify: the field inventories and candidate keys are documented for both sides
2. Trace the cancellation flow as a user experiences it, in a test account, from the cancel click through confirmation to the survey invitation or embed, recording every redirect and parameter passed. The break is usually visible here, the survey opens bare with no account context because the flow never appends the identifier or a signed equivalent. Verify: the flow trace shows exactly where account context is lost
3. Implement the pass through properly. Have the cancellation flow include the account identifier, and plan and tenure as hidden fields where the survey tool supports it, in the survey link or embed, using an opaque internal ID rather than anything sensitive, and test end to end with a test cancellation so the response lands in the survey tool already carrying its account key. Verify: a test response arrives carrying the correct account identifier and attributes
4. Backfill history conservatively. For past responses, match only where a strong key exists, such as a respondent provided account detail verified against the CRM, or a tight timestamp and plan match for a low volume day, and mark matched confidence honestly. Leave the rest unmatched and say so in reporting, because a forced match teaches the business false churn reasons with false confidence. Verify: the backfill matches a stated percentage with the method and confidence recorded per match
5. Rebuild the churn reason reporting on the joined data, comparing stated reasons against account value, tenure, and segment for the first time, and share one concrete finding with CS leadership to demonstrate what the join unlocks, which builds the support that keeps the wiring maintained through future flow redesigns. Verify: the joined report exists and one segment level finding is circulated
6. Protect the wiring. Add the survey identifier step to the cancellation flow checklist and to any redesign review, and run a monthly match rate report that alerts when the share of responses carrying an account ID drops, because flows get rebuilt often and this parameter is exactly the kind of detail a redesign drops silently. Verify: the monthly match rate report runs and alerts on a simulated drop

Why it happens

Survey tools optimise for collecting responses and cancellation flows optimise for completing or saving the cancellation, and the join between them is nobody's feature. Without an identifier deliberately carried across, the survey platform holds opinions with timestamps and the CRM holds accounts with outcomes, and no amount of analysis tooling can merge them after the fact beyond guesswork. The data was collected, the value was designed out at the handoff.

Compatibility: Exit survey tools such as Typeform, Qualtrics, or in product survey tools, cancellation flows, and CRM account records, in current versions.

Variants and edge cases

exit survey responses cannot match cancelled accounts

['The direct phrasing. Field inventories on both sides first, the absence of a shared key is provable in one short exercise.']

survey ID not passed cancellation flow

['The implementation variant. Use an opaque internal account ID, never billing details or personal contact details, as the passed identifier.']

churn exit survey data unusable no account link

['The analysis variant. Report the historical match rate honestly and build decisions on the matched subset with its limits stated.']

Edge cases to work through before you close the incident:

• Self reported account details in free text are unreliable and sometimes wrong on purpose. Verify them before using them as keys and treat them as the lowest confidence tier.
• If multiple brands or products share one survey, the identifier must carry product context too or the join will mix populations.
• Privacy review belongs in the design. Linking survey answers to accounts is legitimate for churn analysis your customers were told about, and the survey copy should say responses may be linked to the account.

Provenance

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

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

Thread query: exit survey responses not matched to cancelled accounts: survey ID not passed through the cancellation flow

TL;DR: The responses are there and the cancellations are there, they simply share no key. Exit surveys only become churn insight when each response joins to the account, plan, tenure, and value that cancelled, and that join needs an identifier carried from the cancellation flow into the survey tool, which is the step that was skipped when the survey was set up in the survey tool alone. Add the identifier to the flow, backfill what can honestly be matched, and the next quarter of exit data becomes analysable instead of anecdotal.

Not specified by the original author.

TL;DR

Fix this in ChurnZero by acting on the exact message first: link ChurnZero in-app survey responses to accounts using the account id passed with the survey, fix any response carrying only a contact reference with no account match, resync the unlinked responses, and verify a named response appears on its account health profile. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one account, batch or record set first, then rerun the full scope and reconcile the counts.

ChurnZero in-app survey responses not linked to account health profile

Use this when

• The operation in ChurnZero fails with this exact message or symptom: ChurnZero in-app survey responses not linked to account health profile.
• The same failure repeats on retry with unchanged inputs.
• Health scoring, alerting or routing 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 error 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 ChurnZero, and copy the full message plus the account, measure or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: link ChurnZero in-app survey responses to accounts using the account id passed with the survey, fix any response carrying only a contact reference with no account match, resync the unlinked responses, and verify a named response appears on its account health profile. Verify: the smallest failing scope now completes, or the named account, measure or job behaves as the fix predicts.
3. Check the neighbouring accounts, measures or jobs that share the same config, schema or source, 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 ChurnZero on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, scores or status against the source in ChurnZero 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 error, the fix applied and the evidence of success.

Why it happens

Survey tools store responses against the contact who answered, and without the account id join those responses never attach to the account health profile.

Variant phrasings

ChurnZero in-app survey responses not linked to account health profile

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

How to fix - ChurnZero in-app survey responses not linked to account health profile

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

ChurnZero troubleshooting for this failure

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

Edge cases

• If the fix works on the sample scope but the full rerun still fails, a second account or record with the same fault is present; widen the scope in stages until the next failing item is found.
• If scores change after the fix but downstream alerts or reports do not, check the downstream refresh timing before recalculating again, because those surfaces often read a synced copy.
• If the source information itself is missing for the affected accounts, record that as a source gap rather than scoring the accounts as zero.

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

Provenance

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

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

Thread query: ChurnZero in-app survey responses not linked to account health profile

TL;DR: Fix this in ChurnZero by acting on the exact message first: link ChurnZero in-app survey responses to accounts using the account id passed with the survey, fix any response carrying only a contact reference with no account match, resync the unlinked responses, and verify a named response appears on its account health profile. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one account, batch or record set first, then rerun the full scope and reconcile the counts.

Not specified by the original author.

Fixing "agent cancelled the wrong subscription: matched on name instead of id"

TL;DR

Never cancel by name. Resolve the exact subscription id first, then show the customer name, plan, and amount back for confirmation before cancelling. The cancel call itself takes only the id. Name matching is the bug.

agent cancelled the wrong subscription: matched on name instead of id

Steps

1. Change the cancel flow to require a subscription id (for example sub_xxx) as input, never a name or email. Expected: The code cannot compile or run a cancel without an id in hand.

2. Add a lookup step: given a customer, list their subscriptions and pick by id, displaying plan name, amount, and status for each. Expected: The agent sees exactly which subscription it is about to cancel.

3. Add a confirmation gate showing customer name, plan, billing amount, and next renewal date, requiring explicit approval. Expected: A wrong pick is visible to a human before anything is cancelled.

4. Log the id, the actor, and the confirmation for every cancellation. Expected: Any wrong cancel is traceable to the exact decision point.

Prevention

Names are not unique and plan names repeat across customers. Design the flow so the id is resolved once, early, and carried through; every later step references the id, never a re-derived name search.

Detection

Watch cancel webhooks and compare each cancelled id against the intended id in your task log. Alert when a cancel targets a subscription whose customer name differs from the one in the request. Review any cancel that happened without a logged confirmation.

Recovery

Most providers let you reactivate a recently cancelled subscription within a grace window; do that immediately. If reactivation is not possible, recreate the subscription with the same plan and price, backdate the start if the provider allows, and notify the customer with an apology and a service credit. Fix the flow before the next cancel.

When this applies

• A cancel request named a customer and the wrong one of their subscriptions was cancelled
• The agent searched subscriptions by plan name or customer name
• Two subscriptions share a name and the agent picked the first result

When it doesn't

• The right subscription was cancelled but the customer disputes wanting it cancelled (that is a consent problem)
• The provider failed to cancel after receiving the correct id
• You are cancelling all of a customer's subscriptions on purpose

Compatibility

Stripe API (subscription ids, cancel and reactivate), Adyen (recurring contract disable by reference), PayPal REST API v2 (subscription suspend and cancel by id), Chargebee and Recurly subscription ids.

agent cancelled a subscription by customer name

wrong subscription cancelled when a customer had two plans

cancel matched the plan name instead of the subscription id

Why it happens

Language is name-shaped: customers say "cancel my pro plan," so the agent searches by the words it heard. Search returns the first match, which is often another customer's subscription or the customer's older, already-cancelled one that still matches the name.

Edge cases

• Customers with multiple active subscriptions on the same plan: the list-and-confirm step is mandatory, not optional
• Recently cancelled subscriptions still appear in searches; filter to active and trialing before presenting choices
• Test-mode ids and live-mode ids look alike; confirm the environment matches before cancelling

Provenance

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

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

Thread query: agent cancelled the wrong subscription: matched on name instead of id

TL;DR: Never cancel by name. Resolve the exact subscription id first, then show the customer name, plan, and amount back for confirmation before cancelling. The cancel call itself takes only the id. Name matching is the bug.