Ich suche hier nach Best-Practice-Vorschlägen.
Welche Gründe sprechen dafür und dagegen, Rollennamen als Präfixe für E-Mail-Konten anstelle des Benutzernamens zu verwenden?
"[email geschützt]" vs. "[email geschützt]"
oder
"[email geschützt]" vs "[email geschützt]"
Und gibt es darüber hinaus Sonderfälle, in denen die „allgemeine Regel“ nicht gelten sollte? Etwa für bestimmte Rollen? Z. B. „Rezeption“, „Kontakt“, „Helpdesk“, „Administrator“??
Ich muss mir lediglich der Vor- und Nachteile stärker bewusst sein, damit ich der Geschäftsleitung mehr Informationen geben kann.
Antwort1
Der Hauptgrund für Rollenadressen ist der Arbeitsplatzwechsel.
Es ist viel einfacher, einen Mailserver-Alias zu ändern, sodass „reception@“ oder „sales@“ auf die Mailingliste des neuen Mitarbeiters oder eines Teams verweist, als jeden Kunden zu kontaktieren, der jemals diese Adresse erhalten hat, und ihn aufzufordern, sein Adressbuch zu ändern.
Ergänzung zur Klarstellung:
Aus geschäftlicher Sicht möchten Kunden die Sicherheit haben, dass sie jederzeit mit jemandem Kontakt aufnehmen können, der ihnen weiterhilft, und dennoch bei Bedarf Zugriff auf bestimmte Mitarbeiter für die Kunden-/Kontoverwaltung oder den Support/Vertrieb auf höherer Ebene haben.
Um dieses Ziel zu erreichen, empfehle ich die Verwendung beider Techniken. Die Mitarbeiter sollten über personalisierte/benannte Konten verfügen und Mitglieder eines Alias oder einer Mailing-/Verteilerliste für ihre Abteilung, Funktion oder Niederlassung sein – je nachdem, welche Abgrenzung sinnvoll ist.
Welche Adresse weitergegeben oder verwendet wird, ist dann eine geschäftliche Entscheidung in Bezug auf die erwartete Nachverfolgung / den persönlichen Kontakt / das erforderliche historische Wissen, die Personalfluktuation und wie „allgemein“ die Kundenanfragen sind (Beispiel: Kennwortzurücksetzungen können von jedem Helpdesk-Mitarbeiter durchgeführt werden).
Für Rollen mit direktem Kundenkontakt, Abteilungen mit hoher Fluktuation oder wo Anfragen von jedem Mitarbeiter bearbeitet werden können, kann den Kunden ein Alias (support@, sales@, reception@) für diese Abteilung bereitgestellt werden, um sicherzustellen, dass jemand aus dieser Abteilung ihre E-Mails erhält und sich darum kümmern kann. Wenn ein Mitarbeiter die Rolle verlässt oder wechselt, muss der Alias oder das Abonnement der Mailingliste geändert werden.
Bei Rollen, bei denen ein hohes Maß an persönlichem Kontakt oder historischem Wissen erforderlich ist oder die Arbeit nur von bestimmten Mitarbeitern ausgeführt werden kann, kann die Kontaktaufnahme über das angegebene Konto erfolgen. Ich würde empfehlen, dem Kunden auch eine Alias-Adresse bereitzustellen, damit er nicht im Regen steht, wenn ein Mitarbeiter das Unternehmen verlässt oder in Urlaub ist.
Antwort2
Es hängt definitiv vom Kontext ab - benannte Konten sollten für den Fall verwendet werden, dass Leute mit dieser Person kommunizieren möchtenspeziell(z. B. 'sende diese Datei an John in Konten'), während Rollenkonten sehr nützlich sind, wenn Sie sich nicht darum kümmernWHOerledigt diese Aufgabe derzeit, nur dass sie Ihre Nachricht erhalten (z. B. „Benachrichtigen Sie die Rezeption, dass ich einen Besucher erwarte“).
Möglicherweise haben Sie sogar einige Personen mit persönlichen Konten, die für Rollenkonten verantwortlich sind oder Zugriff darauf haben – beispielsweise Helpdesk-Mitarbeiter: Kunden senden möglicherweise zunächst eine E-Mail an „helpdesk@...“ und erhalten dann eine Antwort von „ann.other@...“. So läuft es bei uns in der Firma und es funktioniert sehr gut für uns.
Antwort3
Normalerweise erstelle ich Verteilungsgruppen mit Rollennamen und füge die betreffenden Personen in die Gruppe ein. Wenn es nur eine Person gibt, mache ich das trotzdem, sodass es immer eine E-Mail-Adresse pro Person und mindestens eine E-Mail-Adresse pro Rolle gibt.
Antwort4
Es gibt einen Grund, warum E-Mail-Aliase entwickelt wurden. Sie erleichtern den Rollenwechsel erheblich.
für bestimmte Rollen? zB. „Rezeption“, „Kontakt“, „Helpdesk“, „Admin“??
RFC 2142enthält eine Liste mit E-Mail-Adressen, die man für jede Domäne vernünftigerweise erwarten kann.