What is the best email address format for people with the same first and last name?

Question

The larger the organisation (for example a company or educational institution), the more likely that there will be two people with the same name.

Typically, email addresses are formatted [email protected]

What should the email address format be to minimise the risk of emailing the wrong person when you have two people with the same name?

I have seen:

firstname.middleinitial(s)[email protected]

[email protected]

[email protected]

[email protected]

Edit: the other consideration is that the format should work for people both inside and outside the company.

People working in the same company have access to the email directory and may know the person's location or department, but someone on the outside would not.

Edit 2: this is also a common issue for domains that cycle through users on a regular basis, for example universities/colleges where a typical user may only use the email for 3 or 4 years, then graduate/leave. If you choose not to recycle emails, there is a potentially unlimited pool of people with similar names joining/leaving every year.

Answer 1

Your question seems to assume that email senders have to either remember the email address of the intended recipient, or will have to accurately reverse-engineer the email address of the intended recipient. You also seem to assume that email addresses must be of a single form company-wide.

I think that the answers over-engineer a solution because they rely on the sender knowing information about both the intended recipient and the format of email addresses. While you are virtually guaranteed to have a name collision at some point, engineering a single solution to attempt to avoid the eventual name collision is a lot of effort with very little payoff and a lot of potential downside. As has been pointed out elsewhere, most of the alternatives require the user to know quite a lot about the person whom they are emailing.

Instead, email addresses can be more pragmatic. Using a basic format like firstname.lastname and simply adding a number to the email address is a sufficient solution to the problem. In this case, instead of asking users to rely on their memory, we can instead engineer our solution to allow users to recognize the correct recipient who they want to email. For senders who work for the same company, they can use the corporate directory to look up the right email address. Usage of the corporate directory allows for mistakes, as well as more ambiguity, in what the would-be email sender remembers about their intended recipient. For example, people often remember my name, but often spell it wrong. My corporate directory has both my correct spelling and the oft-used but lesser Nadine spelling associated with my name. My entry in the corporate directory also allows people to find me using other metadata, without having to determine which (if any) of that metadata is part of my email address. For users who are not in the company, they can either look at the individual's business card or hit reply on the email that the individual sent them. They can, of course, try to reverse-engineer it, but then they can also look to a good search engine instead of a corporate directory.

In either case, we are designing a solution that meets the sender's real goal. The sender does not care about the format of the email address. The sender only wants to contact the intended recipient. The communication is the goal. The mechanics of the communication, including the format of the email address, are not the goal.

Using a firstname.lastname (or similar) format still has some ways to minimize the likelihood of name collision. For example, supporting alternate names can help. If Samuel or Samantha goes by Sam, they could be assigned Sam.surname instead.

It's also worthwhile to note that any given naming scheme will eventually fail. For example, I worked with someone who was born with a first name and nothing more. They didn't have a surname, and they certainly didn't want to take on a surname because our employer forced them to.

In other words, design a solution that works most of the time for the real goals of your users, and be prepared for the edge cases that will inevitably occur.

Answer 2

MIDDLE NAMES COULD BE A BAD WAY TO FIND A SOLUTION

Ok, we are looking for a global solution, rather than a region specific one. Hence, lets understand that not everyone has a middle name. I don't. And I was faced with this problem of same names in an organization, at my last company. One guy, named Amit Jain was already working as a developer, and had the emailId amit.jain@ so when i joined, I was 'awarded', amit.j@ - no logic, but what the admin thought was a quick fix! Anyways, I did give it some thought, and here are some opinions.

1) Department suffixes could be a solution that could work for some organizations. So for example, you can have, amitjain_ux@ and amitjain_dev@ and that format, helps two ways. One, in giving a quick insight into the person's role, and secondly, helps in avoiding conflicts (in most cases).

2) I have suggested department/team in suffix for a good reason. Assume, you want to send an email and start adding the email id in 'to' field - You start by name (typical user behavior), and auto complete gives you two options (with two suffixes). That makes it easier for you to pick the desired one.

3) In extreme cases, where there are two people with same name in same team - one could use, amitjain01_ux@ and amitjain02_ux@ perhaps!

Answer 3

I don't know if this is "the best" method to separate duplicate first and last names. But we need to reason with ourselves and our users what first name + last name represent. They are identifiers to a person, which means that you need to add another identifier to the email address. This identifier needs to be something that we can connect to the person we try to reach.

1. Your fist suggestion address that with its middle name initials. The problem is we often don't know our closest colleagues middle names. And especially not someone we haven't met in person. So this won't work well.

2. Your second suggestion (a random number) can't be used as an identifier either - wrong again.

3. Your third suggestion using initials + last name doesn''t do any good to us either. See point 1.

