it-swarm.com.de

Was ist das beste E-Mail-Adressformat für Personen mit demselben Vor- und Nachnamen?

Je größer die Organisation (z. B. ein Unternehmen oder eine Bildungseinrichtung) ist, desto wahrscheinlicher ist es, dass zwei Personen denselben Namen haben.

In der Regel werden E-Mail-Adressen formatiert [email protected]

Wie sollte das E-Mail-Adressformat sein, um das Risiko zu minimieren, dass eine falsche Person per E-Mail benachrichtigt wird, wenn Sie zwei Personen mit demselben Namen haben?

Ich habe gesehen:

firstname.middleinitial(s)[email protected]

[email protected]

[email protected]

[email protected]

Bearbeiten : Die andere Überlegung ist, dass das Format für Personen innerhalb und außerhalb des Unternehmens funktionieren sollte.

Personen, die in derselben Firma arbeiten, haben Zugriff auf das E-Mail-Verzeichnis und kennen möglicherweise den Standort oder die Abteilung der Person, jemand außerhalb jedoch nicht.

Edit 2 : Dies ist auch ein häufiges Problem für Domänen, die regelmäßig durch Benutzer wechseln, z. B. Universitäten/Hochschulen, an denen ein typischer Benutzer die E-Mail möglicherweise nur 3 oder 4 Jahre lang verwendet und dann seinen Abschluss macht. verlassen. Wenn Sie sich dafür entscheiden, E-Mails nicht zu recyceln, gibt es einen potenziell unbegrenzten Pool von Personen mit ähnlichen Namen, die jedes Jahr beitreten/verlassen.

25
Midas

Ihre Frage scheint davon auszugehen, dass sich E-Mail-Absender entweder die E-Mail-Adresse des beabsichtigten Empfängers merken müssen oder die E-Mail-Adresse des beabsichtigten Empfängers genau zurückentwickeln müssen. Sie scheinen auch davon auszugehen, dass E-Mail-Adressen unternehmensweit eine einzige Form haben müssen.

Ich denke, dass die Antworten eine Lösung überentwickeln, weil sie darauf beruhen, dass der Absender Informationen sowohl über den beabsichtigten Empfänger als auch über das Format der E-Mail-Adressen kennt. Während Sie praktisch garantiert irgendwann eine Namenskollision haben, ist die Entwicklung einer einzigen Lösung, um die eventuelle Namenskollision zu vermeiden, ein großer Aufwand mit sehr geringem Gewinn und viel potenziellem Nachteil. Wie bereits an anderer Stelle erwähnt, muss der Benutzer bei den meisten Alternativen viel über die Person wissen, an die er eine E-Mail sendet.

Stattdessen können E-Mail-Adressen pragmatischer sein. Die Verwendung eines Grundformats wie Vorname.Nachname und das einfache Hinzufügen einer Nummer zur E-Mail-Adresse ist eine ausreichende Lösung für das Problem. In diesem Fall können wir unsere Lösung so gestalten, dass Benutzer den richtigen Empfänger erkennen, den sie per E-Mail versenden möchten, anstatt die Benutzer zu bitten, sich auf ihren Speicher zu verlassen. Absender, die für dasselbe Unternehmen arbeiten, können im Unternehmensverzeichnis nach der richtigen E-Mail-Adresse suchen. Die Verwendung des Unternehmensverzeichnisses führt zu Fehlern und mehr Unklarheiten in Bezug darauf, woran sich der potenzielle E-Mail-Absender über den beabsichtigten Empfänger erinnert. Zum Beispiel erinnern sich die Leute oft an meinen Namen, schreiben ihn aber oft falsch. Mein Unternehmensverzeichnis hat sowohl meine korrekte Schreibweise als auch die häufig verwendete, aber weniger Nadine-Schreibweise, die mit meinem Namen verknüpft ist. Durch meinen Eintrag im Unternehmensverzeichnis können Benutzer mich auch mithilfe anderer Metadaten finden, ohne feststellen zu müssen, welche (falls vorhanden) dieser Metadaten Teil meiner E-Mail-Adresse sind. Benutzer, die nicht im Unternehmen sind, können entweder die Visitenkarte der Person einsehen oder in der E-Mail, die die Person ihnen gesendet hat, auf Antwort klicken. Sie können natürlich versuchen, es rückzuentwickeln, aber dann können sie auch eine gute Suchmaschine anstelle eines Unternehmensverzeichnisses suchen.

