Ticket-Management

Ein neues Ticket legst du über „New Ticket" in der linken Leiste an. Das Formular heißt „Create new ticket". Als Bearbeiter erfasst du damit auch Anliegen anderer. Dafür gibt es das Feld „User". Dort steht, für wen der Vorgang läuft, und nicht, wer ihn eintippt.

Pflicht ist, was einen Stern trägt: „Title", „User", „Main category" und „Description". Ein Feld wird dabei leicht übersehen. Ohne Unterkategorie speichert das Formular nicht, obwohl an „Subcategory" kein Stern steht. Haupt- und Unterkategorie gehören zusammen und werden immer als Paar gesetzt.

Welche Felder Pflicht sind, legst du unter „Settings → Ticket Settings" fest. Die Karte „Admin / Agent Field Settings" hat dafür nur den Schalter „Field is mandatory". Die Karte „Customer Field Settings" hat zusätzlich „Is hidden for Customer" und „Is not editable". Ein Kunde kann deshalb ein kürzeres Formular sehen als du. Zwei Formulare musst du dafür nicht pflegen. „Title" und „Description" sind immer Pflicht. Das lässt sich nicht abschalten.

Nachträglich ändern kannst du fast alles. Auf dem Ticket steht rechts die Karte „Details" mit Anfragendem, Telefon, E-Mail, Standort, Kategorie und Referenznummer. Du änderst direkt im Feld und bestätigst mit „Save" darunter. Status, Zuweisung, Priorität, Eingangskanal und Beobachter liegen eine Karte darüber unter „Actions". Status und Zuweisung wirken sofort. Priorität, Eingangskanal und Beobachter werden erst mit „Save" in der Karte „Details" gespeichert.

Ändern dürfen das nur Bearbeiter und Administratoren. Der Anfragende kann seinen Vorgang lesen, kommentieren und Dateien anhängen. Die Einordnung kann er nicht ändern. Auf ihr beruht deine Auswertung.

Eine Nebenwirkung solltest du kennen. Bearbeitest du ein Ticket, das noch niemandem gehört, gehört es danach dir. Das System trägt dich als Bearbeiter ein und setzt den Status von „Open" auf „Assigned". Beides steht anschließend in der Historie. Willst du das nicht, weise das Ticket danach jemand anderem zu.

Jede dieser Änderungen landet in der Historie des Tickets, mit Name, Zeitpunkt, altem und neuem Wert. Du musst dafür nichts einschalten.

Tickets wieder loszuwerden geht über das Archiv. Unter „Settings → Archive" wählst du einen Zeitraum. „Preview" zeigt dir, wie viele geschlossene Tickets darin liegen, und „Create archive" legt eine ZIP-Datei an. Darin stehen Tickets, Kommentare, Historie, Zusatzfelder und Anhänge. Das Anlegen entfernt nichts. Aus der laufenden Datenbank verschwinden die Tickets erst mit dem eigenen Schritt „Delete from live DB" in der Liste „Existing archives". Aus derselben Datei lassen sie sich wieder zurückholen.

Beschreibung und Kommentare sind keine nackten Textfelder. Über jedem liegt eine Werkzeugleiste, und die Knöpfe heißen beim Zeigen darauf, was sie tun: „Bold", „Italic", „Underline", „Strikethrough", „Text color", „Highlight color", „Bullet list", „Numbered list", „Quote", „Link" und „Clear formatting".

Ein Link entsteht so: Text markieren, auf „Link" klicken, die Adresse in die kleine Abfrage eintragen. Eine leere Eingabe entfernt den Link wieder. Erlaubt sind Web- und Mail-Adressen, also http, https und mailto. Alles andere wirft das System beim Speichern weg. So kann ein Kommentar niemandem etwas unterschieben.

Bilder kommen über die Zwischenablage hinein: Bildschirmfoto machen und mit Strg+V direkt in den Editor einfügen. Im Text steht dann zunächst eine Marke wie „[inline-image:1]". Beim Speichern lädt das System das Bild hoch und zeigt es genau an dieser Stelle. Zusätzlich liegt es im Reiter „Attachments", also dort, wo alle Dateien des Vorgangs stehen. Bilder einfügen geht in der Beschreibung eines bestehenden Tickets und in einem neuen Kommentar. Im Formular „Create new ticket" und beim Bearbeiten eines Kommentars geht es nicht.

Was du siehst, sehen auch die anderen: Formatierung, Aufzählungen und Links bleiben im Ticket erhalten, ebenso in der Mail an den Anfragenden. Fremde Formatierung aus einer kopierten Webseite oder einer eingehenden E-Mail wird auf diese erlaubte Auswahl zurückgeschnitten. Dein Text bleibt dabei vollständig, nur die Verpackung fällt weg.

Ein Kommentar lässt sich mit „Internal note (not visible to the customer)" als intern markieren. Er trägt dann die Marke „Internal" und ist für den Anfragenden nicht sichtbar. Auch über die Suche findet er ihn nicht.

