Linear im Kundensupport: aus Tickets Bug-Reports machen und Kunden sagen, wann der Fehler behoben ist

Ein Kunde meldet am Montag einen Bug. Dein Agent postet ihn im Kanal der Entwickler, jemand legt ein Linear-Issue an, und das Ticket bleibt liegen. Bis Freitag haben 20 weitere Kunden denselben Bug gemeldet.

Der Fix ging am Mittwoch raus, und niemand hat es ihnen gesagt. Dieser Leitfaden zeigt, wie du Bugs an Linear übergibst, Duplikate bei einem Issue hältst und Kunden sagst, wann der Fix live ist.

Die Kurzfassung

• Erst suchen, dann erstellen. Such zuerst nach einem bestehenden Linear-Issue, über den Key oder über Wörter aus dem Titel.
• Schreib den Report für Entwickler. Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis, Umgebung, Auswirkung. Keine Namen oder Kontaktdaten von Kunden.
• Ein Bug, ein Issue, viele Tickets. Jedes Ticket zum selben Bug wird mit demselben Issue verknüpft. Die Zahl der verknüpften Tickets zeigt der Entwicklung, wie groß er ist.
• Lass den Status zurück ans Ticket kommen. Agenten sollten nicht in Linear nachsehen oder Updates von Hand einfügen müssen.
• Sag dem Kunden Bescheid, wenn der Fix live ist. Done in Linear und live bei deinen Kunden können 2 verschiedene Tage sein.

Deskwoot, der Helpdesk, den wir bauen, übernimmt mit seiner Linear-Integration das Verknüpfen und den Status. Alles andere in diesem Leitfaden funktioniert mit jedem Tool, das du nutzt.

Warum Bugs zwischen Helpdesk und Linear verloren gehen

Der Support arbeitet im Helpdesk, die Entwicklung in Linear. Ein Bug-Report wandert einmal vom einen zum anderen, und danach laufen die 2 Einträge auseinander.

Niemand ist für den Rückweg zuständig

Der Agent, der das Issue erstellt hat, macht mit den nächsten 40 Tickets weiter. Der Entwickler schließt das Issue und macht ebenfalls weiter. Bringt nichts den Status zurück ans Ticket, merkt der Kunde es erst, wenn er es noch einmal versucht.

Linear beschreibt in einem Beitrag darüber, wie sein Customer-Experience-Team in Linear arbeitet, wie sein eigener Support das vermeidet. Wird ein Issue als Done markiert, öffnet sich die verknüpfte Support-Konversation wieder mit einer Notiz. Das Support-Team meldet sich dann beim Kunden, teilt den Fix und lässt sich bestätigen, dass er funktioniert.

Status-Updates von Hand

Ohne Verknüpfung öffnet jemand im Support jeden Morgen Linear, prüft eine Liste von Issues und kopiert den Status in die Tickets. Das kostet Zeit, fällt an vollen Tagen aus und stimmt am Nachmittag schon nicht mehr.

Derselbe Bug, 20-mal

Wenn Agenten nicht sehen, was die Entwicklung schon weiß, erstellt jeder sein eigenes Issue. Die Entwickler verbringen dann Zeit damit, Duplikate zusammenzuführen. Und die echte Größe des Problems bleibt versteckt, verteilt auf 5 Issues mit jeweils 1 oder 2 Meldungen.

Bevor du ein Issue erstellst

Nicht jedes Ticket, in dem „es geht nicht“ steht, ist ein Bug. Die Entwicklung verliert schnell das Vertrauen in die Reports des Supports, wenn sich die Hälfte davon als Frage entpuppt, wie eine Funktion gedacht ist.

3 Fragen vorab

1. Kannst du es nachstellen? Probier es selbst, mit demselben Plan, demselben Browser oder derselben App-Version wie der Kunde.
2. Soll das so sein? Prüf dein Hilfecenter und die Produktdoku. Ist das Verhalten dokumentiert, ist es eine Frage zur Funktion, und der Kunde braucht vielleicht eine bessere Erklärung.
3. Gibt es schon ein Issue? Durchsuche Linear nach den Wörtern, die ein Entwickler in einem Titel benutzen würde, etwa „export“ oder „CSV“, und nach dem Bildschirm, auf dem es passiert.

Ist die dritte Antwort ja, verknüpfe das Ticket mit diesem Issue und schreib alles Neue als Kommentar dazu. Erstelle nur dann ein neues Issue, wenn nichts passt.

Was einen Bug-Report ausmacht, mit dem Entwickler arbeiten können

Die Richtlinien für Bug-Reports von Mozilla wurden für Firefox geschrieben und taugen für jedes Softwareteam. Die Zusammenfassung soll das Problem erklären, nicht deinen Vorschlag für die Lösung, und der Report soll Fakten von Vermutungen trennen.

