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

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

    [email protected] (kidding). In my experience, the majority of these kinds of errors don't have to do with the email address, rather they select the wrong entry in the company-wide directory.

    Not sure 'taxonomy' is the right term here. I think perhaps you mean 'format'?

    What about [email protected] (you would have to do that for everyone though I guess) or [email protected]. In any case confusions and mixups will happen for sure.

    The format my college used was the first 3 letters of the last name followed by the first 3 letters of the first name, with the middle initial added at the end in case of collisions. e.g. Barack Obama would be [email protected] or [email protected]

    examples I've seen usually went with the standard of adding a number to the end of their name then distinguishing them only in the directory by adding their office to the end of their name there....what happens if there are two with the same name in the same office and department isn't something I've encountered.

    @Trilarion this doesn't fail nicely if people move divisions (I've seen one case where John.Smith.Marketing meant the John.Smith who had left Marketing, while John.Smith was the one who had moved to marketing). You have to either change email addresses on a move (a pain for their customers, and no panacea) or have errors (confusing for new contacts).

    @ChrisH You are right. Email adresses should stay constant over the time being in the company and also have meaning and be easily readable. So I woud go for [email protected] where XXX is an easy to remember differentiator for people with the same name (a number, ...).

    What problem are you trying to solve? Usually people know the address of the person they want to mail to, whether it is physical or electronic.

    @Assimiz have you never sent an email to the wrong person because they had a similar email to your intended recipient? working in a large corporate, that has happened a few times.

  • nadyne

    nadyne Correct answer

    6 years ago

    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.

    "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." +1

    "The sender does not care about the format of the email address" < This is a big assumption. I've worked with many orgs where users routinely guess the address (primarily when on their phone or non-primary device). They do this because the system is easy to remember.

    It’s not just about the sender’s UX, though. It sucks always being addressed as `[email protected]` – also, does that mean there’s `[email protected]`, too, or just `[email protected]`?

    @Crissov - It sucks to have an email address that I didn't select. Left to my own devices, I would never select [email protected] It's my experience that, given no option or input into the email address, most people simply accept whatever (reasonable) email address is assigned to them. With that in mind, I'd rather design for the 95% case as opposed to over-designing for edge cases.

    @plainclothes - I agree that a given format allows senders to guess the address of their intended recipient. The proposed design allows this to happen for the vast majority of cases. I don't necessarily agree that senders actually prefer to do so, or have a need to do so. Just because they *can* doesn't mean they *prefer* it.

    “It sucks to have an email address that I didn't select.” True dat! In a corporation with about 100’000 personal addresses, I encountered a one-time setup dialog that offered several choices to construct one’s address, the default being `first-given.first-family`, but with presets like `family.given` and lots of stranger combinations of the available fields. The system already knew all personal data, of course. Admin action was required for completely arbitrary addresses. A problem, still, is that people’s names may change, e.g. upon marriage in many countries (in different ways).

    I guess if someone is in a situation where there is someone else with the same name in the same company then they most likely have a very common name and are used to having to deal with the problem of there being multiple John Smiths, being John Smith 2, etc....

    I worked with two people who not only had the exact same name (first, middle, and last), but also shared a birthday. As we all know, names are not unique. A convention for email addresses that is based on a name is eventually going to fail because of this. Attempting to force uniqueness by adding complexity to the convention reduces the usability for everyone, and will still ultimately fail.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM