Quel est le meilleur format d'adresse e-mail pour les personnes portant le même prénom et le même nom?

Question

Plus l'organisation est grande (par exemple une entreprise ou un établissement d'enseignement), plus il y a de chances qu'il y ait deux personnes du même nom.

En règle générale, les adresses e-mail sont formatées firstname.lastname@company.com

Quel devrait être le format de l'adresse e-mail pour minimiser le risque d'envoyer un e-mail à la mauvaise personne lorsque vous avez deux personnes du même nom?

J'ai vu:

firstname.middleinitial(s).lastname@company.com firstname.number.lastname@company.com initials.lastname@company.com randomstring@company.com

Edit: l'autre considération est que le format devrait fonctionner pour les personnes à l'intérieur et à l'extérieur de l'entreprise.

Les personnes travaillant dans la même entreprise ont accès à l'annuaire e-mail et peuvent connaître l'emplacement ou le service de la personne, mais pas quelqu'un de l'extérieur.

Edit 2: c'est également un problème courant pour les domaines qui parcourent régulièrement les utilisateurs, par exemple les universités/collèges où un utilisateur typique ne peut utiliser l'e-mail que pendant 3 ou 4 ans, puis diplômé/partir. Si vous choisissez de ne pas recycler les e-mails, il y a un bassin potentiellement illimité de personnes avec des noms similaires rejoignant/quittant chaque année.

nadyne · Accepted Answer

Votre question semble supposer que les expéditeurs d'e-mails doivent soit se souvenir de l'adresse e-mail du destinataire prévu, soit devoir effectuer une rétro-ingénierie précise de l'adresse e-mail du destinataire prévu. Vous semblez également supposer que les adresses e-mail doivent être sous une forme unique à l'échelle de l'entreprise.

Je pense que les réponses sur-conçoivent une solution car elles reposent sur l'expéditeur connaissant les informations sur le destinataire prévu et le format des adresses e-mail. Bien que vous soyez pratiquement assuré d'avoir une collision de noms à un moment donné, concevoir une solution unique pour tenter d'éviter la collision de noms éventuelle demande beaucoup d'efforts avec très peu de bénéfices et beaucoup d'inconvénients potentiels. Comme cela a été souligné ailleurs, la plupart des alternatives nécessitent que l'utilisateur en sache beaucoup sur la personne à qui il envoie un e-mail.

Au lieu de cela, les adresses e-mail peuvent être plus pragmatiques. Utiliser un format de base tel que prénom.nom et simplement ajouter un numéro à l'adresse e-mail est une solution suffisante au problème. Dans ce cas, au lieu de demander aux utilisateurs de s'appuyer sur leur mémoire, nous pouvons plutôt concevoir notre solution pour permettre aux utilisateurs de reconnaître le bon destinataire à qui ils souhaitent envoyer un e-mail. Pour les expéditeurs qui travaillent pour la même entreprise, ils peuvent utiliser l'annuaire d'entreprise pour rechercher la bonne adresse e-mail. L'utilisation du répertoire d'entreprise permet des erreurs, ainsi qu'une ambiguïté accrue, dans ce que l'expéditeur potentiel de l'e-mail se souvient de son destinataire. Par exemple, les gens se souviennent souvent de mon nom, mais l'orthographient souvent mal. Mon annuaire d'entreprise a à la fois mon orthographe correcte et l'orthographe Nadine souvent utilisée mais moindre associée à mon nom. Mon entrée dans l'annuaire d'entreprise permet également aux gens de me trouver à l'aide d'autres métadonnées, sans avoir à déterminer laquelle (le cas échéant) de ces métadonnées fait partie de mon adresse e-mail. Pour les utilisateurs qui ne sont pas dans l'entreprise, ils peuvent soit regarder la carte de visite de l'individu, soit répondre sur l'e-mail que l'individu leur a envoyé. Ils peuvent, bien sûr, essayer de procéder à une rétro-ingénierie, mais ils peuvent également rechercher un bon moteur de recherche au lieu d'un répertoire d'entreprise.

Dans les deux cas, nous concevons une solution qui répond au véritable objectif de l'expéditeur. L'expéditeur ne se soucie pas du format de l'adresse e-mail. L'expéditeur souhaite uniquement contacter le destinataire prévu. La communication est le but. Les mécanismes de la communication, y compris le format de l'adresse e-mail, ne sont pas le but.