4. Using a random string. I'm not going to comment on that ;)

So all these fails. But there are things we do know about the user that doesn't often change. A location is usually a fixed parameter that will stand the test of time. Much better than a job title which eventually will change since larger companies have the notorious cycle of re-organizing once every two to three years. That means job titles change as well which will make e-mail address identifier fail again. But location is something that often is the same. It's not all that persistent, but it is the best we have.

So this leads me to the conclusion of using [email protected].

I deliberately didn't tell what location can be since this is comapny specific. You can use different sites in the same city, different buildings in the same site or different cities depending on the company location.

Answer 4

tl;dr

---

• [email protected] is best for users.
• [email protected] provides much more variation and is easy to remember.
• [email protected] buys you a lot more variation for a trade in memorability.

---

Any meaningful name variation can be added: jimmy or jj in place of james.
And complexity can be added progressively to avoid unnecessary fuss when possible.

The most important feature of this system:
The email ID is driven by personal info, not system codes.

Uniqueness isn't always easy to remember.

---

Learning names is a good thing.

Of all the possible solutions, I think real names are the best form of inter-personal organizational identification (which is essentially what an email address does for us). The first thing you learn about a person is their name and you probably shouldn't be contacting them if you don't know it. So we can agree real names are good, right?

On the other hand, a number (like a GUID) is far more programmatically scalable. You will never run out of IDs and it's not connected to any potentially transient facts about the person. But it's a useless thing for people to remember about other people.

What about a short system-generated number appended to a name? That's still something users don't need to know about another user. Maybe their office phone extension or mobile number? No one dials phone numbers these days!

So how do we allow people to use each others' names without running out of options?

Let's look at the conditions to be satisfied.

1. Reasonably unique

If you're a mega corporation, this is a challenge. Names alone may not provide enough unique variations.

I've seen companies try to get away with f.m.last, but that doesn't really save humans any memory load and you're much more likely to run out of unique options.

For the average organization, first.m.last is pretty solid. There are a lot of variations possible (even likely) in those three pieces of data. It is, however, possible to run out of such IDs. Let's come back to that after we've considered our other requirements.

2. Reliably constant

Names, while not set in stone, are relatively constant. And when they do change, the members of an organization should probably know that and learn it.

System generated numbers are extremely constant, but we already addressed why that's not worth the trouble to learn.

Location (as Benny mentioned) is worth considering, but an org might move or expand or consolidate offices and they may favor or at least dabble with a remote workforce. With those factors in mind, location can be difficult to rely on.

A name seems constant enough for these purposes.

3. Human learnable

A name isn't the easiest thing for everyone to learn, but it's a piece of data you should learn if you're going to communicate with another person. And within the set of names that are likely to occur, there are a lot of familiar patterns that make them more learnable than many other unique pieces of data.

A uniqueness safeguard

All in all, I feel pretty good about first.m.last ... but it wouldn't hurt to have a fallback.

I've seen companies append an index like first.m.last.2, but that's kind of demeaning, isn't it? And it's not particularly meaningful that a user is the second with that name.

Consider the condition under which you run out of options:

Someone already working in the org has claimed an ID for themselves.
A newbie comes on-board with the same first.m.last.
The newbie is not ready to change their name for the company's sake.

What's a hard piece of data that is likely to differentiate them in the system and among their co-workers?

An option I've considered (but never implemented) is the hiring year: first.m.last.2015. You might have two people with the same name, but it's highly unlikely they were hired in the same year. And it's a number that's memorable and not a bad thing to learn about a co-worker. "Oh yeah, you just started last year ..." or "I forgot how long you've been here ...".

If you buy that logic, you now have to ask if the year should be appended to everyone's email. I find that option obnoxious, although more consistent and equitable. Personally, I'd take the risk and leave it off until I needed it.

This reply got way out of hand on me.

Answer 5

Let the (new) user decide.

A new member joins your organization or company. The HR department has already done the usual paperwork. That means your IT now has a record (under an arbitrary unique static identifier key) for the person which includes all their names, birthdate etc. A semi-automated process sets up preliminary user accounts and permissions. When they log in for the first time, maybe in the presence of a supervisor or administrator, they are prompted (probably among other things) to choose an email address based upon their name, and a friendly identifier to go with it – the latter may be changed easily later on. Several presets are presented based upon the available data. There is no way to get an arbitrary string as one’s local-part – nick names have to be registered within the HR database and will appear in the directory.

Example

When Dr. John Jay “Joe” Doe III. joined, he got presented with (some of) these options:

