Eine Support-Plattform: Wissensdatenbank, Tickets und E-Mail

Foto: Michael Mroczek · StockSnap (CC0 1.0), via Openverse

Support war in Xircuit lange die Stelle, an der ich mir selbst im Weg stand. Es gab eine Handvoll Screens, auf denen ein Betreiber Fragen stellen konnte, aber keinen Ort, an dem diese Fragen zusammenliefen, und keinen Weg, wie eine Antwort zuverlässig zurückfand. Wenn jemand aus einem der Studios oder aus einer der Praxen eine Mail schrieb, landete sie in einem Postfach, das niemand strukturiert abarbeitete. Das funktioniert, solange man drei Tester hat und alle kennt. Es funktioniert nicht mehr, sobald echte Organisationen mit echten Anliegen dazukommen.

Diese Woche habe ich deshalb nicht an einem einzelnen Feature gearbeitet, sondern an einem zusammenhängenden Stück Plattform: einer Wissensdatenbank, die Antworten gibt, bevor jemand fragen muss, einem Ticket-System, das den Dialog nachvollziehbar hält, und einem eingehenden E-Mail-Pfad, der aus einer Antwort im Postfach automatisch die richtige Ticket-Antwort macht. Drei Teile, die erst zusammen das ergeben, was man vernünftigerweise Support nennen kann.

Warum überhaupt eine eigene Support-Schicht

Man könnte argumentieren, dass ein junges Produkt keinen ausgebauten Support braucht — ein Kontaktformular und eine E-Mail-Adresse reichen doch. In der Praxis ist genau das die Falle. Ein Formular ohne Nachverfolgung erzeugt beim Absender das Gefühl, in ein Loch geschrieben zu haben, und beim Betreiber die ständige Angst, etwas übersehen zu haben. Beides untergräbt das Vertrauen, das eine Plattform braucht, die mit Gesundheitsdaten und mit der Terminorganisation ganzer Betriebe umgeht.

Ich wollte deshalb von Anfang an einen Ablauf, der drei Dinge garantiert: Jede Anfrage bekommt eine Identität, jede Antwort findet zu ihr zurück, und wiederkehrende Fragen werden gar nicht erst zu Anfragen. Der letzte Punkt ist der Grund, warum die Wissensdatenbank vor dem Ticket-System steht — der beste Support-Fall ist der, der nie eröffnet wird.

Die Wissensdatenbank unter /help

Der Einstieg liegt jetzt unter /help. Dort bündelt eine Wissensdatenbank die Hilfe-Artikel zu den Themen, die in den ersten Wochen ohnehin immer wieder aufkamen — von den ersten Schritten in einer Organisation bis zu den Detailfragen rund um Abrechnung und Datenfreigabe. Die Seite ist bewusst schlicht: eine durchsuchbare Übersicht, Artikel als eigenständige Ansichten, kein überladenes Portal.

Der Punkt, der mir hier wichtig war, ist die Herkunft der Inhalte. Die Artikel sind nicht in der Datenbank von Hand gepflegt und nicht im Markup verdrahtet, sondern werden über einen HelpContentSeeder ausgeliefert. Der Seeder läuft beim Start mit, prüft den vorhandenen Bestand und spielt neue oder geänderte Artikel ein, ohne Vorhandenes zu duplizieren. Das hat einen handfesten Vorteil: Ein Hilfe-Text ist damit versionierter Code wie alles andere. Ich schreibe einen Artikel in einem Branch, er durchläuft dieselbe Review, und beim nächsten Deploy steht er in jeder Umgebung identisch da. Kein manuelles Nachpflegen in der Produktion, kein Auseinanderdriften zwischen Test und Live.

Dass die Wissensdatenbank auf demselben .NET-10-Stack läuft wie der Rest der Plattform, macht diese Seeder-Mechanik unspektakulär zuverlässig — sie hängt an der ohnehin bei jedem Aspire-Boot durchlaufenen Initialisierung und braucht keinen Sonderweg.

Tickets, die einen Faden behalten

Foto: Tom Hermans · StockSnap (CC0 1.0), via Openverse

Für alles, was die Wissensdatenbank nicht abfängt, gibt es das Ticket-System. Der Kern hier ist, dass die Tickets threaded sind: Ein Anliegen ist kein einzelner Nachrichtenblock, sondern ein fortlaufender Dialog zwischen dem Mitglied und dem Betreiber. Jede Antwort hängt sich an den Verlauf, und beide Seiten sehen dieselbe Chronologie in derselben Reihenfolge.

Das klingt selbstverständlich, ist es technisch aber nicht ganz. Ein Ticket ist damit kein Statusfeld auf einem Formulareintrag, sondern eine Entität mit einer geordneten Liste von Beiträgen, die von unterschiedlichen Akteuren stammen können — mal vom anfragenden Mitglied, mal vom Support auf Betreiberseite. Genau diese Nachvollziehbarkeit ist der Zweck: Wer später ein Ticket öffnet, sieht die gesamte Geschichte und nicht nur die letzte Zeile. Bei Rückfragen zu einem früheren Fall muss niemand rekonstruieren, was eigentlich besprochen wurde.

