Email Pattern Conventions: How Company Size Shapes Address Format

The Pattern Problem

Your prospect is Jane Smith at Acme Corp. What's her email?

- jane@acme.com? - jane.smith@acme.com? - j.smith@acme.com? - jsmith@acme.com? - jane_smith@acme.com? - janesmith@acme.com?

Without knowing Acme's naming convention, you're guessing. And you'll be wrong 50% of the time.

Why Pattern Learning Works

Each domain settles on a convention early and sticks to it. Why?

1. **Email is legacy infrastructure**: Once you set a naming scheme, you can't easily change it. Everyone's LDAP, mailbox, and forwarding rules depend on it. 2. **Consistency saves admin overhead**: "Everyone gets first.last@company.com" is easier than "CEO is jane@, VPs are first.last@, individual contributors are first_last@". 3. **Branding**: Some companies have strong preferences. Google uses first.last (gmail.com employee addresses are firstname.lastname).

So once you identify the pattern, you can predict the next address.

Common Patterns by Company Stage

Startup (1-50 people) - **Most common**: `first@` (sarah@, mike@) - **Why**: Simplicity. Small team, everyone knows each other. - **Exception**: Founders sometimes use longer patterns as they scale.

Example: ``` sarah@craftapp.com mike@craftapp.com ```

Growth Stage (50-500 people) - **Most common**: `first.last@` (sarah.kim@, mike.chen@) - **Why**: Growing fast, need to avoid collisions. first.last eliminates most duplicates. - **Secondary**: `first_last@` (especially in technical companies and legacy systems)

Example: ``` sarah.kim@acme.com mike.chen@acme.com ```

Enterprise (500+ people) - **Most common**: `first.last@` (still the standard) - **Secondary**: `fi.last@` or `f.lastname@` (Microsoft shops often use this) - **Variation**: Department-specific patterns (engineers: first.last, sales: first_last)

Example: ``` sarah.kim@bigcorp.com mike.chen@bigcorp.com s.kimmons@bigcorp.com (finance team variant) ```

Industry-Specific Patterns

Technology - **Dominant pattern**: first.last@ - **Why**: Hiring from startups where this was the norm. Standard across Google, Meta, Apple. - **Exception**: Older companies (IBM) sometimes use first_last or fi.last

Finance / Legal - **Dominant pattern**: first.last@ or first_last@ - **Why**: Legacy systems and regulatory requirements. Less flexibility. - **Exception**: Some still use single name (john@ for John Smith)

Healthcare - **Pattern variance**: High. Different hospital networks use different schemes. - **Common**: first.last@ but also first_last@, flast@, or even department codes

Nonprofits / Government - **Variant rich**: Role-based addressing common (info@, support@, director_of_programs@) - **Prediction harder**: Less standardization, more department-specific schemes

How Size Shapes Naming

The progression is usually:

Stage 2 (10-50): first@, some first.last@ as hiring scales
Stage 3 (50-500): mostly first.last@, some legacy first@ still works
Stage 4 (500+): first.last@ with department variants
Stage 5 (5000+): strict first.last@ + role accounts (cto@, cfo@)

As companies grow: - Hiring from diverse sources weakens founder/early-team naming - New departments push for their own patterns - IT wants standardization (pushes first.last@) - Compliance wants trackability (no anonymous first@ accounts)

Real-World Examples

Small startup (40 people, Series A) ``` sarah@craftsoftware.io mike@craftsoftware.io alex@craftsoftware.io ```

Tries first.last@? Mostly fails. Real pattern: first@

Growing company (200 people, Series B) ``` sarah.kim@craftsoftware.io mike.chen@craftsoftware.io alex.rodriguez@craftsoftware.io ```

90% of addresses follow first.last@. Trying first@ now mostly fails.

Enterprise (5000+ people) ``` sarah.kim@bigcorp.com mike.chen@bigcorp.com s.kimmons@bigcorp.com (finance exception) john.smith@bigcorp.com ```

Dominant pattern: first.last@ Variants: department-specific or legacy accounts

How Coalstoke Uses This

When you request jane.doe@acme.com:

1. We run SMTP verification first 2. If it verifies: great, return it 3. If it fails but we've seen acme.com before: check our pattern database 4. If we have 5+ examples of acme.com using first.last@: high confidence 5. If acme.com is small/new: lower confidence, but we return the guess with a score

Each time you verify a real address, we store the pattern anonymously: - Company: acme.com - Pattern: first.last@ - Confidence: +1

Next time you find another person at acme.com, the pattern is smarter.

The Practical Impact

Pattern learning reduces your false negatives (addresses you think don't exist but do):

- Without pattern learning: 30-40% of valid addresses get rejected by guess-based verification - With pattern learning: 8-12% false negative rate - With 100+ lookups at a domain: 3-5% false negative rate

In other words: on your 20th lookup at Acme Corp, your verification accuracy jumps from 60% to 97%.

That's why pattern learning matters.