Kundensupport für SaaS: Stufen, Übergabe, Antwortzeiten
Kundensupport für SaaS aufbauen: Hilfe-Stufen von Doku bis Ticket, Onboarding-Fragen, Bug oder Anwendungsfrage, Übergabe an Entwickler, Antwortzeiten je Tarif.
In diesem Artikel
Ein SaaS-Kunde kauft nicht einmal und geht. Am Montag meldet er sich an, am Dienstag kommt er nicht weiter, und am Tag der Verlängerung entscheidet er, ob sich das Ganze gelohnt hat. Kundensupport für SaaS ist die Arbeit zwischen diesen Momenten. Er unterscheidet sich vom Support eines Onlineshops: Die Fragen drehen sich um das Verhalten von Software, dieselbe Person fragt oft mehrmals, und manches, was gemeldet wird, ist ein echter Fehler, den nur die Entwicklung beheben kann.
Dieser Leitfaden zeigt, wie Sie die Hilfe in Stufen aufbauen, Bug-Meldungen von Anwendungsfragen trennen, Probleme an Entwickler übergeben und was Sie in jedem Tarif zusagen.
Drei Stufen der Hilfe
Die meisten SaaS-Teams landen bei drei Ebenen, ob geplant oder nicht. Planen heißt: Jede Ebene hat eine klare Aufgabe.
| Stufe | Geeignet für | Wer antwortet | Übliche Wartezeit |
|---|---|---|---|
| Selbsthilfe (Doku, Hinweise im Produkt) | Einrichtungsschritte, „Wo finde ich die Einstellung“ | Der Kunde selbst | Keine |
| Live-Chat | Schnelle Frage, während die Person im Produkt ist | Support-Mitarbeiter | Minuten |
| Tickets | Alles, was Prüfung oder mehrere Tage braucht | Support, danach andere | Stunden bis Tage |
Faustregel: Eine Frage mit genau einer richtigen Antwort gehört in die Doku, eine Frage, die einen kurzen menschlichen Blick braucht, in den Chat, und eine Frage, bei der jemand Konto oder Logs ansehen muss, in ein Ticket. Hodhod bringt keine Wissensdatenbank mit; die Doku liegt dort, wo Sie sie veröffentlichen, und wird in Textbausteinen verlinkt. Zum Schreiben siehe Wissensdatenbank und Hilfecenter.
Chat und Tickets können in einem Postfach liegen. Ein Chat, der doch eine Stunde Recherche braucht, wird mitsamt Verlauf zum Ticket. Mehr dazu bei Tickets und Live-Chat.
Onboarding-Fragen sind eine eigene Kategorie
In den ersten zwei Wochen fragen Menschen anderes als langjährige Nutzer. Sie melden selten Bugs. Sie wollen wissen, was sie zuerst tun sollen.
Sammeln Sie die Fragen der ersten zwanzig oder dreißig neuen Konten und gruppieren Sie sie. Meist sind es fünf, sechs immer gleiche: Daten anbinden, Kollegen einladen, eine Datei importieren, Rechnungsgrundlagen, eine verwirrende Einstellung. Dann:
- Schreiben Sie für jede einen Textbaustein, mit Link zur Doku oder einer Antwort in zwei Zeilen.
- Setzen Sie ein kurzes Chatbot-Menü oder eine Frage vor den Chat, damit diese Fragen sofort beantwortet werden.
- Vergeben Sie das Label „onboarding“, um sie monatlich zu zählen.
Kommt dieselbe Onboarding-Frage immer wieder, ist wahrscheinlich das Produkt oder der erste Bildschirm unklar. Das ist ein Befund für das Produktteam, kein Grund für eine weitere Stelle im Support. Siehe Textbausteine und Vorlagen.
Bug oder Anwendungsfrage?
Die erste Aufgabe bei jeder Nachricht ist, das zu entscheiden. Antwort und Zuständigkeit sind verschieden.
| Hinweis | Anwendungsfrage | Bug |
|---|---|---|
| Der Kunde sagt | „Wie exportiere ich das?“ | „Der Export bringt einen Fehler“ |
| Funktioniert bei Ihnen? | Ja, mit denselben Schritten | Nein, Sie sehen denselben Fehler |
| Lösung | Eine Antwort, vielleicht ein Doku-Artikel | Eine Codeänderung |
| Zuständig | Support | Entwicklung |
Ist es unklar, versuchen Sie, das Problem mit demselben Tarif und derselben Rolle wie der Kunde nachzustellen. Gelingt es nicht, fragen Sie die Details in einer Nachricht ab, nicht in fünf. Eine Vorlage zum Kopieren:
Danke für die Meldung. Damit wir das bei uns prüfen können, schicken Sie uns bitte: 1. Die Seite oder den Bildschirm, auf dem es passiert, und was Sie erwartet hätten 2. Was stattdessen erschien (ein Screenshot hilft) 3. Den Zeitpunkt, mit Zeitzone 4. Ihre Browser- oder App-Version 5. Ob es jedes Mal oder nur manchmal passiert
Die Priorität ist eine eigene Entscheidung, unabhängig vom Typ. Ein Bug, der alle Nutzer eines Kontos blockiert, ist dringend, ebenso kann es die Anwendungsfrage eines Testnutzers einen Tag vor Ende seiner Testphase sein. Siehe Ticket-Triage und Priorität.
Einen Bug an die Entwicklung übergeben
Hier hakt es im Support meist, nicht weil Entwickler unerreichbar wären, sondern weil die Meldung ohne die nötigen Angaben ankommt oder elfmal.
Eine Übergabenotiz sollte enthalten, ob im Tracker oder von Hand:
- Zusammenfassung des Problems in einem Satz
- Schritte zum Nachstellen und was Sie gesehen haben
- Konto, Tarif und Zeitpunkt der ersten Meldung
- Wie viele Kunden es bisher gemeldet haben
- Workaround, falls vorhanden, und was Sie dem Kunden gesagt haben
In Hodhod können Sie Gespräche und Tickets mit einem Issue verknüpfen: ein Datensatz für ein Problem, sodass die Entwicklung einen einzelnen Eintrag mit Zähler sieht statt eines Nachrichtenbergs. Ein Issue führt außerdem Vorkommen, wenn das Problem wiederkehrt, und lässt sich als Entwicklungsticket an Jira senden. Siehe Issue-Tracking. Sagen Sie dem Kunden, was als Nächstes passiert („Wir haben es an die Entwickler übergeben und melden uns, sobald es behoben ist“), und setzen Sie am Ticket ein Fälligkeitsdatum, damit Sie sich wirklich melden.
Betrifft ein Problem mehrere Konten gleichzeitig, ist es ein Vorfall, kein Ticket. Wer wann benachrichtigt wird, steht in der Vorlage für eine Eskalationsrichtlinie.
Support direkt in der App
Kunden fragen in dem Moment, in dem sie verwirrt sind, und das ist in Ihrem Produkt. Ein Hilfe-Button, der den Chat öffnet und den Nutzer bereits kennt, spart die Rückfrage „Wie lautet Ihre E-Mail?“ und gibt dem Mitarbeiter Kontext. Für Mobilgeräte bringt das Android-SDK Chat und Tickets in die native App; siehe die Anleitung zum Android-SDK. Im Web übernimmt das Website-Widget dieselbe Aufgabe.
Antwortzeiten je Tarif
Nicht jeder Tarif muss dieselbe Geschwindigkeit bekommen, aber jeder braucht eine Zusage, die Sie halten können. Eine einfache Struktur, mit Beispielwerten in Geschäftszeit:
| Tarif | Kanäle | Erste Antwort | Lösungsziel bei Bug, der die Arbeit blockiert |
|---|---|---|---|
| Free | Doku, Tickets | 2 Werktage | Keine Zusage |
| Standard | Doku, Chat, Tickets | 8 Geschäftsstunden | 3 Werktage |
| Business | Alle, plus feste Ansprechperson | 1 Geschäftsstunde | 1 Werktag |
Das sind Platzhalter. Gehen Sie von dem aus, was Ihr Team heute liefert, und prüfen Sie die Rechnung: Bearbeiten drei Mitarbeiter je etwa 30 Tickets am Tag und hat der Business-Tarif 40 Konten, die je ein Ticket pro Woche schicken, ist die Business-Warteschlange weit vom Limit entfernt. Hat der Free-Tarif 4.000 Nutzer, vielleicht nicht. Rechnen Sie selbst nach, bevor Sie Zahlen auf die Preisseite drucken.
In Hodhod versehen Sie das Gespräch mit einem Label für den Tarif (etwa „tarif-business“) und legen eine Automatisierungsregel an, die Gesprächen mit diesem Label die passende SLA-Richtlinie hinzufügt. Details unter SLA im Kundenservice.
Wöchentliche Checkliste
- Neue Tickets nach Label zählen: Anwendung, Bug, Rechnung, Onboarding
- Die fünf ältesten offenen Tickets lesen
- Bugs mit mehr als einer Meldung auflisten und den Stand bei der Entwicklung erfragen
- Anwendungsfragen finden, die dreimal oder öfter kamen, und einen Doku-Artikel schreiben oder korrigieren
- Verfehlte Fristen mit den Zusagen der Tarife vergleichen
Wenn Sie das in einem gemeinsamen Postfach mit Ihren eigenen Tarifen und Labels sehen möchten, fordern Sie eine kostenlose Demo an.
Häufig gestellte Fragen
Sollten kostenlose Nutzer überhaupt Support bekommen?
Das entscheiden Sie, aber bieten Sie etwas: Doku und ein Ticketformular mit langsamerer Zusage, oder ein Forum. Schweigen wird vor der ersten Zahlung zur Abwanderung.
Wer ist für Bug-Meldungen zuständig, Support oder Entwicklung?
Der Support begleitet das Gespräch mit dem Kunden bis zum Ende, die Entwicklung behebt den Fehler. Der Kunde sollte seine Geschichte nicht der Entwicklung erneut erzählen müssen; dafür gibt es die Übergabenotiz.
Wie verhindere ich, dass dieselbe Anwendungsfrage immer wiederkommt?
Zählen Sie sie. Kommt eine Frage dreimal im Monat, schreiben Sie die Antwort in die Doku und in einen Textbaustein. Kommt sie trotzdem weiter, sehen Sie sich den Bildschirm an, von dem sie stammt.
Ist Live-Chat für ein SaaS-Produkt nötig?
Nein. Viele Teams arbeiten mit Doku und Tickets. Chat hilft, wenn Nutzer mitten in einer Aufgabe feststecken oder vor dem Kauf zögern, und er braucht jemanden, der ihn in festen Zeiten betreut.
Woher kommt die Tarifinformation des Kunden?
Von Ihnen. Hodhod liest Ihr Abrechnungssystem nicht aus, der Tarif muss also von Hand oder durch eine Automatisierungsregel auf Basis anderer Bedingungen als Label gesetzt werden.
