Die laufende Betreuung eines Web-Projekts kann einige Herausforderungen an die Kommunikation zwischen Kunde und Dienstleister stellen. Wir erleben leider immer wieder Probleme bei der Meldung von Fehlern oder Wünschen im Projekt Support, die nicht ohne zeitaufwändige Nachfragen für uns verständlich oder nachvollziehbar werden.
Natürlich fehlt einigen Kunden naturgemäß tiefgehendes internet-technisches Wissen, um manche Situationen gleich im ersten Anlauf vollkommen verständlich überzubringen. Manchmal ist es aber auch einfach nur der Umstand, dass der Kunde sich im Gegensatz zu uns fast den ganzen Tag mit der eigenen Web-Site beschäftigt und übersieht, dass wir ggf. das Projekt schon seit Wochen oder Monaten nicht mehr angesehen haben und mit manchen internen Begrifflichkeiten nichts anfangen können.
Im Folgenden wollen wir einige Punkte und Beispiele nennen, um die Kommunikation besser zu gestalten. Dies spart nicht nur Support-Kosten, es führt auch zu einer zeitnäheren Bearbeitung von Anforderungen, was vor allem im Kundeninteresse liegen dürfte.
Wir erleben oft genug, dass der Sachverhalt eines Problems an sich nicht ausreichend beschrieben wird. Oft vertraut der Kunde darauf, dass wir wissen, was gemeint sein könnte. Wir raten dazu uns gerade komplexere Sachverhalte immer wie einem Außenstehenden zu beschreiben, möglichst keine internen Bezeichnungen zu verwenden und immer genaue Angaben zu machen. Dies ist vor allem dann relevant, wenn Kommunikation zu einem Projekt nur wenige Male im Jahr erfolgt und wir nicht permanent im Thema des Projekts sind und wenn das Web-Projekt komplex ist.
Stellen Sie sich in folgendem Beispiel nur vor, dass es ggf. mehrere Suchen im Shop gibt, die sich auf Produkte oder News oder Downloads beziehen können und der Shop mehrere Sprachen hat.
Schlechtes Beispiel:
Die Search im Shop geht nicht. Bitte reparieren.
Gutes Beispiel:
Die Filterfunktion von Produkten in der englischen Sprachversion der Produktlistenansicht unter https://www.beispiel.de/seitentitel/ wird aktuell weder auf PC, noch auf Smartphone angezeigt.
Beschreiben Sie einen optischen Fehler, teilen Sie uns bitte genau mit, wie und wo dieser zu sehen ist. Ein Screenshot hilft hierbei immer sehr, ebenso die Angabe wo genau innerhalb der Web-Site die jeweilige Seite (URL Adresse oder TYPO3 Datensatz Nummer / ID) konkret zu finden ist.
Dazu bitte immer die Information in welchem Web-Browser in welcher Web-Browser Version, auf welchen Betriebssystem und auf welchem Gerät haben Sie diesen optischen Fehler gesehen?
Schlechtes Beispiel:
Der Abstand der blauen Teaser Box stimmt irgendwie nicht. Bitte prüfen.
Gutes Beispiel:
In der Desktop Ansicht ist der obere Abstand der 2. Teaserbox in der rechten Spalte auf https://www.beispiel.de/seitentitel/ zu klein und sollte besser dem Abstand nach unten entsprechen. Siehe Screenshot anbei von Firefox 74.0 auf Windows 10.
Vielfach wird Bezug auf einen Sachverhalt der Kontext vergessen. Beispielsweise wird ein Fehler genannt oder Wunsch geäußert, ohne klar anzugeben in welcher Umgebung es gemeint ist. Z.B. bei Web-SItes, die auf einem Content Management-System wie TYPO3 basieren, kann ein Problem sich auf das selbe Element im CMS Redaktionssystem oder bei der Ausgabe auf der Web-Site beziehen. Bitte nennen sie den Kontext.
Schlechtes Beispiel:
Im Fließtext passen die Umbrüche nicht.
Gutes Beispiel:
Beim Editieren des Textelements mit der ID 123 im CMS Backend entstehen zu große Umbrüche, wenn ich die Enter Taste im Text-Editor drücke.
Gutes Beispiel:
Auf der Seite mit der URL: https://www.beispiel.de/seitentitel/ wird im Frontend jeder Umbruch doppelt so groß ausgegeben, wie ich ihn im CMS eingegeben habe.
Besteht bspw. irgendwo ein Fehlverhalten benötigen wir meistens genaue Schritte, um die Fehlersituation zu reproduzieren. Oft genug versuchen wir Fehlersituation ohne konkrete Angaben nachzustellen, was uns dann nicht gelingt und wir können den Fehler nicht nachvollziehen.
Ist ein Fehler in einem zugriffsgeschützten Bereich, geben Sie bitte auch direkt den Login mit Username und Passwort an, unter dem der Fehler auftritt. Vergessen Sie auch nicht die genaue Fehlermeldung, wenn eine sichtbar ist.
Schlechtes Beispiel:
Das Kontaktformular lässt sich nicht abschicken.
Gutes Beispiel:
Füllt man das Kontaktformular nicht vollständig aus und sendet es ab und vervollständigt es danach in der Wiederanzeige und versucht es wieder abzusenden erscheint über dem Formular die Fehlermeldung "Meldungstext" und das Formular lässt sich ga nicht mehr abschicken. Der Abschicken Button ist nun ausgegraut.
Generell bevorzugen wir schriftliche Kommunikation. In vielen Projekten setzen wir das Ticket System Mantis ein, dass wir für unsere Kunden unter https://bugs.aemka.de/ bereit stellen. Ein Ticket System hat die Vorteile, dass alle Vorgänge im Projekt jederzeit zentral einsehbar und nachvollziehbar sind, somit ein Projekt-Status schnell ersichtlich ist und automatisch die Projekthistorie dokumentiert ist. Damit können auch nachfolgende Projektbeteiligte einen besseren Einstieg ins Projekt haben. Zusätzlich kann man Projekte so gut auswerten und keine relevante Information versickert in Posteingängen oder Message Diensten. Wenn Sie ein Ticket in Mantis einstellen, können Sie darüber hinaus eine Priorität (hoch, mittel, niedrig, ...) eingeben, eine Kategorie (Design, Frontend, Backend, ...) wählen und die Art des Tickets bestimmen (Fehler, Feature Wunsch, ...)
Nur in Projekten mit extrem wenig Kommunikation verwenden wir Email. Bitte verzichten Sie auf Kommunikation über Messaging Dienste wie Whatsapp, Skype, .... Durch die Vielzahl von verfügbaren Diensten entsteht schnell Chaos, wenn parallel noch Email und Tickets verwendet werden. Informationen laufen kreuz und quer und gehen gerade bei Messaging Diensten schnell verloren, da Sie schon kurze Zeit später nicht mehr im Blick sind.
Lediglich bei extrem kritischen Situationen sehen wir Telefon als sinnvollen Kommunikationsweg an. Bei allen anderen Themen können wir meist eh nicht adhoc am Telefon einen komplexen Sachverhalt analysieren oder beheben. Zusätzlich bringen Telefonanrufe uns immer wieder gedanklich aus laufenden Entwicklungen raus.
Wir sind generell von Montag bis Freitag zu deutschen Bürozeiten (09:00 - 17:00 +/- 1h) verfügbar. Am Wochenende und an Feiertagen sind wir nur in Ausnahmefällen verfügbar. Urlaubszeiten, die Einfluss auf Projekt Support haben, werden Ihnen mit Vorlauf kommuniziert. In sehr dringenden Fällen, rufen Sie uns gerne auch außerhalb unserer Geschäftszeiten an oder sprechen Sie auf unsere Mailbox und wir versuchen Ihnen schnellstmöglich zu helfen.
Wir unterstützen Sie in Deutsch und Englisch.
Gibt es Verfügbarkeitsprobleme der Web-Site wie z.B. Web-Site nicht erreichbar durch Server-Ausfall oder ein abgelaufenes SSL Zertifikat können Sie sich ausserhalb unserer Geschäftszeiten jederzeit an Ihren Web-Hoster wenden, der in der Regel eine 24h Hotline auch am Wochenende hat. Wir selber betreiben kein Web-Hosting und schließen alle Web-Hosting Verträge in Ihrem Namen bei namhaften Web Hosting Firmen ab, so dass Sie der rechtliche Inhaber der Verträge und Domains sind und direkt den Support Ihres Web-Hoster nutzen können und nicht von unseren Geschäftszeiten abhängig sind.
Wir hoffen mit diesen Tipps die Projekt- und Support-Kommunikation zu verbessern und in besser definierte Bahnen zu bringen. Generell, senkt etwas mehr Information am Anfang Support-Kosten und sorgt für schnellere Bearbeitung von Anfragen.
