Supporttickets erstellen, beantworten und bearbeiten

Zweck und Einsatzbereich

Die getrennte Support-Anwendung dient dazu, technische Fragen, Abrechnungsfragen, Integrationsprobleme, Kontothemen, Funktionswünsche und Schulungsbedarf als Ticket zu erfassen. Kundenbenutzer verfolgen dort ihre sichtbaren Tickets und antworten im Nachrichtenverlauf. Plattformoperatoren bearbeiten organisationsübergreifend eingegangene Tickets, setzen Status und Priorität, übernehmen ein Ticket und können interne Notizen anlegen.

Die Support-Anwendung ist kein E-Mail-Postfach und kein Dateiaustausch. Im geprüften Stand werden bei Erstellung, Antwort oder Statusänderung keine E-Mail-Benachrichtigungen versendet; Resend ist nicht an den Ticketablauf angeschlossen. Der Ticketverlauf wird auch nicht automatisch aktualisiert. Öffnen oder laden Sie die Ansicht erneut, um Antworten anderer Beteiligter zu sehen.

Anhänge sind derzeit nicht implementiert. Der Hinweis im Beschreibungsfeld, Screenshots könnten im Nachrichtenverlauf angehängt werden, ist falsch: Es gibt weder eine sichtbare Dateiauswahl noch eine serverseitige Ablage für Ticketanhänge. Damit bestehen für Supporttickets auch keine belegten Prüfungen von Dateityp, Dateigröße, Schadsoftware oder Downloadberechtigung. Übermitteln Sie Dateien nur über einen separat freigegebenen sicheren Kanal.

Voraussetzungen und Berechtigungen

Sie benötigen ein aktives NeuraPort-Benutzerkonto. Normale Organisationsbenutzer verwenden ihre bestehenden Anmeldedaten; ein separates Supportkennwort existiert nicht. Die Organisation muss aktiv sein. Eine eigene Produktmodullizenz wird für Supporttickets im geprüften Stand nicht verlangt.

Die separate Anmeldemaske bietet derzeit nur E-Mail-Adresse, Passwort und Anmelden. Sie kann eine angeforderte Zwei-Faktor-Authentifizierung nicht abschließen und bietet auch keinen Bedienweg für einen erzwungenen Passwortwechsel, eine erforderliche MFA-Einrichtung oder die E-Mail-Verifizierung eines Plattformkontos. Erscheint eine entsprechende technische Meldung oder bleibt die Ticketliste nach der Anmeldung unzugänglich, verwenden Sie den freigegebenen alternativen Supportweg und melden Sie die Zugangslücke. Geben Sie MFA- oder Recovery-Codes niemals an Supportmitarbeiter weiter.

Die Sichtbarkeit richtet sich nach Rolle und Zuordnung:

Rolle	Sichtbarer Ticketumfang	Bearbeitungsrechte
Interner Benutzer	Eigene, selbst erstellte Tickets	Neues Ticket erstellen und auf offene Tickets antworten
ADMIN oder MANAGER	Alle Tickets der eigenen Organisation, auch aus anderen Organisationseinheiten	Antworten wie ein Kundenbenutzer; Status, Priorität und Zuweisung können nicht verwaltet werden
EXECUTIVE	Tickets der zugewiesenen Organisationseinheiten	Antworten wie ein Kundenbenutzer; keine Status- oder Prioritätsverwaltung
Plattformoperator	Alle Supporttickets aller Organisationen	Antworten, interne Notiz, Status, Priorität und eigene Übernahme

Die organisationsübergreifende Sicht ist ein ausschließlich auf Supporttickets begrenzter Plattformzugriff. Sie meldet den Plattformoperator nicht als Kundenbenutzer an und erweitert den Zugriff nicht automatisch auf andere Kundendaten.

Ein als Support-Agent gedachter Nicht-Plattformbenutzer erhält im aktuellen Datenvertrag keine verlässlich nutzbare Agentenrolle und besitzt serverseitig nicht dieselben Bearbeitungsrechte wie ein Plattformoperator. Die getrennte Einschränkung ist unter Einschränkung: Support-Agentenverwaltung beschrieben. Die folgenden Agentenschritte gelten deshalb nur für Plattformoperatoren.

Schritt-für-Schritt-Anleitung

Als Kundenbenutzer anmelden und ein Ticket erstellen