Ein threaded Modell zahlt sich auch dann aus, wenn ein Fall zwischendurch ruht. Meldet sich das Mitglied nach Tagen erneut, landet die neue Nachricht im selben Faden statt in einem zweiten, halb redundanten Ticket. So bleibt die Warteschlange sauber, und der Kontext geht nicht verloren.

E-Mail als vollwertiger Ein- und Ausgang

Der Teil, der mich diese Woche am längsten beschäftigt hat, ist der eingehende E-Mail-Pfad. Die Erwartung realer Anwender ist eindeutig: Wenn ich eine Benachrichtigung über eine Ticket-Antwort per Mail bekomme, will ich einfach auf „Antworten" drücken und tippen — nicht mich irgendwo einloggen, um meinen eigenen Satz in ein Textfeld zu übertragen. Damit das funktioniert, muss eine eingehende Mail zielsicher dem richtigen Ticket zugeordnet werden.

Genau das leistet die VERP-Adressierung. Statt einer generischen Support-Adresse trägt jede ausgehende Benachrichtigung eine eindeutig kodierte Absender- beziehungsweise Antwortadresse, in der die Ticket-Zuordnung steckt. Antwortet jemand darauf, verrät die Empfängeradresse dem System bereits, zu welchem Ticket der Text gehört — noch bevor überhaupt in den Inhalt geschaut wird. Die eingehende Mail wird dann als neue Antwort in den bestehenden Thread eingehängt, so als wäre sie direkt in der Oberfläche geschrieben worden. Aus einem klassischen E-Mail-Hin-und-Her wird auf diese Weise ein sauber protokollierter Ticket-Verlauf, ohne dass der Absender etwas anders tun muss als sonst.

Der Reiz an VERP ist, dass die Zuordnung nicht von fehleranfälligem Parsen des Betreffs oder von zitierten Textblöcken abhängt. Die Adresse selbst ist der Schlüssel, und die ist maschinell erzeugt und maschinell wieder lesbar.

Was Produktion zusätzlich braucht

An dieser Stelle die ehrliche Einordnung, denn der eingehende Pfad ist kein reiner Anwendungscode — er hängt an Infrastruktur, die außerhalb des Repositorys konfiguriert werden muss. Damit eingehende Mails überhaupt bei Xircuit ankommen, braucht es in Produktion drei Dinge: einen MX-Eintrag, der die Support-Domain auf den Empfang zeigt, SendGrid Inbound Parse, das die ankommenden Nachrichten annimmt und an unseren Endpunkt weiterreicht, sowie ein Webhook-Secret, mit dem sich dieser Endpunkt gegen untergeschobene Aufrufe absichert. Fehlt einer dieser drei Bausteine, funktioniert der ausgehende Weg weiterhin tadellos, aber Antworten per Mail kommen nicht an. Das ist eine bewusste Betriebs-Voraussetzung und keine Vermutung — die Verkabelung im Code steht, die DNS- und SendGrid-Seite ist ein separater, nachvollziehbarer Schritt.

Der ausgehende Weg wiederum stützt sich auf eine Regel, die für die gesamte Plattform gilt: Alle Produkt-E-Mails laufen über die verifizierte Domain xircuit.com. Das ist keine kosmetische Entscheidung. Eine einheitliche, authentifizierte Absender-Domain ist die Grundlage dafür, dass unsere Mails nicht im Spam-Ordner versanden und dass die VERP-Antwortadressen überhaupt in denselben verlässlichen Zustellpfad zurückfließen. Ein Ticket-System, dessen Benachrichtigungen nicht ankommen, wäre nur die Hälfte wert.

Die Teile greifen ineinander

Rückblickend ist das Befriedigende an dieser Woche weniger jeder einzelne Baustein als ihr Zusammenspiel. Die Wissensdatenbank senkt die Zahl der Anfragen; die verbleibenden Anfragen werden zu threaded Tickets mit vollständigem Kontext; und die E-Mail-Brücke sorgt dafür, dass ein Mitglied den Weg über die Oberfläche gar nicht kennen muss, um Teil dieses Verlaufs zu bleiben. Jeder Teil für sich wäre ein halbes Feature. Zusammen ergeben sie einen Ablauf, dem ich zutraue, mit wachsender Nutzerzahl mitzuwachsen, ohne dass ich jede Mail persönlich im Blick behalten muss.

Bewusst offen bleibt der Betriebsschritt für den eingehenden Pfad — bis MX, Inbound Parse und Webhook-Secret in Produktion gesetzt sind, ist die E-Mail-Antwort eine Fähigkeit, die im Code lebt, aber noch nicht live atmet. Das ist der ehrliche Stand, und es ist ein gutes Gefühl, dass genau diese Lücke die einzige nennenswerte ist.

Was kommt als Nächstes?

Nächste Woche: Organisations-Kontaktdaten und Profilseiten über alle Branchen hinweg. Nachdem der Support jetzt einen Rahmen hat, geht der Blick zurück zu den Organisationen selbst — und dazu, wie sie sich innerhalb der Plattform darstellen.