Warm intro automation turns a network export into a ranked list of possible connectors. This workflow keeps the source evidence and requires a person to verify the relationship before asking for an introduction.
What is warm intro automation?
Warm intro automation maps contacts in your network to people at target accounts, ranks the possible introduction paths, and prepares each path for review. It can cut the work of finding a connector. It cannot verify the relationship by itself.
A connection graph answers who is connected to whom.
That is easy to answer and often useless. Two people can share a company, school, city, or investor without knowing each other. A database join is not a relationship.
Before asking for an introduction, the operator needs evidence that the connector may know the target.
We built a system to answer that question. It resolves identities, maps target accounts, finds possible connectors, and attaches source records to each path. The output goes to a review queue.
We ran the system against a deterministic public fixture and released the code. The diagrams below come from that run.
Open the public warm intro Play.
It includes the fixture, schemas, expected output, provider policy, privacy checks, and tests.
Scroll on small screens or open the editable source:
warm-intro-automation-workflow.excalidraw
.
1. Import and store LinkedIn contacts
Start with a LinkedIn connections export. The CSV is evidence from one point in time. It is not the Database.
Normalize profile URLs, names, employers, and dates before you merge records. Keep each source ID and alias. A matching URL or email creates a candidate merge, not permission to ignore conflicting identities.
Write one canonical record to the Database. Store the source URL, observation date, current snapshot, and aliases. If two sources disagree, keep both records and send the conflict to review. The same identity rules apply when you run contact data enrichment.
The database joins these sources:
- network connections
- CRM activity and account ownership
- event attendance and form submissions
- dated employment and education history
- public appearances and community context
- explicit relationship notes or confirmed introductions
Every score can now point to a source record. When a reviewer asks why a path exists, the system has an answer.
2. Rank target accounts before enrichment
The fixture starts with five accounts. It keeps three. It suppresses one existing customer and removes one non-B2B company.
Run those checks first. There is no reason to search for contacts, buy data, or draft messages for an account you cannot contact.
For each remaining account, build the buying committee. We search for GTM engineering, revenue systems, RevOps, BizOps, and GTM analytics. Each output keeps the target's current title. This is the same separation between targeting logic and provider calls used in our account mapping play: decide which accounts matter, then call providers.
Scroll horizontally on small screens. Rendered from the current public fixture: five accounts, four person-level paths, and zero messages sent.
3. Score warm intro paths by evidence
The system uses weak clues to find paths. It does not use them to make strong claims.
A company match may reveal a connector. It does not prove that two people worked together. To claim work overlap, the employer must match and the employment dates must overlap.
Before scoring, the current Play validates connector ownership and every cited evidence ID. A forged or mismatched citation earns no points and cannot create a strong path.
We score two edges separately. The first is owner to connector. The second is connector to target. A strong first edge cannot repair a weak second edge.
The evidence order is:
- confirmed direct introduction
- verified dated work overlap
- school, city, community, or public appearance
- role or industry proximity
- investor context
Investor overlap stays last. Ten weak clues do not become one strong fact. Repeated evidence adds citations, not points.
Scroll horizontally on small screens. Higher scores do not bypass the human review boundary.
Warm intro scoring examples
| Target | Connector | Evidence | Route |
|---|---|---|---|
| Nora Imani, Head of GTM Engineering | Avery Stone | Confirmed introduction record | Strong warm intro |
| Mina Sol, Director of Revenue Systems | Casey Morgan | Dated Atlas Works overlap | Strong warm intro |
| Tariq Fen, Director of BizOps | Riley Chen | Same company, non-overlapping dates | Review |
| Elliot Vale, Director of RevOps | Parker Quinn | Investor context only | No strong path |
The third path is the most useful one. Riley and Tariq worked at the same company, but not at the same time. The system keeps the clue and blocks the "former colleagues" claim.
The fourth path has only a shared investor. It goes to direct outreach. The software does not call it a warm path.
4. Review each introduction request
Only strong paths enter the draft queue. A review path needs an operator flag and a row-level override. A row with no strong path never reaches the model.
Every draft starts as unapproved. The reviewer checks the target's role, the cited fact, both identities, the current relationship, suppression state, and the cost of the favor.
Activation uses a versioned ID. It contains the campaign, owner, path, channel, and message version. A material edit creates a new version and removes the old approval.
The outbox records an immutable send intent and attempt before dispatch. A successful or uncertain attempt cannot retry on its own. An uncertain provider response creates a reconciliation task.
Most of the engineering work went into this boundary, not the copy generator. The system makes a careful operator faster. It does not send from an uncertain relationship graph on its own.
5. Run the public warm intro workflow
The code is in the public GTM Engineering Skills repository.
Run the deterministic fixture from the repository root:
python3 examples/office-hours/target-account-warm-intro-campaign/pipeline.py \
--input-dir examples/office-hours/target-account-warm-intro-campaign/sample_data \
--output-dir /tmp/target-account-warm-intro-example \
--config examples/office-hours/target-account-warm-intro-campaign/config.example.json \
--as-of 2026-08-01
The fixture writes nine review files and a hash for each artifact. The hashes make two local runs comparable. They do not authenticate the source. The run makes zero provider calls and sends zero messages.
The loader preserves unknown source columns for audit. Redact provider metadata before ingestion because an unexpected field can contain personal data. Sanitize untrusted CSV values before opening them in a spreadsheet.
The public provider policy routes company job postings to Sentrion, LinkedIn posts to Apify, and X posts to TwitterAPI.
It uses PDL only for gap-fill after URL, email, and identity exclusions. It blocks Bloomberry and Crustdata LinkedIn posts.
Use these three examples in order:
- Target-account campaign ranks accounts, resolves contacts, maps buying committees, and scores paths.
- Warm-intro scoring explains the evidence hierarchy and deterministic exports.
- Ask threads handles drafting, approval, rate limits, idempotency, and reconciliation.
Replace the fictional inputs with a reviewed export from your network and the Database. Keep the contracts for identity, dated evidence, routing, manual approval, and send history.
FAQ
Does a shared employer prove that two people know each other?
No. First require overlapping employment dates. Then ask the connector whether they know the target before you use the claim in a message.
Should investor overlap count as a warm path?
No. Investor overlap can help find a possible path, but it cannot prove a relationship.
Why write the LinkedIn export to the Database?
The export is one snapshot. The Database gives each person a stable identity. It can add new evidence without hiding its source or deleting a conflict.
Can I send directly from the workflow?
Yes, after explicit approval. Run a dry test first and store each send intent, attempt, and provider event. Reconcile an uncertain provider result before retrying.