In beiden Fällen entwerfen wir eine Lösung, die das eigentliche Ziel des Absenders erfüllt. Dem Absender ist das Format der E-Mail-Adresse egal. Der Absender möchte nur den vorgesehenen Empfänger kontaktieren. Die Kommunikation ist das Ziel. Die Mechanismen der Kommunikation, einschließlich des Formats der E-Mail-Adresse, sind nicht das Ziel.

Die Verwendung eines Vornamens.Nachname (oder eines ähnlichen) Formats bietet noch einige Möglichkeiten, um die Wahrscheinlichkeit einer Namenskollision zu minimieren. Beispielsweise kann die Unterstützung alternativer Namen hilfreich sein. Wenn Samuel oder Samantha an Sam vorbeikommen, könnte ihnen stattdessen Sam.surname zugewiesen werden.

Es ist auch erwähnenswert, dass ein bestimmtes Namensschema irgendwann fehlschlagen wird. Ich habe zum Beispiel mit jemandem gearbeitet, der mit einem Vornamen geboren wurde und sonst nichts. Sie hatten keinen Nachnamen und wollten sicherlich keinen Nachnamen annehmen, weil unser Arbeitgeber sie dazu gezwungen hatte.

Mit anderen Worten, entwerfen Sie eine Lösung, die die meiste Zeit für die tatsächlichen Ziele Ihrer Benutzer geeignet ist, und seien Sie auf die unvermeidlichen Edge-Fälle vorbereitet.

13
nadyne

MITTLERE NAMEN KÖNNTEN EIN SCHLECHTER WEG SEIN, EINE LÖSUNG ZU FINDEN

Ok, wir suchen eher nach einer globalen als nach einer regionenspezifischen Lösung. Lassen Sie uns daher verstehen, dass nicht jeder einen zweiten Vornamen hat. Ich nicht. Und ich war in meiner letzten Firma mit diesem gleichnamigen Problem in einer Organisation konfrontiert. Ein Typ namens Amit Jain arbeitete bereits als Entwickler und hatte die emailId amit.jain @. Als ich dazu kam, wurde ich mit 'amit.j @' ausgezeichnet - keine Logik, aber was der Administrator dachte, war eine schnelle Lösung! Wie auch immer, ich habe darüber nachgedacht, und hier sind einige Meinungen.

1) Abteilungssuffixe könnte eine Lösung sein, die für einige Organisationen funktionieren könnte. So können Sie beispielsweise amitjain_ux @ und amitjain_dev @ verwenden, und dieses Format hilft auf zwei Arten. Zum einen, um einen schnellen Einblick in die Rolle der Person zu geben, und zum anderen, um Konflikte zu vermeiden (in den meisten Fällen).

2) Ich habe aus gutem Grund eine Abteilung/ein Team im Suffix vorgeschlagen. Angenommen, Sie möchten eine E-Mail senden und die E-Mail-ID im Feld "an" hinzufügen. Sie beginnen mit dem Namen (typisches Benutzerverhalten) und die automatische Vervollständigung bietet Ihnen zwei Optionen (mit zwei Suffixen). Das erleichtert Ihnen die Auswahl des gewünschten.

3) In extremen Fällen, in denen zwei Personen mit demselben Namen im selben Team sind - man könnte amitjain01_ux @ und amitjain02_ux @ vielleicht verwenden!

3
Amit Jain

