Handling job changes, departures, and stale customer accounts

A known contact changes jobs. The reflex is to disqualify them, and because they were the primary contact, mark the whole Account inactive along with them. Neither reaction is correct, and both destroy information the business will want back the moment that person re-engages from their new company, or the moment someone double-checks whether the account relationship is actually over.

This page covers two related but distinct operational failures: what to do when a person changes employers, and what to do when an Account goes stale without anyone deciding it should. Both are detection-and-review problems, not lifecycle redesign problems. The lifecycle states themselves (person lifecycle, Account lifecycle) are defined in Lead and Contact lifecycle design and Account lifecycle design; this page is about the operational rule that decides when a review should happen and what must never be inferred automatically.

An employment change is evidence about a person, not proof about an account

When a contact's employer field changes (detected through a bounced work email, an enrichment refresh, a rep's note, or a re-engagement from a new domain), the correct response has three parts:

Preserve the relationship history. Every activity, email thread, and prior engagement stays attached to the person's record. A job change is not a reason to archive or disqualify that history.
Record the new employment context without erasing the old one. The person now has a new employer relationship to track. Their history at the previous employer remains real and remains theirs.
Do not automatically change the previous employer's Account lifecycle. One person leaving is a fact about that person. It's evidence to consider, not proof that the Account relationship changed.

Prohibited inference	Why it's wrong
Disqualify the person because they changed jobs	They may re-engage from the new company; disqualification erases the reason to reach out again
Downgrade the Account because its primary contact left	The Account's commercial relationship depends on its own evidence, not on one person's employment

A departed contact who re-engages from a new employer six months later is one of the most common ways stalled pipeline actually reopens. Losing their history at the old employer, or treating the departure as disqualifying, throws that opportunity away before it exists.

Account staleness needs a signal and a review path, not a silent default

A customer Account with no commercial activity for an extended period can sit labeled Customer indefinitely if nothing ever triggers a review. That's not a lifecycle failure; it's a missing detection rule. Define:

A staleness signal: no commercial activity (renewal touch, support case, usage signal, or whatever your business considers evidence of an active relationship) inside a defined window, while status still reads as an active commercial relationship.
A review path: the account routes to its owner for an explicit reactivate-or-archive decision. Staleness detection doesn't change the Account's state by itself; it forces a human decision the business has been avoiding by default.

The account-lifecycle model already defines Former customer as a state with its own entry evidence and reason (see Account lifecycle design). This page's contribution is the detection trigger that gets a stale Account in front of that existing model instead of leaving it un-reviewed.

GTM Lab: a departure and a stale account, resolved separately

GTM Lab, a fictional B2B software company, has two records that test this distinction.

Derek Chen changes employers. Derek was GTM Lab's primary contact at target account Ferrow Industrial, mid-evaluation on a new-business Opportunity. His work email starts bouncing, and an enrichment refresh confirms he's now at Whitfield Manufacturing. The correct handling: Derek's activity history at Ferrow Industrial stays intact and attributed to him. His record gains a new-employer context (Whitfield Manufacturing). Ferrow Industrial's Account lifecycle doesn't change because of his departure alone; someone else at Ferrow may still be the active buyer, and that's a separate fact the Account-lifecycle model already handles. Derek himself isn't disqualified. Two months later, when he re-engages from Whitfield Manufacturing's domain, his prior relationship history is still there to build on instead of starting over.

Kessler Metal Works goes stale. Kessler was an active customer eighteen months ago. No renewal touch, no support case, no usage signal has occurred since, and its Account still reads Customer. Nobody set out to leave it that way; nothing ever triggered a review. Once a staleness signal (no commercial activity past a defined window while status reads active) is defined and run against the population, Kessler surfaces and routes to its account owner, who confirms the relationship has in fact lapsed and moves it to Former customer with the reason and date recorded, consistent with the existing lifecycle model.

This is a worked example. GTM Lab's specific staleness window and detection signals are operating choices, not a universal threshold.

Salesforce and HubSpot: what changes, what doesn't

Neither platform ships an automatic "this contact left their job" or "this account went stale" detector. Salesforce can surface employment-change signals through enrichment integrations or manual updates to Account/Contact fields; a scheduled report or Flow can implement the staleness-detection rule against your own defined window. HubSpot similarly relies on enrichment or manual signals for job changes, and a workflow or report can implement staleness detection against Company activity properties. In both cases, the detection logic and the review routing are yours to build; the platform provides the fields and automation primitives, not the policy.

Departure and stale-account checklist

A person's relationship history is preserved in full when an employment change is detected.
The person is not automatically disqualified because they changed employers.
The previous employer's Account lifecycle does not change automatically because one contact departed.
A staleness signal is defined for Accounts, with its window and evidence stated.
A stale Account routes to a human review, rather than defaulting to either "stay Customer forever" or "auto-downgrade."
The eventual state change (if any) is recorded with its reason and date, using the existing Account-lifecycle model rather than a new ad hoc field.

Where this connects

The lifecycle states this page routes into are defined in Account lifecycle design and Lead and Contact lifecycle design. The recycled-lead re-engagement case that shares a scenario with a departed contact's eventual return is covered by the same lifecycle pages' recycling model. The detection work here feeds the baseline stale-account metric in CRM data quality audit.