---
name: moltsets-attio-personal-to-business-email-upgrade
description: Find Attio person records held below your SQL threshold by a personal email address, resolve a business email and title through MoltSets, and re-trigger lead scoring.
---

# Attio Personal-to-Business Email Upgrade

## Triggers

- "Find contacts stuck as MQL because they signed up with a personal email and upgrade them"
- "Resolve business emails for Attio records on gmail.com and re-run lead scoring"

## What this skill does

Targets the specific records a personal email address is holding back. When someone signs up with a gmail.com or outlook.com address, most lead scoring models cannot credit the firmographic signal that would push them from MQL to SQL. This skill finds those records, resolves a business email and title through MoltSets using whatever else is on file, and re-triggers scoring once the upgrade lands.

## Chain

```
Attio person records on a free-mail domain, below SQL threshold
  to attio/query-records                (email domain in free-mail list, lifecycle stage below SQL)
  to resolve identifier per record      (name + inferred/known employer, or LinkedIn URL if present)
  to MoltSets:
      search_business_email_by_name     (name + company domain -> business email)
      search_business_profile_by_name   (fallback -> title, firmographics, in case company is unknown)
  to validate the returned business email
  to attio/update-record                (add business email, keep personal email as secondary, re-trigger scoring)
```

## Inputs

- **Free-mail domain list** - which personal email domains to target (gmail.com, outlook.com, yahoo.com, and so on)
- **Lifecycle scope** - which stage or score threshold defines "held back" for your model
- **Employer signal** - what you already have to identify the employer (a company attribute, form data, or nothing at all)
- **Write-back behaviour** - replace the primary email, or add a business email as a separate attribute and keep the personal one
- **Acceptable risk scores** - which A-F deliverability grades to keep (recommended: A, B, C and F; D excluded)

## Risk scores - confirm before enriching

Every email MoltSets returns carries a deliverability risk score - a grade from A to F. Ask which grades to keep before running anything:

> "MoltSets grades email deliverability risk from A (best) to F (no data). Which grades should I keep? I'd recommend **A, B, C and F** - and dropping **D**, since D is a confirmed bounce, complaint or spam trap."

| Grade | Meaning | Best practice |
| --- | --- | --- |
| A | Strongest engagement signal available | Safe to send immediately |
| B | Solid | Fine in regular sends; on a new or warming domain, send a smaller batch before scaling |
| C | Deliverability can't be confirmed | Segment separately from A/B, warm at low volume, watch engagement, suppress non-responders after 1-2 attempts |
| D | Confirmed bounce, complaint or spam trap | Never send - fastest way to trip spam traps and damage sender reputation for the whole list |
| F | No data - unknown risk, not "safe" | Re-verify before sending, or treat like C |

Use whatever set the user confirms. Treat the grade as a filter, not a guarantee - it lowers risk, it doesn't remove it. Pair it with the user's own sending domain reputation and list hygiene.

## How it works

1. Pulls person records on a free-mail domain sitting below your SQL threshold or target lifecycle stage
2. For each, checks what employer signal already exists on the record (a company name, a domain from form data, or an inferred one)
3. Runs `search_business_email_by_name` where an employer is known, to resolve a business email
4. Falls back to `search_business_profile_by_name` when the employer itself is unknown, to establish company and title first
5. Validates the returned business email before writing
6. Writes the business email to the record (as primary or as a separate attribute per your policy) and re-triggers lead scoring so the record can move past the personal-email gate

Before any write-back, every found address is checked against the accepted grade set. Out-of-range grades are reported in the table with their true score and skipped - never written to the CRM.

## Output

| Name | Personal Email | Company | Business Email Found | Email Risk | Title | Score Before | Score After | Action |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

Show the risk score on every row that has an email, including grades outside the accepted set - flag those in `Action` (e.g. "held - grade D") rather than dropping them silently. Only emails inside the accepted set are written back to the CRM.

```
Records scanned:             X
Employer known:              X
Business emails found:       X/N (XX%)
Lifecycle stage upgraded:    X
MoltSets tokens used:        X

Email risk scores:
  A: X   B: X   C: X   D: X   F: X
  kept (accepted grades):  X
  filtered (excluded):     X
```

## Tips

- Requires the Attio MCP (mcp.attio.com) and the MoltSets MCP connected in the same client
- Decide up front whether the business email replaces the primary email attribute or sits alongside it, this affects every downstream workflow keyed on email
- Records with no employer signal at all are the hardest match, consider routing those to the signup expansion skill instead, which resolves from name plus domain more broadly
- Re-triggering scoring only helps if your scoring model actually reads the newly filled attributes, confirm that mapping before running this at volume
- If your scoring logic lives in an Attio automation, updating the email attribute alone may be enough to fire the workflow without a separate re-trigger step