Supporteskalation für wichtige Kundenkonten
Ein Supportticket eines wichtigen Kundenkontos erreicht innerhalb von Sekunden die richtige verantwortliche Person. Gleichzeitig fliesst dasselbe Ticket in eine zweiwöchentliche Sicht darauf ein, welche Konten Probleme haben.
Die Ausgangslage
Supportgespräche wurden in Gleap bereits schnell bearbeitet. Customer Success musste trotzdem erfahren, wenn eines seiner wichtigsten Konten ein neues Ticket eröffnete. Bei einem Kunden mit hohem Wert musste die richtige verantwortliche Person schnell informiert werden. Diese Person zu finden, erforderte jedoch eine manuelle Suche.
Die andere Hälfte des Problems lief nach einer anderen Uhr. Ein einzelnes Ticket beschreibt einen Moment. Es zeigt nicht, dass ein wichtiges Konto innerhalb von zwei Wochen elf Tickets eröffnet hat – eine andere Art von Information, die auf Abwanderungsrisiko hinweisen kann.
Die Herausforderung
Die einfache Lösung ist ein Slack-Alert für jedes Supportticket. Sie scheitert innerhalb einer Woche. Ein Kanal, der bei allem auslöst, wird stummgeschaltet. Dann ist die Eskalation schlechter als keine, weil alle annehmen, jemand habe sie im Blick.
Der n8n-Workflow entscheidet, bevor er jemanden unterbricht. Er prüft, ob das Ticket bereits bearbeitet wurde, ordnet den Kunden dem richtigen Unternehmen in HubSpot zu, bestätigt den Status als wichtiges Konto und identifiziert die verantwortliche Person. Erst danach erreicht etwas Slack.
Webhooks machten das schwieriger als gedacht. Dasselbe Gleap-Gespräch kann mehr als einmal zugestellt werden. Ohne Schutz würden daraus doppelte Ticketdatensätze und wiederholte Alerts – genau der Lärm, den das Design verhindern soll. Jedes eingehende Ereignis wird deshalb zuerst mit den bereits verarbeiteten Ereignissen abgeglichen.
Die zwei Fragen des Teams verwenden dieselben Daten, aber auf unterschiedlichen Zeitskalen. Ein Alert beantwortet: „Wer braucht jetzt Aufmerksamkeit?“ Er beantwortet nicht: „Welche Konten erzeugen seit zwei Wochen unauffällig Supportvolumen?“ Ein zentraler Ticketdatensatz dient beiden Fragen, statt getrennte Alert- und Reporting-Workflows zu bauen, die jeweils nur die Hälfte der Geschichte kennen.
Was wir gebaut haben
Ein neues Gleap-Gespräch wird mit bereits verarbeiteten Tickets abgeglichen und danach gespeichert. Der Kunde wird seinem Unternehmen in HubSpot zugeordnet, das Unternehmen auf den Status als wichtiges Konto geprüft und die zuständige Customer-Success-Person ermittelt. Tickets normaler Konten enden hier und bleiben in Gleap, wo sie hingehören.
Wichtige und normale Kunden erhalten in Gleap denselben Support. Der zusätzliche Zweck dieses Systems ist, Customer Success zu zeigen, wenn ein wichtiges Konto Schwierigkeiten mit einem Service hat, damit die zuständige Person über eine persönliche Kontaktaufnahme entscheiden kann.
Prioritätstickets werden mit Konto- und Zuständigkeitsdaten angereichert und mit Kunde, Unternehmen, Thema, verantwortlicher Person und direktem Gesprächslink in den Customer-Success-Kanal gepostet. Alle zwei Wochen liest ein zweiter Workflow dieselben Ticketdatensätze, gruppiert sie nach Konto und Zuständigkeit, zählt sie und schreibt pro Konto eine Zeile für den Berichtszeitraum in ein gemeinsames Sheet. Mit der Zeit entsteht daraus eine Historie statt einer Momentaufnahme.
Aktueller Stand
Customer Success sieht, welche wichtigen Konten offene Probleme haben, und kann neben dem regulären Support in Gleap über eine persönliche Kontaktaufnahme entscheiden. Die zweiwöchentliche Sicht macht wiederkehrende Belastung auf Kontoebene sichtbar, statt sie in einzelnen Supportgesprächen verborgen zu lassen.
Nächste Referenz
KI Kundenfeedback Analyse für bessere Produktentscheidungen
Bereit für bessere Geschäftsergebnisse mit KI-Automatisierung?
Buchen Sie ein 30-minütiges Operations-Review. Wir schauen gemeinsam, wo manuelle Arbeit Ihren Betrieb bremst und ob es eine konkrete Möglichkeit gibt, Kapazität zu schaffen.
Operations-Review buchenSwiss precision. Valley speed.