Vom Kundenchat zum Jira-Issue und zurück: ein Eskalationsprozess für Bugs, dem Support und Entwicklung vertrauen

Du eskalierst einen Bug und hörst nichts mehr davon. Die Entwicklung beschwert sich, dass der Support Fragen schickt, die nie Bugs waren. Dann stapeln sich 3 Jira-Issues zu einem einzigen Fehler, und niemand kann dem Kunden sagen, wann der Fix kommt.

Dieser Leitfaden gibt dir einen Prozess in 4 Phasen mit einer klaren Übergabe in jeder Phase. Dazu kommen 5 Prüffragen, eine Vorlage für den Bug-Report und eine Nachricht für den Tag, an dem der Fix live geht.

Wie ein Bug zwischen Support und Entwicklung verloren geht

Eine Kundin schreibt im Chat auf deiner Website: Das Rechnungs-PDF, das sie aus deiner iPad-App exportiert, bricht vor der letzten Seite ab. Dein Agent probiert es aus, sieht dasselbe und postet im Kanal der Entwicklung: „PDF-Export auf dem iPad kaputt?“ Jemand reagiert mit einem Emoji.

In den nächsten 2 Wochen melden 4 weitere Kunden das Problem, 2 Agenten legen zusammen 3 Jira-Issues an, und niemand im Support kann sagen, ob ein Fix kommt. Als er dann live geht, merken die Kunden das nur, weil sie es noch einmal versuchen.

Tray.ai, ein Anbieter von Automatisierungssoftware, beschreibt genau dieses Ende in seinem Leitfaden zur Eskalation an die Entwicklung: Der Kunde erfährt es „trotzdem aus den Release Notes oder indem er nachfragt“, weil „niemand dafür zuständig war, es ihm zu sagen“.

Die Entwicklung klagt über das Gegenteil. Zenatta, eine Beratung, die Helpdesks auf Basis von Zoho aufbaut, schreibt in einer Fallstudie auf ihrer Website, ein „Jira-Backlog voller Supportfragen, die nie Fehler waren, wird zu Rauschen, das die Entwicklung zu ignorieren lernt“.

Die 4 Phasen unten enden jeweils mit einer klaren Übergabe und funktionieren mit jedem Helpdesk, der sich mit Jira verbinden lässt.

Phase 1: Beweisen, dass es ein Fehler ist, bevor die Entwicklung ihn sieht

Viele Eskalationen, die Entwickler nerven, gehen schon hier schief: Der Kunde hat eine Einstellung nicht gefunden oder will etwas, das das Produkt nie konnte.

Atlassians eigenes Support-Team hat in seiner Cloud Bug Fix Policy eine einfache Regel: „Wir versuchen, den Bug nachzustellen, um ihn zu bestätigen, und reichen die Meldung bei Erfolg für Sie ein.“ Übernimm sie. Kann niemand im Support das Problem nachstellen, ist es noch nicht reif für Jira.

5 Fragen, bevor jemand eskaliert

Bevor ein Agent eskaliert, beantwortet er im Ticket 5 Fragen:

1. Kann ich es nachstellen, und auf welchem Gerät, in welchem Browser, mit welcher App-Version oder in welchem Konto?
2. Ist das laut Hilfecenter oder Release Notes dokumentiertes Verhalten?
3. Gibt es das schon in Jira? Such nach dem Fehlertext und dem Namen der Funktion.
4. Wen betrifft es? Ein Konto, einen Plan, alle auf Android?
5. Was blockiert es, und gibt es einen Workaround?

Wohin jede Meldung gehört

Dann ordnest du die Meldung danach ein, was sie wirklich ist:

Priorität in der Sprache der Entwicklung

Für die Priorität nimmst du die Skala der Entwicklung. Gibt es keine, leih dir die von Atlassian:

• Priorität 1, wenn „Nutzer ihre Arbeit nicht erledigen können und es keinen Workaround gibt“.
• Priorität 3, wenn eine Funktion „nicht wie erwartet funktioniert, es aber einen Workaround gibt“.

Der Support beschreibt die Auswirkung in diesen Begriffen, und die Entwicklung legt daraus die Reihenfolge der Arbeit fest.

Phase 2: Ein Jira-Issue pro Bug, mit jedem betroffenen Ticket verknüpft

Such in Jira, bevor du irgendetwas anlegst. Ein zweites Issue für denselben Fehler verteilt die Kommentare und die Zahl der Kunden auf 2 Orte, und jemand muss eines davon als Duplikat schließen.

