Tickets und Feature Requests: der Dialog als Teil des Produkts
Wie Sie ein Ticket in Narraya öffnen, eine Funktion vorschlagen und warum der Dialog mit den Autorinnen und Autoren integraler Bestandteil des Produkts ist. Ehrliche Zeiten, menschliche Antworten.
Es gibt zwei gegensätzliche Erfahrungen, wenn etwas in einer Software aufhört zu funktionieren. Die erste: Sie öffnen ein Ticket, erhalten eine automatische E-Mail, dann Stille, dann — nach fünf Tagen — eine vage Antwort, die Sie bittet, „den Browser neu zu starten". Die zweite: Sie öffnen ein Ticket, erhalten in einem oder zwei Tagen eine menschliche Antwort, das Problem wird ernst genommen, und manchmal sogar gelöst. Der Unterschied zwischen den beiden Erfahrungen ist nicht technisch: er ist kulturell.
Narraya ist ein junges, kleines Projekt, gebaut von wenigen Händen. Wir können uns die erste Erfahrung nicht leisten. Und ehrlich gesagt wollen wir sie auch nicht.
Der Tickets-Kanal, für wenn etwas schiefgeht
Die Tickets in Narraya dienen zwei Dingen: einen Bug zu melden (etwas, das nicht wie vorgesehen funktioniert) und um Hilfe zu bitten (etwas, das Sie nicht verstehen oder schaffen). Sie öffnen sich über eine Schaltfläche, die auf fast jeder Seite der Anwendung im Menü „Hilfe" vorhanden ist. Die Antwort kommt per E-Mail, mit der internen Spur des Tickets, die immer von Ihrem Konto aus zugänglich ist.
Kein Chatbot, der trainiert ist, Sie abzuschütteln. Keine FAQ, durch die Sie sich vor dem Formular durchquälen müssen. Der erste Kontakt ist menschlich — zumindest solange die Größe des Projekts es erlaubt, und wir verpflichten uns, dafür zu sorgen, dass es so bleibt, so lange wie möglich.
Wie man ein Ticket öffnet, das eine echte Antwort erhält
-
Beschreiben Sie, was Sie taten.
„Ich schrieb ein Kapitel" reicht nicht. „Ich exportierte das dritte Kapitel als DOCX" ist besser. Ein Satz zum Kontext.
-
Erzählen Sie, was passiert ist.
Das beobachtete Verhalten: genaue Fehlermeldung, Schritt, der nicht startet, Funktion, die seltsam reagiert. Was Sie gesehen haben, nicht was Sie geschlussfolgert haben.
-
Sagen Sie, was Sie stattdessen erwartet hatten.
Einfach: „Ich erwartete, die DOCX-Datei zum Download zu erhalten, ich erhielt eine Fehlerseite". Das hilft uns zu verstehen, ob es ein Bug ist oder ein Missverständnis.
-
Wenn möglich, hängen Sie einen Screenshot an.
Er sagt mehr als tausend Worte. Die Anhang-Schaltfläche ist im Ticket-Formular. Dateien bis 10 MB.
-
Achten Sie auf Ihre E-Mail.
Die Antwort kommt dort an und kann Sie um weitere Details bitten. Antworten Sie aus derselben E-Mail: Der Faden bleibt geordnet.
Wir versprechen keine Antwort innerhalb von 24 Stunden. Ein kleines Projekt kann diesen Service-Level nicht halten, ohne etwas anderes zu opfern — wie die Produktentwicklung, die alle erwarten. Wir antworten im Schnitt innerhalb von 2–4 Werktagen für nicht dringende Tickets, und deutlich schneller für Bugs, die eine Funktion vollständig blockieren. Es ist ein realistisches Versprechen, das wir halten können. Versprechen, die wir nicht halten können, vermeiden wir, denn sie sind eine Form von Täuschung.
Die Feature Requests: die Stimme der Autorinnen und Autoren
Es gibt einen weiteren, getrennten und wichtigen Kanal: die Feature Requests. Es sind öffentliche Vorschläge für neue Funktionen — oder Verbesserungen bestehender — die jeder Nutzer öffnen kann. Jede Feature Request ist für alle Narraya-Nutzer sichtbar und abstimmbar: ein „+1", wenn die Idee Ihnen dient, ein Kommentar, wenn Sie Ihren Standpunkt hinzufügen wollen.
Es ist keine direkte Demokratie — am Ende entscheiden wir, was wir entwickeln, indem wir Prioritäten, Aufwand und Produktkohärenz abwägen. Doch es ist auch kein Theater: Wir lesen jede Anfrage, die Stimmen wiegen wirklich, und viele in den letzten Monaten erschienene Funktionen sind genau dort entstanden.
Drei Arten von Rückmeldungen, die uns wirklich helfen
Ein reproduzierbarer Bug
„Wenn ich hier klicke, passiert dies, obwohl jenes passieren sollte." Mit Schritten, die jeder wiederholen kann. Es ist die Art Ticket, die wir am schnellsten lösen, weil sie am wenigsten mehrdeutig ist.
Eine gut begründete fehlende Funktion
Nicht „es wäre schön, X zu haben", sondern „wenn ich Y mache, bin ich gezwungen, einen externen Schritt zu gehen und verliere dreißig Minuten". Die Begründung macht die Anfrage bewertbar. Ohne Begründung bleibt sie ein abstrakter Wunsch.
Eine UX-Verbesserung
„Das Figurenblatt ist drei Klicks von dort entfernt, wo ich schreibe — könnte es eine Schaltfläche neben dem Kapitel sein?". Kleine operative Vorschläge, die echte Arbeitstage verbessern. Oft die wertvollsten, weil sie aus realer Nutzung entstehen.
Was KEINE nützliche Feature Request ist
Sagen wir es klar: „Macht es wie [andere Software]" ist keine Feature Request. Jedes Produkt hat eine Philosophie, und Narraya hat seine. Wenn Ihnen etwas fehlt, interessiert uns zu wissen, warum es Ihnen fehlt — das echte Problem, das es lösen würde — nicht ein generischer Verweis auf ein Konkurrenzwerkzeug. Dieselbe Funktion, gedacht innerhalb einer anderen Philosophie, kann etwas anderes werden.
Und eine weitere Klarstellung: Anfragen, die unserer Grundphilosophie widersprechen — zum Beispiel „ich will, dass die KI das Kapitel an meiner Stelle schreibt" — lesen wir mit Respekt, doch wir werden sie nicht umsetzen. Nicht aus Sturheit: weil Narraya eine ausdrückliche Position dazu eingenommen hat, was es sein will und was nicht, und diese Position aufzugeben, um isolierte Anfragen zu befriedigen, hieße jene zu verraten, die uns gerade dafür gewählt haben.
Der Dialog als Teil des Produkts
Wir erhalten täglich Tickets und Anfragen. Manche bringen uns zum Lächeln (im guten Sinn), andere zum Nachdenken, andere wieder weisen auf Probleme hin, von deren Existenz wir ohne den Nutzer, der sie erlebt hat, nie etwas geahnt hätten. Dieser Austausch ist kein „Extra" des Produkts: er ist Teil des Produkts. Ohne Sie wäre Narraya eine schlechtere Software.
Um ein Ticket zu öffnen oder eine Funktion vorzuschlagen, betreten Sie Narraya und suchen Sie das Menü „Hilfe" in der unteren linken Ecke. Die erste Antwort kommt von Hand — in jeder Bedeutung des Wortes.