L'utilisation d'un format firstname.lastname (ou similaire) permet toujours de minimiser la probabilité de collision de noms. Par exemple, la prise en charge d'autres noms peut être utile. Si Samuel ou Samantha passe par Sam, on pourrait leur attribuer Sam.

Il convient également de noter que tout schéma de dénomination donné échouera éventuellement. Par exemple, j'ai travaillé avec quelqu'un qui est né avec un prénom et rien de plus. Ils n'avaient pas de nom de famille et ils ne voulaient certainement pas prendre un nom de famille parce que notre employeur les y obligeait.

En d'autres termes, concevez une solution qui fonctionne la plupart du temps pour les objectifs réels de vos utilisateurs et soyez prêt pour les cas Edge qui se produiront inévitablement.

Amit Jain · Answer

LES NOMS MOYENS POURRAIENT ÊTRE UNE MAUVAISE FAÇON DE TROUVER UNE SOLUTION

Ok, nous recherchons une solution globale, plutôt qu'une solution spécifique à une région. Par conséquent, permet de comprendre que tout le monde n'a pas de deuxième prénom. Je ne. Et j'étais confronté à ce problème des mêmes noms dans une organisation, dans ma dernière entreprise. Un gars, nommé Amit Jain, travaillait déjà en tant que développeur et avait l'e-mailId amit.jain @ donc quand j'ai rejoint, j'ai été "récompensé", amit.j @ - pas de logique, mais ce que l'administrateur a pensé était une solution rapide! Quoi qu'il en soit, j'y ai réfléchi, et voici quelques opinions.

1) suffixes de département pourrait être une solution qui pourrait fonctionner pour certaines organisations. Ainsi, par exemple, vous pouvez avoir, amitjain_ux @ et amitjain_dev @ et ce format, aide de deux manières. Premièrement, en donnant un aperçu rapide du rôle de la personne, et deuxièmement, aide à éviter les conflits (dans la plupart des cas).

2) J'ai suggéré le département/l'équipe en suffixe pour une bonne raison. Supposons que vous souhaitiez envoyer un e-mail et commencer à ajouter l'identifiant de l'e-mail dans le champ 'à' - Vous commencez par le nom (comportement typique de l'utilisateur) et la saisie semi-automatique vous donne deux options (avec deux suffixes). Cela vous permet de choisir plus facilement celui que vous souhaitez.

3) Dans les cas extrêmes, où il y a deux personnes du même nom dans la même équipe - on pourrait utiliser, amitjain01_ux @ et amitjain02_ux @ peut-être!

Benny Skogberg · Answer

Je ne sais pas si c'est "la meilleure" méthode pour séparer les prénoms et les noms en double. Mais nous devons raisonner avec nous-mêmes et nos utilisateurs ce que le prénom + le nom de famille représentent. Ce sont des identifiants pour une personne, ce qui signifie que vous devez ajouter un autre identifiant à l'adresse e-mail. Cet identifiant doit être quelque chose que nous pouvons connecter à la personne que nous essayons de joindre.

Votre première suggestion adresse cela avec ses initiales de deuxième prénom. Le problème est que nous ne connaissons souvent pas les prénoms de nos collègues les plus proches. Et surtout pas quelqu'un que nous n'avons pas rencontré en personne. Cela ne fonctionnera donc pas bien.
Votre deuxième suggestion (un nombre aléatoire) ne peut pas non plus être utilisée comme identifiant - elle est de nouveau erronée.
Votre troisième suggestion en utilisant les initiales + le nom de famille ne nous fait aucun bien non plus. Voir point 1.
Utilisation d'une chaîne aléatoire. Je ne vais pas commenter cela;)

Donc tout cela échoue. Mais il y a des choses que nous savons sur l'utilisateur qui ne changent pas souvent. Un emplacement est généralement un paramètre fixe qui résistera à l'épreuve du temps. Beaucoup mieux qu'un titre de poste qui changera finalement puisque les grandes entreprises ont le cycle notoire de réorganisation une fois tous les deux à trois ans. Cela signifie que les titres d'emploi changent également, ce qui entraînera à nouveau l'échec de l'identifiant de l'adresse e-mail. Mais l'emplacement est quelque chose qui est souvent le même. Ce n'est pas si persistant que ça, mais c'est le meilleur que nous ayons.