Der Leitfaden von Tray.ai fasst das Ziel so zusammen: „Ein Issue pro Bug, mit jedem betroffenen Ticket verknüpft.“ Diese Verknüpfungen sind zugleich dein Argument: Laut dem Leitfaden sind es die Zahl der Kunden und der Umsatz dahinter, die „einen Bug in der Priorität nach oben bringen“.

Ein Bug-Report, mit dem Entwickler etwas anfangen können

Eine Studie, die du hier kennen solltest, ist „What Makes a Good Bug Report?“ von Zimmermann und Kollegen (IEEE Transactions on Software Engineering, 2010). Sie beruht auf einer Umfrage bei Apache, Eclipse und Mozilla mit 466 Antworten von Entwicklern und von Leuten, die Bugs melden.

• Von den Entwicklern, die schon mit Schritten zum Nachstellen gearbeitet hatten, zählten 83 % sie zu den 3 Angaben, die ihnen am meisten halfen.
• Von denen, die auf unvollständige Reports gestoßen waren, nannten 74 % das unter den 3 Problemen, die Fixes am stärksten verzögerten.

Ausgerechnet die Angaben, die Entwickler am meisten schätzten, waren für die Meldenden am schwersten zu liefern. Diese Lücke kann der Support schließen, denn der Agent kann beim Kunden noch nachfragen, solange der Chat offen ist.

Nutze jedes Mal dieselben Abschnitte:

Halte Kundendaten aus Jira heraus

Lass Namen, E-Mail-Adresse, Telefonnummer und Bestellnummer des Kunden weg, außer ein Entwickler braucht eine dieser Angaben, um den Bug nachzustellen. Setzt dein Helpdesk in Jira einen Link zurück zum Ticket, der den Titel des Tickets trägt, dann benenne Tickets nach dem Problem, nie nach dem Kunden.

Jira lesen oft mehr Leute als dein Support-Tool. Außerdem liegt die Kopie dort außerhalb des Systems, in dem du Lösch- und Auskunftsanfragen bearbeitest.

Gilt für dich die DSGVO, verlangt das auch ihr Grundsatz der Datenminimierung in Art. 5 Abs. 1 lit. c. Laut der Zusammenfassung der Europäischen Kommission sollen personenbezogene Daten „angemessen, relevant und auf das für den Zweck Notwendige beschränkt“ sein. Das ist eine allgemeine Information, keine Rechtsberatung.

Phase 3: Den Status aus Jira zurück in den Support holen

Sobald das Issue existiert, sollte niemand im Support mehr im Team-Chat fragen müssen: „Gibt's hier was Neues?“ Der Status muss von selbst im Ticket ankommen.

In Zendesk braucht es dafür eine Post-Funktion im Jira-Workflow. Der Hilfeartikel von Zendesk beschreibt das Ergebnis: „Jira kann dem verknüpften Zendesk-Ticket automatisch eine interne Notiz hinzufügen, die den Agenten benachrichtigt. Der Agent kann dann den Kunden benachrichtigen.“

Egal, womit du arbeitest: Teste es einmal mit einem Dummy-Issue.

Fertig heißt nicht immer ausgeliefert

Vereinbare mit der Entwicklung, welcher Jira-Status bedeutet, dass die Kunden den Fix haben. In vielen Teams heißt Fertig nur gemergt oder getestet, und das Release geht erst Tage später raus.

Hat euer Workflow einen Status wie Released oder Deployed, ist das dein Auslöser für Phase 4, und der Support braucht seinen genauen Namen. Fertig und Released liegen in Jira meist beide in der Kategorie Fertig. Eine Regel, die nur auf die Kategorie achtet, verpasst also den Wechsel von Fertig zu Released.

Bring die Zahl mit in die Planung

Einmal pro Woche sollte die Support-Leitung der Entwicklung die Zahl der offenen Tickets vorlegen, die auf jedes Issue warten. In der Planung kommst du mit „14 Konten haben APP-482 gemeldet“ weiter als mit „Kunden fragen ständig danach“.

Phase 4: Jedem betroffenen Kunden Bescheid geben, sobald der Fix live ist

Warte, bis der Fix bei den Kunden angekommen ist, und prüf ihn dann selbst mit dem Setup aus Phase 1.

Schreib allen, die den Bug gemeldet haben, auch denen, die nur „bei mir auch“ geschrieben haben. Beschreib das Problem mit ihren Worten und sag ihnen, was sie jetzt tun sollen:

