Naming conventions for business email

Naming conventions for business email aren't about which format sounds best — they're about which one survives growth. A convention that works at five people often falls apart at fifty, and the migration is painful. Pick once with the future in mind.

Here's the playbook by team size, plus how to handle role aliases, shared inboxes, and the moves that prevent a forced migration later.

Teams of 5 — keep it personal

Recommended: first@yourcompany.com

At five people, first-name-only is delightful. Customers feel they're emailing a human. Internal email feels personal. Business cards look clean. Use this — but plan the exit before you need it.

The catch: the moment you hire a second Sarah, you're in trouble. You'll be tempted to use sarah2@ or sarahc@ as a workaround. Don't. That's the signal to migrate the whole company to a scalable format.

Pre-commit now: pick a scalable format (probably first.last@) and document the trigger event for the switch. Most teams pick "at the 15th hire" or "at the first name collision."

Teams of 50 — first.last or flast, no exceptions

Recommended: first.last@yourcompany.com for most companies, flast@ for sales-heavy teams.

At 50, you need predictability. New hires need to figure out anyone's address without asking. Auto-complete needs to work in Gmail, Slack, calendar invites, and any CRM your team touches. The scheme has to be guessable from one example.

first.last wins for most companies because it's unambiguous (Mark's address is mark.hanson@, notmarkha nson@) and reads as a real name in print. flast wins for sales-heavy companies where addresses get typed into CRMs hundreds of times a day — two fewer characters each makes a real difference.

Document collision rules:

• Two people, same first and last name: add middle initial (sarah.j.chen@) or numeric tiebreak (sarah.chen2@).
• Hyphenated surnames: strip the hyphen (sarah.smithjones@).
• Non-ASCII characters: transliterate to ASCII (ramón → ramon, è → e).

Teams of 500 — first.last + employee ID for collisions

Recommended: first.last@ with deterministic collision handling tied to employee ID.

At 500 employees, name collisions are guaranteed and have to be resolved by a system, not a person. The cleanest pattern: when a new hire's name collides with an existing employee, append a number derived from join date or HR record (not chosen ad-hoc by IT).

Stop trying to be clever. Don't use middle initials for some and numeric suffixes for others. Pick one rule and apply it uniformly. Inconsistency is what kills enterprise email schemes — the new hire who can't find anyone's address because half the company isfirst.last and half is first.m.last wastes weeks of organizational time.

Role-based addresses — when and how

Every company needs a small set of role addresses. The standard kit:

• support@ or help@ — customer support inbound
• sales@ — inbound sales (lower-quality leads; route to BDR queue)
• hello@ or contact@ — general inquiries
• billing@ — billing questions; usually routes to ops
• careers@ or jobs@ — recruiting
• security@ — required by responsible-disclosure standards; route to security team
• press@ — for PR and journalist inquiries

Each one routes to a shared inbox (Front, Help Scout, Missive, or a Google Group). Individual employees never receive directly from these addresses — they respond through the shared inbox so the thread stays visible to the team.

Avoid: per-team prefixes

sales.sarah@, support.jamie@, eng.marcus@ — anything that puts the team in front of the name. Three problems:

1. When the person changes teams, the address breaks or stays wrong.
2. External recipients route to spam mentally on team-prefixed addresses.
3. The address itself signals "don't reply, this is bulk mail" even when it's a personal message.

Keep the local part name-only. Use Slack channels, Salesforce, and HR directories to encode team membership — not the email address.

The founder problem

Founders almost always keep their original firstname@ address from the early days. This is fine for the founder. It's ruinous for everyone else.

When a candidate gets sarah@ from the CEO and jamie.smith@ from the recruiter, they notice. It signals a two-tier company. Fix it at 50 employees: the founder moves to the company-standard format and sets up an alias on the old address. The alias forwards forever; nobody notices the change externally.

Migration — when you have to do it

Migrating an entire company's email format is genuinely painful. The minimum playbook:

1. Set up the new addresses for every employee. Aliases forward old → new for 12 months.
2. Change the default reply-to in everyone's email client to the new address.
3. Announce internally that the new format is the official one. New email signatures use the new address.
4. Update external profiles over the next quarter: LinkedIn, Twitter, Crunchbase, conference bios.
5. Track old-address inbound traffic. After 12 months, if old addresses still receive meaningful mail, extend the alias another year — don't cut it off cold.

Most companies do this once. Plan it carefully.

The shortcut

If you're setting up a brand-new domain and want to compare format candidates for your founding team, run their names through our email address generator with your domain. It produces every common format for each person at once — pick the scheme that looks consistent across all of them.

For the broader debate on which format reads best, see the 7 most common business email formats — that post ranks the formats themselves; this one is about deploying them at scale.

Naming conventions are infrastructure. They don't feel important until they break. Spend the hour now writing yours down — the future you, with 500 employees and a half-finished migration, will be very grateful.