Jeder kann seine eigenen Kommentare ändern und löschen. Was ein Kunde geschrieben hat, ändert oder löscht außer ihm nur ein Administrator. Das gilt auch für seine Mails. Kommentare von Kollegen darf jeder Bearbeiter ändern und löschen, der am Ticket mitarbeiten darf. Das gilt auch für ein Team, das das Ticket früher hatte.

Dateien hängen am Vorgang, nicht am einzelnen Kommentar. Auf dem Ticket führt der Reiter „Attachments" zur Liste: „Upload file" legt eine Datei dazu, jede Zeile nennt Name, Größe und Datum. Anhängen darf jeder, der am Ticket beteiligt ist. Das gilt auch für den Anfragenden. Er muss dir das Bildschirmfoto also nicht per Mail schicken. Ein Kunde löscht nur Anhänge, die er selbst hochgeladen hat. Wird ein Unterticket geschlossen, kommen seine Anhänge in das Hauptticket. Dort tragen sie die Marke „Internal". Bearbeiter sehen sie, Kunden sehen und laden sie nicht.

Ein Klick auf den Namen öffnet die Vorschau, ohne dass du die Datei herunterladen musst. Bei Bildern kannst du darin vergrößern, verkleinern und drehen. Das hilft bei einem schief fotografierten Display. Ein PDF wird im selben Fenster angezeigt, mit Seitenübersicht, Zoom und Drucken. Textdateien zeigt die Vorschau als Text. Über „Open in new tab" öffnest du die Datei im eigenen Fenster.

Ein Anhang gehört zum Vorgang und wandert mit ihm. Er steht in der Historie als „File uploaded: …". Beim Abgeben an ein anderes Team bleibt er erhalten, und beim Archivieren landet er mit in der Archivdatei.

Der Reiter „History" auf dem Ticket beantwortet die Frage: Wer hat wann was geändert? Jede Zeile nennt den Namen, das Feld, den alten Wert durchgestrichen, den neuen dahinter und den Zeitpunkt auf die Sekunde. Das Neueste steht oben.

Eingetragen wird ohne dein Zutun. Das gilt für Statuswechsel, Priorität, Zuweisung, Kategorie, Standort, Beobachter, Titel und Beschreibung, ebenso für das Anlegen als „Ticket opened", für jeden Kommentar und für jede hochgeladene Datei. Die Zahl am Reiter sagt dir vorab, wie viel Bewegung in dem Vorgang steckt.

Die Historie lässt sich nicht bearbeiten und nicht abschalten. Sie ist auch der Grund, warum ein Ticket nicht einzeln gelöscht werden kann. Beim Archivieren wandert sie mit in die Archivdatei.

Für einen Kommentar hält die Historie nur fest, dass er hinzugefügt, bearbeitet oder gelöscht wurde. Den Wortlaut findest du im Reiter „Comments". Ein interner Kommentar taucht in der Historie ebenfalls auf, aber nur für Bearbeiter und Administratoren.

Der Status sagt, wo ein Ticket gerade steht. Mitgeliefert werden zwölf Status, darunter Open, Assigned, In Progress, Waiting for User Response, Resolved und Closed. Du findest sie unter „Settings → General Settings" im Abschnitt „Drop-down lists" hinter dem Reiter „Status". „+ Add status" legt einen eigenen an, „Edit status" öffnet einen vorhandenen.

Wichtig ist der Unterschied zwischen dem Namen und der Bedeutung. Im Editor eines Status stehen unter „Meaning of this status" drei Schalter: „Counts as resolved", „Counts as closed" und „Waiting for the requester". Erst diese Schalter sagen dem System, wie es einen Status behandeln soll.

Umbenennen darfst du jeden Status, auch die mitgelieferten. Ganz unten im Editor steht unter „Translations" je Sprache ein Feld „Name". Trage dort ein, was deine Leute lesen sollen. Der technische Name dahinter bleibt unverändert. Automatik, Auswertung und die Schalter oben hängen an ihm und nicht an deiner Beschriftung. Aus „Resolved" darf also „Erledigt" werden.

Löschen geht dagegen nicht bei allen. Acht Status tragen in der Liste die Marke „Mandatory": Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval und Rejected. Sie lassen sich umbenennen und umsortieren, aber nicht entfernen. Der Versuch endet mit einer klaren Meldung. An diesen Status hängen Abläufe, die sonst kommentarlos aussteigen würden. Ein Beispiel ist das automatische Schließen, das einen Status als Ausgangspunkt braucht, der als gelöst zählt.

Zwei Status gehören dem System selbst. „Waiting for approval" und „Rejected" tragen die Marke „System only". Sie entstehen aus einem Antragsverfahren. Von Hand kann sie deshalb niemand setzen.

