Einführung #
“Email ist die schlimmste Form aller Kommunikationsmittel im Internet, abgesehen von allen anderen Kommunikationsmitteln im Internet.”
Wenn die meisten jedoch einige Antipattern vermieden werden, wird es in meinen Augen ein gutes Kommunikationsmittel.
Organisation über Email #
Eine Organisation ist Email zentrisch, wenn einige der folgenden Themen per Email gelöst werden:
- Meeting Organisation über Email
- Dokumentenversand via Email
- Mittagessen Organisation via Email
- Raumreservation über Email
- Email Suche während Meeting
- Meeting-Protokoll Versand via Email
- Bekommt jedes Team ein Gruppenpostfach
- Technisches Problem melden via Email
- Intranet aktualisieren via Email
- Geschäftsreisen via Email beantragen
Antipatterns #
Unverschlüsselte Email #
Kontext #
Es sollen vertrauliche Daten zwischen einem oder mehreren Empfängern ausgetauscht werden. Eine Möglichkeit ist die “Standard”-Email
Problem #
Der Inhalt ist zwischen Sender und Empfänger nicht End-zu-End verschlüsselt.
Lösung #
Der Email-Sender und der Email-Empfänger müssen sich auf eine Signier- und Verschlüsselungstechnologie einigen. Im Anschluss müssen Zertifikate getauscht werden.
Alternativ können andere Kommunikationsmittel eingesetzt werden.
Es gibt Lösungen, wo der Absender ein Onlineportal für den Empfänger bewirtschaftet. Behörden können beispielsweise den Strafregisterauszug im Onlineportal hinterlegen und eine Benachrichtigung per Email versenden.
Alternativ können auch Online-Kontakt-Formulare verwendet werden, die dann jedoch nur in eine Richtung funktionieren.
Prozess Patch #
Kontext #
In einem Unternehmen gibt Systeme, die sich nicht (leicht) anpassen lassen. Eine sehr einfache Lösung wäre es, den Prozess mit einem Email Zwischenschritt zu reparieren. Emails sind unstrukturiert und deshalb sehr flexible.
Problem #
Der zusätzliche manuelle Aufwand ist nicht zu unterschätzen. Durch die Wartezeit auf die Antwort, muss der Absender die Tätigkeit wechseln. Ausserdem erhöht sich das Fehlerpotential.
Lösung #
Die bessere Lösung ist es jedoch den Prozess nicht zu patchen sondern so umzustellen, dass Emails nicht nötig sind.
Weiterleitung #
Kontext #
Eine Person erhält eine Email, die nicht an sie hätte gesendet werden sollen. Da der Empfänger nicht der Richtige ist, sollte der Absender informiert werden. Anstelle dass die Email weitergeleitet wird, wird lediglich geantwortet, dass sie hier falsch sei.
Problem #
Der Absender hat keine neuen Informationen, wer der richtige Empfänger sein könnte. Ausserdem erhöht es den Aufwand für beide Personen, da allenfalls noch Folgeemails versandt werden. Falls der korrekte Empfänger nicht bekannt ist, kann dem Absender mit hilfreichen Informationen allenfalls weitergeholfen werden.
Lösung #
Das bessere Vorgehen ist, dass die Email direkt an die richtige Person weitergeleitet wird und der ursprüngliche Absender ins cc genommen wird. Es muss jeweils beachtet werden, ob die Information weitergeleitet werden darf oder der Inhalt besonders vertraulich ist.
Bumped-up #
Kontext #
Der Absender hat in einer bestimmten Frist keine Antwort erhalten. Der Absender könnte die Email nochmals senden, in der Hoffnung, dass sie schneller bearbeitet wird.
Problem #
Der Empfänger hat nun 2 Emails in seinem Posteingang und muss voraussichtlich seine Tasks neu priorisieren.
Lösung #
Eine Email sollte alle Informationen enthalten und wenn nötig auch eine Deadline.
Ticketloser Support #
Kontext #
Es gibt immer wieder Interaktionen mit anderen Abteilungen oder Kunden, also Aufträge oder Anfragen, die bearbeitet werden müssen. Für die Kommunikation könnten Emails eingesetzt werden.
Problem #
Die Email hat jedoch mehrere Nachteile:
- Keine komplette Kommunikationshistorie pro Kunde
- Keine einfache Verarbeitung durch mehrere Mitarbeiter oder Abteilungen
- Keine einfache Integration in andere Systeme wie Zeiterfassung, SLA-Verwaltung oder CRM-Systeme
- Ein Risiko, dass ein Email endlos im Unternehmen umherirrt.
Lösung #
Die andere Möglichkeit ist die Kommunikation über ein Ticketsystem. Ein Ticket kann Metadaten wie Kundennummern, Kundenberater, Priorität oder Deadline enthalten. Ticketsysteme besitzen Schnittstellen von Email nach Ticket und umgekehrt, so dass mit Kunden besonders einfach kommuniziert werden kann.
Die Vorteile eines Ticket-Systems sind:
- Hohe Volumen von Tickets können mit Metadaten-Feldern organisiert werden
- Die Kommunikation pro Anfrage ist konsolidiert und kann von allen Benutzern des Systems gelesen werden.
- Metriken für allfällige SLA können überwacht werden
- Bei der Mitarbeit von mehreren Abteilungen bei einem Ticket, kann es einfach weitergegeben werden.
- Besonders wichtige Tickets können “beobachtet” werden, um eine Benachrichtigung bei Änderung zu erhalten.
- Tickets können automatisch der korrekten Abteilung je nach Inhalt zugewiesen werden. Das wird oftmals mittels “betrifft System” oder anderen Metadaten-Feldern erreicht.
Kollaborative Bearbeitung #
Kontext #
Es muss mit mehreren Personen ein Dokument geschrieben werden. Das Antipattern wurde vor ein paar Jahren relativ häufig verwendet, heute eher noch im beruflichen Umfeld, weil die Dienste gesperrt sind.
Problem #
Es entstehen einige Probleme:
- Es ist unklar, wie die verschiedenen Versionen ausgetauscht werden können
- Es können nicht mehrere Personen gleichzeitig ohne Abstimmung am selben Dokument arbeiten.
- Es ist unklar wer das aktuellste Dokument hat.
- Es ist unklar, ob jemand am Dokument arbeitet.
- Es ist nicht einfach möglich, dass Änderungen diskutiert werden.
- Die Änderungen in einem Dokument zusammenzuführen ist nicht einfach.
Lösung #
Jemand soll ein Account bei OneDrive, gDrive usw. erstellen, um so in Echtzeit gemeinsam das Dokument bearbeiten zu können.
FAQ Antwort #
Kontext #
Ein Kunde sendet eine sehr spezifische Email mit Fragen. Der Kunde erhält eine Email, die sehr viele Antworten auf Fragen beinhaltet, die er nicht gestellt hat.
Problem #
Die Email enthält viele unnötige Informationen. Deshalb muss sich der Kunde die gewünschte Information suchen. Die Chance ist hoch, dass die Antwort gar nicht enthalten ist. Das reduziert die Kundenzufriedenheit.
Lösung #
Die Antwort auf eine Email sollte möglichst spezifisch sein.
An Zwei #
Kontext #
Es wird eine Email an zwei Empfänger (An-Zeile) gesendet.
Problem #
Die zwei Personen wissen nicht, wer die Email bearbeitet. Es gibt also 4 Varianten: niemand, Beide, einer der Beiden oder mehr Emails.
Lösung #
Eine Person in die An-Zeile und fragen, ob es die richtige Person ist und ob es allenfalls die andere Person sei. Allenfalls wäre ein Ticket-System hilfreich, dass die Zuständigkeit automatisch beantwortet.
Frohe Festtags Emails #
Kontext #
Ein Unternehmen möchte mit dem Kunden in Kontakt treten und sich positiv darstellen. Eine Lösung ist, die Festtagesmails zu versenden.
Problem #
Da diese Emails keinen persönlichen Charakter haben und das Emailpostfach sowieso fast voll ist, sind sie bei den Empfängern nicht sehr beliebt.
Lösung #
Besser ist es, wenn der Kontakt persönlich stattfindet oder der Kontakt dem Kunden einen Mehrwert bietet.
Bewerbungsemail #
Kontext #
Bewerbungen wurde lange Zeit per Briefpost versendet. Dies musste dann jeweils eingescannt werden, um weiterverarbeitet zu werden. Eine Verbesserung ist, dass die Bewerbungsunterlagen direkt per Email versendet werden.
Problem #
PDF Dokumente sind nicht maschinell auswertbar. Deshalb ist es schwierig die Bewerber zu sortieren und zu filtern. Auch die Ablage ist mühsam, müssen die Dateien umbenannt und in eine Ordnerstruktur gebracht werden.
Lösung #
Die Bewerber geben ihre Informationen direkt in ein Formular auf der Firmenwebsite ein.
Web Master Email #
Kontext #
In Unternehmen gibt es oftmals ein Intranet-Portal, bei dem Inhalte verschiedenster Themen veröffentlicht werden können. Wenn das System nicht dazu konzipiert ist, dass mehrere Personen Inhalte veröffentlichen können, muss eine Kommunikation via Email mit dem Web Master erfolgen.
Problem #
Der Webmaster kann bei vielen Anpassungen zum Engpass werden. Ausserdem muss der User die Daten kontrollieren, was den Aufwand zusätzlich erhöht.
Lösung #
Das System sollte es ermöglichen, dass die User ihre Daten selber veröffentlichen können. CMS Systeme wie Wordpress sind mittlerweile weit verbreitet.
Im Auftrag von #
Kontext #
Der Absender der Email sende im Auftrag von jemand anderem die Email.
Problem #
Da der Auftraggeber nicht der Absender ist, ist die Beantwortung der Email nicht einfach. Es scheint auch, dass der Auftraggeber einen Status erreicht hat, wo er nicht mehr Emails senden kann oder muss.
Eine Weitere Form dieses Antipattern sind die noreply Email-Adressen, die beispielsweise im Auftrag der Kundenbetreuung (zum Beispiel Rechnungen von Bestellungen) gesendet werden.
Lösung #
Der Auftraggeber sollte die Email selber senden. Er kann die Email auch vorformulieren lassen und dann selber senden.
Bei der zweiten Ausprägung sollte mindestens eine Antworte-Email-Adresse vorhanden sein.
siehe-Anhang-Emails #
Kontext #
Der Empfänger erhält eine Email, die keinen nennenswerten Text hat, jedoch einen Anhang.
Problem #
Ist es lesbar auf allen Handys? Auch Word-Dokumente? Kann die Email nicht versehentlich angepasst werden? Ist der Anhang noch zusätzlich komprimiert?
Lösung #
Besser für die Usability ist es, wenn der gesamte Text im Emailtext ersichtlich ist. Besonders Kundenfreundlich ist es, wenn die Referenznummer der Einzahlungsscheine im Emailtext vorhanden sind.
Daten-Emails #
Kontext #
Der Absender möchte Daten in oder aus einem System haben. Das könnte er mit einer Email erreichen.
Problem #
Die für die Datenbank zuständige Person ist der einzige Gatekeeper. Wenn sie nicht verfügbar ist, gibt es keinen Zugriff. Mergen der Daten ist kaum möglich und muss manuell erfolgen. Der Ansatz skaliert nicht und ist auch fehleranfällig. Die Datenhaltung ist in der Regel verteilt sowie nicht leicht aggregierbar. Das Antipattern tritt häufig auf, wenn in der Organisation in Excel und Access programmiert wird, weil dann häufig einige Abteilungen ihre eigene Datenbank haben.
Lösung #
Besser ist es, dass ein System für den Benutzer bereitgestellt wird. So kann er seinen Report jeweils generieren.
Unnütze Bestätigungen #
Kontext #
Eine Person enthält eine Email-Antwort auf eine Anfrage, die nichtssagend ist. Beispielsweise “Links oder Rechts?”, “Ok”.
Problem #
Die Antwort wertlos und enthält auch keine Zeitangabe, wann mit einer definitiven Antwort gerechnet werden kann.
Diese Email sind einfach zu erkennen. Wenn man sich fragt, ob die Person die Email gelesen hat, die Person nochmals schreibt oder man nochmals nachfragen soll.
Lösung #
Es sollte immer darauf geachtet werden, dass die Email für den Empfänger verständlich und vollständig ist. Wenn etwas nicht beantwortet werden kann, sollte es im Emailtext erwähnt werden.
Späte Antwort #
Kontext #
Die Antwort auf eine Email dauert zu lange.
Problem #
Es erweckt den Eindruck nicht wichtig zu sein.
Wenn die Mail schlicht als ungelesen markiert wird, hilft das nicht, da die Antwort nicht gesendet wurde.
Wird zu lange nicht geantwortet, werden voraussichtlich neue Emails versendet und erhöhen den Aufwand zusätzlich.
Lösung #
Wenn das Email so wichtig ist, sollte den anderen Personen dies mitgeteilt werden. Es kann dann helfen sich eine Timebox zu reservieren und dann daran zu arbeiten. Ein Ticketsystem hilft Transparenz zu schaffen.
Erinnerungsmails #
Kontext #
Der Empfänger ist bei einem Event eingeladen und erhält eine Email, dass der Event bald starte.
Problem #
Wenn der Teilnehmer ein Kalender bedienen kann, ist die Mail SPAM.
Lösung #
Es gibt Kalender-Erinnerungen, weshalb auf diese Email verzichtet werden kann.
Meta Spam #
Kontext #
Der Empfänger erhält eine Email, dass SPAM Mails im Umlauf sind.
Problem #
Diese Emails sind nicht gewünscht.
Lösung #
Diese Emails nicht versenden, wenn es nicht sicherheitsrelevant ist.
WG:‘CC: #
Kontext #
Die Email wird dem Empfänger nochmals gesendet, obwohl die Person bereits im cc war.
Problem #
In der Hälfte der Email erinnerte man sich, dass man sowas doch bereits schon einmal gelesen hat. Dann geht die Suche los, wo das war.
Lösung #
Es sollte darauf geachtet werden, dass Emails nicht doppelt versendet werden.
Antwort-An-Alle #
Kontext #
Eine Person antwortet an alle ursprünglichen Empfänger.
Problem #
Es werden viele Empfänger benachrichtigt, obwohl es für diese nicht relevant ist. Wenn die Antwort wieder an alle geht, spricht man von einem Antwort-An-Alle Sturm. Darauf folgt in der Regel sogleich der Antwort-An-Alle-Unsubscribe.
Gerne wird Antwort-An-Alle verwendet, um alle in einem Projekt auf dem gleichen Stand zu halten. Besser ist es jedoch, die Informationen in einem Wiki zu erfassen und dann via Email zu benachrichtigen. So ist sichergestellt, dass alle Informationen an einem Ort sind und nicht in dem Emails gesucht werden müssen.
Lösung #
Der Antwort-An-Alle hat keine Daseinsberechtigung.
Unfertige Antwort #
Kontext #
Der Absender erhält eine Teilantwort auf seine Email.
Problem #
Das passiert oftmals dann, wenn mehr als eine Frage enthalten ist und diese nicht einfach ersichtlich sind oder nicht alle beantwortet werden können.
Lösung #
Der Absender sollte es dem Empfänger so einfach wie möglich machen, ein vollständige Antwort zu geben.
Wenn etwas nicht beantwortet werden kann, sollte es explizit genannt werden. Es kann auch helfen, dass bei der Beantwortung die Frage jeweils im Antwortemail zitiert wird. So ist sofort ersichtlich, was beantwortet wurde.
Unklarer Link #
Kontext #
In der Email wird auf eine externe Ressource verwiesen, die nicht einfach gefunden werden kann. Beispielsweise “Die Information ist im Intranet im Marketing-Bereich”, “Das Formular ist ist auf der Kundenplattform unter Vermögensverwaltung”.
Problem #
Die Information muss regelrecht gejagt werden. Das kostet Nerven und verursacht Aufwand.
Lösung #
Entweder den konkreten Link im Email hinzufügen, die erwähnte Datei anhängen oder die Datei in einer Dateiablage hinterlegen und dann den Pfad angeben.