Öffnen Sie die freigegebene Support-Anwendung. Verwenden Sie keine Demo- oder Produktadresse, deren Zuordnung der Betrieb nicht bestätigt hat.
Geben Sie E-Mail-Adresse und Passwort ein und wählen Sie Anmelden.
Prüfen Sie nach der Anmeldung den Organisationsnamen unter Meine Anfragen. Wenn dort eine unerwartete Organisation erscheint, melden Sie sich ab und legen Sie kein Ticket an.
Wählen Sie Neue Anfrage oder Neue Anfrage stellen.
Geben Sie einen eindeutigen Betreff ein und wählen Sie Kategorie und Priorität.
Beschreiben Sie unter Beschreibung den beobachteten Zustand, den erwarteten Zustand, Zeitpunkt, betroffenen Arbeitsbereich und die letzte sichere Aktion. Fügen Sie keine Kennwörter, Tokens, MFA-Codes, API-Schlüssel oder unnötigen personenbezogenen Daten ein.
Wählen Sie Anfrage senden. Nach erfolgreicher Erstellung erscheint die Meldung Ticket erstellt — wir melden uns bald! und das Ticket erhält eine Nummer sowie den Status Offen.
Bleibt das Fenster ohne Erfolgsmeldung geöffnet, prüfen Sie die Ticketliste, bevor Sie erneut senden. Ein Erstellungsfehler wird derzeit nicht sichtbar erklärt; wiederholtes Klicken kann nach einer unklaren Netzwerksituation zu mehreren Tickets führen.

Das aktive Formular bietet keine Organisationseinheiten-Auswahl. Es ordnet das Ticket der aktuell verwendeten Organisationseinheit zu. Prüfen Sie deshalb vor dem Absenden Ihren aktuellen Organisationskontext in NeuraPort.

Ein Ticket suchen, öffnen und beantworten

Verwenden Sie unter Meine Anfragen die Suche nach Ticketnummer oder Betreff. Die Suche wirkt nur auf die bereits geladene Liste.
Grenzen Sie die Liste bei Bedarf über Alle, Offen, In Arbeit, Wartet oder Gelöst ein.
Wählen Sie das Ticket. Prüfen Sie Ticketnummer, Kategorie, Status, Priorität und Letzte Aktivität.
Geben Sie unter Ihre Antwort oder weitere Informationen… eine Ergänzung ein. Senden Sie mit Antwort senden oder mit Strg+Enter beziehungsweise Cmd+Enter.
Eine Kundenantwort setzt das Ticket auf Offen. Laden Sie die Seite später erneut; es gibt keine E-Mail-Benachrichtigung und keine automatische Aktualisierung bei einer neuen Supportantwort.
Bei Gelöst oder Geschlossen ist das Antwortfeld ausgeblendet. Erstellen Sie für ein neues Thema ein neues Ticket. Ein Plattformoperator kann ein Ticket bei Bedarf wieder in einen bearbeitbaren Status setzen.

Als Plattformoperator Tickets bearbeiten