Was die drei bewirken: Ein Status, der als gelöst zählt, schließt das Ticket nach 24 Stunden von selbst. Ein Status, der als geschlossen zählt, ist der Endzustand, in den dabei umgestellt wird. „Waiting for the requester" heißt, dass auf den Melder gewartet wird. Es heißt nicht, dass auf ein anderes Team oder auf einen Dienstleister gewartet wird. An dieser Angabe hält die SLA-Uhr an, wenn du sie so eingestellt hast.

Darunter steht „Allowed transitions to new status". Hier hakst du an, welche Status von diesem aus erreichbar sind. Lässt du alles leer, ist nichts gesperrt. Hakst du etwas an, ist jeder andere Weg zu. So baust du einen Ablauf, der sich nicht überspringen lässt. Aus „Open" geht es dann zum Beispiel nur nach „In Progress" oder „Assigned", aber nicht direkt nach „Closed".

Die übrigen Schalter im Editor sind schnell erklärt. Die Farbe gilt für die Liste, „Sort order" für die Reihenfolge. „Show status in new ticket form" entscheidet, ob man diesen Status beim Anlegen überhaupt wählen kann. „Requires comment in dialog" erzwingt eine Begründung. „System only" ist für Status, die nur das System selbst setzen darf.

Bis zu vier Status stehen am Ticket als Schaltflächen unter „Change Status to:". Du wählst sie im Editor mit dem Schalter „Set as primary status (max. 4)". Als Werkseinstellung sind das In Progress, Waiting for User Response, Waiting for Service Provider Response und Resolved. Alle anderen Status findest du unter „More statuses".

Alles, was im Ticket als Auswahlliste erscheint, gehört dir. Unter „Settings → General Settings" liegt die Karte „Drop-down lists" mit sechs Reitern: „Department", „Position", „Location", „Role", „Status" und „Priority". Die Bedienung unterscheidet sich je Liste.

Einzeln anlegen: den englischen Namen in das leere Feld schreiben und auf die Schaltfläche daneben klicken. Sie heißt nach der Liste, also „+ Add location", „+ Add department" und so weiter. Die Zeilen darunter sind die vorhandenen Einträge. In „Department", „Position" und „Location" änderst du dort einen Namen und bestätigst mit „Save" daneben.

Für viele Einträge auf einmal gibt es bei „Department", „Position" und „Location" zusätzlich „Export JSON" und „Import JSON". Auf einem frisch installierten System lädst du dir mit „Export JSON" die leere Struktur herunter, füllst sie aus und spielst sie wieder ein. Zum Umbenennen taugt der Weg nicht. Das sagt die Karte auch selbst.

Manche Einträge tragen die Marke „Mandatory". Dazu gehören die drei Rollen „Admin", „Agent" und „Customer", acht der mitgelieferten Status und je ein Platzhalter in den Listen Location, Position und Department. Der Platzhalter heißt „None selected or available". Löschen lässt sich keiner dieser Einträge. An ihnen hängen Berechtigungen und Abläufe, die sonst kommentarlos aussteigen würden. Die Status kannst du in ihrem Editor weiterhin umbenennen. Die Rollen und die Platzhalter lassen sich nicht umbenennen. Was erlaubt ist, hängt an der Liste. „Role" ist gesperrt: Eine Rolle lässt sich weder anlegen noch umbenennen. In „Priority" legst du Einträge an und löschst sie. Eine Datei und ein Umbenennen gibt es dort nicht. „Status" hat einen eigenen Editor und ebenfalls keine Datei.

Die Übersetzung in die anderen Sprachen machst du nicht hier, sondern in einem Zug über die Übersetzungsseite. Hier reicht der englische Name. An ihm hängen die Übersetzungen später.

Der Status ist der einzige Eintrag mit einem eigenen Editor, weil an ihm mehr hängt als ein Name. Er hat weiter unten eine eigene Karte.

Kategorien wählt der Anfragende oder der Bearbeiter beim Anlegen eines Tickets aus. Nach ihnen wertest du später aus. Jedes Team hat seine eigenen Kategorien. Der Helpdesk sortiert nach anderen Dingen als die Netzwerk-Abteilung, und keiner sieht die Listen des anderen.

Du findest sie unter „Settings" als Eintrag „<Teamname> Categories". Im Beispiel heißt das Team „Helpdesk", der Eintrag also „Helpdesk Categories".

Die Seite hat drei Karten: „Main categories", „Subcategories" und „Links". Am schnellsten geht es so: den englischen Namen in das Feld „EN (required)" schreiben und auf „+ New main category" oder „+ New subcategory" klicken. Die Übersetzung in die anderen Sprachen machst du später in einem Zug über die Übersetzungsseite. Hier musst du dafür nichts vorbereiten.

Hast du viele Kategorien vor dir, nimm den Weg über die Datei. „Export JSON" lädt die Struktur herunter. Auf einem frisch installierten System ist die Datei leer und zeigt dir nur den Aufbau. Du füllst sie aus, von Hand oder mit Hilfe einer KI, speicherst sie und lädst sie über „Import JSON" wieder hoch. Zum Umbenennen taugt der Weg nicht. Namen änderst du im Feld der jeweiligen Kategorie und bestätigst mit „Save" daneben. Das sagt dir die Seite auch selbst.