Ich weiß nicht, ob dies die "beste" Methode ist, um doppelte Vor- und Nachnamen zu trennen. Aber wir müssen mit uns und unseren Benutzern überlegen, was Vorname + Nachname bedeuten. Sie sind Kennungen für eine Person. Dies bedeutet, dass Sie der E-Mail-Adresse eine weitere Kennung hinzufügen müssen. Diese Kennung muss etwas sein, das wir mit der Person verbinden können, die wir erreichen möchten.

  1. Ihr erster Vorschlag spricht das mit seinen Initialen für den zweiten Vornamen an. Das Problem ist, dass wir den zweiten Vornamen unserer engsten Kollegen oft nicht kennen. Und vor allem nicht jemanden, den wir nicht persönlich getroffen haben. Das wird also nicht gut funktionieren.

  2. Ihr zweiter Vorschlag (eine Zufallszahl) kann auch nicht als Kennung verwendet werden - wieder falsch.

  3. Ihr dritter Vorschlag mit Initialen + Nachname nützt uns auch nichts. Siehe Punkt 1.

  4. Verwenden einer zufälligen Zeichenfolge. Ich werde das nicht kommentieren;)

All dies schlägt also fehl. Es gibt jedoch Dinge, die wir über den Benutzer wissen und die sich nicht oft ändern. Ein Ort ist normalerweise ein fester Parameter, der den Test der Zeit bestehen wird. Viel besser als eine Berufsbezeichnung, die sich irgendwann ändern wird, da größere Unternehmen den berüchtigten Zyklus haben, sich alle zwei bis drei Jahre neu zu organisieren. Das bedeutet, dass sich auch die Berufsbezeichnungen ändern, wodurch die E-Mail-Adresskennung erneut fehlschlägt. Aber die Lage ist oft dieselbe. Es ist nicht allzu hartnäckig, aber es ist das Beste, was wir haben.

Dies führt mich zu dem Schluss, dass [email protected].

Ich habe absichtlich nicht gesagt, welcher Standort sein kann, da dies unternehmensspezifisch ist. Sie können je nach Standort des Unternehmens unterschiedliche Standorte in derselben Stadt, unterschiedliche Gebäude am selben Standort oder unterschiedliche Städte verwenden..

3
Benny Skogberg

tl; dr



Jede sinnvolle Namensvariation kann hinzugefügt werden: jimmy oder jj anstelle von james =.
Und Komplexität kann schrittweise hinzugefügt werden, um unnötigen Aufwand zu vermeiden, wenn dies möglich ist.

Das wichtigste Merkmal dieses Systems:
Die E-Mail-ID basiert auf persönlichen Daten, nicht auf Systemcodes.

Einzigartigkeit ist nicht immer leicht zu merken.


Namen lernen ist eine gute Sache.

Von allen möglichen Lösungen denke ich, dass echte Namen die beste Form der zwischenmenschlichen organisatorischen Identifikation sind (was im Wesentlichen eine E-Mail-Adresse für uns bedeutet). Das erste, was Sie über eine Person erfahren, ist ihr Name, und Sie sollten sie wahrscheinlich nicht kontaktieren, wenn Sie es nicht wissen. Wir können uns also darauf einigen, dass echte Namen gut sind, oder?

Andererseits ist eine Zahl (wie eine GUID) viel programmgesteuerter skalierbar. Sie werden nie keine IDs mehr haben und es ist nicht mit potenziell vorübergehenden Fakten über die Person verbunden. Aber es ist für Menschen nutzlos, sich an andere Menschen zu erinnern.

Was ist mit einer kurzen systemgenerierten Nummer, die an einen Namen angehängt wird? Das müssen Benutzer immer noch nicht über einen anderen Benutzer wissen. Vielleicht ihre Bürotelefonerweiterung oder Handynummer? Niemand wählt heutzutage Telefonnummern!

Wie können wir also zulassen, dass die Namen der anderen verwendet werden, ohne dass die Optionen ausgehen?

Schauen wir uns die Bedingungen an, um erfüllt zu werden.

1. Ziemlich einzigartig

Wenn Sie ein Mega-Unternehmen sind, ist dies eine Herausforderung. Namen allein bieten möglicherweise nicht genügend eindeutige Variationen.

