Wenn ein Support-Ticket zugleich eine Transaktion ist
Händleranfragen betreffen fast immer eine konkrete Transaktion, Auszahlung oder Rechnung. In einem Allzweck-Helpdesk außerhalb des Payment-Panels beginnt ein Ticket als leere Konversation, und der Agent muss Transaktionsreferenzen, Händler-IDs und Daten zwischen zwei Systemen kopieren, bevor er sich überhaupt ansehen kann, worum es dem Händler geht.
Ein Ticket dort öffnen, wo der Datensatz bereits liegt
Ein Händler kann ein Ticket stattdessen direkt aus der Transaktion, Rechnung oder Wallet heraus erstellen, die er gerade ansieht – die Referenz wandert so mit der Konversation, statt nachträglich eingefügt zu werden. Der Mitarbeiter, der das Ticket beantwortet, sieht den tatsächlichen Datensatz, keinen Screenshot und keine kopierte Kennung.
Eine Warteschlange, dieselben Berechtigungen
Tenant-Manager bearbeiten die Support-Warteschlange innerhalb ihres eigenen Panels, unter derselben rollenbasierten Zugriffskontrolle, die auch den Rest ihres Zugriffs regelt. Support-Mitarbeiter benötigen keine erweiterten Rechte, nur um eine Frage zu beantworten, und es gibt keinen zweiten Login, kein separates SSO-Setup und keinen zweiten Ort, an dem personenbezogene Daten von Händlern gespeichert werden.
Gemeinsamer Speicher statt zweites Dateisystem
Anhänge wie Belege und Nachweise nutzen denselben Dokumentenspeicher und dieselben Download-Routen wie Dispute-Beweise. Nichts muss in ein zweites System dupliziert werden, und zwischen einem Anhang und dem Datensatz, den er belegen soll, geht nichts verloren.
Was sich dadurch im Alltag ändert
Da Tickets tenant-bezogen sind und innerhalb der Plattform in die Warteschlange gestellt werden, ist das Reporting der Reaktionszeit eine Eigenschaft der Plattform selbst und nicht etwas, das nachträglich aus zwei Systemen zusammengestellt wird. Und weil Tickets aus dem Kontext heraus geöffnet werden, entfällt eine ganze Fehlerkategorie: die falsche Transaktionsreferenz, die in die falsche Konversation kopiert wird.
Eine optionale Ebene – und wo Disputes ins Bild passen
Zusätzlich zum Support-Postfach kann ein separates Modul eingehende Tickets priorisieren und Antwortvorschläge entwerfen, die auf demselben Transaktions- und Händlerkontext basieren, den der Mitarbeiter bereits sieht – der Mitarbeiter bearbeitet und sendet weiterhin selbst, und nichts geht automatisch an einen Händler. Das ergänzt den eigenen Dispute-Workflow der Plattform, in dem ein Händler einen Dispute zu einer Zahlung oder Auszahlung mit einem Grund und bis zu fünf Beweisdateien eröffnen kann und ein Manager ihn löst, wobei Salden automatisch zurückgebucht und neu verbucht werden – so bleiben die Support-Konversation und der Dispute, zu dem sie führen kann, am selben Ort.