Die dritte Karte, „Links", ist die eigentliche Arbeit. Oben wählst du eine Hauptkategorie, darunter hakst du die Unterkategorien an, die dazu passen, und speicherst mit „Save links". Eine Unterkategorie darf an mehreren Hauptkategorien hängen. „Malfunction" brauchst du deshalb genau einmal und benutzt sie bei Printer, Network, Meeting-Room und Notebook wieder.

Danach stehen die Kategorien im Ticket zur Auswahl. Löschen kann fehlschlagen, solange Tickets die Kategorie benutzen. Das ist Absicht, sonst verlören alte Tickets ihre Einordnung. Löst du eine Verknüpfung, lassen sich Tickets mit diesem Paar trotzdem weiter speichern. Geprüft wird nur eine neu gewählte Kategorie.

Gibst du ein Ticket an ein anderes Team ab, bleibt seine Einordnung erhalten. Das gilt auch dann, wenn das neue Team diese Kategorien gar nicht führt. Sie steht dann mit ihrer Herkunft im Feld, etwa „Meeting-Room · von Helpdesk", und ist ausgegraut. Das neue Team sieht, als was der Vorgang bisher lief, kann diesen Eintrag aber nicht selbst vergeben. Zum Umsortieren wählst du aus der eigenen Liste. Dann verlangt das System Haupt- und Unterkategorie gemeinsam.

Jedes Ticket trägt einen Eingangskanal. Er steht im Formular und später auf der Karte „Actions" unter „How the request came in". Er beantwortet eine Frage, die in der Auswertung schnell wichtig wird: Kommt die Arbeit über das Portal herein oder über das Telefon?

Wählbar ist nur, was ein Mensch weiß und das System nicht: „Phone" und „Entered by an agent". Die beiden anderen Werte vergibt das System selbst. „Self-service" steht dort, wenn der Anfragende das Ticket im Portal angelegt hat, und „E-mail", wenn es aus einer eingehenden Mail entstanden ist. Legt ein Bearbeiter ein Ticket an, steht im Formular zunächst „Entered by an agent".

Einen Kanal, den das System gesetzt hat, kann danach niemand mehr ändern. Am Feld steht dann „Recorded by the system. It cannot be changed." Sonst würde das Feld genau die Aussage verlieren, für die es da ist. An einem telefonisch erfassten Ticket darfst du alles andere weiter ändern.

Setzen darf den Kanal nur ein Bearbeiter oder Administrator. Für den Anfragenden wäre es eine Angabe über den eigenen Vorgang, und die Auswertung müsste sich darauf verlassen.

„E-mail" setzt voraus, dass ein Postfach angebunden ist. Das gehört zur Professional-Edition. Die übrigen drei Kanäle gibt es in beiden Editionen.

Über jeder Ticketliste steht das Feld „Search tickets…". Es sucht nicht nur in Titeln, sondern im ganzen Vorgang: Titel, Beschreibung, Name, E-Mail-Adresse und Telefonnummer des Anfragenden, Standort, Referenz-Ticketnummer, alle Kommentare und die Textwerte deiner eigenen Felder.

Das Beispiel zeigt es: „coffee" steht in keinem Titel, sondern nur im Beschreibungstext eines Tickets. Der Treffer kommt trotzdem. Du musst dir also nicht merken, wie ein Ticket überschrieben war. Ein Wort aus dem Vorgang genügt.

Groß- und Kleinschreibung spielt keine Rolle. Die Suche gilt immer für die Liste, in der du gerade stehst, und lässt sich mit „Filter" daneben kombinieren. „Reset" räumt Suche und Filter wieder weg. Die Liste merkt sich deine Filter, getrennt für jede Teamliste. Sie stehen wieder da, wenn du aus einem Ticket zurückkommst, die Seite neu lädst oder dich an einem anderen Rechner anmeldest. Den Suchtext merkt sie sich nicht. Für Kunden gilt eine Grenze, die man nicht sieht: Sie durchsuchen keine internen Kommentare. Sonst könnten sie an der Trefferliste ablesen, was intern besprochen wurde. Auch Zusatzfelder, die für Kunden verborgen sind, durchsuchen sie nicht.

Jeder stellt seine Ticketliste selbst zusammen. Neben „Filter" steht dafür die Schaltfläche „Columns". Sie öffnet den Dialog „Choose columns".

Im Dialog setzt du einen Haken bei jeder Spalte, die du sehen willst. Mit den Pfeilen daneben legst du die Reihenfolge fest. „#" und „Title" sind immer dabei. Die Breite einer Spalte ziehst du in der Liste direkt am Rand des Spaltenkopfs.