Melden Sie sich mit einem freigegebenen Plattformkonto an und öffnen Sie Support Console.
Verwenden Sie die Suche nach Ticket, Organisation, Betreff oder Ersteller und die Statusfilter. Nur meine zeigt Tickets, die Sie erstellt haben oder die Ihnen zugewiesen sind.
Öffnen Sie ein Ticket und prüfen Sie Organisation, Organisationseinheit, Ersteller, Bearbeiter, Kategorie, Status, Priorität und Verlauf.
Wählen Sie Ticket übernehmen, wenn noch kein Bearbeiter eingetragen ist. Dadurch wird das Ticket Ihrem Plattformkonto zugewiesen.
Schreiben Sie unter Antwort eine kundenlesbare Nachricht. Nach dem Senden wechselt das Ticket automatisch auf Wartet auf Antwort.
Verwenden Sie Interne Notiz nur für Informationen, die Kundenbenutzer nicht sehen sollen. Eine interne Notiz ändert den Ticketstatus nicht. Sie ist dennoch Teil des Plattformdatenbestands und kein Ablageort für Geheimnisse.
Setzen Sie Status oder Priorität im Informationsbereich. Mit Als „In Arbeit“ markieren, Als gelöst markieren und Ticket schließen stehen passende Schnellaktionen bereit.
Laden Sie vor einer kritischen Statusentscheidung die Ansicht neu. Parallele Änderungen werden zwar nacheinander gespeichert, aber die Oberfläche zeigt keinen Versionskonflikt; die zuletzt verarbeitete Status- oder Prioritätsänderung kann eine vorherige überschreiben.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
E-Mail-Adresse	Ja	Benutzername des bestehenden NeuraPort-Kontos	Eingabe im E-Mail-Format; die Supportmaske ergänzt derzeit keinen MFA-Code.
Passwort	Ja	Persönliches Kontokennwort	Anmelden wird erst mit E-Mail-Adresse und Passwort aktiv. Keine Zugangsdaten weitergeben.
Betreff	Ja	Kurze Bezeichnung des Supportfalls	Sichtbares Formular verlangt Text; serverseitig 3 bis 255 Zeichen. Nur Leerzeichen können über alternative Clients derzeit nachträglich zu einem leeren Betreff werden.
Kategorie	Ja	Ordnet den Fall fachlich ein	Sichtbar: Technisch, Abrechnung, Integration, Konto, Feature-Wunsch, Schulung, Sonstiges.
Priorität	Ja	Vom Ersteller gewählte Dringlichkeit	Sichtbar: Niedrig, Mittel, Hoch, Dringend. Eine hohe Priorität ist keine zugesagte Reaktionszeit.
Beschreibung	Ja	Erste Nachricht und Sachverhalt des Tickets	Mindestens ein Zeichen; sichtbares Formular verhindert reine Leerzeichen. Keine belegte Höchstlänge.
Ticketnummer	Systemseitig	Eindeutige Referenz im Format aus Supportpräfix, Jahr und laufender Nummer	Nach erfolgreicher Erstellung vergeben; bei Rückfragen angeben, ohne den gesamten Verlauf öffentlich zu teilen.
Organisation	Systemseitig	Eigentümerorganisation des Tickets	Kundenformular verwendet die Organisation des angemeldeten Kontos. Plattformoperatoren sehen die Organisation am Ticket.
Organisationseinheit	Nein	Ordnet den Supportfall einem organisatorischen Bereich zu	Standardformular verwendet die aktuelle Einheit und bietet keine Auswahl. Alternative Clients werden derzeit nur auf Zugehörigkeit zur Organisation, nicht auf Benutzerzuweisung geprüft.
Status	Systemseitig / Plattformoperator	Bearbeitungsstand des Tickets	Sichtbare Werte: Offen, In Arbeit, Wartet auf Antwort, Gelöst, Geschlossen. Nur Plattformoperatoren dürfen ihn manuell ändern.
Bearbeiter	Nein	Zugewiesener Plattformoperator	Ticket übernehmen setzt das eigene Konto, wenn noch kein Bearbeiter vorhanden ist.
Antwort	Bei Ergänzung	Kundenlesbare Nachricht im Verlauf	Darf nicht leer sein; keine belegte Höchstlänge und kein Anhang.
Interne Notiz	Nein	Nur für Plattformoperatoren sichtbare Verlaufsnachricht	Für Kunden ausgeblendet; nur Plattformoperatoren dürfen sie anlegen.
Letzte Aktivität	Systemseitig	Zeitpunkt der letzten Nachricht	Ändert sich bei einer Nachricht, nicht zwingend bei einer reinen Status- oder Prioritätsänderung.
Anhang	Nicht verfügbar	Vorgesehene Ergänzung durch Datei oder Screenshot	Derzeit kein Upload, keine Dateiprüfung und kein Downloadweg für Supporttickets.

Kategorie, Priorität und Status werden im sichtbaren Formular aus festen Listen gewählt. Die serverseitige Verarbeitung beschränkt diese Werte derzeit jedoch nur nach Textlänge und nicht auf die vorgesehenen Wertelisten. Nicht vorgesehene Werte aus alternativen Clients können deshalb als technische Codes sichtbar werden.

Status und mögliche Übergänge

Ausgangszustand	Aktion	Ergebnis
Neues Ticket	Anfrage senden erfolgreich	Offen
Offen oder In Arbeit	Plattformoperator sendet Antwort	Wartet auf Antwort
Wartet auf Antwort, Offen oder In Arbeit	Kundenbenutzer sendet Antwort senden	Offen
Beliebiger sichtbarer Status	Plattformoperator wählt In Arbeit	In Arbeit
Offen, In Arbeit oder Wartet auf Antwort	Plattformoperator wählt Als gelöst markieren	Gelöst; Antwortfeld ist ausgeblendet
Gelöst	Plattformoperator wählt Ticket schließen	Geschlossen; Antwortfeld ist ausgeblendet
Gelöst oder Geschlossen	Plattformoperator wählt wieder einen bearbeitbaren Status	Antwortfeld erscheint wieder
Beliebiger Status	Plattformoperator speichert Interne Notiz	Status bleibt unverändert