Cela m'amène donc à la conclusion d'utiliser firstname.lastname@location.company.com.

Je n'ai délibérément pas dit quel emplacement peut être car cela est spécifique à une entreprise. Vous pouvez utiliser différents sites dans la même ville, différents bâtiments sur le même site ou différentes villes selon l'emplacement de l'entreprise.

plainclothes · Answer

tl; dr

first@org.com est le meilleur pour les utilisateurs.

first.last@org.com offre beaucoup plus de variations et est facile à retenir.

first.m.last@org.com vous offre beaucoup plus de variations pour un échange de mémorisation.

Toute variation de nom significative peut être ajoutée: jimmy ou jj à la place de james =.
Et la complexité peut être ajoutée progressivement pour éviter les tracas inutiles lorsque cela est possible.

La caractéristique la plus importante de ce système:
L'ID e-mail est généré par des informations personnelles, pas par des codes système.

L'unicité n'est pas toujours facile à retenir.

Apprendre des noms est une bonne chose.

De toutes les solutions possibles, je pense que les vrais noms sont la meilleure forme d'identification organisationnelle interpersonnelle (ce qui est essentiellement ce qu'une adresse e-mail fait pour nous). La première chose que vous apprenez sur une personne est son nom et vous ne devriez probablement pas la contacter si vous ne le connaissez pas. Nous pouvons donc convenir que les vrais noms sont bons, non?

D'un autre côté, un nombre (comme un GUID) est beaucoup plus évolutif par programmation. Vous ne manquerez jamais d'identifiants et ce n'est lié à aucun fait potentiellement transitoire sur la personne. Mais il est inutile que les gens se souviennent des autres.

Qu'en est-il d'un petit numéro généré par le système ajouté à un nom? C'est toujours quelque chose que les utilisateurs n'ont pas besoin de savoir sur un autre utilisateur. Peut-être leur extension de téléphone de bureau ou numéro de téléphone portable? Personne ne compose de numéros de téléphone ces jours-ci!

Alors, comment pouvons-nous permettre aux gens d'utiliser les noms des autres sans manquer d'options?

Regardons les conditions à remplir.

1. Raisonnablement unique

Si vous êtes une méga entreprise, c'est un défi. Les noms seuls peuvent ne pas fournir suffisamment de variations uniques.

J'ai vu des entreprises essayer de s'en sortir avec f.m.last, mais cela n'économise pas vraiment les humains de la charge de mémoire et vous êtes beaucoup plus susceptible de manquer d'options uniques.

Pour l'organisation moyenne, first.m.last est assez solide. Il existe de nombreuses variations possibles (voire probables) dans ces trois éléments de données. Il est cependant possible de manquer de tels identifiants. Revenons à cela après avoir considéré nos autres exigences.

2. Constamment fiable

Les noms, bien qu'ils ne soient pas gravés dans la pierre, sont relativement constants. Et lorsqu'ils changent, les membres d'une organisation devraient probablement le savoir et l'apprendre.

Les nombres générés par le système sont extrêmement constants, mais nous avons déjà expliqué pourquoi cela ne valait pas la peine d'apprendre.

L'emplacement (comme Benny l'a mentionné) mérite d'être pris en considération, mais une organisation peut déplacer ou agrandir ou consolider des bureaux et elle peut favoriser ou au moins essayer une main-d'œuvre distante. Compte tenu de ces facteurs, l'emplacement peut être difficile à utiliser.

Un nom semble constant assez à ces fins.

3. Apprentissage humain

Un nom n'est pas la chose la plus facile à apprendre pour tout le monde, mais c'est une donnée que vous devez apprendre si vous allez communiquer avec une autre personne . Et dans l'ensemble des noms susceptibles de se produire, il existe de nombreux schémas familiers qui les rendent plus faciles à apprendre que de nombreux autres éléments de données uniques.

Une garantie d'unicité

Dans l'ensemble, je me sens plutôt bien first.m.last ... mais ça ne ferait pas de mal d'avoir un repli.

J'ai vu des entreprises ajouter un indice comme first.m.last.2, mais c'est un peu humiliant, non? Et ce n'est pas particulièrement significatif qu'un utilisateur soit le deuxième avec ce nom.