Mit „Save" wird die Auswahl in deinem Benutzerkonto gespeichert. Sie gilt deshalb auf jedem Rechner und bleibt nach dem Abmelden erhalten. „Default columns" stellt die Liste wieder so her, wie sie als Werkseinstellung aussieht.

Reicht der Platz nicht für alle Spalten, fallen zuerst die ganz rechts weg. „#", „Title" und „Status" bleiben immer stehen. Was dir am wichtigsten ist, schiebst du also nach vorn.

Mit Professional stehen auch deine eigenen Felder zur Auswahl. Sie erscheinen im Dialog unter ihrem Namen, hier zum Beispiel „Asset tag".

Kunden können ihre Liste genauso einrichten, bekommen aber weniger Spalten angeboten. „Team", „Created by", „Last activity", „Status changed at", „Deadline", „Follow-up" und „Time" fehlen dort. Auch Felder, die du vor Kunden verborgen hast, erscheinen nicht als Spalte.

Auf dem Smartphone gibt es die Schaltfläche nicht. Dort zeigt die Liste die Spalten, für die Platz ist.

Auf dem Ticket stehen dafür zwei Schaltflächen nebeneinander, und der Unterschied steht klein darunter. „Involve another team": Du bleibst zuständig, das andere Team arbeitet in einem verknüpften Ticket zu. „Escalate to another team": Das andere Team übernimmt.

Beim Abgeben wandert die Zuständigkeit, ohne dass ein zweites Ticket entsteht. Dein Team behält Leserecht und darf weiter kommentieren, aber nichts mehr ändern. Genau das sagt dir der Dialog, bevor du bestätigst. Dort wählst du das Zielteam und kannst einen Grund mitgeben.

Beim Einbeziehen bleibt dein Ticket in deiner Hand und bekommt ein Unterticket im anderen Team. Dein Ticket geht in den Status „Waiting for other team". Schließt das andere Team seines, kommt deines als „Back from other team" zurück. Du musst also nicht nachfragen, ob dort etwas passiert ist. Die Anhänge des Untertickets kommen dabei in dein Ticket. Sie tragen dort die Marke „Internal", und der Kunde sieht sie nicht.

Die Kategorien des abgebenden Teams bleiben am Ticket stehen, auch wenn das neue Team sie gar nicht führt. Sie erscheinen dort mit ihrer Herkunft und ausgegraut. Das neue Team sieht damit, als was der Fall bisher lief, und ordnet ihn bei Bedarf in die eigene Liste um.

Abgeben darf nur, wer gerade zuständig ist. Eine frühere Station sieht den Vorgang weiterhin, kann ihn aber nicht ein zweites Mal weiterreichen. Sie kann kommentieren, das Ticket aber nicht wieder an sich ziehen.

In der Liste deines Teams steht das Ticket danach als „Waiting for other team", solange das andere Team daran arbeitet. Der Haken „Also show tickets this team handed over" ist als Werkseinstellung gesetzt, und jeder Benutzer behält seine eigene Wahl. Für das andere Team beginnt das Ticket als „Open".

Wer eskaliert, wird Beobachter des Tickets. Das sagt der Dialog, bevor du bestätigst. Als Beobachter bekommst du eine Mail, wenn sich der Status ändert, das Ticket geschlossen wird oder jemand kommentiert. Wie jeder Beobachter trägst du dich mit „Stop observing" wieder aus.

Fehlt dir im Ticket eine Angabe, legst du sie selbst an. Das kann die Inventarnummer sein, das Ende der Garantie oder die Kostenstelle. Unter „Settings → Ticket Settings" steht ganz unten die Karte „Custom fields", die Schaltfläche heißt „Add custom field".

Im Dialog gibst du einen Namen und einen Feldtyp an: „Text", „Multiline text", „Integer", „Decimal", „Date" oder „Yes / No". Der Typ bestimmt, was eingegeben werden kann. Ein Datumsfeld nimmt kein „nächste Woche" an. Deshalb kannst du später danach auswerten.

Unter „Scope" entscheidest du, wo das Feld gilt: „All teams (including new ones)" oder „Selected teams only". Die erste Wahl greift auch für Teams, die es heute noch gar nicht gibt.

Die drei Schalter unter „Defaults" heißen „Mandatory by default", „Hidden for customer by default" und „Not editable by customer by default". Sie gelten für ein Feld nur, solange in der Feldsteuerung auf derselben Seite für dieses Feld nichts gespeichert ist. Sobald du es dort festlegst, gilt die Feldsteuerung.

Am Ticket stehen die Zusatzfelder in einer eigenen Karte „Additional information", zwischen Beschreibung und Kommentaren. Ohne Vorlage zeigt das Formular alle Zusatzfelder des Teams. Wählst du beim Anlegen eine Vorlage, zeigt es genau die Felder, die diese Vorlage aufführt, und zwar in ihrer Reihenfolge.

