Ein Kunde meldet: „Der Export ist kaputt, weil die Vertragsnummer fehlt.” Das Feld könnte bereits vorgesehen sein, oder der Kunde braucht eine Erweiterung des funktionierenden Exports. Kläre Erwartungsgrundlage und tatsächliches Ergebnis, bevor du eine Kategorie auswählst.
Hier findest du eine Entscheidungskarte und Antwortbeispiele. Sie dienen der Einordnung einer Anforderung statt automatischer Fehlererkennung. Kunden beschreiben ihr Problem mit eigenen Worten; das Team prüft, wie sich das Produkt tatsächlich verhält.
Kläre die Grundlage des erwarteten Verhaltens
Frage nach dem Kundenziel und prüfe Funktionsbeschreibung, bestätigte Absprache oder früheres Ergebnis. Das sind unterschiedliche Quellen. Dokumentation kann einen anderen Tarif beschreiben, eine ältere Datei aus einem anderen Werkzeug stammen.
Vergleiche die Funktion und ihre Bedingungen, statt dich allein auf einen vertrauten Schaltflächennamen zu verlassen. Halte fest, welche Quelle auf dieses Konto zutrifft.
Fehlende Formulierung in einer Anleitung beweist kein korrektes Verhalten. Bewahrt das Speichern keine Änderung, prüfe das erwartete Ergebnis des vollständigen Schritts.
Zugleich begründet Gewöhnung an ein anderes Produkt keine Fähigkeit dieses Werkzeugs. Notiere das Kundenziel getrennt von der Bewertungsgrundlage. So bleibt erkennbar, welcher Vergleich durchgeführt wurde.
Im Exportbeispiel suche die Feldbeschreibung und bestätige die ausgewählte Dateivariante. Versprich nicht sofort das Hinzufügen der Vertragsnummer. Widersprechen sich Dokumentation und Konfiguration, bewahre beide Beobachtungen.
Die Klärung dieser Abweichung gehört zur Prüfung und ist kein Anlass, dem Kunden die Verantwortung zuzuschieben. Eine passende Erklärung folgt erst aus dem konkreten Vergleich.
Unterscheide Fehler, Konfiguration und zusätzlichen Umfang
Diese Tabelle ordnet die erste Entscheidung, ersetzt aber keine Prüfung. „Zu prüfen” ist bei unbekannten Bedingungen ein ehrliches Ergebnis.
Benenne es nicht nur deshalb als Funktionswunsch, um die Fehlerliste zu verkürzen. Der Kunde braucht weiterhin eine Antwort auf das Problem. Bewahre den Grund, auch wenn sich die erste Einordnung später ändert.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Feststellung | Weitere Kontrolle |
|---|---|
| Beschriebenes Verhalten liefert das erwartete Ergebnis nicht | Möglichen Fehler unter denselben Bedingungen prüfen. |
| Die Funktion erfordert eine andere Einstellung oder Berechtigung | Voraussetzung prüfen und vorhandenen Nutzungsweg erklären. |
| Gewünschtes Ergebnis liegt außerhalb des aktuellen Umfangs | Bedarf als Änderungsvorschlag festhalten. |
| Erwartung oder tatsächliches Ergebnis sind unklar | Einordnung bis zu den nötigen Fakten offen lassen. |
Tarifgrenze, fehlende Berechtigung und Ausführungsfehler brauchen verschiedene Antworten. Bezeichne nicht alles als Störung und empfehle keinen höheren Tarif ohne Kontrolle.
Löst eine vorhandene Funktion das Anliegen, erkläre den zutreffenden Weg. Eine Umgehung soll den Bedarf erfüllen, ohne eine neue unbelegte Zusage zu erzeugen. Ein ähnlicher Knopf in einem anderen Konto beweist noch keinen Zugriff hier.
Sammle nur die für die Einordnung nötigen Fakten
Fordere nicht sofort vollständige Aufzeichnung, sämtliche Protokolle und weitere Bilder. Beginne beim Export mit Variantenname, erwartetem Feld und Beschreibung der erhaltenen Datei.
Ist eine frühere Absprache relevant, bitte um den passenden Abschnitt. Sammle nicht den gesamten Vertrag zur Prüfung einer Funktionszusage. Nutze zunächst Angaben, die schon im Gespräch vorliegen.
- Das Kundenergebnis benennen.Notiere, was nach dem Schritt möglich sein soll, ohne eine bestimmte Lösung vorzuschreiben.
- Die Erwartungsgrundlage prüfen.Finde Beschreibung oder Absprache zur Funktion und den zutreffenden Bedingungen.
- Das Ergebnis vergleichen.Kläre den tatsächlichen Ausgang derselben Handlung und noch unbekannte Fakten.
- Kategorie und Grund festhalten.Nenne Fehler, vorhandenen Nutzungsweg, Änderungsvorschlag oder weitere Prüfung.
Nach bestätigtem Fehler nutze die Aufgabenvorlage für einen Kundenfehler, statt hier einen vollständigen Bericht auszubauen. Die Einordnung bleibt kurz. Eine weitere Person soll den gewählten Weg und seine Informationsgrundlage verstehen. Damit ist auch eine spätere Kategorieänderung nachvollziehbar und wirkt nicht wie eine unbegründete Verschiebung.
Beispiel nach dem ersten Gespräch: „Bedarf: Export mit der Vertragsübersicht verbinden. Beobachtung: In der gewählten Datei fehlt die Nummer; die Feldbeschreibung wurde noch nicht geprüft. Einordnung: offen, Vergleich mit dem Umfang dieser Variante steht aus.” Das benennt die nächste Kontrolle ohne vorgetäuschte Diagnose. Bestätigt eine weitere Person die Beschreibung, ergänze Grundlage und Ergebnis der Prüfung. Ersetze die frühere Beobachtung nicht durch „gelöst”, solange der Kundenbedarf offen bleibt. Halte fest, welche Unklarheit tatsächlich beantwortet wurde.
Trenne Regression und neuen Bedarf in derselben Nachricht
Im fiktiven Beispiel enthielt der Export früher eine vereinbarte Datumsspalte, die jetzt fehlt. Zusätzlich wünscht der Kunde eine neue Vertragsnummernspalte.
Prüfe die erste Abweichung als mögliche Regression, die zweite als Erweiterung. Eine Nachricht erfordert keine gemeinsame Kategorie für alle enthaltenen Bedürfnisse. Halte jeden gewünschten Ausgang separat erkennbar.
„Es ging früher” ist ein wichtiger Hinweis, braucht aber Vergleich. Prüfe, ob die Datei aus derselben Funktion stammt und Konto sowie Einstellungen vergleichbar sind. Auch ein früherer unbeabsichtigter Effekt muss erklärt werden.
Versprich seine Wiederherstellung nicht vor der Entscheidung zum vorgesehenen Produktverhalten. Historische Ausgabe ist nicht automatisch eine angenommene Anforderung.
Kehren ähnliche Fälle zurück, prüfe wiederkehrende Kundenmeldungen. Die Kontaktzahl beweist nicht, dass jeder Wunsch denselben Fehler betrifft.
Gleicher Wortlaut kann andere Bedingungen beschreiben. Bewahre sinnvolle Verbindungen ohne eigenständige Bedürfnisse zu verlieren. Eine vertraute Beschwerde ist vor Kontrolle ihres Ergebnisses noch nicht vollständig verstanden. Ist der Fehler bestätigt, hilft die Zahl verschiedener betroffener Kunden bei der Reihenfolge der Korrekturen, wie unser Leitfaden zu Schweregrad und Priorität bei Fehlern zeigt.
Erkläre die Feststellung ohne Umsetzungsversprechen
Möglicher Fehler: „Die Beschreibung sieht dieses Feld im ausgewählten Export vor, die erhaltene Datei enthält es jedoch nicht. Wir geben diese Abweichung zur Prüfung weiter. Ursache und Korrekturtermin sind noch nicht bestätigt.” Nutze das nur mit zutreffender Grundlage und tatsächlicher Übergabe. Eine bloß geplante Weiterleitung darf nicht als ausgeführter Schritt erscheinen.
Vorhandene Möglichkeit: „Dieses Feld steht in einer anderen Exportvariante zur Verfügung. Wähle unter den geprüften Bedingungen diese Variante und vergleiche das Ergebnis.” Nenne konkrete Schritte nach ihrer Bestätigung. Stelle keine Anleitung eines anderen Tarifs als zugängliche Lösung auf dem Kundenkonto dar. Ist eine Voraussetzung ungeklärt, benenne sie ausdrücklich.
Neuer Bedarf: „Der aktuelle Export umfasst keine Vertragsnummer. Wir haben den Bedarf zur Verbindung mit deiner eigenen Übersicht und dessen Anwendung festgehalten. Die Aufnahme des Vorschlags ist noch keine Umsetzungsentscheidung.” Findet kein weiterer Review statt, suggeriere keine bereits geplante Arbeit. Die Antwort muss euren tatsächlichen Umgang mit dem Vorschlag wiedergeben. Wie du eine solche Sichtung organisierst, wenn sich viele ähnliche Bedürfnisse sammeln, zeigt der Leitfaden dazu, wie du Supportanfragen für die Produktplanung nutzt.
Bewahre den Einordnungsgrund an der Aufgabe in Meetlead
In Meetlead Projekte hältst du Beschreibung, Aufgabentyp, Kommentare und Ticketverknüpfung zusammen. Notiere Bedarf, verglichenes Verhalten und Einordnungsgrund.
Das Team wählt den Typ; er ist keine automatische Diagnose. Die Arbeit benötigt Konto, installierte Anwendung und passende Berechtigungen. Beschreibe den vorgeschlagenen Umfang statt eine nicht vorhandene Kategorie zu versprechen.
Der Weg von der Supportmeldung zur Aufgabe bewahrt den Kundenkontext. Eine Typänderung nach neuen Erkenntnissen darf ihn nicht verlieren.
Ergänze kein Lieferdatum, das niemand vereinbart hat. Ein Warteschlangeneintrag ist keine bestätigte Produktzusage. Halte offene Prüfungsfragen sichtbar, damit niemand eine vorläufige Einordnung als endgültigen Befund übernimmt.
- Kundenbedarf und vorgeschlagene Lösung sind getrennt.
- Die Erwartungsgrundlage gilt für die relevanten Bedingungen.
- Die Einordnung enthält einen kurzen Grund oder eine offene Frage.
- Gemischte Bedürfnisse wurden nicht auf ein Etikett reduziert.
- Die Antwort macht aus dem Eingang keine Lieferzusage.
Abgeschlossene Arbeit braucht einen eigenen Nachweis der Aufgabenerledigung. Die erste Einordnung bestätigt noch kein korrigiertes Ergebnis. Bewahre eine Prüfmöglichkeit für eine zweite Person vor der Lösungsnachricht an den Kunden. Die Kategorie hilft bei der Weiterleitung; erst das kontrollierte Ergebnis stützt eine Aussage über den Erfolg.
Fragen zu mehrdeutigen Meldungen
Entscheidet die Kundenbezeichnung „Fehler” über die Kategorie? Nein. Notiere das Problem und prüfe den erwarteten Ausgang.
Verbessere nicht nur den Wortlaut zulasten des Verständnisses. Die Einordnung folgt Fakten statt der Stärke einer Formulierung.
Bedeutet fehlende Dokumentation einen Funktionswunsch? Nicht automatisch. Kläre vorgesehenes Verhalten mit der zuständigen Person und prüfe vorhandene Absprachen.
Eine fehlende Beschreibung ist eine Informationslücke statt einer fertigen Umfangsentscheidung. Halte die Frage während der Kontrolle offen.
Kann die Kategorie später wechseln? Ja, wenn neue Fakten die Bewertung ändern. Halte einen kurzen Grund und den zugehörigen Kontext fest.
Stelle den Etikettwechsel nicht als erledigte Arbeit oder Terminbestätigung dar. Die nächste Person braucht die Erkenntnis, die diesen Wechsel erklärt.
Atlassian beschreibt Funktionswünsche als Vorschläge für neue Möglichkeiten oder Verbesserungen. Daraus folgt keine automatische Umsetzung: Feature Requests einordnen.