Considérez la condition dans laquelle vous manquez d'options:

Quelqu'un qui travaille déjà dans l'organisation a réclamé lui-même un identifiant.
Un débutant vient à bord avec le même first.m.last.
Le débutant n'est pas prêt à changer son nom pour le bien de l'entreprise.

Qu'est-ce qu'une donnée dure qui est susceptible de les différencier dans le système et parmi leurs collègues?

Une option que j'ai envisagée (mais jamais mise en œuvre) est l'année d'embauche: first.m.last.2015. Vous pourriez avoir deux personnes du même nom, mais il est très peu probable qu'elles aient été embauchées la même année. Et c'est un chiffre mémorable et pas une mauvaise chose à apprendre sur un collègue. "Oh ouais, tu viens de commencer l'année dernière ..." ou "J'ai oublié depuis combien de temps tu es ici ...".

Si vous achetez cette logique, vous devez maintenant demander si l'année doit être ajoutée au courrier électronique de chacun. Je trouve cette option désagréable, bien que plus cohérente et équitable. Personnellement, je prendrais le risque et le laisserais jusqu'à ce que j'en ai besoin.

Cette réponse m'a échappé.

Crissov · Answer

Laissez le (nouvel) utilisateur décider.

Un nouveau membre rejoint votre organisation ou entreprise. Le service des ressources humaines a déjà effectué les formalités administratives habituelles. Cela signifie que votre service informatique dispose désormais d'un enregistrement (sous une clé d'identifiant statique unique arbitraire) pour la personne qui inclut tous ses noms, sa date de naissance, etc. Un processus semi-automatisé configure les comptes utilisateur et les autorisations préliminaires. Quand ils se connectent pour la première fois, peut-être en présence d'un superviseur ou d'un administrateur, ils sont invités (probablement entre autres) à choisir une adresse e-mail en fonction de leur nom et un identifiant convivial pour l'accompagner - ce dernier peut être changé facilement plus tard. Plusieurs préréglages sont présentés en fonction des données disponibles. Il n’existe aucun moyen d’obtenir une chaîne arbitraire en tant que partie locale - les pseudonymes doivent être enregistrés dans la base de données HR et apparaîtront dans le répertoire.

Exemple

Lorsque le Dr John Jay "Joe" Doe III. rejoint, il a été présenté avec (certaines) ces options:

john.doe@ - C'est probablement celui qui est déjà pris par quelqu'un avec un nom similaire. Sinon, c'est la valeur par défaut présélectionnée.
doe.john@ - Il a peut-être un ancêtre hongrois, mais cet ordre lui semble probablement étranger en tant que natif de Murkin.
john.doe.3@ = john.doe3@ - Le nom est une tradition familiale depuis le décès de son grand-père bien-aimé, donc le nombre apparemment arbitraire ne lui est pas vraiment étranger.
j.doe@ - Dans son cas, il n'est pas évident que les initiales proviennent du prénom ou du deuxième prénom. Il est fort probable qu'il se heurte à quelqu'un d'autre, à moins que le nom de famille ne soit vraiment rare.
j.j.doe@ = jj.doe@ - Les initiales peuvent devenir un surnom.
jay.doe@ - John était son père, tout le monde dans la famille l'appelait toujours par son deuxième prénom de toute façon.
john.jay@ - Le deuxième prénom est en réalité un autre nom de famille de l'autre parent ou d'un conjoint.
john.j.doe@ - C'est bien d'avoir un deuxième prénom, mais gardons le secret à ce sujet.
john.jay.doe@ - Son deuxième prénom est important pour lui, et pas du tout gênant.
- john-jay.doe@ - Il est déjà connu sous le nom de "John Jay" car son deuxième prénom est en fait un deuxième prénom.
- john.jay-doe@ - Ses parents lui ont donné leurs deux noms de famille ou il a ajouté celui de son épouse Jane lors du mariage.
joe.doe@ - Depuis l'université, il s'appelle Joe, car il y avait déjà trop de Johns. En fait, cela a commencé dans la classe de karaté en tant que "doejoe".
john."joe".doe@ - Oui, c'est une partie locale légale, mais on va avoir des problèmes avec elle tôt ou tard.
"joe"@ - Ceci est également valide et n'est pas (nécessairement) équivalent à joe@, que les expéditeurs ne connaissent pas et qui se tromperaient tout le temps.

