Champion-departure monitoring

The job of champion-departure monitoring is to tell a CSM that a specific, already-named champion looks gone, and to attach a cite they can check. It is not to rebuild the buying committee, start a sequence, or pick who owns the relationship next.

Quality is the alert itself. You want the contact record, the account, the reason the system thinks they left, and a freeze on customer-facing mail until a person confirms. Anything that auto-notifies the account, or fills an empty champion field with a guess, fails the outcome even if the underlying job-change event was real.

Champify and UserGems are one class of job-change sensors. Salesforce is where you store who the champion is. Gainsight is where many CS teams run the account. Use them as a stack, not as a ranked shortlist, and do not assume a feature you have not configured.

The play lives in the confirmation step and in who is allowed to talk to the customer after.

A broader churn-risk prediction model may also move when a champion disappears. Keep that score in its own lane. Departure monitoring answers a narrower question: did this named person leave, and can you show why.

Watch people you have already named. The champion should already sit on the opportunity, the account team, or the sales-to-CS handoff briefing. If the field is empty, fix the handoff. Do not let the monitor invent a champion so it has someone to follow.

Limit the watch list to named roles: champion, executive sponsor, day-to-day admin, if those people are actually on the record. Domain-wide watching pulls in promotions, contractors, and employees who never touched the product. That noise trains CSMs to ignore the queue.

Keep this queue separate from buying-signal trigger monitoring. A new role at the same company can look like intent. A new employer is a hole in the relationship. If both events land in one inbox, someone will congratulate a departed champion or treat a promotion as churn.

When a signal fires, require a payload a CSM can audit: which contact, which account, the title you stored, and the cite. A cite can be a public profile showing a new employer, a hard bounce tied to that mailbox, or a CRM status the team already uses for departed contacts. A payload that only says "someone at this company changed jobs" is not a champion-departure alert.

Name the champion in Salesforce (or your CRM) in language humans use. "Primary contact" that is actually an AP clerk will generate alerts that waste the queue. The named champion is the person whose departure would force you to re-earn the account, not every stakeholder.

The CSM confirms before anyone emails the account. That order is the control. Job-change feeds fire on title edits, department moves, and profile cleanups. Those events are not departures.

Open the CRM record and the cite together. Check whether the employer changed, whether mail still delivers, and whether the person still appears on recent meetings. If the cite is only a new title at the same company, you do not have a departure.

Reach the champion on the thread you already have. A new blast to the team is an account email, which is what you are holding. If an auto-reply says they have left, log that as a cite. If a colleague says they are on parental leave, log that it is not a departure and close the alert.

Do not auto-email. A workflow that sends "we noticed you started a new role" can land at the new employer, in a shared inbox, or in a distribution list the remaining users still read. You will have told the account you were watching the champion, and you will have skipped whoever still owns the renewal.

Park the alert as a confirm-departure task in Gainsight or whatever CS workspace you use. The task owner is the CSM, with the AE copied when they still own the commercial relationship. The task is not a sequence enrollment.

Confirm on the existing thread, leave the champion field empty, and ask a named admin who owns the tool. Skip that order and you get a title-change false positive, an account-wide auto-email, or an org-chart successor.

Priya is the named champion on an account with a renewal several months out. A job-change alert cites her public profile with a new company. The CSM does not email the account group and does not ask an SDR to find the next VP. They open Salesforce: last working session was Priya plus an admin. They reply on that thread. The auto-reply says she left last week. The CSM attaches that cite, marks Priya departed, and leaves the champion field empty until a person names the next owner. The AE who closed the original deal and the CSM agree to ask the admin who owns the tool now. That is the example. There is no save rate attached to it.

Title-change false positive: Priya is still at the same company, Director of Operations becoming VP of Operations. The title string changed, so the sensor fired. If you treat that as a departure, you may open a retention motion against someone who just gained authority. Confirm employer first, title second.

Auto-emailing the account: a playbook sends condolences, a re-introduction, or a QBR hold to every contact. Remaining users read it as you already treating the account as at risk. Anyone who might become the next champion hears it from the side, not from a designed conversation.

Guessing a successor from the org chart: the system proposes the next leader in the same branch and writes them into Salesforce as champion. That person may never have seen the product. Every later motion that assumes a warm champion, including a save-play recommender, now points at the wrong human.

After confirmation, people choose the next conversation. The monitor does not. You might ask a named admin who owns the product. You might ask the AE who else sat in the evaluation. You might wait until the customer names someone. Empty champion is more honest than a guessed one.

If usage is thin and the date is close, work a save motion only after you have a real counterpart. A recommender can suggest plays. It cannot invent the person those plays are for.

If a QBR was aimed at the departed champion, do not ship an auto-generated QBR to that inbox. Rebuild the audience, then reschedule. Sending a polished deck into a dead mailbox is another form of auto-email.

Log the cite on the account so the next CSM does not re-discover the departure from a bounce. Keep the old champion on the record as departed, not deleted, so you do not re-watch them as if they were still the relationship.

The quality bar does not change after the first week. You still have a named person who left, a cite, and a human-owned next step. You do not have a synthetic successor, and nobody emailed the account on an unconfirmed job-change event.