Eine Vorlage kann ein Feld zusätzlich zur Pflicht machen. Was der Administrator für Kunden verborgen hat, bleibt verborgen, auch wenn eine Vorlage es aufführt. Ein Pflichtfeld, das eine Vorlage nicht aufführt, fragt das Formular nicht ab. Für Tickets mit dieser Vorlage entfällt diese Pflicht.

Wie viele Zusatzfelder ein Team haben darf, steht unter „Settings → General Settings" in der Karte „Custom fields limit". Weg bekommst du ein Feld mit „Deactivate". Es verschwindet aus dem Formular, seine Werte bleiben aber an den alten Tickets stehen. Mit dem Schalter „Show deactivated" holst du es wieder in die Liste.

Manchmal soll jemand einen Vorgang mitlesen, ohne ihn zu bearbeiten: der Teamleiter bei einem heiklen Fall oder die Kollegin, die nächste Woche Vertretung macht. Dafür gibt es Beobachter. Auf dem Ticket steht das Feld „Observers" auf der Karte „Actions", die Schaltfläche heißt „Add observer". Im Formular „Create new ticket" steht dasselbe Feld. Am Ticket wird eine Änderung dort mit „Save" in der Karte „Details" gespeichert.

Zur Auswahl stehen nur Bearbeiter und Administratoren des Teams, dem das Ticket gehört. Ein Kunde kann kein Beobachter sein. Er bekäme sonst Post über interne Vorgänge.

Ein Beobachter bekommt eine E-Mail, wenn sich am Ticket etwas tut: neuer Kommentar, geänderter Status, neue Zuweisung, geänderte Felder. Verschickt wird nicht sofort, sondern gebündelt: Nach der letzten Änderung wartet das System eine Minute und schickt dann EINE Mail über alles, was in dieser Zeit passiert ist. Wer ein Ticket in einem Rutsch bearbeitet, löst also keine sieben Mails aus. Kommen in dieser Zeit mehrere Kommentare, stehen alle in der Mail.

Wer beobachtet, steht in der Historie: Ein Wechsel wird wie jede andere Änderung mit altem und neuem Stand festgehalten.

Beobachter eintragen gehört zu Basic. Die Mail an Beobachter ist Professional, denn sie braucht den Mailversand. Ohne ihn kannst du Beobachter eintragen, aber es geht nichts hinaus. Ein Beobachter kann sich mit dem Knopf „Stop observing" selbst austragen. Dafür braucht er kein Recht, das Ticket zu ändern.

Ein Beobachter kommt auch von selbst dazu: Wer ein Ticket mit „Escalate to another team" abgibt, wird Beobachter. So erfährt er, was das andere Team damit macht.

Arbeiten zwei Personen gleichzeitig am selben Ticket, kann das spätere Speichern das frühere überschreiben. Bemerken würde das niemand. Deshalb zeigt das Ticket, wer es gerade noch offen hat. Außerdem weist es ein Speichern ab, das auf einem veralteten Stand beruht.

Der Hinweis steht im Kopf des Tickets. „Marco Rossi is viewing this ticket" heißt, dass Marco das Ticket offen hat. „Marco Rossi is actively editing this ticket" heißt, dass er darin ungespeicherte Eingaben hat. Das kann eine angefangene Antwort sein, ein Kommentar, den er gerade ändert, Titel oder Beschreibung im Bearbeitungsmodus, eine Wiedervorlage, ein Zusatzfeld oder eine Zeitbuchung. Dazu zählen auch geänderte Felder in den Karten „Actions" und „Details", solange sie nicht mit „Save" gespeichert sind. Ein offenes Fenster am Ticket zählt ebenfalls. Das sind die Fenster „Involve another team?", „Escalate to another team?", „Close ticket", „Resolve incident" und „Start a workflow". Dazu kommt das Fenster für den Kommentar zu einem Statuswechsel. Nach zwei Minuten ohne Eingabe zeigt der Hinweis wieder „viewing". Das gilt auch, wenn der Entwurf noch dasteht.

Haben mehrere Kollegen das Ticket offen, fasst der Hinweis sie zusammen, zum Beispiel „Marco Rossi and 2 more are viewing this ticket". Zeigst du auf den Hinweis, siehst du alle Namen. Sobald jemand aktiv bearbeitet, zählt die Zeile nur noch die Bearbeitenden. Dich selbst siehst du nie. Hast du das Ticket in zwei Tabs offen, zählst du einmal. Hast du das Ticket nur in einem verdeckten Tab offen, verschwindest du nach etwa einer Minute aus dem Hinweis der anderen.

Speichert ein Kollege eine Änderung, steht dort „Marco Rossi changed this ticket" mit der Schaltfläche „Refresh" daneben. Ein neuer Kommentar von jemand anderem zeigt „Marco Rossi added a comment". Stammt die Änderung von keiner Person, etwa von einer Automatisierungsregel oder einer eingegangenen E-Mail, steht dort „This ticket was changed". Der Hinweis bleibt stehen, bis du neu lädst.