Ich habe gesehen, wie Unternehmen versucht haben, mit f.m.last Durchzukommen, aber das spart den Menschen nicht wirklich Speicherplatz und es ist viel wahrscheinlicher, dass Ihnen die einzigartigen Optionen ausgehen.

Für die durchschnittliche Organisation ist first.m.last Ziemlich solide. In diesen drei Daten sind viele Variationen möglich (sogar wahrscheinlich). Es ist jedoch möglich, dass solche IDs ausgehen. Kommen wir darauf zurück, nachdem wir unsere anderen Anforderungen berücksichtigt haben.

2. Zuverlässig konstant

Namen sind zwar nicht in Stein gemeißelt, aber relativ konstant. Und wenn sie sich ändern, sollten die Mitglieder einer Organisation das wahrscheinlich wissen und es lernen.

Systemgenerierte Zahlen sind extrem konstant, aber wir haben bereits angesprochen, warum sich das Lernen nicht lohnt.

Der Standort (wie Benny erwähnte) ist eine Überlegung wert, aber eine Organisation kann Büros verlegen oder erweitern oder konsolidieren und sie kann eine entfernte Belegschaft bevorzugen oder zumindest mit ihr experimentieren. Unter Berücksichtigung dieser Faktoren kann es schwierig sein, sich auf den Standort zu verlassen.

Ein Name scheint für diese Zwecke konstant genug zu sein.

3. Mensch lernbar

Ein Name ist nicht für jeden am einfachsten zu lernen, aber es sind Daten, die Sie lernen sollten, wenn Sie mit einer anderen Person kommunizieren möchten . Und innerhalb der wahrscheinlich vorkommenden Namen gibt es viele bekannte Muster, die sie lernbarer machen als viele andere eindeutige Daten.

Ein einzigartiger Schutz

Alles in allem fühle ich mich ziemlich gut mit first.m.last ... aber es würde nicht schaden, einen Fallback zu haben.

Ich habe gesehen, wie Unternehmen einen Index wie first.m.last.2 Anhängen, aber das ist irgendwie erniedrigend, nicht wahr? Und es ist nicht besonders aussagekräftig, dass ein Benutzer der zweite mit diesem Namen ist.

Betrachten Sie die Bedingung, unter der Ihnen die Optionen ausgehen:

Jemand, der bereits in der Organisation arbeitet, hat einen Ausweis für sich beansprucht.
Ein Neuling kommt mit demselben first.m.last An Bord.
Der Neuling ist nicht bereit, seinen Namen um des Unternehmens willen zu ändern.

Was ist ein schwieriges Datenelement, das sie im System und unter ihren Mitarbeitern unterscheiden kann?

Eine Option, die ich in Betracht gezogen (aber nie implementiert) habe, ist das Einstellungsjahr: first.m.last.2015. Möglicherweise haben Sie zwei Personen mit demselben Namen, aber es ist höchst unwahrscheinlich, dass sie im selben Jahr eingestellt wurden. Und es ist eine Zahl, die unvergesslich ist und keine schlechte Sache, etwas über einen Kollegen zu lernen. "Oh ja, du hast erst letztes Jahr angefangen ..." oder "Ich habe vergessen, wie lange du schon hier bist ...".

Wenn Sie diese Logik kaufen, müssen Sie jetzt fragen, ob das Jahr an die E-Mail aller angehängt werden soll. Ich finde diese Option widerlich, obwohl sie konsequenter und gerechter ist. Persönlich würde ich das Risiko eingehen und es weglassen, bis ich es brauchte.

Diese Antwort ist mir außer Kontrolle geraten.

3
plainclothes

Lassen Sie den (neuen) Benutzer entscheiden.

