Wie kann eine IDC-SaaS-Plattform die Nutzerzufriedenheit durch kürzere Reaktionszeiten bei Tickets steigern?

Wie kann eine IDC-SaaS-Plattform die Nutzerzufriedenheit durch kürzere Reaktionszeiten bei Support-Tickets steigern?

Langsame Reaktionen auf Support-Tickets und wiederholte Nachfragen von Nutzern sind nicht unbedingt nur auf Personalmangel zurückzuführen. Wenn nicht erreichbare Websites, ausgefallene Anfrageformulare und fehlerhafte Anzeigen-Landingpages alle in derselben Warteschlange landen, verliert der Kundenservice leicht Zeit mit Weiterleitungen und Rückfragen. Ein Konzept zur Steigerung der Nutzerzufriedenheit auf einer IDC-SaaS-Plattform sollte zunächst die Prozesskette „Auswirkungen erkennen – Verantwortung zuweisen – Fortschritt kommunizieren – Wiederherstellung überprüfen“ durchgängig gestalten, statt den Kundenservice lediglich zu schnelleren Antworten zu drängen.

Nutzer wollen nicht nur eine Eingangsbestätigung, sondern einen klaren Plan zur Bearbeitung

Hier geht es um IDC-SaaS-Plattformen für Website-Hosting, Cloud-Ressourcen und damit verbundene Betriebs- und Wartungsdienste. In einem integrierten Szenario für Websites und Marketing kann ein einzelner Ausfall gleichzeitig den Website-Zugriff, das Werbebudget und die Gewinnung von Anfragen beeinträchtigen. Eine automatische Antwort kann lediglich bestätigen, dass ein Ticket erfasst wurde; sie ersetzt keine wirksame Rückmeldung.

Eine wirksame erste Rückmeldung sollte mindestens angeben, wer für den Fall zuständig ist, was gerade geprüft wird, ob der Nutzer mitwirken muss und wann das nächste Update erfolgt. Lässt sich der Zeitpunkt der Wiederherstellung zunächst nicht bestimmen, sollte der nächste Rückmeldezeitpunkt zugesagt werden, anstatt vorschnell eine „baldige Wiederherstellung“ zu versprechen. Verlässliche Angaben verringern bereits die Zahl wiederholter Nachfragen.

Bei der Auswertung sollten die erste substanzielle Reaktion durch einen Mitarbeiter, die Wiederherstellung des Geschäftsbetriebs und die endgültige Lösung getrennt erfasst werden. Andernfalls gilt „sofort geantwortet, aber lange niemand zuständig“ ebenfalls als ausgezeichnetes Ergebnis: Die Zahlen sehen gut aus, die Zufriedenheit verbessert sich jedoch nicht.

Zuerst nach geschäftlichen Auswirkungen priorisieren, dann die intelligente Ticketzuweisung nutzen

Eine vollständig nicht erreichbare Website sollte offensichtlich nicht in derselben Reihenfolge bearbeitet werden wie eine Anfrage zur Änderung eines Seitentextes. Bei der Priorisierung sollten der Umfang der Auswirkungen, eine mögliche Unterbrechung kritischer Geschäftsabläufe, verfügbare Alternativen und laufende Werbekampagnen berücksichtigt werden. Auch wenn eine Seite erreichbar ist, die Anfrage aber nicht übermittelt werden kann, kann der Fall dringender sein als eine lokale Darstellungsstörung.

Im Ticketformular können die Domain, der Zeitpunkt des Fehlerbeginns, betroffene Seiten, die Zugriffsregion und Schritte zur Reproduktion abgefragt werden; bei Werbeproblemen sollten außerdem die Landingpage und der Kampagnenstatus angegeben werden. Es sollten nicht zu viele Pflichtfelder vorhanden sein. Stattdessen können je nach Problemtyp zusätzliche Felder eingeblendet werden, damit Nutzer nicht erst einen langen Fragebogen ausfüllen müssen, um einen Fehler zu melden.

Die intelligente Ticketzuweisung sollte Servicezuständigkeit, Kompetenz-Tags, aktuelle Auslastung und Dienstpläne berücksichtigen und nicht nur Schlüsselwörter erkennen. Bei Problemen mit Zertifikaten, DNS-Auflösung, dem Website-Baukastensystem oder Ad-Tracking können jeweils passende Teams vorgeschlagen werden. Ist die Zuordnung unsicher, sollte das Ticket zur manuellen Triage weitergeleitet werden; bei schwerwiegenden Störungen muss eine manuelle Eskalation möglich bleiben. AI eignet sich zur Unterstützung bei Klassifizierung, Zusammenfassung und Wissensvorschlägen, sollte jedoch keine Änderungen mit hohem Risiko automatisch ausführen.

Nach der Zuweisung muss eine eindeutig verantwortliche Person feststehen. Bei der teamübergreifenden Zusammenarbeit können weitere Beteiligte hinzugezogen werden, aber Kunden sollten nicht selbst zwischen Hosting-, Website- und Marketingteams nach einem Verantwortlichen suchen müssen.