„Refresh" lädt den aktuellen Stand des Tickets, also Status, Zuweisung, Felder und Historie. Die ganze Seite lädt dabei nicht neu. Deine ungespeicherten Eingaben bleiben. Eine angefangene Antwort bleibt im Antwortfeld stehen. Ein offener Titel oder eine offene Beschreibung behält deinen Text. Hat sich der gespeicherte Text inzwischen geändert, steht darunter „The saved text has changed in the meantime.". Speicherst du dann, ersetzt dein Text den gespeicherten. Die Schaltfläche „Refresh" im Kopf des Tickets macht dasselbe.

Speicherst du trotzdem auf einem veralteten Stand, wird das Speichern abgewiesen. Es öffnet sich das Fenster „Ticket changed in the meantime". Hat eine Person die Änderung gemacht, nennt es ihren Namen. Deine Änderung ist nicht gespeichert. Klicke auf „Refresh", prüfe deine Änderung gegen den aktuellen Stand und speichere erneut. Das gilt für jede Änderung am Ticket selbst, zum Beispiel Status, Zuweisung, Priorität, die Karte „Details" und Zusatzfelder.

Kommentare werden nie abgewiesen. Zwei Antworten überschreiben sich nicht. Beide landen am Ticket. Dasselbe gilt für Anhänge und Zeitbuchungen. Auch Sammelaktionen auf der Ticketliste und Automatisierungsregeln werden nicht gegen den Stand geprüft. Sie ändern das Ticket direkt. Wer es offen hat, sieht danach den Hinweis.

Kunden sehen nichts davon. Sie erscheinen nicht im Hinweis. Sie sehen auch nicht, wer an ihrem Ticket arbeitet.

Wer ein Ticket offen hat, steht nur im Arbeitsspeicher des Servers. Etwa eine Minute nachdem die Person das Ticket verlassen hat, ist der Eintrag weg. In ein Protokoll wird davon nichts geschrieben. Das Ticket speichert, wer es zuletzt geändert hat. Dieser Eintrag gehört zur Datenauskunft für diese Person. Wird die Person anonymisiert, wird er entfernt.

Der Mailkanal ist ein Weg mit zwei Richtungen, und beide gehören zusammen. Aus einer eingehenden Mail entsteht ein Ticket, deine Antwort geht als Mail hinaus, und die Antwort des Anfragenden landet als Kommentar im selben Ticket. Ein zweites Ticket entsteht dabei nicht.

Eine Antwort landet nur dann am bestehenden Ticket, wenn die Mail die Kennung des Vorgangs im Betreff trägt oder die Antwort-Kopfzeilen des Mailprogramms mitschickt. Eine Mail ohne beides beginnt einen neuen Fall. Sonst könnten zwei fremde Vorgänge zusammenlaufen, nur weil der Betreff zufällig gleich lautet.

Alles dazu steht unter „Settings → E-Mail Settings". Die obere Karte „SMTP settings" ist der Weg nach draußen: Host, Port, „Use SSL", Benutzer und Passwort, dazu Absenderadresse und Absendername. Mit „Send test e-mail" schickst du dir eine Probe. Erst speichern, dann testen. Das sagt die Karte auch.

Die Karte „IMAP settings" ist der Weg herein: Host, Port, der Abrufabstand unter „Poll interval" und die beiden Ordner. Den Ordnernamen musst du nicht raten. „Read from server" holt die tatsächlich vorhandenen Ordner deines Postfachs zur Auswahl, „Create on server" legt einen neuen an. Das Feld übernimmt danach den Pfad, den dein Mailserver dafür benutzt. Der eine schreibt „INBOX/Processed", der andere „INBOX.Processed". Beide meinen dasselbe.

Der „Processed folder" nimmt die Mails auf, die das System beiseitelegt. Das sind Mails gesperrter Absender, automatisch erzeugte Mails und Mails, die ein Ablauf mit „Move to folder" ohne eigenen Ordner verschiebt. Lässt du ihn leer, bleiben sie im Posteingang liegen. Darunter stellst du mit „Hour" und „Minute" ein, wann aufgeräumt wird, und mit „Retention (days)", wie alt eine Mail werden darf. Ohne diese Angaben wächst das Postfach weiter.

Postfächer gehören dem Team, nicht dem System. Unter „Team mailboxes" trägt jedes Team seine eigene Adresse mit Passwort ein. Diese Adresse ist zugleich der Absender der Mails dieses Teams. Der Anfragende antwortet also dorthin, wo auch abgeholt wird.

Der wichtigste Teil ist der Arbeitsablauf. Ein eingerichtetes Postfach allein tut gar nichts. Gibt es für ein Team keinen eingeschalteten Ablauf, wird das Postfach nicht einmal abgerufen. Es entsteht kein Ticket, es geht keine Empfangsbestätigung hinaus, und die Mails bleiben liegen. Die automatische Antwort an deine Kunden gibt es ausschließlich hier, und du richtest sie selbst ein. Das ist Absicht, damit das System nicht ungefragt an jede Absenderadresse schreibt.

