Schweregrad, Priorität, Fehler: Diese drei Begriffe tauchen bei jeder Durchsicht von Kundenmeldungen auf. Der Schweregrad beschreibt die technische Auswirkung, also was nicht mehr funktioniert und ob es eine Umgehung gibt. Die Priorität beantwortet eine andere Frage: wann sich das Team darum kümmert, mit Blick auf Kunden, Termine und die übrige Arbeit. Stehen beide Bewertungen in einem Feld, wird jede Diskussion über die Reihenfolge zum Streit darüber, wie sehr es wehtut.
Dieser Leitfaden richtet sich an kleine Teams, in denen dieselbe Person oft Tester, Support und Produktverantwortliche ist. Du bekommst eine Schweregradskala nach Auswirkung, die Belege, die eine Priorität wirklich erhöhen, und den Moment, in dem eine Meldung eine verantwortliche Person bekommt. Um die Reihenfolge der Antworten im Support-Postfach geht es hier nicht, nur um die Reihenfolge der Korrekturen im Produkt.
Schweregrad beschreibt die Auswirkung, Priorität den Zeitpunkt
Den Schweregrad bewertest du am Fehler selbst: Welche Funktion ist betroffen, sind Daten gefährdet, gibt es eine Umgehung? Diese Bewertung ändert sich selten, solange sich das Wissen über den Fehler nicht ändert. Die Priorität hängt vom Umfeld ab: Wie viele Personen stoßen auf den Fehler, blockiert er den Verkauf, startet nächste Woche eine Kampagne? Derselbe Fehler kann also einen festen Schweregrad und eine Priorität haben, die von Woche zu Woche steigt oder sinkt.
Die Bugzilla-Dokumentation trennt beide Felder: Der Schweregrad gibt an, wie ernst das Problem ist (von unbenutzbarer Anwendung bis zum kosmetischen Mangel), die Priorität legt die zugewiesene Person oder jemand fest, der die Arbeit des Teams steuert. Das beschreibt die Konvention eines Werkzeugs, keine Norm für jedes Team.
Eine praktische Regel: Den Schweregrad vergibt, wer den Fehler nachgestellt hat und seine Folgen kennt, die Priorität, wer über den Arbeitsplan entscheidet. Im kleinen Unternehmen kann das dieselbe Person sein, trotzdem lohnt es sich, beide Bewertungen getrennt festzuhalten. Nach einem Monat siehst du dann, ob ein Fehler wartete, weil er klein war, oder weil jemand ein ernstes Problem bewusst verschoben hat.
Eine Schweregradskala nach Auswirkung, nicht nach Gefühl
Schweregrade funktionieren nur, wenn alle sie gleich verstehen. Beschreibe sie deshalb über die Auswirkung, die Nutzer sehen, und nicht mit Wörtern wie dringend oder Katastrophe. Die Skala unten hat vier Stufen und zwei fiktive Beispiele: einen Onlineshop für Tee und eine Physiotherapiepraxis mit Onlinebuchung.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Stufe | Technische Auswirkung | Fiktiver Shop | Fiktive Praxis |
|---|---|---|---|
| S1 kritisch | Eine Kernfunktion fällt ohne Umgehung aus oder Daten gehen verloren beziehungsweise werden offengelegt | Die Zahlung scheitert bei jeder Zahlungsart | Das Formular speichert keine einzige Buchung |
| S2 schwer | Eine Kernfunktion arbeitet nur teilweise oder mit Umgehung | Ein Rabattcode greift erst nach dem Neuladen des Warenkorbs | Der Termin wird gespeichert, die Bestätigungsmail kommt nicht an |
| S3 mittel | Eine Nebenfunktion arbeitet falsch, das Ziel bleibt erreichbar | Die Sortierung nach Preis zeigt eine falsche Reihenfolge | Der Standortfilter zeigt einen zusätzlichen Eintrag |
| S4 gering | Kosmetik: Text, Ausrichtung, Tippfehler | Ein Tippfehler in der Fußzeile | Ein verschobenes Symbol in der Preisliste |
Stütze den Schweregrad auf das, was geprüft wurde, nicht auf die erste Kundennachricht. Aus „Nichts geht mehr“ wird nach dem Nachstellen oft S2 mit einfacher Umgehung. Trage die Bewertung deshalb erst ein, wenn die Vorlage für einen prüfbaren Fehlerbericht ausgefüllt ist und du Schritte, Umgebung und tatsächliches Ergebnis kennst.
Vier Kombinationen aus Schweregrad und Priorität
Am meisten lernst du aus Fällen, in denen beide Bewertungen auseinanderlaufen. Ein schwerer Fehler in einer selten genutzten Funktion kann warten, ein kleiner Fehler auf der Startseite ist manchmal dringender als ein Absturz im Verwaltungsbereich. Die Tabelle zeigt fiktive Beispiele und die Entscheidung, die du dazu festhalten solltest.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Kombination | Fiktives Beispiel | Entscheidung |
|---|---|---|
| Hoher Schweregrad, hohe Priorität | Die Zahlung scheitert am Starttag einer Kampagne | Sofort eine verantwortliche Person, laufende Arbeit wartet |
| Hoher Schweregrad, niedrige Priorität | Ein Export im alten Format friert das Panel ein; eine Person nutzt ihn einmal im Quartal und kennt eine Umgehung | Backlog mit beschriebener Umgehung und Prüftermin |
| Niedriger Schweregrad, hohe Priorität | Ein Banner auf der Startseite nennt ein falsches Enddatum der Aktion | Schnelle Korrektur, weil es ein Versprechen an Kunden ist |
| Niedriger Schweregrad, niedrige Priorität | Ein Tippfehler auf einer selten besuchten Unterseite | Backlog, zusammen mit einer anderen Änderung |
Ein Artikel von Sauce Labs beschreibt den Schweregrad als technische Auswirkung und die Priorität als Reihenfolge der Behebung nach Wirkung auf Nutzer und Geschäft, mit ähnlichen vier Kombinationen. Er schlägt außerdem eine Beispielskala von 1 bis 10 mit groben Beschreibungen der Bereiche vor. Das ist der Vorschlag eines Anbieters von Testwerkzeugen, kein Standard, also beschreibe die Stufen passend zu deinem Produkt.
Was die Priorität erhöht: Gespräche, Aufzeichnungen und Zielwirkung
Priorität ohne Belege wird schnell zur Belohnung für den schärfsten Ton. Sammle vor der Vergabe einige Fakten, die andere nachprüfen können. Jeder davon beantwortet die Frage, was das Warten auf die Korrektur kostet.
- Die Zahl verschiedener Kunden mit demselben Symptom, nicht die Zahl der Nachrichten.
- Eine Sitzungsaufzeichnung, die zeigt, an welchem Schritt jemand hängen blieb und ob er abbrach.
- Wirkung auf das Seitenziel: Steht der Fehler einem Kauf, einer Buchung oder einer Anfrage im Weg?
- Eine Umgehung, die der Support in einer einzigen Nachricht erklären kann.
- Ein externer Termin: Kampagne, Saison oder eine Veranstaltung, für die sich der Kunde angemeldet hat.
- Reichweite: ein Konto, ein Browser oder alle Nutzer.
Lies Meldungszahlen mit Vorsicht. Fünf Nachrichten einer Person bleiben ein Fall, und zehn ähnliche Beschreibungen können zwei verschiedene Fehler verbergen. Kehrt dasselbe Symptom trotz Korrekturen zurück, suche die gemeinsame Ursache mit dem Leitfaden zu wiederkehrenden Kundenanfragen. Sieh dir Aufzeichnungen mit einer konkreten Frage an, wie in Sitzungsaufzeichnungen gezielt analysieren beschrieben, statt sie auf gut Glück durchzuscrollen.
Wer entscheidet und wann ein Fehler eine verantwortliche Person bekommt
Die Triage, also die erste Sichtung neuer Fehler, läuft am besten in festem Rhythmus, etwa zweimal pro Woche, kritische Meldungen besprichst du sofort. Diese Reihenfolge passt zu einem Team aus wenigen Personen.
- Bestätigen, dass es ein Fehler ist.Vergleiche das Ergebnis mit dem vereinbarten Verhalten. Wünscht sich der Kunde etwas Neues, gehört es auf eine andere Liste als Korrekturen.
- Schweregrad bewerten.Das übernimmt, wer den Fehler nachgestellt hat, mit einer Stufe von S1 bis S4 und einem Satz Begründung.
- Belege anhängen.Verknüpfte Tickets, Aufzeichnung, Zielwirkung und Umgehung. Ohne sie bleibt die Priorität vorläufig.
- Priorität festlegen.Es entscheidet, wer für den Arbeitsplan zuständig ist, nicht wer die lauteste Nachricht geschrieben hat.
- Verantwortliche Person zuweisen.Hohe Priorität bekommt sofort jemanden. Niedrige kann im Backlog warten, aber mit dem Datum der nächsten Sichtung.
Den ersten Schritt klärt der Leitfaden Fehler oder Feature-Wunsch, denn ein Wunsch nach neuem Umfang sollte nicht mit Störungen auf derselben Liste konkurrieren. Die Reihenfolge der Antworten im Postfach ist eine eigene Frage: Ein Ticket kann eine hohe Priorität in der Support-Warteschlange haben, weil der Kunde eine Umgehung braucht, während die Korrektur im Produkt mittel eingestuft ist.
Beide Bewertungen in Meetlead Projekte festhalten
In Meetlead Projekte hat eine Aufgabe den Typ Fehler, eine Priorität (hoch, mittel oder niedrig) und eine verantwortliche Person. Du kannst sie mit dem Kundenticket, einer Sitzungsaufzeichnung und anderen Aufgaben verknüpfen und eine spätere Meldung desselben Problems als Duplikat markieren. Board und Backlog lassen sich nach Priorität, Typ oder Person filtern. Ein eigenes Feld für den Schweregrad gibt es nicht, also schreib ihn als feste erste Zeile in die Beschreibung.
Vorlage für den Anfang der Beschreibung: „Schweregrad: S2 – der Termin wird gespeichert, die Bestätigungsmail geht nicht raus. Umgehung: Der Support verschickt die Bestätigung manuell. Belege: 4 verknüpfte Tickets, 2 Aufzeichnungen. Zielwirkung: keine, Buchungen werden gespeichert.“
Die Priorität setzt ein Mensch; das Produkt bewertet keine Ticketinhalte und vergibt sie nicht automatisch. Der Änderungsverlauf der Aufgabe zeigt, wer die Priorität wann geändert hat, sodass sich die Entscheidung, einen schweren Fehler zu verschieben, später nachvollziehen lässt. Für die Arbeit in Projekte brauchst du ein Konto, die aktive App Projekte und passende Berechtigungen.
Fragen zu Schweregrad und Priorität
Darf der Kunde die Priorität eines Fehlers bestimmen? Der Kunde beschreibt am besten die Folgen für sich: was er tun wollte, was nicht ging und bis wann er es braucht. Das ist wertvoller Input, doch über die Reihenfolge der Korrekturen entscheidet das Team, das alle Meldungen gleichzeitig sieht. Halte seinen Termin als Beleg fest, nicht als fertige Priorität.
Wie viele Prioritätsstufen braucht ein kleines Team? Meist reichen drei: jetzt, im nächsten Arbeitszyklus und im Backlog. Mehr Stufen erzeugen Streit über die Grenzen. Verbesserungen, die keine Fehler sind, gehören nicht auf diese Skala; für sie passt eine eigene Methode besser, die der Leitfaden zu Prioritäten für UX-Verbesserungen beschreibt.