Eine Vorlage, die deine Agenten kopieren können

• Titel: was schiefgeht und wo. „CSV-Export lässt die letzte Zeile weg, wenn ein Filter gesetzt ist“ ist besser als „Export kaputt“.
• Schritte zum Nachstellen: nummeriert, so kurz wie möglich, und ob es jedes Mal passiert oder nur manchmal.
• Erwartetes Ergebnis: was hätte passieren sollen.
• Tatsächliches Ergebnis: was passiert ist, mit dem genauen Fehlertext oder einem Screenshot.
• Umgebung: Plan, Browser oder App-Version, Gerät und die Uhrzeit, damit Entwickler es in den Logs finden.
• Auswirkung: wie viele Kunden es gemeldet haben, ob sie blockiert sind und welchen Workaround du gefunden hast.
• Was der Support schon versucht hat: Cache geleert, anderer Browser, anderes Konto.

In Linears eigenem CX-Beitrag enthalten Bugs, die das Support-Team aus Slack meldet, die genauen Worte des Kunden und einen Link zurück zur ursprünglichen Konversation. Nimm beides auch in deine Reports auf. Das Zitat zeigt Entwicklern, was der Kunde gesehen hat, in seinen eigenen Worten.

Lass personenbezogene Daten weg

Was du in Linear einfügst, bleibt in Linear. Bittet dich ein Kunde später, seine Daten zu löschen, kommt dein Helpdesk an diese Kopie nicht heran.

Schreib also „ein Kunde mit Jahresplan“ statt eines Namens, und lass E-Mail-Adressen, Telefonnummern und Bestellnummern weg, die Entwickler nicht brauchen. Müssen sie sich das Konto ansehen, folgen sie dem Link zurück zum Ticket.

Ein Bug, ein Issue, viele Tickets

Die nützlichste Gewohnheit in diesem ganzen Leitfaden: Jedes Ticket zum selben Bug wird mit demselben Linear-Issue verknüpft. Die Entwickler haben einen Ort zum Arbeiten, und du hast einen Ort zum Nachsehen, wenn der Fix kommt.

Lass die Zahl sprechen

Ein Issue mit 20 verknüpften Tickets spricht in einem Planungsmeeting für sich. Bitte die Agenten um einen kurzen Kommentar am Issue, wenn eine neue Meldung etwas Neues bringt, etwa einen anderen Browser oder einen Kunden, der komplett blockiert ist.

Spar dir Kommentare, die nur „+1“ sagen. Das verknüpfte Ticket zählt schon mit.

Duplikate, die trotzdem durchrutschen

Ein paar werden es. In Linear markiert ein Entwickler ein Issue als Duplikat des anderen. Seit Mai 2026 bekommt das Issue dadurch einen eigenen Status Duplicate, und Linear verschiebt seine Anhänge und Kundenanfragen zum Original, wie das Changelog von Linear erklärt.

Springt das Issue eines Tickets auf Duplicate, verknüpfe das Ticket auch mit dem ursprünglichen Issue. Sonst folgt das Ticket einem Issue, an dem niemand mehr arbeiten wird.

Wo neue Meldungen in Linear landen

Ein Linear-Team kann Triage einschalten, einen eigenen Posteingang für dieses Team. Issues, die eine Integration oder jemand außerhalb des Teams erstellt, landen zuerst dort. Jemand aus dem Team nimmt jedes davon an, lehnt es ab, markiert es als Duplikat oder stellt es zurück.

Frag deine Entwickler, ob sie Triage nutzen und wer es prüft. Ein sauberer Report mit der Auswirkung ganz oben wird schneller angenommen.

Kunden auf dem Laufenden halten, ohne Updates einzufügen

Kunden brauchen nicht jede Statusänderung. Sie müssen wissen, dass du den Bug bestätigt hast, dass jemand daran arbeitet und dass du dich meldest, wenn er behoben ist.

Was das Ticket bei welchem Linear-Status tut

Die Standardstatus von Linear sind Backlog, Todo, In Progress, Done und Canceled, und jedes Team kann eigene hinzufügen. Eine einfache Zuordnung für die Seite des Tickets:

• Triage, Backlog oder Todo: Das Ticket wartet auf die Entwicklung. Pausiere seine SLA-Uhr, damit die SLA nicht reißt, während die Entwicklung arbeitet.
• In Progress: Dem Kunden gibt es noch nichts zu sagen.
• Done: Das Ticket geht zurück an einen Agenten, der prüft, ob der Fix live ist.
• Canceled oder Won't fix: Der Agent schreibt eine ehrliche Antwort, mit einem Workaround, falls es einen gibt.
• Duplicate: Verknüpfe das Ticket mit dem ursprünglichen Issue und warte weiter.

Done heißt nicht immer live