Unter „E-Mail workflows" wählst du oben das Team und legst mit „+ Add workflow" einen Ablauf an. Er bekommt einen Namen, den nur du siehst, und einen Schalter „Enabled". Dazu kommen zwei Angaben, wann er greift. „Match" entscheidet, ob alle Bedingungen zutreffen müssen oder eine genügt. „Stop after match" beendet den Durchlauf, sobald dieser Ablauf getroffen hat. Ein weiter unten stehender Ablauf kommt dann nicht mehr an die Reihe. Die Reihenfolge änderst du mit den Pfeilen daneben.

Unter „When?" steht die Bedingung selbst. „Every e-mail in this mailbox" nimmt jede Mail, „Only when subject or text contains" verlangt ein Wort im Betreff oder im Text. Über „Advanced" wird es genauer. Dort wählst du, worauf geschaut wird: „Subject or body", „Subject", „Body", „Sender (From)" oder „Recipient (To/Cc)". Daneben wählst du, wie verglichen wird: „Contains", „Equals" oder „Regex". So trennst du zum Beispiel Meldungen an eine Sammeladresse von allem anderen.

Darunter stehen fünf Aktionen als Schalter. Sie sind der eigentliche Inhalt des Ablaufs. Was nicht eingeschaltet ist, passiert nicht.

„Create or append ticket" macht aus der Mail ein Ticket. Steht die Kennung im Betreff, hängt es die Mail stattdessen als Kommentar an das bestehende Ticket. Ohne diese Aktion entsteht aus einer Mail nie ein Vorgang.

„Set fields" setzt beim Anlegen gleich Priorität, Status, Haupt- und Unterkategorie, zuständiges Team und Bearbeiter. Alles, was auf „— Keep default —" steht, bleibt so, wie es ohne Ablauf wäre.

„Auto-reply" ist die Empfangsbestätigung an den Absender. Ist dieser Schalter aus, bekommt dein Kunde keine Empfangsbestätigung, egal wie gut der Rest eingerichtet ist. Auch „Send mail" kann an den Absender schreiben. Das zeigt die nächste Aktion.

„Send mail" verschickt eine zusätzliche Mail, wahlweise an den Absender der eingegangenen Mail oder an ausgewählte Teammitglieder und feste Adressen. Sie hat eigene „Send conditions". Lässt du die leer, geht sie bei jedem Durchlauf dieses Ablaufs hinaus.

„Move to folder" räumt die abgearbeitete Mail in einen Ordner. Bleibt das Feld leer, gilt der allgemeine „Processed folder" aus den IMAP-Einstellungen weiter oben.

Die Aktion „Auto-reply" im Einzelnen: Den Betreff baust du aus Bausteinen. „Original subject {originalSubject}" übernimmt den Betreff der eingegangenen Mail, „Ticket reference {ticketTag}" setzt die Kennung des Vorgangs ein. Aus beidem wird zum Beispiel „Printer problem [TICKET-99-a1b2c3]".

Die Kennung wird nicht von selbst angehängt. Sie steht nur da, wo du {ticketTag} hinschreibst. {ticketId} setzt nur die nackte Nummer ein, und an ihr erkennt das System keine Antwort. Fehlt die Kennung im Betreff, ordnet das System eine Antwort trotzdem zu, wenn sie die Antwort-Kopfzeilen der Bestätigung mitschickt. Erst eine Mail ohne beides wird ein neues Ticket.

Der Text darunter ist deine Bestätigung. Schreib ihn auf Englisch: Er läuft über denselben Export/Import wie alle anderen Texte, und nur so lässt er sich in die anderen Sprachen übersetzen. Lässt du ihn leer, verschickt das System seinen eigenen Standardtext. Dieselben Platzhalter sind auch hier erlaubt.

„Reply language" bestimmt, in welcher Sprache Betreff und Text hinausgehen: „Standard English" nimmt das Englische, „Fixed language" eine feste Sprache deiner Wahl, „Assigned agent's language" die Sprache des zugewiesenen Bearbeiters und „Team default language" die Standardsprache des Teams. Die Übersetzungen selbst pflegst du auf der Sprachen-Seite.

Ein Rat steht auch im System über der Karte: Alles, was zu einem Fall gehört, gehört in EINEN Ablauf. Nur Aktionen desselben Ablaufs kennen das gerade erzeugte Ticket. Die Bestätigung kann seine Nummer deshalb nennen, eine Aktion aus einem zweiten Ablauf nicht.

Der ganze Mailkanal gehört zur Professional-Edition, für den Eingang wie für den Ausgang. In Basic verschickt und empfängt das System keine E-Mails. Die Tickets entstehen dort über das Portal, das Telefon und den Bearbeiter.