Die Oberfläche bietet diese fünf Status an, erzwingt aber serverseitig keine feste Übergangsreihenfolge. Ein Plattformoperator kann daher auch direkt zwischen weiter auseinanderliegenden Zuständen wechseln. Status-, Prioritäts- und Zuweisungsänderungen erscheinen nicht als eigene Einträge im Nachrichtenverlauf. Es gibt keine sichtbare Änderungsbegründung oder vollständige Ticket-Auditspur.

Die Oberfläche verhindert Antworten auf Gelöst und Geschlossen. Die serverseitige Nachrichtenfunktion prüft den Ticketstatus jedoch nicht. Ein alternativer angemeldeter Client kann deshalb auch einem geschlossenen Ticket eine Nachricht hinzufügen und es je nach Absender wieder auf Offen oder Wartet auf Antwort setzen. Behandeln Sie den geschlossenen Zustand bis zur Korrektur nicht als unveränderbare technische Sperre.

Was im Hintergrund passiert

Die Support-Anwendung ist ein eigenständiges Frontend, verwendet aber dieselbe Benutzeranmeldung und dieselben Sitzungsregeln wie die Hauptanwendung. Das Zugriffstoken bleibt im Arbeitsspeicher; eine bestehende Sitzung wird über ein geschütztes Browser-Cookie erneuert. Zustandsändernde Sitzungsaufrufe verwenden zusätzlich den im Browser gesetzten CSRF-Schutz. Läuft die Support-Anwendung unter einer getrennten Adresse, müssen Datenweiterleitung, erlaubte Browserherkunft und Sitzungs-Cookies dafür passend betrieben werden.

Beim Erstellen übernimmt der Dienst für Organisationsbenutzer die eigene Organisation und standardmäßig die aktuelle Organisationseinheit. Ticket und erste Nachricht werden gemeinsam gespeichert. Die Ticketnummer wird aus Jahr und interner laufender Nummer gebildet. Das aktive Standardformular übermittelt keine frei gewählte Organisation oder Organisationseinheit.

Normale Abfragen bleiben auf die eigene Organisation begrenzt. Zusätzlich filtert der Dienst nach Ersteller, Organisationsrolle oder berechtigten Organisationseinheiten. Für Plattformoperatoren wird nur innerhalb der Supportverarbeitung ein organisationsübergreifender Datenbankkontext aktiviert. Interne Notizen werden vor der Ausgabe an Kundenbenutzer entfernt und deshalb auch nicht in deren Nachrichtenzahl eingerechnet.

Ticketänderungen und neue Nachrichten sperren den betroffenen Datensatz während der Verarbeitung. Das verhindert gleichzeitiges unkoordiniertes Schreiben innerhalb desselben Augenblicks, ersetzt aber keine sichtbare Konfliktprüfung. Es gibt weder eine Versionsnummer noch eine Rückfrage, wenn zwei Plattformoperatoren nacheinander unterschiedliche Statuswerte speichern.

Der Supportdienst ruft keinen Mailversand auf. Insbesondere wird Resend weder bei der Ticketerstellung noch bei Antworten, Zuweisung oder Statuswechsel verwendet. Die E-Mail-Konfiguration anderer NeuraPort-Bereiche belegt daher keine Supportbenachrichtigung.

Der Releaseablauf baut die Support-Oberfläche, enthält im geprüften Repository aber keine eigene aktive Serverroute für deren Auslieferung. Die Anwendung verwendet ohne besondere Buildkonfiguration dieselbe Adresse für Oberfläche und Backend. Eine funktionsfähige öffentliche Installation muss deshalb zusätzlich durch den Plattformbetrieb nachgewiesen werden. Die vorbereitete Demo-Konfiguration stellt nur die Hauptanwendung und deren getrenntes Backend bereit; ein eigener Demo-Supportweg ist nicht belegt.