Ein neues Mitglied tritt Ihrer Organisation oder Firma bei. Die Personalabteilung hat bereits die üblichen Formalitäten erledigt. Das bedeutet, dass Ihre IT jetzt einen Datensatz (unter einem beliebigen eindeutigen statischen Identifizierungsschlüssel) für die Person hat, der alle Namen, das Geburtsdatum usw. enthält. Ein halbautomatischer Prozess richtet vorläufige Benutzerkonten und Berechtigungen ein. Wenn sie sich zum ersten Mal anmelden, möglicherweise in Anwesenheit eines Vorgesetzten oder Administrators, werden sie (wahrscheinlich unter anderem) aufgefordert, eine E-Mail-Adresse basierend auf ihrem Namen und eine dazugehörige freundliche Kennung auszuwählen - letztere möglicherweise später leicht geändert werden. Basierend auf den verfügbaren Daten werden mehrere Voreinstellungen angezeigt. Es gibt keine Möglichkeit, eine beliebige Zeichenfolge als lokalen Teil abzurufen. Spitznamen müssen in der HR-Datenbank registriert sein und werden im Verzeichnis angezeigt.

Beispiel

Als Dr. John Jay "Joe" Doe III. Als er Mitglied wurde, wurden ihm (einige) dieser Optionen vorgestellt:

  • [email protected] - Dies ist höchstwahrscheinlich diejenige, die bereits von jemandem mit einem ähnlichen Namen übernommen wurde. Andernfalls ist dies die vorgewählte Standardeinstellung.
  • [email protected] - Er mag ungarische Vorfahren haben, aber dieser Befehl fühlt sich ihm als gebürtiger Murkin wahrscheinlich fremd an.
  • [email protected] = [email protected] - Der Name ist seit dem Tod seines geliebten Großvaters eine Familientradition, daher ist ihm die scheinbar willkürliche Zahl eigentlich nicht fremd.
  • [email protected] - In seinem Fall ist nicht ersichtlich, ob die Initiale aus dem Vor- oder Nachnamen stammt. Es ist sehr wahrscheinlich, dass es mit jemand anderem zusammenstößt, es sei denn, der Familienname ist wirklich ungewöhnlich.
  • [email protected] = [email protected] - Initialen können zu einem Spitznamen werden.
  • [email protected] - John war sein Vater, jeder in der Familie nannte ihn sowieso immer bei seinem zweiten Vornamen.
  • [email protected] - Der zweite Vorname ist wirklich ein anderer Nachname des anderen Elternteils oder eines Ehepartners.
  • [email protected] - Es ist in Ordnung, einen zweiten Vornamen zu haben, aber lassen Sie uns etwas Geheimhaltung wahren.
  • [email protected] - Sein zweiter Vorname ist ihm wichtig und überhaupt nicht peinlich.
    • [email protected] - Er ist bereits als "John Jay" bekannt, da sein zweiter Vorname tatsächlich ein zweiter Vorname ist.
    • [email protected] - Seine Eltern gaben ihm beide Familiennamen oder er fügte den seiner Ehefrau Jane bei der Heirat hinzu.
  • [email protected] - Seit dem College heißt er Joe, weil es bereits zu viele Johns gab. Eigentlich begann es in der Karateklasse als "Doejoe".
  • john."joe"[email protected] - Ja, dies ist ein legaler lokaler Teil, aber früher oder später wird es Probleme damit geben.
  • "joe"@ - Dies ist ebenfalls gültig und nicht (unbedingt) gleichbedeutend mit [email protected], Den Absender nicht kennen und der ständig falsch liegen würde.

Das System weiß auch, dass unser John Doe am 21. Dezember 1991 in Smallville, Texas, geboren wurde. Aus Datenschutzgründen darf jedoch nichts davon zum Erstellen der E-Mail-Adresse verwendet werden, obwohl diese Daten häufig in frei gewählten Benutzernamen, einschließlich E-Mail-Konten, verwendet werden und Adressen (bei G-Mail, Yahoo, Hotmail, Facebook usw.).

Wenn ein Mitarbeiter seinen Namen legal ändert, z. Wenn sie heiraten, sich scheiden lassen, ihr Geschlecht neu bestimmen oder adoptiert werden, können sie eine andere Standardadresse auswählen. Der alte wird zu einem expliziten Alias ​​und wird niemals jemand anderem zugewiesen.

Technische Hinweise

