---
name: moltsets-hubspot-personal-to-business-email-upgrade
description: Use this skill to find HubSpot contacts held below your SQL threshold by a personal email address, resolve a business email and title through MoltSets, and re-trigger lead scoring.
---

# HubSpot Personal-to-Business Email Upgrade

Target the specific contacts 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. Find those contacts, resolve a business email and title through MoltSets using whatever else is on the record, and re-trigger scoring once the upgrade lands.

## Triggers

"Find contacts stuck as MQL because they signed up with a personal email and upgrade them", "resolve business emails for HubSpot contacts on gmail.com and re-run lead scoring". Use when free-mail addresses are blocking contacts from progressing in the lifecycle.

## Requirements

- HubSpot remote MCP (mcp.hubspot.com) and the MoltSets MCP connected in the same client
- Custom objects are not reachable through HubSpot's remote MCP - write to standard contact properties

## Chain

```
HubSpot contacts on a free-mail domain, below SQL threshold
  -> hubspot/search-crm-objects        (email domain in free-mail list, lifecycle stage below SQL)
  -> resolve identifier per contact    (name + inferred/known employer, or LinkedIn URL if present)
  -> MoltSets:
       search_business_email_by_name   (name + company domain -> business email)
       search_business_profile_by_name (fallback -> title, firmographics, when company is unknown)
  -> validate the returned business email
  -> hubspot/update-object             (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 the model
- **Employer signal** - what already exists to identify the employer (a company field, form data, or nothing at all)
- **Write-back behaviour** - replace the primary email, or add a business email as a separate property 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.

## Steps

1. Pull contacts on a free-mail domain sitting below the SQL threshold or target lifecycle stage.
2. For each, check what employer signal already exists on the record (a company name, a domain from form data, or an inferred one).
3. Run `search_business_email_by_name` where an employer is known, to resolve a business email.
4. Fall back to `search_business_profile_by_name` when the employer itself is unknown, to establish company and title first.
5. Validate the returned business email before writing.
6. Write the business email to the record (as primary or as a separate property per policy) and re-trigger lead scoring so the contact 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.

```
Contacts 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

- Decide up front whether the business email replaces the primary email property or sits alongside it - this affects every downstream workflow keyed on email.
- Contacts with no employer signal at all are the hardest match; consider routing those to a broader signup-expansion skill that resolves from name plus domain.
- Re-triggering scoring only helps if the scoring model actually reads the newly filled fields - confirm that mapping before running at volume.