Le système sait également que notre John Doe est né le 21 décembre 1991 à Smallville, au Texas, mais pour des raisons de confidentialité, rien de tout cela ne peut être utilisé pour créer l'adresse e-mail, bien que les gens exploitent généralement ces données dans des noms d'utilisateur librement choisis, y compris des comptes de messagerie et adresses (chez G-Mail, Yahoo, Hotmail, Facebook etc.pp.).

Lorsqu'un employé change légalement de nom, par ex. lorsqu'ils se marient, divorcent, réattribuent leur sexe ou sont adoptés, ils peuvent choisir une autre adresse par défaut. L'ancien devient un alias explicite et n'est jamais réaffecté à quelqu'un d'autre.

Notes techniques

La partie locale (côté gauche du signe at) devrait être traitée par la plupart des systèmes de messagerie comme celui-ci:

Il existe une variante canonique à cas unique ASCII uniquement qui peut avoir des alias explicites et implicites. Certains alias implicites sont:
- Une autre chaîne qui se traduit par la même partie locale après tous les caractères de période unique . ont été supprimés des deux. (Les points consécutifs invalident une adresse e-mail.)
- Une autre chaîne qui se traduit par la même partie locale après tout pliage de cas valide. Cela signifie que la partie locale est insensible à la casse.
- Une chaîne avec des caractères non ASCII qui se traduit par la même partie locale après tout schéma de translittération.
- Une chaîne avec des caractères non ASCII qui peut ressembler à la même partie locale avec des variantes de glyphe normales.
Toutes les lettres de la partie locale doivent provenir d'un seul script. Cela n'inclut pas les caractères de ponctuation.

gabe3886 · Answer

J'ai été témoin de ce problème lorsque je travaillais pour un ancien employeur. Les choses que les gens ont dit ici sur le fait d'avoir un suffixe de département n'auraient pas fonctionné là-bas, car il y avait deux personnes du même nom dans le département dans lequel je travaillais et une autre personne du même nom qu'eux dans un département différent.

Ils ont contourné cela en faisant: firstname.surname@company.com pour celui qui était là depuis le plus longtemps, puis firstperson.surnameNUMBER@company.com, où NUMBER a commencé à partir de 2 et incrémenté chaque fois qu'une nouvelle personne a commencé avec le même nom .

Peut-être pas idéal, mais les gens (les utilisateurs et les clients) ne semblaient pas s'en soucier.

Mark Stewart · Answer

Ayant travaillé dans une grande entreprise pendant près de 30 ans, qui avait été acquise par une autre entreprise, et avait besoin d'adresses e-mail pour moi sur le réseau du client, et ayant un prénom et un nom communs, j'en ai été victime.

J'ai été mark.stewart@example.com, mark.x.stewart@example.com, un collègue avait mark.stewart2@example.com, et un compte de messagerie pour moi chez un client était mstew599@example.net - et pendant ces 30 années, je reçois occasionnellement un e-mail pour l'un des Mark Stewarts de l'entreprise quelques fois par an (généralement 2 ou 3 autres marques à tout moment) que je viens de répondre à tous et carbone -copiez les 2 ou 3 autres marques, en disant: "Je pense que vous avez le mauvais Mark Stewart, je travaille en xxx."

Dans la plupart des cas dans ma carrière, first.last@example.com en omettant l'initiale du milieu s'il n'est pas nécessaire, la deuxième personne portant le même prénom/nom de famille obtient first.middle.last@example.com. Ce n'est donc pas vraiment une réponse, mais plutôt un rapport de mes expériences. Et en ce qui concerne une organisation internationale, il y a des employés qui n'ont pas de prénom ou de deuxième prénom, juste un nom de famille, ou un certain nom de famille dans certaines régions (Ng me vient à l'esprit) est utilisé par un pourcentage énorme de la population de la région. Je suppose que ma seule vraie réponse est d'éviter les suffixes de nombres aléatoires et d'éviter les combinaisons de prénom/nom de famille partielles, pour la facilité des utilisateurs externes et internes. L'opinion personnelle est également que le "département" est généralement trop général ou trop subjectif pour être d'une grande utilité.