• john.doe@ – This is most likely the one that is already taken by someone with a similar name. Otherwise it’s the pre-selected default.
• doe.john@ – He may have a Hungarian ancestors, but this order likely feels alien to him as a native Murkin.
• john.doe.3@ = john.doe3@ – The name has been a family tradition since his beloved grandfather passed away, so the seemingly arbitrary number isn’t actually alien to him.
• j.doe@ – In his case it isn’t obvious whether the initial originates form the first or middle name. It’s quite likely that it will clash with someone else, unless the family name is really uncommon.
• j.j.doe@ = jj.doe@ – Initials can become a nick name.
• jay.doe@ – John was his father, everybody in the family always called him by his middle name anyway.
• john.jay@ – The middle name is really another surname from the other parent or from a spouse.
• john.j.doe@ – It’s okay to have a middle name, but let’s keep some secrecy about it.
• john.jay.doe@ – His middle name is important to him, and not embarrassing at all.
  • john-jay.doe@ – He’s already known as “John Jay” since his middle name is actually a second given name.
  • john.jay-doe@ – His parents gave him both their family names or he added the one of his spouse Jane upon marriage.
• joe.doe@ – Since college he’s been called Joe, because there were too many Johns already. Actually it started in karate class as “doejoe”.
• john."joe".doe@ – Yes, this is a legal local-part, but one will run into problems with it sooner or later.
• "joe"@ – This is valid, too, and not (necessarily) equivalent to joe@, which senders won‘t know and would get wrong all the time.

The system also knows that our John Doe was born on 21 December 1991 in Smallville, Texas, but for privacy reasons none of that may be used to build the email address, although people commonly exploit such data in freely chosen user names, including email accounts and addresses (at G-Mail, Yahoo, Hotmail, Facebook etc.pp.).

When an employee legally changes their name, e.g. when they marry, divorce, reassign their gender or get adopted, they may select another default address. The old one becomes an explicit alias and is not ever reassigned to someone else.

Technical notes

The local-part (left side of the at sign) should be treated by most email systems like this:

• There is a canonic single-case ASCII-only variant which may have explicit and implicit aliases. Some implicit aliases are:
  • Another string that results in the same local-part after all single period characters . have been stripped from both. (Consecutive dots invalidate an email address.)
  • Another string that results in the same local-part after any valid case folding. That means the local-part is case-insensitive.
  • A string with non-ASCII characters that results in the same local-part after any transliteration scheme.
  • A string with non-ASCII characters that may look like the same local-part with normal glyph variants.
• All letters in the local-part must be from a single script. That does not include punctuation characters.

Answer 6

I have witnessed this problem when working for a previous employer. Things people have said here about having a department suffix wouldn't have worked there as there were two people with the same name in the department I worked in, and another person with the same name as them in a different department.

They got around this by doing: [email protected] for the one who had been there the longest, and then [email protected], where NUMBER started from 2 and incremented each time someone new started with the same name.

Maybe not ideal, but people (the users and customers) didn't seem to mind.

Answer 7

Having worked at a large company for almost 30 years, that had been acquired by another company, and have needed email addresses for me on client's network, and having a common first and last name, I've been a victim of this.

I've been [email protected], [email protected], a co-worker had [email protected], and an email account for me at a client was [email protected] -- and for those 30 years, I occasionally get an email for one of the Mark Stewarts in the company a few times a year (usually 2 or 3 other Marks at any point in time) that I just reply-all and carbon-copy the 2 or 3 other Marks, saying, "I think you have the wrong Mark Stewart, I work in xxx."

In most cases in my career, [email protected] omitting the middle initial if not needed, then the second person with same first/last name gets [email protected]. So this isn't really an answer, but rather a report of my experiences. And as far as an international organization goes, there are some employees that don't have a first or middle name, just a last name, or a certain last name in some regions (Ng comes to mind) is used by a huge percentage of the population of the region. I guess my only real answer is avoid random number suffixes, and avoid partial first/partial last name combinations, for ease of external and internal users both. Also personal opinion is "department" is usually too general or too subjective to be of much use.

Answer 8

You need to include the aspect of history. Let's say the 2 persons with the same name are called John Appleseed.

• At first, there is only 1 John Appleseed working at company.com. His e-mail is [email protected].
• But then, a second John Appleseed joins company.com. It is only at this moment that the ambiguity needs to be solved.
• At this moment, the first John.Appleseed needs to lose his e-mail address. Sending an e-mail to [email protected] will result in a robot responding:

Dear sir, madame,

There are 2 persons named John Appleseed working at company.com so we cannot determine for which one your message was intended. The first John Appleseed who joined our company in 1989 works at sales. His e-mail address is [email protected]. More recently another John Appleseed joined our forces, he works at marketing. You can reach him by sending your message to [email protected].

The decision to split up based on location, function, division,... depend entirely on the structure of the company. Also mind the possibility that both John appleseeds can work at sales.