CRM hygiene and prospect job changes

# CRM hygiene and prospect job changes

You have access to a CRM, a professional network, and a messaging
tool. Run this **[weekly]** across the CRM's companies and contacts.


## 1. Run on the weekly schedule

Run on a fixed weekly cadence rather than on a trigger. Record
edits arrive continuously and in small numbers, so reacting to each
one produces constant churn for no benefit; a weekly pass is frequent
enough that a job change is caught before the next renewal
conversation and rare enough that the recap in step 5 is worth
reading.

Pull the companies and contacts to check, and note the timestamp of
the last run so the recap can say what changed since.

## 2. Merge duplicates, keep the history

Normalise first, because the matching below keys on fields that are
stored inconsistently:

- Country and region to one vocabulary. "UK", "U.K.", "United
  Kingdom" and "GB" are one country stored four ways, and they break
  every segment built on the field.
- Website fields to a registrable domain: strip the protocol, strip
  `www`, drop paths and tracking parameters.
- Whitespace, casing on names that arrived fully capitalised, and
  placeholder values such as "n/a", "test", "-" and "unknown".
- Phone numbers to international format where the country is known,
  and left alone where it is not. A number reformatted against the
  wrong country code is worse than an ugly one.

Then group companies by normalised registrable domain. Never by name:
legal suffixes come and go, trading names differ from registered
ones, and two unrelated companies can share a name.

Group people by normalised work email first, falling back to a
professional-network profile URL where emails differ or are missing.
Never merge two people on name plus employer alone, because two
people with a common name at a large company is ordinary and merging
them destroys both histories at once.

Two cases to hold back on rather than resolve:

- Free mailbox, shared-office and agency domains are not evidence of
  anything. Never merge on them.
- A parent and a subsidiary usually share a domain. Where the records
  differ by country or registration number, flag rather than merge.

Merge onto whichever record carries the most linked activity, not the
oldest or the most complete on paper. A missing phone number can be
re-enriched; six months of call notes cannot be reconstructed at any
price.

Before merging, write the losing record's identifiers into a note on
the survivor: its record ID, its email, and every field value that
differed. Where both records hold a different non-empty value, keep
the survivor's and log the discarded one. Never silently overwrite
something a person typed.

## 3. Spot prospects and customers who changed jobs

For each contact, compare the employer on their professional-network
profile against the company on their CRM record. A mismatch is a
candidate, not a fact: profiles go stale in both directions.

Treat a move as confirmed when either holds:

- The profile shows a start date at the new employer later than the
  CRM record's last activity.
- Their old work address now bounces.

Anything else stays a candidate and goes into the recap for a person
to look at, rather than being acted on.

## 4. Move contacts to their new company

- Do not overwrite the old record. Close the contact out with a note
  saying where they went and when, so the account's history stays
  intact.
- Create or update the contact on the new employer's record, carrying
  a note that they were previously a contact at the old one.
- Flag the old account as having lost a known contact.

That last flag is the reason this is worth running weekly rather than
quarterly. A departing champion is a retention signal that arrives
well before the renewal conversation, and it is invisible unless two
systems are being compared.

A contact who moved to a company already in the CRM is a warm
introduction there. Say so explicitly in the recap.

## 5. Post the weekly recap

One message to the team channel, in two halves.

First, the confirmation nobody has to act on: the CRM is current as of
this run, with counts for fields normalised, duplicate groups merged,
and groups flagged rather than merged. Two or three lines. Most weeks
this is the whole message and it exists so the team knows the run
happened.

Second, the part that needs a person, named individually rather than
counted:

- Prospects and customers who changed employer, with where they went.
  Each one is either a warm introduction at the new company or a lost
  contact at the old, and usually both.
- Accounts that lost a known contact, which is a retention signal
  ahead of the renewal conversation.
- Candidates the rules refused to decide, such as a probable parent
  and subsidiary pair, or a profile mismatch that could not be
  confirmed.

One weekly message, not a running stream. A channel receiving a
notification per record edit is a channel everyone mutes, which
defeats the only part of this a human needs to see.

## Output

Report: fields normalised by type, duplicate groups merged, groups
flagged for review and why, job moves confirmed, accounts that lost a
contact, warm introductions found, and unresolved candidates.