Eine Überschreitungswarnung muss Maßnahmen auslösen, nicht nur eine weitere Nachricht senden

SLA sollten separate Ziele für die erste Reaktion, Fortschrittsmeldungen und die Bearbeitung festlegen sowie Servicezeiten und die Berechnung der Reaktionszeit erläutern. Bei Kunden im Ausland kann es dort tagsüber sein, während in China Nacht ist. Wenn keine entsprechende Bereitschaft verfügbar ist, darf Support während der Geschäftszeiten nicht als Rund-um-die-Uhr-Service zugesagt werden.

Bei drohender Überschreitung sollte zunächst die zuständige Person erinnert werden. Erfolgt weiterhin keine Übernahme, wird an die diensthabende Leitung oder eine Vertretung eskaliert. Die konkreten Schwellenwerte sollten an die Kapazitäten des Teams angepasst werden. Während auf Angaben des Nutzers gewartet wird, kann die Zeitmessung gemäß Vereinbarung teilweise ausgesetzt werden; der Grund muss jedoch dokumentiert werden. „Warten auf den Kunden“ darf nicht dazu dienen, interne Warteschlangen zu verschleiern.

Wenn ein und derselbe Fehler mehrere Tickets auslöst, sollten diese einem gemeinsamen Vorfall zugeordnet und der Fortschritt zentral kommuniziert werden; zugleich sind die Auswirkungen auf die einzelnen Kunden festzuhalten. So lässt sich die wiederholte Fehlersuche reduzieren und verhindern, dass verschiedene Servicemitarbeiter widersprüchliche Erklärungen geben.

Nach der Wiederherstellung der Website auch die Marketing-Prozesskette überprüfen

Yiyingbao Information Technology (Beijing) Co., Ltd. wurde 2013 gegründet und hat seinen Hauptsitz in Peking. Das Unternehmen bietet integrierte Dienstleistungen rund um AI-gestützte intelligente Website-Erstellung, mehrsprachige Websites, SEO, Anzeigenschaltung und soziale Medien im Ausland. Da diese Leistungen Website-Erstellung und kontinuierliche Kundengewinnung verbinden, sollte die Abnahme durch den Kundenservice nicht nur prüfen, ob der Server online ist, sondern auch, ob wichtige Seiten, Benachrichtigungen zu Anfragen und Conversion-Tracking ordnungsgemäß funktionieren.

Nach der Wiederherstellung einer Anzeigen-Landingpage muss beispielsweise zusätzlich überprüft werden, ob Formulare übermittelt werden können, Leads ankommen und Tracking-Ereignisse ausgelöst werden. Dies beschreibt eine Vorgehensweise und keinen Kundenfall. Bei Zugriffsproblemen in verschiedenen Regionen sollten Tests in den betroffenen Regionen durchgeführt werden, statt ein Ticket allein deshalb zu schließen, weil der Zugriff über ein Netzwerk in China funktioniert.

Bei Prüfprotokollen und Screenshots gilt das Prinzip der Datensparsamkeit; Nutzer sollten in gewöhnlichen Support-Tickets keine Passwörter im Klartext übermitteln müssen. Vor dem Austausch von Zertifikaten sowie Änderungen an der DNS-Auflösung oder an der Produktivkonfiguration müssen die Berechtigung bestätigt, Änderungen dokumentiert und eine Rollback-Möglichkeit vorgesehen werden. Schnellere Reaktionen dürfen nicht mit einem höheren Ausfallrisiko erkauft werden.

Mit einer häufig auftretenden Fehlerkette beginnen und den Ablauf überprüfen

Für die Einführung kann zunächst ein Fall wie „Website nicht erreichbar“ oder „Anfrage kann nicht übermittelt werden“ ausgewählt werden. Dafür werden die Formularfelder, Zuweisungsregeln, Eskalationskontakte und Prüfschritte zur Abnahme festgelegt, bevor der Ablauf schrittweise erweitert wird. Eine Wissensdatenbank mit Reproduktionsbedingungen, Prüfpfaden und Methoden zur Überprüfung der Wiederherstellung ist nützlicher als eine Sammlung bloßer Ergebnisse mit dem Vermerk „gelöst“.

Bei der Erfolgsmessung sollten gleichzeitig die Zeit bis zur ersten wirksamen Rückmeldung, lange wartende Tickets, die Zahl der Weiterleitungen, die Wiedereröffnungsquote und die Zufriedenheit nach dem Schließen des Tickets beobachtet und nach Schweregrad verglichen werden. Werden die Antworten schneller, während die Wiedereröffnungsquote steigt, sollte zunächst geprüft werden, ob Tickets zu früh geschlossen werden. Eine Beschleunigungsmaßnahme ist nur dann dauerhaft sinnvoll, wenn Nutzer schneller eine zuständige Person erreichen und dasselbe Problem seltener erneut melden müssen.