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

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

## Output

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

```
Contacts scanned:            X
Employer known:              X
Business emails found:       X/N (XX%)
Lifecycle stage upgraded:    X
MoltSets tokens used:        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.