Automatisierte Supporttests prüfen derzeit nur, dass ein Organisationsadministrator ein Ticket erstellen, aber nicht schließen darf, und dass ein Plattformadministrator schließen darf. Nicht automatisiert abgedeckt sind Rollen- und OE-Sichtbarkeit, interne Notizen, Antworten und automatische Statuswechsel, ungültige Statuswerte, Paralleländerungen, MFA- und Verifikationsanforderungen, E-Mail-Benachrichtigungen, Anhänge, Browserfehler sowie Produktiv- oder Demorouting.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
Anmeldung fehlgeschlagen	Zugangsdaten sind ungültig oder der technische Fehler enthält keine genauere sichtbare Erklärung.	Eingabe prüfen. Nicht wiederholt raten; Kontosperre beachten und bei Bedarf den freigegebenen alternativen Supportweg verwenden.
MFA_REQUIRED oder MFA-Code ungültig	Das Konto verlangt MFA, die Supportmaske besitzt aber kein Codefeld.	Keine Recovery-Codes weitergeben. Zugangslücke über den alternativen Supportweg melden; Supportfrontend bis zur MFA-Erweiterung nicht als vollständigen Anmeldeweg behandeln.
Ticketliste bleibt leer und Tickets konnten nicht geladen werden erscheint	Sitzung, Organisation, Passwortwechsel, MFA-Einrichtung, E-Mail-Verifizierung, Datenweiterleitung oder Server sind nicht verwendbar.	Hauptkonto- und Sicherheitsstatus sowie Supportbereitstellung durch die zuständige Administration prüfen lassen.
Keine Tickets vorhanden	Im aktuellen Sichtbereich existiert kein Ticket oder der Statusfilter schränkt die Liste ein.	Alle wählen, Suche leeren und Rollen-/OE-Sicht prüfen.
Ticket konnte nicht geladen werden	Ticket existiert nicht, ist nicht sichtbar oder wurde zwischen Liste und Detailaufruf entfernt.	Liste neu laden und Ticketnummer prüfen; keine fremde Ticketnummer ausprobieren.
Anfrage senden reagiert scheinbar nicht	Erstellungsfehler wird im Dialog derzeit verschluckt.	Ticketliste vor einem zweiten Versuch neu laden. Zeitpunkt und Eingaben ohne vertrauliche Inhalte melden.
Fehler beim Senden	Sitzung, Berechtigung, Ticketstatus oder Serveraufruf ist fehlgeschlagen.	Seite neu laden, Status und Sichtbarkeit prüfen und Antwort einmal erneut eingeben. Keine Geheimnisse in Fehlerscreenshots zeigen.
Screenshot kann nicht angehängt werden	Ticketanhänge sind nicht implementiert; der sichtbare Platzhaltertext ist irreführend.	Datei nicht in das Ticket zwingen. Nur einen ausdrücklich freigegebenen sicheren Übertragungsweg verwenden.
Keine E-Mail nach Antwort oder Statuswechsel	Der Ticketablauf ist nicht an Resend oder einen anderen Mailversand angeschlossen.	Support-Anwendung manuell öffnen und neu laden; keine Benachrichtigung zusagen.
Neue Antwort erscheint nicht automatisch	Es gibt kein Polling und keine Live-Aktualisierung für Tickets.	Browseransicht neu laden. Vor einer parallelen Bearbeitung den aktuellen Verlauf prüfen.
Status- oder Prioritätsanzeige enthält einen technischen Code	Ein alternativer Client hat einen nicht vorgesehenen, serverseitig nicht streng validierten Wert gespeichert.	Ticket nicht weiter umstufen und durch den Plattformbetrieb bereinigen lassen.
Plattformantwort ist für Kunden nicht sichtbar	Nachricht wurde möglicherweise als Interne Notiz gespeichert.	Kennzeichnung im Operatorverlauf prüfen. Kundenlesbare Information ausdrücklich unter Antwort senden.
Geschlossenes Ticket wurde wieder geöffnet	Die serverseitige Nachrichtenfunktion sperrt geschlossene Tickets nicht.	Verlauf und Absender prüfen, Zustand fachlich korrigieren und die Logiklücke melden.
Demo zeigt keine Support-Anwendung	Für die vorbereitete Demo ist kein eigener Support-Frontendweg belegt.	Nicht auf Produktivdaten ausweichen. Separate Demo-Bereitstellung und synthetische Ticketdaten durch den Betrieb bestätigen lassen.