Der lokale Teil (linke Seite des at-Zeichens) sollte von den meisten E-Mail-Systemen wie folgt behandelt werden:

  • Es gibt eine kanonische Einzelfall-ASCII-Variante, die explizite und implizite Aliase haben kann. Einige implizite Aliase sind:
    • Eine weitere Zeichenfolge, die zum gleichen lokalen Teil führt, nachdem alle einzelnen Punktzeichen . Von beiden entfernt wurden. (Aufeinanderfolgende Punkte machen eine E-Mail-Adresse ungültig.)
    • Eine weitere Zeichenfolge, die nach jeder gültigen Fallfaltung denselben lokalen Teil ergibt. Das heißt, der lokale Teil unterscheidet nicht zwischen Groß- und Kleinschreibung.
    • Eine Zeichenfolge mit Nicht-ASCII-Zeichen, die nach jedem Transliterationsschema zum gleichen lokalen Teil führt.
    • Eine Zeichenfolge mit Nicht-ASCII-Zeichen, die wie der gleiche lokale Teil mit normalen Glyphenvarianten aussehen kann.
  • Alle Buchstaben im lokalen Teil müssen aus einem einzigen Skript stammen. Das beinhaltet keine Satzzeichen.
2
Crissov

Ich habe dieses Problem bei der Arbeit bei einem früheren Arbeitgeber gesehen. Dinge, die die Leute hier über ein Abteilungssuffix gesagt haben, hätten dort nicht funktioniert, da es in der Abteilung, in der ich gearbeitet habe, zwei Personen mit demselben Namen und in einer anderen Abteilung eine andere Person mit demselben Namen gab.

Sie haben dies umgangen, indem sie Folgendes getan haben: [email protected] für denjenigen, der am längsten dort gewesen war, und [email protected], wobei NUMBER bei 2 begann und jedes Mal erhöht wurde, wenn jemand Neues mit demselben Namen begann .

Vielleicht nicht ideal, aber die Leute (die Benutzer und Kunden) schienen nichts dagegen zu haben.

1
gabe3886

Nachdem ich fast 30 Jahre in einem großen Unternehmen gearbeitet habe, das von einem anderen Unternehmen übernommen wurde, E-Mail-Adressen für mich im Kundennetzwerk benötigt habe und einen gemeinsamen Vor- und Nachnamen habe, bin ich ein Opfer davon geworden.

Ich war [email protected], [email protected], ein Mitarbeiter hatte [email protected] und ein E-Mail-Konto für mich bei einem Kunden war [email protected] - und für diese 30 Jahre bekomme ich gelegentlich ein paar Mal im Jahr eine E-Mail für einen der Mark Stewarts im Unternehmen (normalerweise 2 oder 3 andere Marks zu jedem Zeitpunkt), die ich nur antworte und Carbon -kopieren Sie die 2 oder 3 anderen Marken und sagen Sie: "Ich denke, Sie haben die falsche Marke Stewart, ich arbeite in xxx."

In den meisten Fällen in meiner Karriere [email protected] Wenn die mittlere Initiale nicht benötigt wird, erhält die zweite Person mit demselben Vor-/Nachnamen [email protected]. Das ist also keine wirkliche Antwort, sondern ein Bericht über meine Erfahrungen. Und was eine internationale Organisation betrifft, gibt es einige Mitarbeiter, die keinen Vor- oder Nachnamen, nur einen Nachnamen oder einen bestimmten Nachnamen in einigen Regionen haben (Ng kommt in den Sinn), der von einem großen Prozentsatz von verwendet wird die Bevölkerung der Region. Ich denke, meine einzige wirkliche Antwort ist, Zufallszahlen-Suffixe zu vermeiden und teilweise Vor-/Nachnamen-Kombinationen zu vermeiden, um sowohl externen als auch internen Benutzern die Arbeit zu erleichtern. Auch die persönliche Meinung ist, dass "Abteilung" normalerweise zu allgemein oder zu subjektiv ist, um von großem Nutzen zu sein.

0
Mark Stewart