CRM hygiene and prospect job changes

The prompt

The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.

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

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it
first. This prompt is only as real as the tools behind it:

1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this
   prompt uses: your CRM, a professional network, and your team's
   messaging tool.

Once connected, your assistant has real tool access and the rest of
this prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

A merge is destructive and a wrong merge is expensive to unpick.
Everything below is biased towards leaving two records alone when the
evidence is thin, and towards recording what was done so a bad call
can be found afterwards.

## 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 duplicate companies and people

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. Browse for prospect and customer job changes

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. Reconcile the records

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