Hallo, ein kurzes Update zu den Rechnungs-PDFs aus der iPad-App, die vor der letzten Seite abgebrochen sind. Wir haben den Fehler in Version 4.2.2 behoben, die jetzt im App Store ist.

Exportiere die Rechnung nach dem Update einfach noch einmal, dann sind alle Seiten da. Falls noch etwas nicht stimmt, antworte hier mit einem Screenshot.

Das 24-Stunden-Fenster bei WhatsApp

Meta erlaubt freien Text nur innerhalb von 24 Stunden nach der letzten Nachricht des Kunden (das Kundenservice-Fenster). Danach darf ein Unternehmen nur noch freigegebene Vorlagennachrichten senden.

Die meisten Fixes dauern länger als einen Tag. Lass dir also eine Vorlage für Fix-Ankündigungen freigeben, bevor du sie brauchst.

Der Prozess in Deskwoot

Deskwoot ist unser Helpdesk. Dort laufen die Phasen 2 bis 4 über das Ticket, also die interne Aufgabe, die dein Team aus einem Kundenchat herauslöst (siehe wie du aus einem Chat ein Ticket erstellst). Der Kunde sieht weder das Ticket noch das Jira-Issue.

Ein Bug-Report, aus dem Chat entworfen

Die Schaltfläche Bug-Report mit Copilot entwerfen schreibt Titel und Beschreibung aus dem Ticket, seinem Chat und den Kommentaren deines Teams. Copilot liest den Chat mit „name withheld“ anstelle des Kundennamens und hat die Anweisung, Kontaktdaten und Bestellnummern wegzulassen, außer ein Entwickler braucht eine davon.

Nichts geht an Jira, bevor der Agent den Entwurf geprüft und auf Issue erstellen geklickt hat, und das Issue entsteht unter seinem eigenen Atlassian-Konto. Ein Entwurf zählt zu deinen KI-Konversationen.

Statuszeilen und 2 fertige Regeln

Jede Statusänderung in Jira schreibt eine Zeile in jedes verknüpfte Ticket, etwa „Das Jira-Issue APP-482 ist jetzt In Arbeit“. Suchst du in der Ticketliste nach APP-482, findest du jedes verknüpfte Ticket für deine wöchentliche Zählung.

Auf der Seite mit den Jira-Einstellungen findest du 2 fertige Regeln, die du nur prüfen und speichern musst:

Kommt Fertig in deinem Jira vor dem Release, stell die Kategoriebedingungen der zweiten Regel auf den Statusnamen um, zum Beispiel Status des Issues ist Released. Details stehen im Hilfeartikel zu Jira.

Ein Update für alle betroffenen Kunden

Bei 2 oder 3 betroffenen Kunden nutzt du an jedem Ticket Dem Kunden antworten. Bei mehr Kunden nimmst du ein Sammelticket, also ein Ticket ohne Kunden für ein Problem, das viele Kunden gemeinsam haben. Verknüpfe die betroffenen Chats, die Tickets und das Jira-Issue damit.

Wenn der Fix live ist, schickt Verknüpfte Kunden informieren deinen Text an jeden Kunden in seinen eigenen Chat, an bis zu 500 Kunden auf einmal. Im selben Schritt kann das Update die verknüpften Chats und Tickets lösen.

Updates aus Sammeltickets gehen nie als WhatsApp-Vorlagen raus. In einem Posteingang mit WhatsApp Cloud API öffnest du die Chats außerhalb des 24-Stunden-Fensters und sendest eine freigegebene Vorlage aus dem Antwortfeld.

Was es kostet und wie du anfängst

Tickets, Sammeltickets und die Jira-Integration gehören zum Enterprise-Plan: 12 $ pro Agent und Monat oder 9,60 $ bei jährlicher Zahlung (Preise).

Fang klein an:

1. Verbinde Jira.
2. Leg einen Ticketstatus für Arbeit an, die auf die Entwicklung wartet.
3. Speichere die 2 fertigen Regeln.

Der nächste Bug, der über den Chat reinkommt, ist dein Testlauf. Registrier dich, und dein neuer Workspace bekommt 7 Tage Enterprise ohne Kreditkarte, für bis zu 30 Plätze, deinen eingeschlossen.

Wenn die 7 Tage vorbei sind, wählst du einen Plan oder arbeitest im kostenlosen Hacker-Plan für 1 Agenten weiter.