Wer die Feedback-Schleife mit Kunden schließen will, scheitert meist am letzten Schritt: der Nachricht an die Person, die den Fehler gemeldet hat. Die Aufgabe wandert nach „Erledigt“, das Team nimmt sich neue Arbeit vor, und der Kunde weiß weiterhin nicht, ob er es erneut versuchen kann. Eine kurze Nachricht nach geprüftem Ergebnis schließt diese Lücke und zeigt, dass sich die Meldung gelohnt hat.
Dieser Leitfaden setzt dort an, wo die Arbeit an der Korrektur läuft oder gerade abgeschlossen ist. Wie aus einem Ticket eine Aufgabe wird, beschreibt der Leitfaden von der Kundenanfrage zur Aufgabe. Hier legst du fest, wie du die meldende Person nicht verlierst, wann du „behoben“ schreiben darfst und was du sendest, wenn es keine Korrektur geben wird oder sie noch fehlt.
Wann der Kunde von der Korrektur erfahren sollte
Schick die Nachricht, sobald die Änderung für den Kunden verfügbar ist und jemand sie unter ähnlichen Bedingungen wie in der Meldung geprüft hat. Nicht, wenn ein Entwickler den Code zusammenführt, und nicht, wenn die Aufgabe ihren Status wechselt. Diese Ereignisse beschreiben den Fortschritt im Team; den Kunden interessiert nur, ob sein Ablauf wieder funktioniert. Kommt die Korrektur erst mit dem nächsten Release bei allen an, warte auf dieses Release.
Die GitHub-Dokumentation beschreibt, dass ein per Schlüsselwort verknüpftes Issue automatisch geschlossen wird, sobald der Pull Request in den Standardbranch gemergt ist. Das zeigt den Stand des Repositorys, beweist aber nicht, dass die Korrektur beim Kunden schon wirkt: GitHub: Pull Request mit einem Issue verknüpfen.
Eine Antwort steht dem Kunden auch dann zu, wenn das Ergebnis keine Korrektur ist. Die Entscheidung „wird nicht behoben“ oder „wir prüfen zu einem festen Termin erneut“ ist eine Information, mit der er planen kann.
Halte die meldende Person mit der Aufgabe verknüpft
Die Schleife reißt meist bei der Übergabe. Der Support legt eine Aufgabe an, und das Ticket wird als „weitergegeben“ geschlossen. Wenn die Arbeit Wochen später fertig ist, weiß niemand mehr, wer darum gebeten hatte. Melden fünf Kunden denselben Fehler, sollten alle fünf Tickets auf eine einzige Aufgabe zeigen.
- Die Aufgabe verweist auf jedes Ticket, das sie betrifft, auch auf später hinzugekommene.
- Im Ticket steht eine interne Notiz mit der Aufgabennummer und dem Namen der Person, die dem Kunden antwortet.
- Bei Duplikaten verknüpfst du die neue Meldung mit der bestehenden Aufgabe, statt ihren Fall spurlos zu schließen.
- Ein Zitat aus der ersten Nachricht des Kunden ist gespeichert, damit die Antwort seine Worte aufgreifen kann.
Das Zitatfeld lässt sich leicht ergänzen, wenn du eine Vorlage für einen prüfbaren Fehlerbericht nutzt. Trenne außerdem die Rollen: Wer die Aufgabe verantwortet, kümmert sich um die Korrektur, wer den Kontakt verantwortet, um die Nachricht. Das kann dieselbe Person sein, dann halte es aber ausdrücklich fest.
Prüfe die Korrektur, bevor du „behoben“ schreibst
- Zu den gemeldeten Schritten zurückkehren.Wiederhole den Ablauf des Kunden in seiner Umgebung: derselbe Browser oder dasselbe Gerät, ähnliche Daten, derselbe Kontotyp.
- Mit dem erwarteten Ergebnis vergleichen.Prüfe das Ergebnis, um das es dem Kunden ging, nicht nur das Verschwinden der Fehlermeldung.
- Klären, ob der Kunde etwas tun muss.Muss der Kunde die Seite neu laden, sich erneut anmelden oder eine Bestellung wiederholen, gehört das in die Nachricht.
- Ergebnis im Ticket festhalten.Eine Notiz wie „am 8.10. in Safari geprüft, Speichern funktioniert“ erlaubt Kollegen, ohne erneuten Test zu antworten.
Schlägt die Prüfung fehl, schick keine Nachricht wie „sollte jetzt funktionieren“. Die andere Seite dieses Ablaufs, die Bitte um Bestätigung und die Entscheidung über das Schließen, beschreibt der Leitfaden Problemlösung bestätigen, bevor ein Ticket geschlossen wird. Betrifft eine Änderung viele Kunden und das ganze Supportteam, hilft zusätzlich eine saubere Übergabe der Änderung an den Support.
Antworte mit den Worten des Kunden, nicht mit denen der Aufgabe
Ein Aufgabentitel ist für das Team geschrieben: Er nennt eine Komponente, eine Version oder eine Abkürzung. Der Kunde hat das Problem anders beschrieben und erkennt seinen Fall an dieser Beschreibung wieder. Beginne also mit seiner Situation und sag dann, was er jetzt sehen wird. Die Tabelle zeigt erfundene Beispiele für die Umformulierung.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Beschreibung in der Aufgabe | Worte des Kunden | Satz in der Nachricht |
|---|---|---|
| Datumsvalidierung im Formular zur Terminänderung | Ich kann meinen Termin nicht auf morgen verschieben | Das Verschieben eines Termins auf den nächsten Tag funktioniert wieder |
| CSV-Export scheitert an Umlauten | In der Datei steht Zeichensalat statt Namen | Namen mit Umlauten werden jetzt korrekt exportiert |
| Regression im Warenkorb nach Gutscheinumbau | Mein Rabattcode verschwindet beim Bezahlen | Der Rabattcode bleibt bis zur Zahlung im Warenkorb |
Lass die technische Ursache weg, wenn der Kunde nicht danach gefragt hat. Ein Satz Erklärung genügt, wenn er hilft einzuschätzen, ob das Problem wiederkommen kann.
Drei Vorlagen: behoben, wird nicht behoben, noch nicht
Jede Vorlage enthält dieselben Teile: Bezug zur Meldung, Stand des Falls, was der Kunde jetzt tun kann und ob sich noch jemand meldet.
„Guten Tag [Name], am [Datum] haben Sie uns geschrieben, dass [Worte des Kunden]. Die Korrektur ist jetzt verfügbar und wir haben sie auf [Gerät/Browser] geprüft: [was jetzt funktioniert]. War die Seite schon geöffnet, genügt ein Neuladen. Antworten Sie gern in diesem Gespräch, falls noch etwas anders aussieht. Danke für die genaue Beschreibung, sie hat sehr geholfen.“
„Guten Tag [Name], ich komme auf Ihre Meldung zu [Worte des Kunden] zurück. Nach der Prüfung haben wir entschieden, dieses Verhalten nicht zu ändern, weil [kurzer, ehrlicher Grund]. Ich verstehe, dass das [Ziel des Kunden] erschwert. Derzeit können Sie [geprüfte Übergangslösung]. Falls sich die Entscheidung ändert, schreibe ich Ihnen in diesem Fall.“
„Guten Tag [Name], das Problem mit [Worte des Kunden] wartet noch auf eine Korrektur. Es steht auf der Liste des Teams, einen Termin für die Umsetzung kann ich heute aber nicht nennen. Bis dahin [Übergangslösung oder Hinweis, dass es keine gibt]. Ich prüfe den Stand am [konkretes Datum] und melde mich dann, unabhängig vom Ergebnis.“
In der dritten Vorlage versprichst du einen Kontakttermin, keinen Korrekturtermin. Trag ihn in den Kalender oder als interne Notiz ins Ticket ein und halte ihn ein. Ist der Grund für die Absage eine Produktentscheidung und kein technisches Hindernis, erklärt der Leitfaden zu Kundenwünschen und der Roadmap, wie du sie begründest.
Eine Regel für alte Meldungen
Manchmal kommt eine Korrektur ein halbes Jahr nach der Meldung. Eine Nachricht ist trotzdem sinnvoll, solange sie kurz ist und keine Antwort verlangt. Erinnere zuerst daran, worum es in der Meldung ging, denn ohne diesen Zusammenhang wirkt die Nachricht wie Spam.
Vereinbare eine Regel für das ganze Team, zum Beispiel: Meldungen, die älter als drei Monate sind, erhalten eine einzige Informationsnachricht ohne Testbitte, und der Fall wird geschlossen, wenn keine Antwort kommt. Schreib nicht an Personen, die die Zusammenarbeit erkennbar beendet haben und keinen weiteren Kontakt wünschen. War der Fehler Teil einer größeren Störung mit vielen Tickets, beschreibt der Leitfaden zum Kommunizieren einer Serviceunterbrechung die Reihenfolge der Updates.
Fallstatus, den der Kunde in Meetlead sieht
In der App Projekte kannst du eine Aufgabe aus einem Ticket anlegen oder eine bestehende Aufgabe damit verknüpfen, und eine Aufgabe kann mehrere verknüpfte Tickets haben. Interne Notizen im Ticket sieht der Kunde nicht, dort kannst du also das Prüfergebnis und die zuständige Person für die Nachricht festhalten.
Sind auf der Website dauerhafte Tickets aktiviert, sieht der Kunde im Widget eine Liste seiner Fälle mit Referenznummer, letzter Nachricht und Status: offen, gelöst oder geschlossen. Eine Antwort im Ticket landet im selben Fall, und antwortet der Kunde auf einen gelösten Fall, wird das Ticket wieder geöffnet. Ein Statuswechsel der Aufgabe schickt dem Kunden keine Nachricht: Den Text schreibst du selbst. Projekte setzt ein Konto, eine aktive App auf der Website und einen Tarif mit Zugang voraus.
Fragen zum Abschließen von Meldungen nach einer Korrektur
Muss ich den Kunden bitten, die Korrektur zu testen? Nicht immer. Hast du das Ergebnis unter seinen Bedingungen geprüft, reicht eine Information mit der Einladung, sich zu melden, falls noch etwas nicht klappt. Bitte um einen Test, wenn du die Umgebung des Kunden nicht nachbilden kannst, etwa seine Daten oder sein Gerät.
Was tun, wenn die Korrektur nur einen Teil des Problems löst? Schreib genau, was schon funktioniert und was noch aussteht, und behandle den Rest wie die Vorlage „noch nicht“ mit einem Termin für den nächsten Kontakt. Schließ den Fall nicht nur deshalb, weil die Aufgabe in Projekte erledigt ist. Den fehlenden Teil legst du als eigene Aufgabe an, verknüpft mit demselben Ticket.
