Jede Agentur kennt diese Mail. Betreff „Website-Problem“, Text „das Formular auf der Kontaktseite funktioniert auf meinem Rechner nicht“. Von: die Kundschaft, CC: deren Assistenz, zweimal weitergeleitet. Kein Browser, keine URL außer „die Kontaktseite“, keine Fehlermeldung, dafür ein Screenshot eines Word-Dokuments, in dem ein Screenshot steckt. Zwei abrechenbare Stunden später stellt sich heraus, dass eine Browser-Erweiterung schuld war.
Von der Kundschaft gemeldete Bugs gehören zum Agenturalltag: während der Entwicklung, in der UAT und bei jedem Wartungsvertrag. Über welchen Kanal sie kommen, entscheidet, ob sie Minuten kosten oder ganze Nachmittage.
Warum E-Mail der schlechteste Kanal ist
E-Mail verliert schon an der Quelle jeden technischen Kontext. Die Kundschaft beschreibt, woran sie sich erinnert, aus einer Umgebung, die du nicht siehst, über eine Seite, die du erraten musst. Dann fangen die eigentlichen Kosten an:
Die Rückfrageschleife. „Welcher Browser? Können Sie mir den genauen Link schicken? Worauf haben Sie zuerst geklickt?“ Jede Runde kostet einen Kalendertag und ein Stück vom Wohlwollen der Kundschaft.
Kein gemeinsamer Stand. Die Kundschaft weiß nicht, ob du die Mail gesehen hast, ob jemand daran arbeitet oder warum das, was sie letzten Monat gemeldet hat, noch nicht behoben ist. Also hakt sie nach, und auch das Nachhaken will beantwortet werden.
Keine Grenzen zwischen Projekten. Zehn Wartungsverträge bedeuten Fehlerberichte von zehn Websites, durcheinander in einem Postfach. Jeden davon musst du von Hand zuordnen, in deinen Tracker übertragen und nachverfolgen.
Das Muster dahinter: Von der Kundschaft wird ein QA-Job verlangt (beobachten, dokumentieren, Kontext liefern), und dazu ist sie weder in der Lage noch verpflichtet. Also hör auf, danach zu fragen.
Das Widget-Modell
Bring die Meldefunktion direkt auf die Website der Kundschaft. Ein kleiner schwebender Button auf jeder Seite: Die Kundschaft klickt ihn an, schreibt einen Satz, kreist das Problem auf Wunsch auf einem Screenshot ein und sendet ab. Alles andere erfasst das Tool im selben Moment: URL der Seite, Browser, Betriebssystem, Gerät, Viewport, Console-Logs mit markierten Fehlern, Netzwerk-Requests mit hervorgehobenen Fehlschlägen und ein Session-Replay dessen, was bis zum Bericht passiert ist.
Mit BugDump ist die Installation ein Script-Tag pro Website:
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="site-specific-key"></script>Was im Agenturalltag zählt:
Ein Projekt pro Website. Jedes Projekt hat seinen eigenen API-Key, sein eigenes Board und seinen eigenen Berichtsverlauf. Nichts gerät durcheinander. Der Ultra-Plan erlaubt bis zu 100 Projekte, genau für diese Art der Nutzung.
White-Labeling. In den bezahlten Plänen verschwindet das BugDump-Branding aus dem Widget. Es wirkt wie ein Teil der Website, die du gebaut hast, nicht wie ein angeschraubtes Fremdteil.
Passend zur Website. Theme (hell/dunkel/automatisch), Button-Icon, Position und jeder Text der Oberfläche sind konfigurierbar, bis hin zur vollständigen Übersetzung für Websites, die nicht auf Englisch sind.
Lade während der UAT zum Melden ein. Eine Hinweisblase neben dem Button („Problem entdeckt?“) macht aus Review-Runden mit einem PDF voller kommentierter Screenshots strukturierte Berichte, die du einen nach dem anderen abarbeitest.
Für die Kundschaft schrumpft das Ganze auf: Problem sehen, klicken, einen Satz tippen, fertig. Kein Login, kein Formular und nie wieder „Welchen Browser benutzen Sie?“.
Was sich für dich ändert
Berichte kommen diagnosefähig an. Der Console-Fehler und der fehlgeschlagene Request stehen im Bericht. Der Fehlalarm durch eine Browser-Erweiterung zeigt sich nach Minuten statt nach einem Neuaufbau der Website. „Nicht reproduzierbar“ verschwindet weitgehend, weil du den Fehler nachliest, statt ihn nachzustellen.
Die Triage wird zum sichtbaren Stand. Die Berichte jedes Projekts landen auf einem Kanban-Board: Neu, In Arbeit, Fertig. Ruft die Kundschaft wegen des Problems von letzter Woche an, genügt ein Blick, statt im Postfach zu graben. Doppelte Berichte sammeln sich bei derselben Aufgabe und zeigen nebenbei, wie schwer ein Problem wiegt.
Bugs fließen in deine Delivery-Pipeline. Integrationen leiten Berichte dorthin, wo dein Team ohnehin arbeitet: Slack oder Discord, damit alle Bescheid wissen, GitHub Issues, Jira oder Asana für die, aus denen Tickets werden. Kein Abtippen, kein Bug, der zwischen Postfach und Backlog verloren geht.
Den ersten Durchgang übernimmt ein Assistent. Über den MCP-Server von BugDump lesen Claude Code oder Cursor die Berichte eines Projekts, samt Console-, Netzwerk- und Replay-Kontext. Bei einem Wartungsvertrag ist „Fass die Berichte dieser Woche zur Meridian-Website zusammen und markiere alles, was nach einer Regression aussieht“ eine echte Anfrage für Montagmorgen.
Die Übergabe regeln
Agenturen stehen und fallen mit sauberen Projektabschlüssen. Zwei Gewohnheiten helfen:
Zugriff pro Projekt begrenzen. Keys gelten pro Projekt, also sieht jemand von extern, der an einer Kundenwebsite mithilft, nur dieses Projekt. Steigt jemand aus, rotierst du die MCP-Keys sofort in den Einstellungen.
Die Wartung ausdrücklich klären. Übernimmt die Kundschaft die Website selbst, übertrag ihr entweder ein eigenes Projekt oder entferne das Script-Tag bei der Übergabe. Ein Widget, das in ein Konto meldet, auf das niemand schaut, ist schlimmer als gar keins. Halte die Erwartungen im Vertrag fest.
Was es für Wartungsverträge bedeutet
Ein Widget für Fehlerberichte verbessert ganz nebenbei die Wirtschaftlichkeit von Wartungsverträgen. Die Diagnose geht schneller, weil der Kontext mit dem Bericht kommt. Der Kommunikationsaufwand sinkt, weil der Stand auf einem Board steht statt in Mail-Threads. Und der Berichtsverlauf selbst wird zum Dokument: eine Liste von allem, was gefunden und behoben wurde, bei der Vertragsverlängerung nützlicher, als ein Mail-Archiv es je ist.
Die Kosten sind klein und kalkulierbar: ein Script-Tag pro Website und eine Abrechnung nach Volumen statt pro Kopf. Dein ganzes Team und das der Kundschaft sind dabei, ohne dass jemand Lizenzen nachzählen muss.
Die Mail wird trotzdem manchmal kommen. Aber „Klicken Sie einfach auf der Seite auf den Bug-Button und schicken Sie die Meldung ab“ ist eine Antwort in einer Zeile, und der Bericht, der dann zurückkommt, ist einer, den du wirklich beheben kannst.
Fehlerberichte in QA und UAT: So melden Testpersonen ohne Technikwissen brauchbar – warum die Tabelle aus einer UAT-Runde zur Hälfte unbrauchbar ist und wie der Meldekanal die Belege behält.
So fügst du deiner Website einen Button für Fehlerberichte hinzu – Script-Tag, npm-Paket oder Initialisierung im Code, mit Tipps zur Konfiguration und typischen Stolperfallen.
Schlanker Bug-Tracker für kleine Teams: wenn Jira zu viel ist – warum schwere Issue-Tracker kleine Teams ausbremsen und was ein schlankes Setup braucht.