Linear sagt es in seiner Doku zu Releases klar: Der Status Done eines Issues heißt nicht immer, dass der Fix bei deinen Kunden angekommen ist. Der Pull Request liegt vielleicht noch auf Staging, oder ein Fix für die mobile App wartet auf das nächste App-Release.

Wer das Ticket zurückbekommt, prüft den Fix also in der Produktion oder fragt den Entwickler, bevor er dem Kunden schreibt.

Wie lange Kunden warten könnten

Frag deine Entwickler nach ihren Zielen und teile sie mit deinem Team. Linear veröffentlicht seine eigenen in einem Beitrag über seine Zero-Bugs-Policy: 48 Stunden für Bugs mit hoher Priorität und 7 Tage für den Rest.

Die Zahlen deines Teams werden anders aussehen. Sie helfen Agenten, ehrliche Erwartungen zu setzen, aber ein Ziel ist kein Datum, das du einem Kunden nennst.

Die Nachricht, wenn du den Bug bestätigst

„Danke für die klare Beschreibung. Wir können den Fehler nachstellen, und unsere Entwickler haben ihn auf ihrer Liste. Ich schreibe dir hier, sobald der Fix live ist, du musst also nicht nachfragen.“

Nenn ein Datum nur, wenn sich deine Entwickler darauf festgelegt haben. Ein verpasstes Datum kostet mehr Vertrauen als gar keins.

Die Nachricht am Tag des Fixes

„Gute Nachricht: Seit heute Morgen enthält der CSV-Export wieder jede Zeile, auch mit Filtern. Kannst du es noch einmal versuchen und mir sagen, ob es bei dir klappt? Danke für deine Meldung, deine Beschreibung hat uns geholfen, den Fehler schnell zu finden.“

Nenn das Problem, das der Kunde gemeldet hat, und bitte ihn um eine Bestätigung. Eine Antwort wie „klappt jetzt“ schließt das Ticket wirklich.

So funktioniert es in Deskwoot

Deskwoot ist der Helpdesk, den wir bauen. Ist Linear verbunden, erstellen oder verknüpfen Agenten Issues direkt aus dem Ticket, und der Status des Issues kommt von selbst zurück ans Ticket.

Einrichten

1. Schalte Tickets unter Einstellungen > Tickets ein. Tickets und Linear gehören zum Enterprise-Plan.
2. Klick unter Einstellungen > Integrationen > Linear auf Linear verbinden. Du brauchst das Recht Integrationen verwalten.
3. Ein Admin des Linear-Workspace erlaubt Deskwoot den Zugriff und wählt die Teams, die es sehen darf. Wähl dann das Team für neue Issues.

Agenten brauchen kein Linear-Konto, weil Deskwoot als App beitritt. Der Hilfeartikel zu Linear zeigt jeden Schritt.

Was deine Agenten bekommen

• Aus dem Ticket erstellen oder verknüpfen. Verknüpfe ein Issue über seinen Key, etwa ENG-123, oder klick auf Issue erstellen. Bug-Report mit Copilot entwerfen schreibt den Report. Copilot hat die Anweisung, Name und Kontaktdaten des Kunden wegzulassen, und der Agent prüft den Entwurf.
• Der Status am Ticket. Jede Statusänderung schreibt eine Zeile in jedes verknüpfte Ticket. Eine Suche nach dem Key findet jedes verknüpfte Ticket, deine Liste für den Tag des Fixes.
• 2 fertige Regeln. Die eine setzt einen Ticketstatus, wenn ein Issue erstellt oder verknüpft wird, etwa einen Status, der die SLA pausiert. Die andere gibt das Ticket mit einer Notiz an die Person zurück, die das Issue verknüpft hat, sobald es fertig ist.
• Bekannte Bugs. Meldet ein Kunde ein Problem, durchsucht Copilot die offenen Issues des Teams für neue Issues und der Teams, mit denen deine Tickets verknüpft sind. Ein Datum für den Fix soll es nur nennen, wenn das Issue eines enthält, das noch bevorsteht.

Kunden sehen das Issue und seine Statuszeilen nie.

Was es kostet

Enterprise kostet 12 $ pro Agent und Monat oder 9,60 $ bei jährlicher Zahlung, 10 Agenten zahlen also 120 $ im Monat. Linear zu verbinden kostet nichts extra (siehe Preise). Hacker, Startup und Business enthalten es nicht, und jeder Deskwoot-Workspace verbindet einen Linear-Workspace.

Probier es an einem Bug aus

Nimm den offenen Bug, hinter dem die meisten Tickets stehen. Registrier dich, verbinde Linear, verknüpfe diese Tickets mit seinem Issue und speichere die fertige Regel für erledigte Issues. Die Enterprise-Testphase über 7 Tage braucht keine Kreditkarte, gilt für bis zu 30 Plätze, deinen eingeschlossen, und enthält Linear.