Anleitung

Jede Funktion Schritt für Schritt, mit Bildschirmfotos aus einem laufenden System. Die Oberfläche auf den Bildern läuft auf Englisch — das ist die Grundsprache des Produkts.

Die Bildschirmfotos stammen aus Version 0.46.0. An den gezeigten Seiten hat sich bis Version 1.1.6 nichts geändert. Anders sieht nur die Versionsnummer aus, die unten in der Seitenleiste steht.

Anpassung & Verwaltung

Hier stellst du das System auf dein Haus ein. Sprache, Logo und Farben gehören dazu. Ebenso die Arbeiten, die selten anfallen und dann wichtig sind: ein Hinweis an alle Benutzer, ein Update, ein Archiv. Bis auf den Versand des Hinweises als E-Mail gehört der ganze Block zu Basic.

1

Sprachen freischalten und selbst übersetzen

Unter „Settings → Language Settings" wählst du aus, welche Sprachen dein Haus anbietet. Es stehen 30 zur Wahl.

Englisch ist immer an und lässt sich nicht abschalten. Es ist die Sprache, auf die das System zurückfällt, wenn ein Text noch keine Übersetzung hat.

Jeder Benutzer wählt danach in seinem eigenen Menü, in welcher der freigeschalteten Sprachen er arbeitet.

Die Übersetzungen kommen nicht mit einem Update. Ein Update bringt neue englische Texte, die Übersetzung dazu spielst du selbst ein.

Der Weg dafür hat zwei Schritte. Du lädst mit „Export JSON" eine Datei herunter, in der jeder englische Text und deine bisherige Übersetzung steht.

Die Datei füllst du in Ruhe aus und spielst sie mit „Import JSON" wieder ein. Leere Felder werden übersprungen, vorhandene Übersetzungen überschrieben.

Platzhalter wie {count} müssen in der Übersetzung erhalten bleiben. Ein Eintrag, dem ein Platzhalter fehlt, wird abgelehnt und bleibt englisch. Das System sagt dir, welcher es war.

Die Karte „State of your language packs" sagt je Sprache, wie weit du bist. Sie nennt drei Fälle: übersetzt, nicht übersetzt und veraltet.

„Veraltet" ist der Fall, auf den es ankommt. Der englische Text hat sich geändert, deine Übersetzung steht noch da und sagt inzwischen etwas anderes.

Die Karte „Languages" mit den Sprachen als Schaltflächen, Englisch fest eingeschaltet.
Der rote Rahmen liegt auf Deutsch und auf „Save languages". Englisch trägt die Marke „Always active".Bild in voller Größe öffnen
Die Karte „Export translations" mit der Auswahl der Zielsprache.
Erst die Zielsprache wählen, dann herunterladen. Die Datei enthält den englischen Text und deine bisherige Übersetzung.Bild in voller Größe öffnen
Die Karte „Import translations" mit der gewählten Datei.
Nach „Select file" steht der Dateiname daneben. Erst „Import JSON" spielt sie ein.Bild in voller Größe öffnen
Die Karte „State of your language packs" mit dem Stand für Deutsch.
In dieser Beispielwelt ist das deutsche Paket vollständig. Die Zahl links wächst mit jedem Update, das neue Texte bringt.Bild in voller Größe öffnen
2

Logo, Favicon und Farben

Unter „Settings → CI Settings" hinterlegst du dein Logo, dein Favicon und drei Farben.

Das Logo steht in der Seitenleiste unter dem Logo des Systems. Empfohlen sind 400 mal 160 Bildpunkte als PNG oder SVG mit durchsichtigem Hintergrund, höchstens 2 MB.

Das Favicon ist das kleine Bild im Reiter des Browsers. Empfohlen sind SVG oder 64 mal 64 Bildpunkte.

Die drei Farben heißen „Primary color", „Accent color" und „Background color". Die erste färbt die wichtigen Schaltflächen, die zweite Symbole und Hervorhebungen, die dritte den Untergrund.

Die Schrift- und Hover-Farben berechnet das System selbst, damit der Text lesbar bleibt. Du gibst nur die drei Grundfarben vor.

Ein leeres Feld heißt: es gilt die eingebaute Farbe. Das Quadrat daneben zeigt dann Schwarz, weil es keine leere Farbe darstellen kann. Der Hinweis darunter sagt es dir.

Die Vorschau unter den Feldern zeigt deine Farben, bevor du speicherst. Erst „Save" macht sie für alle Benutzer gültig.

„Restore defaults" setzt alles zurück. Dabei verschwinden auch das hochgeladene Logo und das Favicon.

Die Karte „Colors" mit zwei gesetzten Farben und der Vorschau darunter.
Der rote Rahmen liegt auf den zwei Schaltflächen der Vorschau. Sie zeigen die eingetragenen Farben sofort.Bild in voller Größe öffnen
Das eigene Logo in der Seitenleiste, unter dem Logo des Systems.
Der rote Rahmen liegt auf dem hochgeladenen Logo. Es erscheint sofort und auf jeder Seite.Bild in voller Größe öffnen
3

Helle und dunkle Ansicht, und die Ansicht auf dem Telefon

Das System kommt in einer dunklen und einer hellen Ansicht. Umgeschaltet wird im eigenen Menü unten in der Seitenleiste.

Die Wahl gilt je Benutzer und wird gespeichert. Ein Bearbeiter kann hell arbeiten, während seine Kollegin dunkel arbeitet.

Im selben Menü stehen der eigene Anwesenheitszustand, das Profilbild, das Passwort und die Sprache.

Auf einem schmalen Bildschirm ordnet sich die Oberfläche um. Aus der Tabelle werden Karten untereinander, und die Seitenleiste klappt hinter das Symbol oben links.

Es gibt keine eigene App. Die Adresse ist dieselbe wie am Schreibtisch, und angemeldet wird auf demselben Weg.

Das eigene Menü mit den Einträgen „Light mode" und „Dark mode".
Der rote Rahmen liegt auf „Light mode". Der Haken daneben zeigt, welche Ansicht gerade gilt.Bild in voller Größe öffnen
Die Ticketliste in der hellen Ansicht.
Dieselbe Seite, dieselben Daten. Nur die Farben wechseln.Bild in voller Größe öffnen
Dieselbe Seite in einem schmalen Fenster, wie auf einem Telefon.
Auf dem Telefon steht die Liste untereinander. Die Seitenleiste öffnest du über das Symbol oben links.Bild in voller Größe öffnen
4

Datum und Uhrzeit in deiner Schreibweise

Voraussetzung: Administratoren und Bearbeiter dürfen die allgemeinen Einstellungen ändern. Alle anderen lesen das Datum so, wie es dort eingestellt ist.

Unter „Settings → General Settings" findest du die Karte „Date and time format". Sie steht direkt hinter der Zeitzone.

Vier Angaben ergeben die Schreibweise. „Date order" ist die Reihenfolge aus Tag, Monat und Jahr.

„Date separator" ist das Zeichen zwischen den Zahlen. Zur Wahl stehen der Punkt, der Schrägstrich und der Bindestrich.

„Clock" ist die Uhr: 24 Stunden oder 12 Stunden mit AM und PM. „Time separator" ist das Zeichen zwischen Stunde und Minute.

Unter den vier Feldern steht „This is how it looks". Dort siehst du das Ergebnis, bevor du auf „Save" klickst.

Die Einstellung gilt für die ganze Installation. Sie hängt nicht an der Sprache und nicht am einzelnen Benutzer.

Das ist Absicht. Ein Haus schreibt das Datum auf eine Art, und jeder Kollege liest dieselbe Schreibweise.

Als Werkseinstellung gilt Tag, Monat, Jahr mit Punkt und die 24-Stunden-Uhr. Wer nichts umstellt, sieht keine Änderung.

Die Schreibweise gilt überall dort, wo das System ein Datum anzeigt. Dazu gehören das Ticket, die Listen, die Wiedervorlage und die gebuchten Zeiten.

Die Exporte bleiben davon unberührt. Sie schreiben das Datum als 2026-08-22, weil Tabellenprogramme diese Form sicher lesen.

Ein Feld, in das du selbst ein Datum eintippst, gehört nicht dazu. Es öffnet den Kalender deines Browsers und behält dessen Schreibweise.

Mehr dazu in der Karte: Sprachen freischalten und selbst übersetzen

Die Karte „Date and time format" mit den vier Auswahlfeldern und der Vorschau.
Der rote Rahmen liegt auf der Reihenfolge und auf der Vorschau. Die Beispiele in den Auswahllisten ziehen mit der gewählten Reihenfolge mit.Bild in voller Größe öffnen
Die Angaben am Ticket in der Werkseinstellung: Tag, Monat, Jahr und 24-Stunden-Uhr.
So sieht ein Ticket aus, solange nichts umgestellt ist. Oben stehen Zeitpunkte, unten die Tage der gebuchten Zeiten.Bild in voller Größe öffnen
Dieselben Angaben nach dem Umstellen auf Monat, Tag, Jahr mit 12-Stunden-Uhr.
Dasselbe Ticket nach dem Umstellen. Die gebuchten Tage folgen der Einstellung ebenso wie die Zeitpunkte darüber.Bild in voller Größe öffnen
5

Wartung und Störungen ankündigen

Voraussetzung: Der Hinweis auf der Anmeldeseite gehört zu Basic. Ihn zusätzlich als E-Mail zu verschicken, gehört zu Professional.

Die Seite „Maintenance / Incident-Notification" steht in der Seitenleiste. Dort schreibst du einen Hinweis, den jeder sieht.

Der Hinweis erscheint auf der Anmeldeseite und im ganzen System. Wer noch nicht angemeldet ist, liest ihn also auch.

Der Zweck ist, unnötige Tickets zu vermeiden. Wer liest, dass das Netz gerade ausgefallen ist, meldet es nicht noch einmal.

Der Text wird zusammengeklickt. Zuerst klickst du das Feld an, das du füllen willst. Es bekommt einen roten Rahmen, und alles, was du danach anhakst, landet dort.

„Title / Subject" steht oben im Hinweis. „Body" steht darunter. Verschickst du den Hinweis als E-Mail, wird aus dem einen der Betreff und aus dem anderen der Text.

Fertige Sätze liegen als Bausteine bereit. Eigene Sätze kannst du unter „Text Modules" anlegen, deine Systeme und Dienste unter „Systems / Services".

Mit „Calendar (add date)" und „Time (add time)" fügst du ein Datum und eine Uhrzeit ein. Das ist der Weg für eine geplante Wartung.

Der Schalter oben stellt den Hinweis an und wieder aus. Er bleibt stehen, bis du ihn ausschaltest.

Daneben gibt es eine zweite Art Hinweis. Machst du ein Ticket zur Störung, erscheint es ebenfalls auf der Anmeldeseite und verschwindet von selbst, sobald das Ticket gelöst ist. Dieser Schalter gilt dafür nicht.

Mit „Send as E-Mail" schickst du denselben Text zusätzlich an eine Liste von Adressen. Das ist der Teil, der zu Professional gehört.

Mehr dazu in der Karte: Die Störung als Banner und als Hinweis in der Eingangsbestätigung

Die Karte mit den Textbausteinen und den eigenen Systemen.
Der rote Rahmen liegt auf der Liste der Systeme. In dieser Beispielwelt stehen dort E-Mail, VPN und ein Dateiserver.Bild in voller Größe öffnen
Titel und Text mit angehakten Bausteinen, das Feld „Body" ist aktiv.
Der rote Rahmen liegt auf dem aktiven Feld und auf „Calendar (add date)". Unter dem Feld steht, welches gerade aktiv ist.Bild in voller Größe öffnen
Die Anmeldeseite mit dem eingeschalteten Hinweis quer über der Seite.
So liest ihn ein Kunde, bevor er sich anmeldet. Der Hinweis lässt sich mit „Dismiss" für diesen Besuch wegklicken.Bild in voller Größe öffnen
Derselbe Text mit angehaktem „Send as E-Mail" und der Empfängerliste.
Der rote Rahmen liegt auf der Empfängerliste und auf „Send Mail". Mehrere Adressen trennst du mit einem Komma.Bild in voller Größe öffnen
6

Frühwarnung, bevor die Platte voll ist

Das System sieht auf den Plattenplatz des Servers und meldet sich, bevor er ausgeht.

Es gibt zwei Stufen. Ab 90 Prozent belegt kommt ein Hinweis, ab 95 Prozent eine Warnung.

Wer die Updates verwaltet, sieht die Zahlen und was zu tun ist. Meist sind alte Abbilder früherer Updates der größte Posten.

Alle anderen angemeldeten Benutzer bekommen einen kurzen Satz und den Verweis auf ihre Administration. Sie sehen ihn erst ab der Warnstufe.

Auf der Anmeldeseite steht davon nichts. Wie voll die Platte eines Servers ist, geht niemanden etwas an, der noch nicht angemeldet ist.

Eine volle Platte trifft nicht nur das Update. Anhänge, der Mail-Eingang, die Datenbank und die Sicherung liegen auf derselben Platte.

Das Banner mit dem Hinweis, dass der Platz knapp wird.
Die erste Stufe. In dieser Beispielwelt sind 93 Prozent belegt und 14 von 200 GB frei.Bild in voller Größe öffnen
Dasselbe Banner mit dem Text der Warnstufe.
Die zweite Stufe bei 96 Prozent. Jetzt nennt der Text auch, was ausfallen kann.Bild in voller Größe öffnen
Dasselbe Ereignis im Fenster einer Bearbeiterin: ein kurzer Satz ohne Zahlen.
Wer den Platz nicht aufräumen kann, bekommt keine Zahlen. Der Satz nennt die Folge und den Weg zur Administration.Bild in voller Größe öffnen
7

Update auf Knopfdruck

Unter „Settings → Updates" siehst du, welche Fassung läuft und ob es eine neuere gibt.

Gibt es eine neue Fassung, steht darunter, was sie bringt. Die Liste zeigt jede Version, die du überspringst.

Vor dem Update legt das System selbsttätig eine Sicherung an. Sie umfasst die Datenbank, die Anhänge und die Archive.

Danach prüft es, ob genug Platz frei ist. Ein Update braucht das alte und das neue Abbild gleichzeitig, deshalb verlangt es 10 GB.

Reicht der Platz nicht, lehnt das System das Update ab und sagt warum. Das ist die bessere Nachricht als ein Abbruch auf halber Strecke.

Vor dem Start fragt das System nach. Während des Updates ist es einige Minuten nicht erreichbar, deshalb wählst du besser eine ruhige Zeit.

Geht etwas schief, kehrt das System auf die vorherige Fassung zurück und läuft weiter.

Kommt dein Server nicht an die Update-Quelle, sagt das System genau das. Es behauptet dann nicht, du seist auf dem neuesten Stand.

Ein Update, das die Datenbank auf eine neue Fassung hebt, wird nicht auf Knopfdruck eingespielt. Das System sagt es dir, und die Anleitung zur Fassung sagt, was zu tun ist.

Die Karte „Version status" mit der Meldung, dass das System aktuell ist.
Der rote Rahmen liegt auf der Meldung. „Check now" fragt sofort nach, statt auf die nächste Prüfung zu warten.Bild in voller Größe öffnen
Dieselbe Karte mit einer verfügbaren Version und ihren Release-Notes.
Der rote Rahmen liegt auf „Install update". Darüber steht, was die neue Fassung bringt.Bild in voller Größe öffnen
Die Rückfrage vor dem Start des Updates.
Die Rückfrage nennt die Version und sagt, dass vorher gesichert wird.Bild in voller Größe öffnen
Dieselbe Karte, wenn die Update-Quelle nicht erreichbar ist.
Der rote Rahmen liegt auf der Meldung. Ohne Antwort sagt das System, dass es nichts weiß.Bild in voller Größe öffnen
8

Geschlossene Tickets archivieren

Voraussetzung: „Delete from live DB" löscht die Tickets endgültig aus der laufenden Datenbank. Lade das Archiv vorher herunter und sieh hinein.

Unter „Settings → Archive" packst du geschlossene Tickets eines Zeitraums in eine Datei. Der laufende Bestand bleibt dadurch klein.

Es wandert nur, was geschlossen ist. Ein offenes Ticket im selben Zeitraum bleibt, wo es ist.

„Preview" sagt dir vorher, wie viele Tickets der Zeitraum trifft. Es schreibt nichts und ändert nichts.

„Create archive" legt eine ZIP-Datei an. Darin stehen die Tickets mit ihren Kommentaren, ihrem Verlauf, ihren eigenen Feldern und ihren Anhängen.

Die Datei liegt danach in der Liste darunter, mit Zeitraum, Anzahl und Größe. Ein Unterordner ist möglich, wenn du nach Jahren ablegen willst.

Erst danach entscheidest du, ob die Tickets aus der laufenden Datenbank verschwinden. Das Anlegen des Archivs allein ändert daran nichts.

„Restore" holt die Tickets aus der Datei zurück. Tickets, deren Nummer es schon gibt, werden dabei übersprungen.

Die Wiederherstellung braucht die Teams und die Vorgänge, auf die sich ein Ticket bezieht. Fehlen sie, sagt das System, was es nicht zuordnen konnte.

„Delete archive file" löscht nur die Datei. Die Tickets in der laufenden Datenbank bleiben davon unberührt.

Die Karte „Create archive" mit den beiden Datumsfeldern.
Der rote Rahmen liegt auf dem Zeitraum. Der Unterordner ist freiwillig.Bild in voller Größe öffnen
Dieselbe Karte mit dem Ergebnis der Vorschau.
In dieser Beispielwelt trifft das Jahr zwei geschlossene Tickets. Die Vorschau ändert nichts.Bild in voller Größe öffnen
Die Liste der Archive mit Zeitraum, Anzahl, Anhängen und Größe.
Der rote Rahmen liegt auf den beiden Aktionen, die den laufenden Bestand betreffen.Bild in voller Größe öffnen
Die Rückfrage, bevor die Tickets aus der laufenden Datenbank verschwinden.
Die Rückfrage sagt, dass sich der Schritt nicht rückgängig machen lässt.Bild in voller Größe öffnen
9

Auswahllisten als Datei füllen

Unter „Settings → General Settings" stehen die Auswahllisten des Systems. Jede Liste hat einen eigenen Reiter.

Für Abteilungen, Positionen und Standorte gibt es zusätzlich den Weg über eine Datei. Das lohnt sich, wenn du viele Einträge auf einmal anlegst.

„Export JSON" lädt die Liste herunter. Auf einer frischen Installation bekommst du damit die leere Struktur, in die du deine Einträge schreibst.

In der Datei steht ein Beispiel, das zeigt, wie ein Eintrag aussieht. Es wird beim Einspielen übergangen.

„Import JSON" legt an, was noch fehlt. Vorhandene Einträge bleiben unberührt.

Umbenennen geht über die Datei nicht. Dafür sind die Felder auf dieser Seite da, und der rote Hinweis sagt es auch.

Die Übersetzung der Einträge machst du danach auf der Sprachseite. In der Datei steht der englische Name.

Für die Kategorien gibt es denselben Weg. Sie gehören einem Team und stehen deshalb auf der Kategorieseite dieses Teams.

Mehr dazu in der Karte: Haupt- und Unterkategorien sind pro Team frei konfigurierbar

Der Reiter „Department" mit den Schaltflächen für Export und Import.
Der rote Rahmen liegt auf den beiden Schaltflächen. Der rote Satz darüber warnt vor dem Umbenennen über die Datei.Bild in voller Größe öffnen
Die heruntergeladene Datei im Browser, mit dem Beispiel und den Einträgen.
Mehr als Namen steht nicht darin. Deshalb lässt sie sich in jedem Texteditor bearbeiten.Bild in voller Größe öffnen

Teams & Benutzer

Ein Team ist eine Zuständigkeit und kein Ordner. Es hat eigene Kategorien, eigene Fristen und eigene Mitglieder. Der Kunde sieht davon genau ein Team. Alles Weitere hängt daran, wer welches Konto hat und was dieses Konto darf.

1

Teams anlegen und einstellen

Die Teams liegen unter „Settings → Teams". Links steht die Liste, rechts die Einstellungen des Teams, das du angeklickt hast. Die Zahl hinter dem Namen ist die Zahl seiner Mitglieder.

Ein neues Team bekommt seinen Namen im Feld „Team name". Darunter kannst du unter „Copy categories from" ein vorhandenes Team wählen. Dann startet das neue Team mit denselben Haupt- und Unterkategorien. „Create team" legt es an.

Das erste Team ist das Team der Kunden. Jedes weitere ist ein Fachteam dahinter. Einem Melder ist nicht zuzumuten, selbst die zuständige Abteilung zu wählen. Er legt sein Ticket beim ersten Team ab, und von dort wird es weitergegeben.

Umstellen kannst du das jederzeit. Die Karte „Customer permissions" legt je Team fest, ob Kunden dort Tickets anlegen und ihre eigenen sehen dürfen. Ohne eine der beiden Erlaubnisse taucht das Team beim Kunden gar nicht auf.

Die Karte „Agent permissions" gilt für die Bearbeiter dieses Teams. Sie regelt, ob sie Tickets verwalten, Kategorien verwalten und die Berichte dieses Teams sehen dürfen.

Die Karte „Agents" führt die Mitglieder. Trotz der Überschrift stehen dort auch die Kunden des Teams. Über die Auswahl darüber und „Add Agent" kommt jemand dazu, mit „Remove" wieder heraus. Wer hinzugefügt oder entfernt wird, muss sich einmal ab- und wieder anmelden.

„Default e-mail language" ist die Sprache, in der dieses Team schreibt. Sie greift, wenn eine Mailregel „Team default language" wählt.

Der Schalter „Active" nimmt ein Team aus dem Betrieb. Es verschwindet aus der Seitenleiste und steht in keiner Auswahl mehr. Gelöscht ist es damit nicht.

„Delete" entfernt ein Team nur, solange kein Ticket mehr offen ist. Sonst nennt das System den Grund und tut nichts.

Die Karte „Audit log" hält jede Änderung am Team fest, mit Name und Zeitpunkt.

Basic führt ein Team. Professional kennt keine Grenze.

Die Seite „Teams" mit der Liste der beiden Teams links und den Einstellungen des Helpdesks rechts.
Die roten Rahmen liegen auf den beiden Teams. Ein Klick darauf wechselt, was rechts steht. Die Zahl am Rand ist die Zahl der Mitglieder.Bild in voller Größe öffnen
Das Feld „Team name" mit einem eingetragenen Namen, darunter „Copy categories from" und die Schaltfläche „Create team".
Name eintragen, wahlweise die Kategorien eines vorhandenen Teams übernehmen, dann „Create team".Bild in voller Größe öffnen
Die Karten „Customer permissions" und „Agent permissions" mit ihren Schaltern.
Die roten Rahmen liegen auf den beiden Überschriften. Diese Schalter gelten nur für dieses eine Team.Bild in voller Größe öffnen
Die Karte „Agents" mit der Auswahl, der Schaltfläche „Add Agent" und den Mitgliedern darunter.
Der rote Rahmen liegt auf „Add Agent". Hinter der Marke an jedem Namen steht die Rolle, und die Karte führt auch die Kunden des Teams.Bild in voller Größe öffnen
Die Karte „Audit log" mit zwei Einträgen, jeweils mit Name und Zeitpunkt.
Der rote Rahmen liegt auf der Überschrift. Jede Zeile nennt die Änderung, wer sie gemacht hat und wann.Bild in voller Größe öffnen
2

Administratoren und Bearbeiter anlegen

Die Konten liegen unter „User management". Die Liste zeigt Name und Anmeldenamen, die E-Mail-Adresse, das Team mit der Abteilung darunter und die Rolle.

„New user" öffnet das Formular. Pflicht sind Vorname, Nachname, Anmeldename und E-Mail-Adresse. Dazu kommt entweder ein Passwort oder der Haken „Send login details by e-mail".

Mit dem Haken vergibst du kein Passwort. Der neue Benutzer bekommt eine Mail mit seinem Anmeldenamen und einem zeitlich begrenzten Link und setzt sein Passwort selbst. Passwörter verschickt das System nie.

Die Rolle entscheidet alles Weitere. „Admin" und „Agent" sind beide Bearbeiter und zählen auf dasselbe Kontingent. Ein Administrator darf als Werkseinstellung mehr, aber jede einzelne Berechtigung lässt sich umstellen.

Basic hat zwei Bearbeiter-Plätze. Wie du sie verteilst, ist deine Sache: entweder ein Administrator und ein Bearbeiter oder zwei Administratoren. Kunden zählen nicht mit, sie sind in beiden Ausgaben unbegrenzt.

Verlässt jemand das Haus, klickst du in seiner Zeile auf das Archiv-Symbol. Das Konto wird gesperrt. Anmelden geht damit nicht mehr.

Ein gesperrtes Konto steht in der Ansicht „Archived" und trägt dort die Marke „locked". In der Ansicht „Active" ist es nicht mehr zu sehen.

Ein gesperrtes Konto belegt keinen Bearbeiter-Platz mehr, und es steht in keiner Zuweisen-Auswahl. Bereits zugewiesene Tickets behalten ihren Bearbeiter und seinen Namen.

Dieselbe Schaltfläche heißt in der Ansicht „Archived" dann „Restore" und gibt das Konto wieder frei. In Basic braucht das wieder einen freien Platz.

Die beiden Symbole dazwischen setzen ein Passwort und die Zwei-Faktor-Anmeldung zurück. Das neue Passwort steht danach einmal auf dem Bildschirm. Verschickt wird es nicht.

Die Seite „User management" mit allen Konten, ihrer Rolle und den Aktionen je Zeile.
Die roten Rahmen liegen auf „New user" und auf der Umschaltung zwischen offenen und gesperrten Konten. Die Schaltfläche zeigt an, welche der beiden Ansichten gerade offen ist.Bild in voller Größe öffnen
Der Dialog „Create new user" mit ausgefüllten Pflichtfeldern und den Auswahlfeldern für Team, Abteilung, Position, Standort und Rolle.
Die roten Rahmen liegen auf der Rolle und auf der Einladung. Die Rolle ist das einzige Auswahlfeld, das ausgefüllt sein muss.Bild in voller Größe öffnen
Derselbe Dialog mit gesetztem Haken: das Passwortfeld ist gesperrt und sagt, dass der Benutzer es über den Link setzt.
Mit dem Haken verschwindet der Stern am Passwortfeld. Das Feld sagt selbst, wer das Passwort vergibt.Bild in voller Größe öffnen
Die Ansicht „Archived" mit einem gesperrten Konto, der Marke „locked" und der Schaltfläche „Restore".
Die roten Rahmen liegen auf der Marke und auf dem Rückweg. Beides gibt es nur in dieser Ansicht.Bild in voller Größe öffnen
3

Kunden: die Konten der Melder

Kunden sind in Basic und in Professional unbegrenzt. Sie belegen keinen Bearbeiter-Platz.

Ein Kundenkonto entsteht auf drei Wegen. Du legst es unter „User management" an. Du lädst die Person per Mail ein. Oder du erlaubst die Selbstregistrierung.

Den Schalter dafür findest du unter „Settings → Security" in der Karte „Self-registration". Als Werkseinstellung ist er aus. Eingeschaltet steht auf der Anmeldeseite ein Link „Register".

Wer sich selbst registriert, bekommt immer die Rolle „Customer". Eine andere Rolle lässt sich auf diesem Weg nicht vergeben.

Ohne Mailversand lässt sich die Adresse nicht prüfen. Solche Konten tragen in der Liste den Hinweis „not confirmed". Der Bearbeiter sieht damit, ob hinter der Adresse jemand steht, der sie nachweislich besitzt.

Für ein internes Ticket-System lässt du den Schalter besser aus. Sonst legt sich jeder ein Konto an, der die Adresse kennt.

Ein Kunde sieht nur seine eigenen Vorgänge. Seine Seitenleiste ist kurz: seine Tickets, ein neues Ticket, die Wissensdatenbank. Einstellungen bekommt er nicht zu Gesicht.

Was er in einem Team darf, steht am Team. Ohne die Erlaubnis, dort Tickets anzulegen, gibt es dieses Team für ihn nicht.

Die Karte „Self-registration" mit dem Schalter und dem Hinweis darunter.
Der rote Rahmen liegt auf dem Schalter. Der Text daneben sagt, was er bewirkt und was ohne Mailversand geschieht.Bild in voller Größe öffnen
Dasselbe System, angemeldet als Kundin: eine kurze Seitenleiste und eine Ticketliste mit ausschließlich ihren eigenen Vorgängen.
In der Spalte „User" steht in jeder Zeile derselbe Name. Ein Kunde sieht nichts, was ihm nicht gehört, und in der Seitenleiste fehlen die Einstellungen.Bild in voller Größe öffnen
4

Rollen und das Berechtigungskonzept

Es gibt drei Rollen: „Admin", „Agent" und „Customer". Weitere lassen sich nicht anlegen. Frei ist dafür jede einzelne Berechtigung.

Umbenennen und übersetzen kannst du die drei. Das machst du unter „Settings → General Settings" im Reiter „Role".

Was eine Rolle darf, steht an einer anderen Stelle: unter „Settings → Security" in der Karte „Permission concept".

Jede Zeile ist eine Funktion, jede Spalte eine Rolle. Ein Haken erlaubt sie. Unter dem Namen steht der interne Schlüssel; für die Bedienung brauchst du ihn nicht.

Die Liste ist lang. Sie reicht von der Benutzerverwaltung über den Zugang zu den einzelnen Einstellungsseiten bis zur Zeiterfassung.

Die Spalte „Agent Team" ist der Sonderfall. Sie wird erst bedienbar, wenn in derselben Zeile der Haken bei „Agent" steht. Wählst du dort ein Team, gilt die Berechtigung nur für Bearbeiter dieses Teams.

Der Rolle „Admin" lässt sich keine Berechtigung nehmen. Der Haken steht nach dem Speichern wieder da. So kann sich niemand aus dem eigenen System aussperren.

Mit „Save" gilt die Änderung sofort. Wer betroffen ist, merkt es beim nächsten Klick.

Die Karte „Permission concept" mit der Tabelle: eine Zeile je Funktion, Spalten für Admin, Agent, Agent Team und Customer.
Der rote Rahmen liegt auf der Kopfzeile. Die Auswahl in der Spalte „Agent Team" ist nur dort bedienbar, wo der Haken bei „Agent" steht.Bild in voller Größe öffnen
Der Reiter „Role" mit den drei Rollen, jeweils mit der Marke „Mandatory".
Der rote Rahmen liegt auf dem Hinweis. Die drei Rollen tragen die Marke „Mandatory" und lassen sich deshalb umbenennen, aber nicht löschen.Bild in voller Größe öffnen
5

Abteilung, Position und Standort

Drei Listen beschreiben den Menschen und nicht das Ticket: Abteilung, Position und Standort.

Angelegt werden sie unter „Settings → General Settings" in der Karte „Drop-down lists". Für alle drei ist die Bedienung dieselbe.

Zugewiesen werden sie am Konto. Im Formular unter „User management" heißen die Felder „Department", „Position" und „Location".

In der Benutzerliste steht die Abteilung unter dem Team. Position und Standort siehst du im Formular des Kontos.

Der Standort hat eine zweite Verwendung. Am Ticket gibt es das Feld „Location", und es greift auf dieselbe Liste zu.

Jede der drei Listen hat einen Eintrag, den du nicht löschen kannst. Er heißt „None selected or available" und trägt die Marke „Mandatory".

Löschst du einen anderen Eintrag, rücken alle Menschen, die ihn trugen, auf diesen Platzhalter. Es bleibt also niemand mit einem Verweis ins Leere zurück.

Übersetzt wird nicht hier, sondern in einem Zug über die Übersetzungsseite. Der englische Name ist der Anker, an dem die Übersetzungen hängen.

Der Dialog „Edit user" mit den ausgefüllten Feldern Department, Position und Location.
Die roten Rahmen liegen auf den drei Feldern. Sie stehen neben dem Team, sind aber etwas anderes: das Team sagt, wer die Tickets bearbeitet, die Abteilung sagt, wo der Mensch arbeitet.Bild in voller Größe öffnen
Die Benutzerliste mit der Spalte „Team", in der unter dem Teamnamen die Abteilung steht.
Der rote Rahmen liegt auf der Spalte. Oben steht das Team, darunter die Abteilung. Wer in keinem Team ist, hat an dieser Stelle einen Strich.Bild in voller Größe öffnen

E-Mail-Integration

Das Ticket-System holt Mails aus einem Postfach ab und verschickt selbst welche. Wie du den Weg einrichtest, steht in der Karte „Tickets aus E-Mails, Antworten und Rückfragen" im Block Ticket-Management. Dieser Block zeigt, was aus einer eingehenden Mail wird, wie du Absender sperrst und welche Nachrichten das System von sich aus verschickt. Der ganze Mailkanal gehört zur Professional-Edition.

1

Was aus einer E-Mail wird

Nur Professional

Schreibt jemand an das Postfach eines Teams, entsteht daraus ein Ticket. Der Betreff wird der Titel, der Text wird die Beschreibung, und die Absenderadresse steht als Anfragender am Ticket. Als Eingangskanal steht „E-mail" darin.

Trägt die Mail einen Absendernamen, steht dieser Name im Feld daneben. Fehlt er, steht dort „E-Mail". Der Eingangskanal sagt ohnehin, dass die Sache per Mail kam.

Vorsätze wie „Re:" oder „AW:" fallen aus dem Titel heraus. Das Ticket trägt damit den Namen der Sache und nicht den einer Antwort darauf.

Die Formatierung der Mail bleibt erhalten. Fettdruck, Aufzählungen und Tabellen stehen im Ticket genauso da wie in der Mail.

Links bleiben erhalten. Der Bearbeiter kann sie im Ticket anklicken, ohne die Adresse abzutippen.

Ein Bild, das in der Mail eingebettet ist, bleibt an seiner Stelle im Text stehen. Zusätzlich liegt es als Anhang am Ticket.

Ein Bild, das die Mail nur aus dem Netz nachlädt, entfernt das System. Solche Bilder melden dem Absender oft, wann und wo eine Mail gelesen wurde. Wer ein Bild zeigen will, fügt es in die Mail ein oder hängt es an.

Dateien im Anhang der Mail werden Anhänge des Tickets. Sie zählen gegen dieselbe Größengrenze wie eine Datei, die ein Bearbeiter hochlädt.

Ist die Auto-Antwort im Arbeitsablauf eingeschaltet, bekommt der Absender sofort eine Empfangsbestätigung. Steht die Referenz im Betreff, findet jede weitere Antwort denselben Vorgang wieder und wird dort ein Kommentar.

Mehr dazu in der Karte: Tickets aus E-Mails, Antworten und Rückfragen

Die abgeschickte Mail im Mailprogramm des Absenders, mit eingebettetem Bild und einem Link.
Dieses Fenster ist nicht das Ticket-System, sondern das Mailprogramm der Absenderin. Die Mail enthält ein eingebettetes Bild und einen Link.Bild in voller Größe öffnen
Die Beschreibung des entstandenen Tickets mit dem Bild an seiner Stelle und dem Link.
Dieselbe Mail als Ticket. Die roten Rahmen liegen auf dem Bild und auf dem Link. Beides steht an derselben Stelle wie in der Mail, der Link ist anklickbar.Bild in voller Größe öffnen
Der Reiter „Attachments" des Tickets mit der Datei inline_image_1.png.
Das eingebettete Bild liegt zusätzlich als Anhang am Ticket. So lässt es sich herunterladen, ohne es aus dem Text zu ziehen.Bild in voller Größe öffnen
Die Eingangsbestätigung im Posteingang der Absenderin, mit der Referenz im Betreff.
Die Empfangsbestätigung, wie sie beim Absender ankommt. Im Betreff steht die Referenz des Vorgangs. Antwortet die Absenderin darauf, landet die Antwort an demselben Ticket.Bild in voller Größe öffnen
2

Absender sperren

Nur Professional

Voraussetzung: Die Sperrliste steht ganz unten auf der Seite „E-Mail Settings". Sie gilt für alle Teams zugleich.

Manche Absender sollen kein Ticket erzeugen. Newsletter gehören dazu und Postfächer, die nur Meldungen von Maschinen verschicken.

Trage eine ganze Adresse ein, wenn genau ein Absender gemeint ist. Im Bild ist das no-reply@example.com.

Trage die Domain mit einem @ davor ein, wenn alle Adressen eines Absenders gemeint sind. Im Bild ist das @newsletter.example.net. Untergeordnete Domains sind damit ebenfalls gesperrt.

Eine Mail von einem gesperrten Absender erzeugt kein Ticket. Sie wird als gelesen markiert und in den Verarbeitet-Ordner verschoben. Im Posteingang bleibt nichts liegen.

Die Sperre wirkt auch in die andere Richtung. An eine gesperrte Adresse verschickt das System keine Mail.

Das ist der eigentliche Nutzen bei Adressen, die niemand liest. Ohne die Sperre ginge die Empfangsbestätigung an ein Postfach, das nicht antwortet.

Mit „Add" kommt ein Eintrag dazu. Das Papierkorb-Zeichen daneben entfernt ihn wieder. Eine Änderung wirkt sofort, ein Speichern ist nicht nötig.

Die Karte „E-Mail Blacklist" mit zwei Einträgen: einer ganzen Adresse und einer Domain.
Der rote Rahmen liegt auf dem Eingabefeld. Sein Platzhaltertext nennt beide erlaubten Formen. Darunter stehen die zwei Einträge dieser Umgebung.Bild in voller Größe öffnen
3

Was das System von sich aus verschickt

Nur Professional

Voraussetzung: Die Schalter dieser Karte stehen je Team unter „Team mailboxes" auf der Seite „E-Mail Settings", direkt unter der Postfachadresse des Teams.

Neben den Antworten an deine Kunden verschickt das System eigene Nachrichten. Dazu gehören die Zuweisung eines Tickets, eine gerissene Frist, eine Einladung, ein neues Passwort, die Zufriedenheitsabfrage und die Genehmigung eines Antrags.

Diese Texte sind fertig vorbereitet und zunächst englisch. Sie stehen mit allen anderen Texten der Oberfläche im Sprachpaket.

Nach dem Import eines Sprachpakets geht jede dieser Nachrichten in der Sprache hinaus, die am Empfänger eingestellt ist. Zwei Menschen in derselben Sache bekommen die Nachricht also in zwei Sprachen.

Den Wortlaut änderst du auf der Sprachen-Seite. Dort lädst du die Texte einer Sprache als Datei herunter, änderst sie und lädst sie wieder hoch. Englisch ist dabei die Vorlage und bleibt, wie es ist.

Ob eine Zuweisung überhaupt gemeldet wird, entscheidest du je Team. Drei Schalter stehen dafür unter dem Postfach.

„Send assignment e-mails" schickt eine Mail an den Bearbeiter, der ein Ticket bekommt. Steht der Schalter aus, meldet dieses Team keine Zuweisungen mehr.

„Notify on self-assignment" entscheidet, ob auch eine Mail kommt, wenn sich jemand ein Ticket selbst nimmt. Als Werkseinstellung ist dieser Schalter aus.

„Send mail on ticket actions" wirkt an anderer Stelle. Ist er an, bieten die Fenster zum Schließen, zum Statuswechsel und zum Abgeben an, den Kommentar zusätzlich als Mail zu verschicken.

Die Empfangsbestätigung an deine Kunden gehört nicht hierher. Ihren Text schreibst du selbst, und zwar im Arbeitsablauf des Postfachs.

Mehr dazu in der Karte: Tickets aus E-Mails, Antworten und Rückfragen

Der Abschnitt „Assignment notifications" mit drei Schaltern.
Die roten Rahmen liegen auf den drei Schaltern. Sie gehören zum Postfach des Teams darüber. Jedes weitere Team hat dieselben drei Schalter für sich.Bild in voller Größe öffnen

Authentifizierung & Sicherheit inkl. SSO

Wer hereinkommt und wie, entscheidest du an zwei Stellen. Die Sicherheitsseite regelt die Anmeldung mit Benutzername und Passwort. Die SSO-Seite bindet ein Verzeichnis oder einen fremden Anmeldedienst an. Beides lässt sich gleichzeitig betreiben.

1

Anmelden mit Benutzername und Passwort

Voraussetzung: Die Einstellungen dieser Karte liegen unter „Settings → Security". Diese Seite sehen nur Administratoren.

Als Werkseinstellung meldet sich jeder mit Benutzername und Passwort an. Statt des Benutzernamens geht auch die E-Mail-Adresse. Unter dem Formular steht ein Link für den Fall, dass jemand sein Passwort vergessen hat.

Nach dem Anmelden bekommt der Browser einen Ausweis, der eine bestimmte Zeit gilt. Wie lange, legt die Karte „JWT token timer" fest. Erlaubt sind 1 bis 24 Stunden, empfohlen sind 12. Danach muss sich der Mensch neu anmelden.

Die Karte „Password policy" gilt für jedes Passwort, das im System gesetzt wird. Sie greift beim Anlegen eines Kontos, beim Ändern durch den Menschen selbst und beim Zurücksetzen durch den Administrator.

Eingestellt werden die Mindestlänge, welche Zeichenarten vorkommen müssen, nach wie vielen Tagen ein Passwort abläuft und wie viele alte Passwörter gesperrt bleiben. Bei den Tagen und der Sperrliste bedeutet die 0 „aus".

Die Regeln zu Groß- und Kleinbuchstaben sperren keine Sprache aus. Viele Schriften kennen diesen Unterschied gar nicht, und ein Zeichen aus einer solchen Schrift erfüllt beide Regeln von selbst.

Konten, die sich über SSO oder ein Verzeichnis anmelden, haben kein eigenes Passwort. Für sie gilt der Ablauf nicht. Ihre Regeln stehen beim Anbieter.

Die Karte „2FA Settings" schaltet die Zwei-Faktor-Anmeldung ein. Sie kennt zwei Schalter. Der obere verlangt sie von Administratoren und Bearbeitern, der untere von allen einschließlich der Kunden. Sind beide aus, ist die Zwei-Faktor-Anmeldung abgeschaltet.

Wer sich das nächste Mal anmeldet und noch keinen zweiten Faktor hat, richtet ihn sofort ein. Das System zeigt einen QR-Code für eine Authenticator-App und denselben Schlüssel zum Abtippen. Nach dem ersten Code ist der Faktor aktiv.

Direkt danach erscheinen zehn Wiederherstellungscodes. Jeder davon ersetzt einmal den Code aus der App. Sie werden genau einmal angezeigt.

Verliert jemand sein Gerät und seine Codes, hilft der Administrator. In der Benutzerliste setzt die Schaltfläche mit dem durchgestrichenen Schild die Zwei-Faktor-Anmeldung dieses Menschen zurück. Beim nächsten Anmelden richtet er sie neu ein.

Die Codes hängen an der Uhr des Servers. Geht sie falsch, wird kein Code angenommen. Die Schaltfläche „Check now" auf derselben Karte vergleicht die Serverzeit mit einer öffentlichen Zeitquelle.

Meldet sich jemand über einen fremden Anmeldedienst an, fragt das System keinen Code ab. Der Anbieter hat den zweiten Faktor dann schon geprüft. Bei der Anmeldung über ein Verzeichnis ist das anders, dort gilt die Regel oben weiter.

Die Anmeldeseite mit den Feldern „Username" und „Password" und der Schaltfläche „Sign in".
Die roten Rahmen liegen auf den beiden Feldern und der Schaltfläche. In das obere Feld passt auch die E-Mail-Adresse.Bild in voller Größe öffnen
Die Karte „JWT token timer" mit dem Feld für die Stundenzahl.
Der rote Rahmen liegt auf dem Feld. Es nimmt Werte von 1 bis 24 an.Bild in voller Größe öffnen
Die Karte „Password policy" mit Mindestlänge, Zeichenarten, Ablauf und Sperrliste.
Die roten Rahmen liegen auf den drei Zahlenfeldern. Die Häkchen darüber legen fest, welche Zeichenarten vorkommen müssen.Bild in voller Größe öffnen
Die Karte „2FA Settings" mit beiden Schaltern in der Stellung „aus".
Die roten Rahmen liegen auf den beiden Schaltern. So wie hier abgebildet ist die Zwei-Faktor-Anmeldung abgeschaltet.Bild in voller Größe öffnen
Der Einrichtungsbildschirm mit QR-Code, abtippbarem Schlüssel und dem Feld für den ersten Code.
Der rote Rahmen liegt auf dem Schlüssel. Er ist dasselbe wie der QR-Code darüber und hilft, wenn die Kamera nichts erkennt.Bild in voller Größe öffnen
Zehn Wiederherstellungscodes in zwei Spalten, darunter „Copy codes".
Der rote Rahmen liegt auf den Codes. Sie erscheinen genau einmal. Die Codes im Bild stammen aus einer Testumgebung und sind wertlos.Bild in voller Größe öffnen
Die Benutzerliste mit der Schaltfläche zum Zurücksetzen der Zwei-Faktor-Anmeldung.
Der rote Rahmen liegt auf dem durchgestrichenen Schild in der Zeile von Marco Rossi. Ein Klick nimmt ihm App und Wiederherstellungscodes.Bild in voller Größe öffnen
2

Schutz gegen das Raten von Passwörtern

Der Schutz läuft ohne Einstellung mit. Es gibt nichts einzuschalten. Der Hinweis dazu steht in der Karte „2FA Settings".

Er wirkt in zwei Stufen. Nach fünf Fehlversuchen für dasselbe Konto pausiert genau die Absenderadresse, von der sie kamen, für 15 Minuten. Von jeder anderen Adresse bleibt das Konto sofort nutzbar.

Das ist der wichtige Teil. Wer einen Anmeldenamen kennt, könnte sonst jeden Kollegen mit fünf falschen Passwörtern aussperren. Ein Passwort bräuchte er dafür nie.

Die zweite Stufe ist das Konto selbst. Es wird nach 20 Fehlversuchen für 15 Minuten gesperrt. Weil eine einzelne Adresse höchstens fünf davon beisteuern kann, braucht es dafür mehrere Adressen.

Eine erfolgreiche Anmeldung setzt beide Zähler zurück. Nach einem Neustart des Servers ist die Adressensperre weg, die Kontosperre bleibt.

In der Benutzerliste trägt ein so gesperrtes Konto die Marke „temporarily locked". Es bleibt in der Liste stehen. Nach 15 Minuten verschwindet die Marke von selbst.

Warten musst du nicht. In derselben Zeile steht eine Schaltfläche mit einem offenen Schloss. Sie hebt die Sperre sofort auf und räumt beide Zähler weg.

Das ist etwas anderes als „Archive". Diese Schaltfläche legt ein Konto dauerhaft still, und nur sie verbraucht oder gibt einen Bearbeiter-Platz frei.

Der Hinweistext zum Schutz gegen das Raten von Passwörtern in der Karte „2FA Settings".
Der rote Rahmen liegt auf dem Hinweis. Er nennt beide Stufen: erst die Adresse, dann das Konto.Bild in voller Größe öffnen
Die Benutzerliste mit der Marke „temporarily locked" und der Schaltfläche zum Entsperren.
Die roten Rahmen liegen auf der Marke und auf dem offenen Schloss. Das Schloss erscheint nur in der Zeile, in der es etwas aufzuheben gibt.Bild in voller Größe öffnen
3

Anmelden über ein Verzeichnis oder einen fremden Anmeldedienst (SSO)

Nur Professional

Voraussetzung: Die Einstellungen liegen unter „Settings → SSO Settings". Ohne einen eingerichteten Anbieter ändert sich an der Anmeldeseite nichts.

Ganz oben steht der Hauptschalter „Enable single sign-on". Solange er aus ist, bleibt es bei Benutzername und Passwort. Alles, was du darunter einrichtest, wird gespeichert und wirkt erst, wenn du ihn einschaltest.

Die Karte „Active Directory / LDAP" bindet ein Verzeichnis im eigenen Haus an. Du trägst den Server ein, den Suchbereich, den Filter, mit dem ein Mensch gefunden wird, und die Felder für E-Mail und Namen.

Das Konto zum Suchen ist freiwillig. Ohne eines fragt das System anonym an. Das Passwort des Menschen wird nur zum Anmelden am Verzeichnis benutzt und nirgends gespeichert.

Ein Verzeichnis bringt keinen zweiten Faktor mit. Verlangt die Sicherheitsseite eine Zwei-Faktor-Anmeldung, wird sie auch von diesen Menschen verlangt.

Die Karte „Identity providers" führt die fremden Anmeldedienste. Jeder bekommt eine eigene Kachel und eine eigene Schaltfläche auf der Anmeldeseite. „Add provider" legt einen neuen an.

Unter „Provider type" wählst du die Art. „Generic OIDC Provider" passt für Dienste wie Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 oder Ping Identity. „SAML 2.0 Provider" passt für dieselben Häuser, wenn sie über SAML angebunden werden sollen.

Daneben stehen sechs regionale Dienste zur Auswahl: LINE, Kakao, Naver, WeChat, WeCom und DingTalk. Ihre Adressen sind vorbelegt und stehen als grauer Text im Feld.

Der Name unter „Display name" steht später auf der Schaltfläche. Der Schalter daneben gilt nur für diesen einen Anbieter.

Bei der Rückruf-Adresse geh in dieser Reihenfolge vor. Trag zuerst nur einen Namen ein und klick auf „Save provider". Erst dann kennt das System die Nummer des Anbieters und zeigt die fertige Adresse unter „Redirect URI" an.

Diese Adresse kopierst du und trägst sie beim Anbieter ein. Sie muss dort auf das Zeichen genau stehen. Der Anbieter gibt dir dafür eine Kennung und ein Geheimnis, und die trägst du hier über „Edit" nach.

Das Feld „Allowed e-mail domains" schränkt ein, wer über diesen Anbieter hereinkommt. Bleibt es leer, ist jede Domain erlaubt.

Fehlt einem Anbieter noch etwas, trägt seine Kachel die rote Marke „Incomplete". Er erscheint dann nicht auf der Anmeldeseite. Der Text daneben sagt, welche Felder sein Typ braucht.

Vollständig eingerichtete Anbieter erscheinen trotzdem nicht, solange der Hauptschalter aus ist. Die Kachel sagt das in einer gelben Zeile.

Die Karte „Single sign-on" mit dem Hauptschalter.
Der rote Rahmen liegt auf dem Hauptschalter. Aus davon bleibt nur die Anmeldung mit Benutzername und Passwort.Bild in voller Größe öffnen
Die Karte „Active Directory / LDAP" mit ausgefüllten Feldern.
Die roten Rahmen liegen auf Server, Suchbereich und Suchfilter. Die Werte im Bild stammen aus einer Testumgebung.Bild in voller Größe öffnen
Zwei Anbieter-Kacheln, eine eingerichtet und eine mit der Marke „Incomplete".
Die roten Rahmen liegen auf beiden Kacheln. Die obere ist fertig und wartet nur auf den Hauptschalter. Der unteren fehlt die Adresse ihres Anbieters.Bild in voller Größe öffnen
Der Dialog „Add provider" mit Typ, Anzeigename, Schalter und der Adresse des Anbieters.
Der rote Rahmen liegt auf dem Adressfeld. Darunter füllt „Quick fill" die bekannten Anbieter vor. Was in geschweiften Klammern steht, ersetzt du vorher.Bild in voller Größe öffnen
Der Dialog eines gespeicherten Anbieters mit der fertigen Rückruf-Adresse.
Der rote Rahmen liegt auf der Rückruf-Adresse. Sie entsteht erst beim Speichern und beginnt mit der Adresse deiner eigenen Umgebung.Bild in voller Größe öffnen
4

Das Konto bei der ersten Anmeldung und das Protokoll

Nur Professional

Der Schalter „Automatically create accounts on first sign-in" steht in derselben Karte wie der Hauptschalter. Er ist als Werkseinstellung an.

Meldet sich jemand zum ersten Mal über einen Anbieter an, sucht das System erst ein Konto, das schon zu diesem Anbieter gehört. Findet es keines, entsteht ein neues.

Das neue Konto bekommt die Rolle „Customer" und kein Team. Ein Kunde braucht keine Mitgliedschaft, um ein Ticket anzulegen, und ist damit sofort arbeitsfähig.

Kunden sind in beiden Editionen unbegrenzt. Ein so entstandenes Konto verbraucht also keinen Bearbeiter-Platz. Wer stattdessen Bearbeiter werden soll, bekommt die Rolle hinterher in der Benutzerverwaltung.

Gibt es schon ein Konto mit derselben E-Mail-Adresse, werden beide verknüpft. Das geschieht nur, wenn der Anbieter die Adresse als bestätigt meldet. Meldet er sie nicht als bestätigt, wird die Anmeldung abgelehnt.

Schaltest du den Schalter aus, kommt nur noch herein, wer schon ein Konto hat. Alle anderen werden abgewiesen.

Die Karte „Recent sign-in attempts" ganz unten zeigt die letzten 100 Versuche. Sie erfasst alle Wege dieser Seite, auch die Anmeldung über das Verzeichnis.

Jede Zeile nennt Zeitpunkt, Anbieter, Ergebnis und Absenderadresse. Bei einem Fehlversuch steht der Grund daneben. Die Spalte „E-mail" zeigt die Adresse, wenn der Anbieter eine gemeldet hat, sonst den eingegebenen Namen.

Die Anmeldung mit Benutzername und Passwort steht nicht in dieser Tabelle. Sie ist kein SSO.

Der Schalter „Automatically create accounts on first sign-in".
Der rote Rahmen liegt auf dem Schalter. Der Text darunter nennt die Rolle, die ein so entstandenes Konto bekommt.Bild in voller Größe öffnen
Die Tabelle „Recent sign-in attempts" mit drei fehlgeschlagenen Versuchen über das Verzeichnis.
Der rote Rahmen liegt auf der obersten Zeile. Sie zeigt einen Fehlversuch mit seinem Grund. Die Einträge im Bild stammen aus einer Testumgebung, deren Verzeichnis es nicht gibt.Bild in voller Größe öffnen

Ticket-Management

Das tägliche Handwerk: Tickets anlegen, ordnen und wiederfinden. Alles in diesem Block ist in Basic enthalten, sofern an der Karte nichts anderes steht.

1

Tickets erstellen und bearbeiten

Voraussetzung: Ein einzelnes Ticket lässt sich nicht löschen. Das gilt auch für Administratoren. Tickets verlassen die Datenbank nur über das Archiv, und nur, wenn sie geschlossen sind. Das ist Absicht, damit ein Vorgang nachweisbar bleibt.

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 überhaupt erscheinen und welche davon Pflicht sind, legst du unter „Settings → Ticket Settings" fest. Das geht getrennt für Bearbeiter und für Kunden. Ein Kunde sieht deshalb ein kürzeres Formular als du. Zwei Formulare musst du dafür nicht pflegen.

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, Priorität, Zuweisung, Eingangskanal und Beobachter liegen eine Karte darüber unter „Actions". Sie wirken sofort, ohne eigenes Speichern.

Ä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. Erst danach verschwinden diese Tickets aus der laufenden Datenbank. Aus derselben Datei lassen sie sich wieder zurückholen.

Das Formular „Create new ticket" mit den Feldern Title, Owning team, User, Status, Priorität und Kategorien.
Das Formular hinter „New Ticket". Die Felder mit Stern sind Pflicht. Weiter unten folgen Kategorien, Beschreibung und Anhänge.Bild in voller Größe öffnen
Die Karte „Details" eines Tickets mit den Feldern zum Anfragenden und der rot umrandeten Schaltfläche „Save".
Nachträglich ändern: Feld anpassen, „Save" drücken. Darunter steht unveränderlich, wer das Ticket angelegt hat und wann.Bild in voller Größe öffnen
2

Rich-Text-Editor für Beschreibung und Kommentare

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.

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 „Only for Admin/Agents" 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.

Die Werkzeugleiste des Editors, darunter der Satz „The display shows ERROR 13.20 and then the paper jams." mit fettem Fehlercode.
Rot umrandet: „Bold", „Bullet list" und „Link". Die Leiste steht sowohl über der Beschreibung als auch über dem Kommentarfeld.Bild in voller Größe öffnen
Drei Kommentare eines Tickets, der untere mit fett gesetztem Begriff und einer Aufzählung, der mittlere mit der Marke „Internal".
So kommt es an: Fettung und Aufzählung bleiben stehen. Der mittlere Kommentar ist mit „Internal" markiert und für den Anfragenden unsichtbar.Bild in voller Größe öffnen
3

Datei-Anhänge mit Vorschau

Voraussetzung: Erlaubt sind PDF, DOC, DOCX, XLS, XLSX, TXT, PNG, JPG, JPEG und GIF, bis 50 MB je Datei. Die Grenze steht im Formular als „Max. 50 MB per file". Größere Dateien werden vor dem Hochladen abgewiesen.

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 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 „Attachments" mit zwei Dateien, darüber die rot umrandete Schaltfläche „Upload file".
Alle Dateien eines Vorgangs an einer Stelle. Die Zeile darunter nennt die erlaubten Dateitypen und die Größengrenze.Bild in voller Größe öffnen
Die Bildvorschau eines Anhangs mit den Schaltflächen zum Vergrößern, Verkleinern und Drehen oben rechts.
Die Vorschau eines Bildes. Vergrößern, verkleinern und drehen kannst du oben rechts. Heruntergeladen wird dabei nichts.Bild in voller Größe öffnen
Die Vorschau eines PDF im selben Fenster, mit Seitenübersicht links und der Werkzeugleiste des PDF-Anzeigers oben.
Ein PDF öffnet sich genauso, ohne Herunterladen und mit Seitenübersicht, Zoom und Drucken.Bild in voller Größe öffnen
4

Ticket-Historie

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.

Der Kommentar erscheint dort gekürzt. Den vollen Wortlaut findest du im Reiter „Comments". Ein interner Kommentar taucht in der Historie ebenfalls auf, aber nur für Bearbeiter und Administratoren.

Der Reiter „History" mit den Einträgen des Tickets: Dateien, Kommentare, Statuswechsel, Priorität, Zuweisung und ganz unten die Eröffnung. Oben stehen zwei Zeilen, die eine Regel geschrieben hat.
Rot umrandet ist der Reiter mit der Anzahl. Bei „Status" und „Priority" siehst du den alten Wert durchgestrichen neben dem neuen.Bild in voller Größe öffnen
5

Status-Workflow mit konfigurierbaren Status & Übergängen

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. Sechs Status tragen in der Liste die Marke „Mandatory": Open, Assigned, In Progress, Resolved, Closed und Reopened. 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 „Rejected", 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.

Die allgemeinen Einstellungen mit dem rot umrandeten Reiter „Status" und der Liste aller Status.
„Settings → General Settings", Reiter „Status". Jeder Status steht dort mit seinem technischen Namen und seinen Merkmalen.Bild in voller Größe öffnen
Der Dialog „Edit status" mit den Schaltern unter „Meaning of this status" und der Liste „Allowed transitions to new status".
Im Editor stehen oben Aussehen und Verhalten, in der Mitte die Bedeutung und unten die erlaubten Übergänge.Bild in voller Größe öffnen
7

Haupt- und Unterkategorien sind pro Team frei konfigurierbar

Voraussetzung: Du brauchst mindestens ein Team. Die Kategorie-Seite heißt nach ihrem Team, es gibt sie also erst, wenn ein Team existiert.

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.

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.

Das geöffnete Einstellungsmenü, der Eintrag „Helpdesk Categories" ist rot umrandet.
Unter „Settings" heißt der Eintrag nach dem Team, hier also „Helpdesk Categories".Bild in voller Größe öffnen
Die Seite „Settings · Manage categories" mit den Karten „Main categories" und „Subcategories".
So sieht die Seite aus: Hauptkategorien links, Unterkategorien rechts. Die Karte „Links" liegt weiter unten auf derselben Seite.Bild in voller Größe öffnen
Das Feld „EN (required)" mit dem Wort „Beamer" und die Schaltfläche „New main category", beide rot umrandet.
Einzeln anlegen: englischer Name ins Feld „EN (required)", dann auf „+ New main category" darunter klicken. In der Karte „Subcategories" heißt die Schaltfläche „+ New subcategory".Bild in voller Größe öffnen
Die Karte „Main categories" mit den rot umrandeten Schaltflächen „Export JSON" und „Import JSON".
Für viele auf einmal: Struktur herunterladen, ausfüllen, wieder hochladen. Die Karte „Subcategories" daneben hat dieselben beiden Schaltflächen.Bild in voller Größe öffnen
Die Karte „Links": „Printer" ist ausgewählt, die Unterkategorien Consumables, Malfunction und New request sind angehakt.
„Printer" ausgewählt, passende Unterkategorien angehakt, dann „Save links". „Malfunction" hängt gleichzeitig an drei weiteren Hauptkategorien.Bild in voller Größe öffnen
8

Wie das Ticket hereingekommen ist

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 „Email", wenn es aus einer eingehenden Mail entstanden ist.

Einen vom System vergebenen Kanal kannst du deshalb nicht nachträglich auf „Phone" umstellen. Damit 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.

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

Der Ausschnitt des Formulars mit Status, Priorität und dem rot umrandeten Feld „How the request came in".
Beim Anlegen steht der Kanal zwischen Priorität und Beobachtern. Zur Auswahl stehen nur „Phone" und „Entered by an agent".Bild in voller Größe öffnen
Die Karte „Actions" eines Tickets, das Feld „How the request came in" steht auf „Phone" und ist rot umrandet.
Am Ticket steht der Kanal auf der Karte „Actions". Hier ist es ein Fall, den der Bearbeiter nach einem Anruf erfasst hat.Bild in voller Größe öffnen
10

Ein Ticket an ein anderes Team abgeben

Nur Professional

Voraussetzung: Beide Wege setzen ein zweites Team voraus. Der Kunde sieht davon nichts: Für ihn bleibt es ein Vorgang mit einer Nummer, egal wie viele Teams daran gearbeitet haben.

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 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.

Die beiden rot umrandeten Schaltflächen „Involve another team" und „Escalate to another team" mit ihren Erklärungen darunter.
Zwei Wege, sichtbar getrennt: mitarbeiten lassen oder übergeben. Der Unterschied steht direkt an der Schaltfläche.Bild in voller Größe öffnen
Der Dialog „Escalate to another team?" mit der Auswahl des Zielteams und dem Feld „Reason (optional)".
Der Dialog nennt die Folge, bevor du bestätigst: kein zweites Ticket, Leserecht bleibt, ändern darf nur noch das neue Team.Bild in voller Größe öffnen
11

Benutzerdefinierte Felder

Nur Professional

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" gelten für neue Tickets: „Mandatory by default", „Hidden for customer by default" und „Not editable by customer by default". Sie sind nur Voreinstellungen. Genau festlegen kannst du es je Rolle in der Feldsteuerung auf derselben Seite.

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, aber keine Regel aufheben. Was der Administrator für Kunden verborgen oder zur Pflicht erklärt hat, bleibt es auch dann, wenn eine Vorlage etwas anderes sagt.

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.

Die Karte „Custom fields" mit zwei Feldern und der rot umrandeten Schaltfläche „Add custom field".
Die Liste der Zusatzfelder liegt unter „Settings → Ticket Settings", ganz unten auf der Seite.Bild in voller Größe öffnen
Der Dialog „New custom field" mit Name, Feldtyp, Geltungsbereich und den drei Voreinstellungen.
Ein Feld braucht Name, Feldtyp und Geltungsbereich. Die drei Schalter darunter sind Voreinstellungen für neue Tickets.Bild in voller Größe öffnen
Die Karte „Additional information" auf einem Ticket mit den Feldern „Asset tag" und „Warranty until".
So sieht der Bearbeiter die Zusatzfelder: eine eigene Karte am Ticket, direkt unter der Beschreibung.Bild in voller Größe öffnen
12

Beobachter

Nur Professional

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.

Zur Auswahl stehen nur Bearbeiter und Administratoren eines beteiligten Teams. 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.

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

Die Benachrichtigung ist eine E-Mail. Dafür muss der Mailversand eingerichtet sein, und der gehört zur Professional-Edition. Ohne ihn kannst du Beobachter zwar eintragen, aber es geht nichts hinaus.

Die Karte „Actions" eines Tickets mit dem rot umrandeten Feld „Observers", in dem ein Bearbeiter eingetragen ist.
Der Beobachter steht auf der Karte „Actions". Das Ticket ist niemandem zugewiesen. Beobachten und bearbeiten sind zwei verschiedene Dinge.Bild in voller Größe öffnen
13

Tickets aus E-Mails, Antworten und Rückmeldungen

Nur Professional

Voraussetzung: Bei Google und Gmail brauchst du ein App-Passwort. Es setzt die Zwei-Faktor-Anmeldung voraus. Die normalen Kontodaten weist Google ab. Microsoft 365 geht derzeit gar nicht. Dort ist die einfache Anmeldung für IMAP abgeschaltet, und App-Passwörter helfen nicht weiter.

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.

Verarbeitete Mails wandern in den Ordner „Processed folder". 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. Es ist die einzige Stelle, an der das System von sich aus antwortet. Ist dieser Schalter aus, bekommt dein Kunde nie eine automatische Antwort, egal wie gut der Rest eingerichtet ist.

„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]".

Die Kennung wird nicht von selbst angehängt. Sie steht nur da, wo du {ticketTag} oder {ticketId} hinschreibst. An ihr erkennt das System später die Antwort deines Kunden. Fehlt sie im Betreff, entsteht aus jeder Rückmeldung ein neues Ticket statt eines Kommentars im alten.

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.

Die Karte „SMTP settings" mit Host, Port, Benutzer, Passwort, Absenderadresse und der Schaltfläche „Send test e-mail".
Der Weg nach draußen. Jedes Feld hat seine Erklärung darunter. Die Portangaben 587 und 465 stehen dort ausdrücklich.Bild in voller Größe öffnen
Die Karte „IMAP settings" mit den rot umrandeten Schaltflächen „Read from server" und „Create on server".
Den Ordner nicht tippen, sondern holen: „Read from server" listet die echten Ordner, „Create on server" legt einen neuen unter dem Posteingang an.Bild in voller Größe öffnen
Der Abschnitt „Team mailboxes" mit dem Postfach des Teams Helpdesk.
Je Team ein Postfach. Die Adresse ist zugleich der Absender. Deshalb steht sie hier und nicht in den allgemeinen Einstellungen.Bild in voller Größe öffnen
Ein Arbeitsablauf mit Name, „Match", „Stop after match", der Bedingung unter „When?" und den fünf rot umrandeten Aktionsschaltern.
Die fünf Aktionen sind rot umrandet. In diesem Beispiel sind „Create or append ticket", „Auto-reply" und „Move to folder" an, „Set fields" und „Send mail" aus. Ohne einen solchen Ablauf wird das Postfach gar nicht erst abgerufen.Bild in voller Größe öffnen
Die Aktion „Auto-reply" mit dem rot umrandeten Betreff-Feld, den Bausteinen, dem englischen Text und der Auswahl der Antwortsprache.
Im Betreff stehen die Bausteine „{originalSubject} {ticketTag}". Daran erkennt das System später die Antwort des Kunden. Darunter stehen der Text und die Antwortsprache, hier die des zugewiesenen Bearbeiters.Bild in voller Größe öffnen

Agenten-Status (Anwesenheit)

Jeder Bearbeiter zeigt an, ob er gerade verfügbar ist. Beim Zuweisen steht der Zustand neben dem Namen. Alles in diesem Block gehört zu Basic. Die automatische Verteilung, die Abwesende überspringt, ist eine eigene Funktion und gehört zu Professional.

1

Anwesend, beschäftigt, abwesend

Jeder Bearbeiter hat einen von drei Zuständen. Er setzt ihn selbst, im Benutzermenü unten links in der Seitenleiste. Über den drei Einträgen steht „Availability".

Ein Punkt zeigt den Zustand an. Anwesend heißt „Available" und trägt einen grünen Punkt. Beschäftigt heißt „Busy" und trägt einen gelben. Abwesend heißt „Away" und trägt einen leeren Ring.

Die drei unterscheiden sich nicht nur in der Farbe, sondern auch in der Füllung. Wer Farben schlecht auseinanderhält, sieht den Unterschied trotzdem.

Der eigene Punkt sitzt am Bild des Kontos, unten links in der Seitenleiste. Dafür musst du das Menü nicht öffnen.

Beim Zuweisen eines Tickets steht der Zustand hinter dem Namen. Ist ein Ende der Abwesenheit eingetragen, steht es dabei.

Ein Bearbeiter, der nicht anwesend ist, bleibt wählbar. Er ist nur gekennzeichnet. Ob das Ticket trotzdem an ihn geht, entscheidest du.

Angeboten werden immer nur die Bearbeiter des Teams, dem das Ticket gehört.

Nur Bearbeiter und Administratoren haben einen Zustand. Bei einem Kunden gibt es ihn nicht.

Mehr dazu in der Karte: Mehrere Tickets gleichzeitig einem Bearbeiter zuweisen

Das Benutzermenü der Seitenleiste mit den drei Zuständen „Available", „Busy" und „Away" und dem Haken am geltenden Zustand.
Das Benutzermenü des Bearbeiters. Ganz oben stehen die drei Zustände, der geltende trägt einen Haken. Unten am Bild des Kontos sitzt derselbe Punkt.Bild in voller Größe öffnen
Die Auswahl „Assign to" am Ticket, aufgeklappt, mit den Bearbeitern des Teams und der Kennzeichnung „Away until" an einem Eintrag.
Der rote Rahmen liegt auf dem Eintrag von Lena Chen. Hinter dem Namen stehen ihr Zustand und das Ende der Abwesenheit. Wählbar bleibt sie. Angeboten werden nur die Bearbeiter des Teams, dem das Ticket gehört.Bild in voller Größe öffnen
2

Krankheit und Urlaub trägt der Administrator ein

Wer krank ist, meldet sich selten selbst ab. Deshalb kann ein Administrator den Zustand für eine andere Person setzen. Das geht unter „User management" im Bearbeiten-Formular des Kontos.

Das Formular hat dafür zwei Felder. „Availability" trägt den Zustand. „Away until" trägt das Ende der Abwesenheit.

Das zweite Feld erscheint nur bei „Away". Für „Busy" und „Available" gibt es kein Ende zum Eintragen.

Ohne Datum gilt die Abwesenheit, bis jemand sie beendet. Mit Datum endet sie von selbst. Der Hinweis unter dem Feld sagt es: „Leave empty for an absence without a set end."

Ein Datum in der Vergangenheit nimmt das System nicht an. Es wäre sofort abgelaufen, und der Kollege stünde weiter als anwesend in der Liste.

Die beiden Felder erscheinen nur bei Bearbeitern und Administratoren. Stellst du die Rolle im selben Formular auf „Customer", verschwinden sie.

Ein Feld trägt beides. Ein Tag Krankheit und drei Wochen Urlaub sind für das System derselbe Vorgang mit einem anderen Datum.

Das Bearbeiten-Formular eines Kontos mit den Feldern „Availability" auf „Away" und „Away until" mit einem Datum.
Die roten Rahmen liegen auf den beiden Feldern. Sie stehen ganz unten im Formular und nur bei Bearbeitern und Administratoren.Bild in voller Größe öffnen
3

„Beschäftigt" stellt sich nach einer Stunde zurück

„Busy" hält eine Stunde. Danach ist der Bearbeiter wieder anwesend, ohne dass er etwas tun muss.

Im Menü steht die Restzeit neben dem Zustand. Dort steht zum Beispiel „60 min left".

Die Stunde ist fest eingestellt. Sie ist ein Sicherheitsnetz gegen das Vergessen und keine Betriebsregel. Wer länger nicht verfügbar ist, wählt „Away".

Die Rückstellung ist ein Zeitpunkt und kein Auftrag. Am Konto steht, wann der Zustand endet. Ausgerechnet wird er erst, wenn ihn jemand liest. War der Server in dieser Stunde aus, ist der Bearbeiter danach einfach wieder anwesend. Es bleibt kein Rückstand liegen, den ein Dienst später nachholt.

„Away" läuft nur ab, wenn ein Ende eingetragen ist. Ohne Ende bleibt es, bis jemand es ändert.

Setzt sich ein Bearbeiter selbst auf „Away", bekommt der Zustand kein Ende. Ein Enddatum vergibt nur der Administrator.

Das Benutzermenü mit dem Zustand „Busy", der Restzeit „60 min left" und dem Haken daneben.
Der rote Rahmen liegt auf dem geltenden Zustand. Rechts steht der Haken, daneben die Restzeit. Der Punkt am Bild des Kontos ist jetzt gelb.Bild in voller Größe öffnen
4

Kein Anwesenheitsverlauf und keine Auswertung pro Person

Das System merkt sich nur, welcher Zustand gerade gilt. Es schreibt nicht mit, wer wann beschäftigt oder abwesend war.

In der Benutzerliste steht deshalb der Zustand von jetzt und sonst nichts. Es gibt keine Spalte mit einem Verlauf und keinen Bericht über Anwesenheitszeiten.

Das ist eine Entscheidung und kein fehlendes Stück. Anwesenheitsdaten je Person sind Verhaltensdaten. In vielen Betrieben redet die Mitbestimmung darüber mit.

Gebraucht wird der Verlauf auch nicht. Der Zustand beantwortet eine einzige Frage: ist der Kollege gerade verfügbar? „Busy" endet nach einer Stunde von selbst.

Wie viele Tickets ein Bearbeiter hat, siehst du in der Ticketliste. Dort filterst du unter „Assigned to" nach einer Person. Wie lange jemand abwesend war, steht nirgends.

Die Benutzerliste mit einem farbigen Punkt vor den Namen der Bearbeiter und den Spalten Name, Email, Team, Role und Actions.
Die roten Rahmen liegen auf zwei Bearbeitern, die nicht anwesend sind. Die Liste zeigt den Zustand von jetzt. Eine Spalte mit dem Verlauf gibt es nicht.Bild in voller Größe öffnen

Automatische Verteilung von Tickets

Ein neues Ticket kann sofort einen Bearbeiter bekommen. Das System nimmt dafür die Anwesenheit, die im Block davor erklärt ist. Die Verteilung wird je Team eingeschaltet und ist als Werkseinstellung aus. Der ganze Block gehört zu Professional.

1

Die Verteilung gehört dem Team

Nur Professional

Ohne Verteilung landet jedes neue Ticket im Topf. Jemand muss es sich nehmen oder jemand muss es vergeben. Beides funktioniert, solange jemand hinsieht.

Schaltest du die Verteilung ein, bekommt jedes neue Ticket beim Anlegen einen Bearbeiter. Das geschieht sofort und nicht erst ein paar Minuten später.

Die Einstellung steht am Team unter „Settings → Teams". Jedes Team entscheidet für sich. Ein Team kann verteilen, während das Nachbarteam im Topf arbeitet.

Als Werkseinstellung steht überall „Off". Eine vorhandene Umgebung ändert ihr Verhalten also nicht, nur weil es die Funktion gibt.

Verteilt wird an die Mitglieder des Teams. Ein Administrator, der mitarbeitet und im Team steht, bekommt genauso Tickets wie ein Bearbeiter.

Der Abschnitt „Automatic assignment" im Team-Dialog des Helpdesks, eingestellt auf „Round robin", darunter zwei erklärende Sätze.
Die Einstellung steht am Team. Unter dem Auswahlfeld erklärt ein Satz das gewählte Verfahren, darunter steht, wer übersprungen wird.Bild in voller Größe öffnen
Das geöffnete Auswahlfeld mit den drei Einträgen „Off", „Round robin" und „Least load".
Drei Einträge stehen zur Wahl. „Off" ist die Werkseinstellung.Bild in voller Größe öffnen
2

Reihum oder nach geringster Auslastung

Nur Professional

Es gibt zwei Verfahren. Du wählst eines je Team.

„Round robin" geht der Reihe nach. Das neue Ticket bekommt der anwesende Bearbeiter, dessen letzte automatische Zuweisung am längsten zurückliegt. Wer neu ins Team kommt, ist damit als Erster an der Reihe.

„Least load" sieht auf den Tisch. Das neue Ticket bekommt der anwesende Bearbeiter mit den wenigsten offenen Tickets.

Ein Ticket, das auf den Anfragenden wartet, zählt dabei halb. Wer viele Rückfragen offen hat, ist nicht dieselbe Art beschäftigt wie jemand mit lauter frischen Störungen.

Ein gelöstes oder geschlossenes Ticket zählt gar nicht mehr. Das gilt auch für einen Status, den du selbst angelegt hast, solange er als gelöst oder geschlossen gekennzeichnet ist.

Das Ergebnis ist in beiden Verfahren nachrechenbar. Bei Gleichstand entscheidet immer dieselbe Regel und nie der Zufall.

Derselbe Abschnitt im Team-Dialog des Netzwerk-Teams, eingestellt auf „Least load", mit dem Satz über die halb zählenden Tickets.
Dasselbe Feld an einem anderen Team, hier auf „Least load". Der Satz darunter wechselt mit der Einstellung.Bild in voller Größe öffnen
3

Wer nicht da ist, bekommt nichts

Nur Professional

Die Verteilung fragt vor jeder Zuweisung den Zustand des Bearbeiters ab. „Busy" und „Away" werden übersprungen.

Gesperrte und gelöschte Konten kommen ebenfalls nicht in Frage. Auch wer nicht im Team des Tickets steht, bekommt es nicht.

Ist niemand verfügbar, bleibt das Ticket ohne Bearbeiter. Das Anlegen läuft trotzdem normal durch.

Das ist Absicht. Ein Ticket im Topf sieht jeder, ein Ticket bei einer abwesenden Person sieht niemand.

Im Verlauf des Tickets steht der Grund. Dort liest du „(nobody available)" statt eines Namens.

Mehr dazu in der Karte: Anwesend, beschäftigt oder abwesend

Der Verlauf eines Tickets mit der Zeile „Auto-assignment", die statt eines Namens „(nobody available)" nennt.
Niemand war verfügbar, das Ticket blieb im Topf. Der rote Rahmen liegt auf der Zeile, die den Grund nennt.Bild in voller Größe öffnen
4

Was die Verteilung anfasst und was nicht

Nur Professional

Die Verteilung greift auf jedem Weg, auf dem ein Ticket entsteht. Das gilt auch für Tickets aus dem E-Mail-Eingang.

Genauso greift sie bei den Untertickets eines Antrags. Jedes Unterticket wird im Team verteilt, das es bekommt.

Ein Ticket, das ein Mensch zugewiesen hat, fasst die Verteilung nie an. Wählst du beim Anlegen selbst einen Bearbeiter, gilt deine Wahl.

Jede automatische Zuweisung steht im Verlauf des Tickets. Dort steht „Auto-assignment" als Urheber und daneben der Name des Bearbeiters.

Der Bearbeiter bekommt dieselbe Mail wie bei einer Zuweisung von Hand. Steht das Ticket noch auf „Open", wechselt es dabei auf „Assigned".

Mehr dazu in der Karte: Aus einer E-Mail wird ein Ticket

Der Verlauf eines Tickets mit zwei Zeilen von „Auto-assignment": die Zuweisung an einen Bearbeiter des Teams und der Statuswechsel von „Open" auf „Assigned".
Der Verlauf nennt die Automatik beim Namen. Sie hat zugewiesen und den Status nachgezogen.Bild in voller Größe öffnen
5

Die Auswertung der Verteilung

Nur Professional

Wer eine Automatik betreibt, muss nachsehen können, was sie tut. Dafür gibt es auf der Berichtsseite eine eigene Karte.

Oben stehen zwei Zahlen. Links, wie viele Tickets die Automatik verteilt hat. Rechts, wie oft niemand verfügbar war.

Neben der rechten Zahl stehen die Nummern der betroffenen Tickets. Damit kommst du mit einem Klick dorthin, wo es passiert ist.

Darunter steht eine Zeile je Bearbeiter mit seiner Zahl und seinem Anwesenheitszustand. Die Zeilen entstehen aus der Mitgliedschaft im Team.

Eine Zeile mit einer Null ist deshalb kein Fehler. Sie ist der eigentliche Zweck der Tabelle.

Wer seit Wochen auf „Away" steht, hat null Tickets bekommen und steht trotzdem da. Neben der Null steht der Grund.

Diese Karte ist ein Protokoll der Maschine und keine Bewertung von Menschen. Es gibt deshalb keinen Anwesenheitsverlauf und keine Auswertung darüber, wer wie lange anwesend war.

Mehr dazu in der Karte: Kein Anwesenheitsverlauf, keine Auswertung pro Person

Die Berichtsseite mit der Karte „Automatic assignment" zwischen den anderen Auswertungen.
Die Karte steht auf der Berichtsseite. Der rote Rahmen zeigt, wo sie liegt.Bild in voller Größe öffnen
Der Kasten „Nobody available" mit der Zahl, einem erklärenden Satz und der Nummer des betroffenen Tickets.
Die zweite Zahl steht gleichrangig neben der ersten. Darunter stehen die Nummern der Tickets, die im Topf geblieben sind.Bild in voller Größe öffnen
Die Tabelle der Auswertung mit sechs Bearbeitern, ihren Zahlen und ihrem Anwesenheitszustand, darunter eine Zeile mit einer Null und dem Vermerk „Away".
Eine Zeile je Bearbeiter. Der rote Rahmen liegt auf der Zeile mit der Null, neben der der Grund steht.Bild in voller Größe öffnen

Anträge mit Teilaufgaben & Genehmigung

Manche Anliegen sind kein einzelnes Ticket. Ein Antrag erzeugt beim Anlegen seine Teilaufgaben, jede als eigenes Ticket im zuständigen Team. Genehmigungen sind möglich und keine Pflicht. Der ganze Block gehört zu Professional.

1

Ein Antrag erzeugt seine Teilaufgaben

Nur Professional

„Eine neue Kollegin fängt an" ist kein einzelnes Ticket. Es sind ein Notebook, zwei Konten, ein Telefonanschluss und vielleicht ein Zugang von außen. Jedes Stück gehört einem anderen Team, und trotzdem soll es einen Vorgang geben, an dem du den Stand abliest.

Dafür gibt es den Antrag. Er ist ein Ticket, das beim Anlegen seine Teilaufgaben erzeugt. Jede Teilaufgabe wird ein eigenes Ticket im zuständigen Team.

Ein Antrag ist nichts, was du zusätzlich pflegst. Er wohnt an einer Ticketvorlage. Unter „Settings → Request workflows" stehen alle Ticketvorlagen, und du hängst die Aufgaben an eine davon.

Je Aufgabe legst du vier Dinge fest. „Task" ist der Name, den der Antragsteller liest. „Handled by" ist das Team, das sie bekommt. „Ticket title" und „What the team has to do" füllen das Ticket, das daraus entsteht.

Mehrere Aufgaben dürfen dasselbe Team tragen. Dann entstehen dort mehrere Tickets und nicht eines mit einer Liste darin.

Eine Aufgabe ohne Team wird nicht angeboten. Das Feld sagt es selbst: „Not assigned yet — this task is not offered". So kannst du einen Bauplan speichern, der noch nicht fertig ist.

Über den Aufgaben steht ein Satz, der den ganzen Bauplan zusammenfasst. Er nennt, was als Werkseinstellung entsteht, wie viel der Antragsteller ändern darf und wer freigibt. Änderst du eine Einstellung, schreibt sich der Satz neu.

Die Liste der Ticketvorlagen unter „Request workflows", je Vorlage die Zahl ihrer Aufgaben und die Schaltfläche „Edit tasks".
Alle Ticketvorlagen an einer Stelle. Hinter jeder steht, wie viele Aufgaben sie trägt. Der rote Rahmen liegt auf dem Weg in den Bauplan.Bild in voller Größe öffnen
Der Bauplan mit dem zusammenfassenden Satz und den ersten Teilaufgaben, je Aufgabe Name, Team und Auswahlart.
Oben der Satz, der den Bauplan zusammenfasst. Darunter die Aufgaben, jede mit ihrem Team und ihrer Auswahlart.Bild in voller Größe öffnen
2

Der Antragsteller kreuzt an, was er braucht

Nur Professional

Wählt jemand die Vorlage im Anlege-Formular, erscheint der Kasten „What is needed?". Darin steht je Teilaufgabe eine Zeile zum Ankreuzen.

Drei Arten gibt es, und du legst sie je Aufgabe fest. „Selectable, off by default" ist leer und wird angekreuzt. „Selectable, on by default" ist schon angekreuzt und lässt sich abwählen. „Always — cannot be deselected" läuft immer mit.

Eine Aufgabe, die immer mitläuft, wird trotzdem angezeigt. Sie trägt den Hinweis „(always included)". Der Antragsteller soll sehen, was ohnehin passiert.

Unter dem Kasten steht, was daraus wird: „Each selected item becomes its own ticket for the team that handles it."

Auch ein Kunde kann einen Antrag stellen. Dafür muss die Vorlage für Kunden freigegeben sein. Der Schalter dazu steht an der Vorlage.

Der Kunde sieht danach nur seinen eigenen Antrag. Die Tickets der Fachteams bleiben ihm verborgen, auch wenn sie aus seinem Antrag entstanden sind. In ihnen stehen Zugangsdaten und interne Absprachen.

Mehr dazu in der Karte: Ticketvorlagen je Vorlage für Kunden freischaltbar

Der Kasten „What is needed?" im Anlege-Formular mit vier Teilaufgaben zum Ankreuzen.
Der Kasten im Anlege-Formular der Antragstellerin. Die erste Zeile läuft immer mit und lässt sich nicht abwählen, die zweite ist als Werkseinstellung angekreuzt. Darunter steht, was aus jedem Kreuz wird.Bild in voller Größe öffnen
3

Der Fortschritt am Antrag

Nur Professional

Am Antrag steht die Liste seiner Teilaufgaben unter „Workflow tasks". Daneben steht die Zahl, zum Beispiel „1 of 4 done".

Je Zeile siehst du den Namen der Aufgabe, die Nummer ihres Tickets, das Team und den Bearbeiter. Der Name ist ein Link in dieses Ticket.

„Erledigt" kommt aus dem Status des Tickets und nicht aus einem eigenen Häkchen. Was in der Ticketliste als geschlossen gilt, gilt hier als erledigt. Zwei Zählweisen für dieselbe Sache würden früher oder später auseinanderlaufen.

Der Block erscheint nur an einem Antrag. Ein gewöhnliches Ticket zeigt ihn nicht.

Der Block „Workflow tasks" am Antrag mit vier Teilaufgaben, ihren Ticketnummern und Teams.
Der rote Rahmen liegt auf der Zeile mit der Zahl. Darunter steht je Aufgabe, in welchem Ticket und in welchem Team sie liegt. Der Haken links kommt aus dem Status.Bild in voller Größe öffnen
4

Eine Genehmigung für den ganzen Antrag

Nur Professional

Eine Genehmigung gilt für den ganzen Antrag und nicht für jede Teilaufgabe. Acht Anwendungen sind eine Mail an den Vorgesetzten und nicht acht.

Eingestellt wird das unter „Approvals" im selben Bauplan. Der Satz darüber sagt die Regel: „One approval covers the whole request. Add a second stage only when single tasks need their own release." Je Stufe legst du drei Dinge fest: „Covers" sagt, wofür sie gilt, „Decided by" sagt, woher der Genehmiger kommt, und „Approver" trägt ihn selbst.

Der Genehmiger braucht kein Konto im Ticket-System. Du trägst eine E-Mail-Adresse ein, und er entscheidet über einen Link. Ein Vorgesetzter, der zweimal im Quartal zustimmt, kostet damit keinen Bearbeiter-Platz.

Die Mail enthält genau einen Link auf eine Seite. Knöpfe zum Zustimmen oder Ablehnen stehen bewusst nicht in der Mail. Ein Virenscanner, der jeden Link öffnet, würde sonst genehmigen.

Die Seite heißt „Approval request". Sie zeigt Nummer und Titel des Antrags, den Antragsteller und unter „This decision covers" die Teilaufgaben, um die es geht. Darunter liegen ein Kommentarfeld und die zwei Knöpfe.

Der Link gilt nicht ewig. Die Seite nennt die Frist: „Please decide by …".

Eine Entscheidung lässt sich nicht zurücknehmen. Die Seite sagt das danach auch: „A decision cannot be changed."

Der Abschnitt „Approvals" im Bauplan mit zwei Stufen, je Stufe Name, Adresse und Erinnerung.
Zwei Stufen an einem Bauplan. Die erste gilt für den ganzen Antrag, die zweite nur für die Aufgaben, die auf sie zeigen. Der Genehmiger steht als Adresse und nicht als Konto.Bild in voller Größe öffnen
Die Genehmigungsmail im Postfach mit einem einzigen Link auf die Entscheidungsseite.
So kommt die Anfrage beim Genehmiger an. In der Mail steht ein Link und sonst nichts zum Klicken. Entschieden wird erst auf der Seite dahinter.Bild in voller Größe öffnen
Die Seite „Approval request" mit dem Antrag, dem Antragsteller, der betroffenen Teilaufgabe, dem Kommentarfeld und den Knöpfen „Approve" und „Reject".
Die Entscheidungsseite. Unter „This decision covers" steht, worum es geht. Der Genehmiger ist nicht angemeldet und hat kein Konto.Bild in voller Größe öffnen
5

Eine zweite Stufe für einzelne Teilaufgaben

Nur Professional

Manche Teilaufgaben brauchen eine eigene Freigabe. Ein Zugang von außen ist etwas anderes als ein Notebook.

Dafür legst du eine zweite Stufe an und wählst sie an der Aufgabe unter „Extra approval". Steht dort „None — the request approval is enough", genügt die Freigabe des Antrags. Beide Stufen werden gleichzeitig gefragt und nicht nacheinander.

Eine Teilaufgabe ist frei, wenn alle Stufen zugestimmt haben, die sie betreffen. Die übrigen Aufgaben laufen schon los, sobald der Antrag genehmigt ist.

Bis dahin ist die Teilaufgabe gesperrt. Ihr Ticket steht auf „Waiting for approval", hat keinen Bearbeiter, und die Statusauswahl bietet nichts an.

Die Sperre gilt auch für die Sammelaktion auf der Ticketliste. Wer sie dort mit auswählt, liest den Grund: „This task is waiting for approval and cannot be worked on yet."

Das Ticket entsteht trotzdem sofort. So sieht das Fachteam, was auf es zukommt, und niemand muss den Antrag im Auge behalten.

Die Aktionen-Karte einer gesperrten Teilaufgabe mit dem Status „Waiting for approval" und einer leeren Statusauswahl.
Die Teilaufgabe, die auf ihre eigene Stufe wartet. Der rote Rahmen liegt auf dem geltenden Status. Über ihm steht ein Strich, weil kein Übergang angeboten wird.Bild in voller Größe öffnen
6

Erinnerung, aber keine Freigabe durch Zeitablauf

Nur Professional

Je Stufe kannst du eine Erinnerung einstellen. Sie steht in Stunden.

Bleibt die Antwort aus, geht nach dieser Zeit dieselbe Mail noch einmal hinaus. Der Link darin ist derselbe wie in der ersten Mail. Wer die erste aufgehoben hat, kann sie weiter benutzen.

Ohne Erinnerung wartet der Antrag ohne Nachfrage.

Was es nicht gibt, ist eine Freigabe durch Zeitablauf. Unter dem Feld steht es wörtlich: „A request is never approved automatically. If nobody reacts, it keeps waiting." Eine Frist, die von selbst zustimmt, wäre keine Genehmigung, sondern eine Formsache.

Eine Genehmigungsstufe mit dem rot umrandeten Feld für die Erinnerung in Stunden.
Die Erinnerung gehört zur Stufe und steht in Stunden. Bleibt sie leer, fragt das System nicht nach.Bild in voller Größe öffnen
7

Die Absage geht mit Begründung an den Antragsteller

Nur Professional

Wer ablehnt, muss einen Grund schreiben. Ohne Text nimmt die Seite die Ablehnung nicht an.

Das Feld sagt, wohin der Text geht: „Comment (required when you reject — the requester will see it)". Eine interne Notiz gehört hier nicht hinein.

Der Antragsteller bekommt eine E-Mail mit der Begründung. Er muss nicht nachfragen, warum nichts weitergeht.

Zustimmen braucht keinen Grund. Es ist der erwartete Ausgang.

Wird nur eine zweite Stufe abgelehnt, betrifft die Absage nur deren Teilaufgaben. Der Rest des Antrags läuft weiter.

Eine abgelehnte Teilaufgabe bekommt den Status „Rejected" und zählt als abgeschlossen. So hängt der Antrag nicht ewig an etwas, das nie kommt.

Die Entscheidungsseite nach der Ablehnung mit dem Satz „You rejected this request." und dem Hinweis, dass eine Entscheidung nicht geändert werden kann.
Nach der Entscheidung. Die Seite bestätigt, was der Genehmiger getan hat, und sagt, dass es dabei bleibt.Bild in voller Größe öffnen
8

Die Prüfspur und der Genehmiger im Urlaub

Nur Professional

Am Antrag steht unter „Approvals" je Stufe eine Zeile. Sie nennt den Genehmiger, den Zustand und bei einer offenen Anfrage, seit wann gewartet wird.

Nach der Entscheidung steht dort, wann entschieden wurde und mit welchem Kommentar. Das ist die Prüfspur, und sie bleibt am Vorgang.

Ist der Genehmiger im Urlaub, stellt ein Administrator die Anfrage auf eine andere Adresse um. Der Knopf heißt „Reassign" und erscheint nur bei einer offenen Anfrage.

Das darf nur ein Administrator. Ein Bearbeiter, der umstellen dürfte, könnte auf sich selbst umstellen und danach entscheiden.

Beim Umstellen entsteht ein neuer Link. Der alte ist sofort tot, auch wenn ihn jemand weitergeleitet hat.

Die Umstellung steht in derselben Liste: wer wann von wem auf wen umgestellt hat.

Im fremden Namen entscheiden kann niemand. Es gibt nur den Weg über den Link, und wer ihn bekommen hat, steht am Vorgang.

Der Dialog „Reassign" mit der Frage nach der neuen Adresse und dem ausgefüllten Feld.
Der Dialog fragt nach der Adresse, an die die Anfrage stattdessen gehen soll. Bestätigt wird mit demselben Wort, das den Dialog geöffnet hat.Bild in voller Größe öffnen
Die Liste „Approvals" mit der genehmigten ersten Stufe, der abgelehnten zweiten Stufe, beiden Kommentaren und dem Vermerk über die Umstellung.
Beide Stufen mit ihrer Entscheidung, ihrem Zeitpunkt und ihrem Kommentar. Der rote Rahmen liegt auf der umgestellten Stufe. Darunter steht, wer sie von wem auf wen umgestellt hat.Bild in voller Größe öffnen

Antwort- & Ticketvorlagen

Zwei Vorlagenarten für zwei Augenblicke: Die Antwortvorlage füllt das Kommentarfeld an einem offenen Ticket, die Ticketvorlage füllt das Anlege-Formular. Beide gehören zu Basic. Nur der Versand einer Antwort als E-Mail hängt am Mailkanal und damit an Professional. Die Vorlage selbst nicht.

1

Antwortvorlagen: Text + Feldaktionen (Status, Zuweisung, Priorität …) in einem Klick

Voraussetzung: Verwalten und Anwenden sind zwei verschiedene Rechte. Administratoren und Bearbeiter können beides als Werkseinstellung. Anwenden darf es jeder, der das Ticket bearbeiten darf. Auch wenn die Rolle die Einstellung nicht verwalten darf, kann sie es trotzdem anwenden.

Die Vorlagen stehen unter „Settings → Templates". Der Satz unter der Überschrift sagt, was sie tun und was sie nicht tun: „Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically." Eine Vorlage ist ein vorbereiteter Handgriff und kein Automat. Abgeschickt wird immer von Hand.

Es gibt zwei Arten, und du wählst sie beim Anlegen: „Add reply template" für die Antwort an einem offenen Ticket, „Add ticket template" für das Anlege-Formular. Die Art lässt sich später nicht mehr wechseln, denn sie entscheidet, welche Felder das Formular überhaupt zeigt. Das Etikett über jeder Vorlage sagt dir, welche du vor dir hast: blau „Reply template", grün „Ticket template".

Eine Antwortvorlage besteht aus dem Antworttext im Feld „Reply text", dem Häkchen „Internal note" und beliebig vielen Aktionen. Aktionen gibt es sechs: „Set the status", „Set the priority", „Assign to a user", „Remove the assignee", „Hand over to another team" und „Set a follow-up".

Bei „Assign to a user" steht ganz oben der Eintrag „The agent who applies it". Nimm ihn, wenn mehrere Leute mit derselben Vorlage arbeiten: Das Ticket gehört danach dem, der sie angewendet hat, und nicht einer festen Person aus der Liste. Bei „Set a follow-up" gibst du Anzahl und Einheit an. Zur Wahl stehen minutes, hours, days, business minutes, business hours und business days. Dazu kommt die Notiz, die dir später sagt, warum das Ticket zurückkommt.

Der blaue Kasten am Ende jeder Vorlage schreibt in einem Satz auf, was sie tun wird. Ein Beispiel: „Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days." Der Satz baut sich beim Einstellen mit. Er ist die Gegenprobe: Wenn er etwas anderes sagt, als du vorhattest, stimmt eine Einstellung nicht.

Ein Text ist keine Pflicht. „An das Netzwerk-Team abgeben, ohne ein Wort zu schreiben" ist eine gültige Vorlage. Der Satz lautet dann „Suggests actions without a reply text".

Die Seite „Templates" mit den beiden rot umrandeten Schaltflächen „Add reply template" und „Add ticket template".
Die Art wird beim Anlegen gewählt: zwei Schaltflächen statt eines Schalters. Darunter liegen die Vorlagen offen, jede mit ihrem Etikett und ihrem Geltungsbereich.Bild in voller Größe öffnen
Die drei Aktionszeilen einer Antwortvorlage, rot umrandet, darunter der blaue Klartextsatz.
Drei Aktionen an einer Vorlage: Status, Zuweisung an den Anwendenden, Wiedervorlage in drei Tagen. Der Satz darunter sagt dasselbe in einem Stück.Bild in voller Größe öffnen
2

Vorgeschlagene Aktionen vor dem Absenden einzeln abwählbar

Am offenen Ticket steht über dem Kommentarfeld die Schaltfläche „Template". Ein Klick öffnet die Tippsuche „Search templates…", und die Auswahl füllt das Kommentarfeld. Mehr passiert nicht, und die Zeile darunter sagt es auch: „Nothing happens until you add the comment."

Jede Aktion der Vorlage wird zu einer Marke neben der Schaltfläche, und zwar im Klartext: „sets status to Waiting for Service Provider Response", „assigns to the applying agent", „sets a follow-up in 3 days". Ein Klick auf eine Marke streicht sie durch. Sie ist dann abgewählt und läuft nicht. Noch ein Klick holt sie zurück.

Abgewählte Aktionen werden durchgestrichen und nicht entfernt. So bleibt sichtbar, was die Vorlage vorgeschlagen hätte. Die Entscheidung bleibt umkehrbar, solange du nicht abgeschickt hast.

Welche Marken von vornherein an sind, entscheidet die Vorlage: In der Verwaltung trägt jede Aktion den Schalter „Suggested". Er ist der Vorschlag für alle Fälle, die Marke am Ticket ist die Entscheidung für diesen einen.

Das „×" hinter den Marken nimmt die Vorlage wieder weg. Der Text bleibt dabei im Feld stehen, denn du hast ihn womöglich längst umgeschrieben. Es entfällt nur die Wirkung, also Aktionen, Mail und Anhänge.

Abgeschickt wird mit dem gewohnten Kommentar-Knopf. Erst dann entsteht der Kommentar, und erst danach laufen die Aktionen, die noch an sind.

Das Kommentarfeld eines Tickets mit der Schaltfläche „Template", drei Marken daneben, die letzte durchgestrichen, und dem eingefügten Text darunter.
Zwei Aktionen laufen, die dritte ist abgewählt: Die Wiedervorlage in drei Tagen passt hier nicht, der Rest schon. Der Text steht im Feld und ist noch änderbar.Bild in voller Größe öffnen
3

Platzhalter (Anfragender, Ticketnummer, Titel …) – beim Einfügen stehen die echten Werte im Text

Im Antworttext darfst du fünf Platzhalter benutzen. Die Liste steht unter dem Feld: „{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}". Geschrieben werden sie mit geschweiften Klammern, genau so, wie sie dort stehen.

„{ticketRef}" ist die Ticket-Kennung in der Form „[TICKET-8-…]". An ihr erkennt das System die Antwort des Kunden wieder, wenn sie per E-Mail zurückkommt. „{ticketId}" dagegen ist nur die nackte Nummer.

Aufgelöst wird beim ANWENDEN und nicht beim Speichern. In der Verwaltung steht weiterhin „{requesterName}", im Kommentarfeld am Ticket steht der echte Name. Würde beim Speichern aufgelöst, stünden die Werte EINES Tickets für immer in der Vorlage.

Damit siehst du den fertigen Text, bevor irgendetwas hinausgeht. Stimmt die Anrede nicht, änderst du sie im Feld wie jeden anderen Text.

Wer „Anfragender" ist, entscheidet das Ticket, nicht das Konto: Der am Ticket eingetragene Anfragende geht vor dem Konto, das das Ticket erfasst hat. Legt ein Bearbeiter nach einem Anruf ein Ticket für einen Kollegen an, grüßt die Antwort trotzdem den Kollegen und nicht den Bearbeiter.

Ein vertippter Platzhalter wird beim Speichern abgelehnt, und zwar mit Namen: „Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}." So merkst du es beim Anlegen und nicht am Kunden.

Der Betreff der E-Mail hat eine EIGENE, kürzere Liste: „{originalSubject}, {ticketTag}, {ticketId}". Deshalb steht sie dort noch einmal. Ein Platzhalter aus dem Text funktioniert im Betreff nicht und wird ebenso abgelehnt.

Das Feld „Reply text" einer Vorlage mit den Platzhaltern im Text, rot umrandet, darunter die Liste der erlaubten Platzhalter.
So steht die Vorlage in der Verwaltung: mit den Platzhaltern, nicht mit Werten. Die Zeile darunter zählt auf, welche es gibt.Bild in voller Größe öffnen
Dieselbe Vorlage am Ticket angewendet: im Kommentarfeld stehen Name, Titel und Ticket-Kennung ausgeschrieben.
Derselbe Text am Ticket: „Hello Amir Khan", der Titel des Tickets und die Kennung „[TICKET-8-…]". Als Unterschrift steht darunter der Bearbeiter, der die Vorlage eingefügt hat. Abgeschickt ist damit noch nichts.Bild in voller Größe öffnen
4

Antwort auf Wunsch als E-Mail an den Anfragenden

Nur Professional

Voraussetzung: Der Mailkanal ist als Ganzes Professional, für den Eingang wie für den Ausgang. Zusätzlich muss im Postfach des Teams der Versand bei Ticket-Aktionen eingeschaltet sein. Ist er es nicht, wird die Mail-Marke am Ticket gar nicht angeboten. Die Aktionen der Vorlage laufen wie immer, nur die Mail entfällt.

Der Schalter „Send the comment as e-mail" macht aus dem Kommentar zugleich die Mail. Es gibt dafür bewusst kein zweites Textfeld. Was im Ticket steht, ist das, was der Kunde liest. Zwei Texte liefen früher oder später auseinander.

Unter „Recipient" wählst du zwischen „Requester", „Assignee", „Observers" und „Fixed address". Wer „Requester" ist, löst der Server erst beim Anwenden am Ticket auf, denn eine Vorlage kennt das Ticket noch nicht. Das Postfach des Mail-Eingangs wird dabei nie angeschrieben. Das wäre eine Nachricht an uns selbst.

Der Betreff kann „{originalSubject}", „{ticketTag}" und „{ticketId}" tragen. Lass „{ticketTag}" darin stehen: An dieser Kennung erkennt das System die Antwort des Kunden wieder und hängt sie an dasselbe Ticket. Fehlt sie, wird aus jeder Rückmeldung ein neues Ticket.

Die Mail geht als reiner Text hinaus. Fettschrift, Listen und Links werden vor dem Versand entfernt, sonst läse der Kunde die rohen Auszeichnungen. Im Ticket bleibt der Kommentar formatiert stehen.

Am Ticket ist der Mailversand eine weitere Marke neben den Aktionen, hier „E-mail to Requester", und genauso abwählbar wie sie. Eine Vorlage schickt also nichts hinaus, ohne dass du es im Bild hattest. Die Marke erscheint nur, wenn das Postfach des Teams Aktionsmails verschickt.

Die Anhänge einer Vorlage stehen in der Karte „Attachments" und sind eigene Kopien der Dateien. Beim Anwenden werden sie an das TICKET gehängt, mit einer eigenen Zeile im Verlauf. In der Mail sind sie nicht enthalten. Anhänge an einer Vorlage zu führen braucht keine Professional-Lizenz. Nur der Versand braucht sie.

Der Mailblock einer Vorlage mit dem rot umrandeten Schalter „Send the comment as e-mail", dem Empfänger und dem Betreff.
Schalter, Empfänger und Betreff. Im Betreff steht „{ticketTag}", die Kennung, an der die Antwort des Kunden wiedererkannt wird.Bild in voller Größe öffnen
5

Vorlage direkt aus einem bestehenden Ticket erzeugen

Die meisten Vorlagen entstehen nicht am Reißbrett, sondern in dem Moment, in dem du eine Antwort zum zweiten Mal schreibst. Deshalb trägt jeder Kommentar eines Tickets rechts ein kleines Blatt-Symbol mit dem Hinweis „Make template". Es nimmt genau diesen Kommentar als Ausgangstext, auch den eines Kollegen.

Hat das Ticket Anhänge, fragt zuerst ein Dialog, welche mitkommen sollen: „Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default." Vorangekreuzt ist nichts, und das ist Absicht.

Danach landest du auf der Vorlagen-Seite mit einem noch NICHT gespeicherten Entwurf. Oben steht das gelbe Band „Draft from ticket #… — name it and review the text (it may contain customer details), then save." Der Name ist leer. Du musst einen vergeben, sonst speichert es nicht.

Übernommen werden der Text, das Häkchen „Internal note", das Team des Tickets und der Zustand des Tickets als Aktionsvorschlag. Sein Status und seine Priorität stehen bereits als zwei Aktionen da. Nicht übernommen werden Anfragender, Adresse und Titel. Das sind die Angaben genau dieses einen Falls.

Lies den Text, bevor du speicherst. Er stammt aus einem echten Vorgang und kann den Namen einer Person, eine Bestellnummer oder einen Raum enthalten. Anonymisiert wird nichts von selbst. Das Band sagt es dir, tun musst du es selbst.

Erst „Save" legt die Vorlage an. Danach werden die angekreuzten Anhänge als Kopie übernommen und mit einer Meldung bestätigt.

Ein Kommentar am Ticket mit dem rot umrandeten Blatt-Symbol „Make template" neben den Knöpfen zum Bearbeiten und Löschen.
Der Weg beginnt am Kommentar, nicht in den Einstellungen: das Blatt-Symbol rechts an der Antwort, die du wiederverwenden willst.Bild in voller Größe öffnen
Der Dialog „Make a template from this comment" mit den beiden Anhängen des Tickets, beide nicht angekreuzt.
Zwei Anhänge hängen an diesem Ticket, angekreuzt ist keiner. Einer davon ist das Bildschirmfoto des Kunden. Das gehört in keine Vorlage.Bild in voller Größe öffnen
6

Entwürfe privat bis zur Veröffentlichung; Geltung je Team oder global

„Applies to" entscheidet, wer die Vorlage angeboten bekommt: ein bestimmtes Team oder „All teams". Beim Anlegen steht dort ein konkretes Team. „Alle Teams" ist eine Wahl, die jemand treffen muss, und keine stille Voreinstellung.

Am Ticket werden die Vorlagen des besitzenden Teams angeboten, dazu die globalen. Wandert das Ticket nach einer Abgabe zu einem anderen Team, wechselt die Liste mit. Die Vorlagen des neuen Teams stehen dann zur Wahl.

Der Schalter „Draft" macht die Vorlage zu deiner Werkstatt: „Only you can see this template until you publish it." Ein fremder Entwurf steht in keiner Liste und ist auch über seine Adresse nicht erreichbar. Das gilt auch für Administratoren. Eine neue Vorlage ist als Werkseinstellung ein Entwurf. Erst wenn du den Schalter ausmachst und speicherst, sehen ihn die anderen.

Zwei Vorlagen dürfen nicht gleich heißen, wenn sie sich begegnen können: Eine globale kollidiert mit jeder gleichnamigen, egal in welchem Team. Eine Antwortvorlage und eine Ticketvorlage dürfen dagegen denselben Namen tragen. Sie stehen nie nebeneinander in derselben Auswahl.

„Duplicate" legt eine Kopie an, und die Kopie ist immer ein Entwurf: „Duplicated. The copy is a draft only you can see." Das ist der bequeme Weg zu einer Abwandlung, ohne dass die halbfertige Fassung schon jemand anders vorgeschlagen bekommt.

Der Kopf einer Vorlage mit den Etiketten „Reply template" und „Draft", dem rot umrandeten Feld „Applies to" und dem ebenfalls umrandeten Schalter „Draft".
Diese Vorlage gehört dem Helpdesk und ist ein Entwurf. Außer ihrem Verfasser sieht sie niemand. Im Text steht nichts, weil sie nur abgeben soll.Bild in voller Größe öffnen
7

Ticketvorlagen: Anlege-Formular vorbefüllt (Titel, Beschreibung, Kategorie, Priorität, Team)

Eine Ticketvorlage füllt das Formular „Create new ticket". Sie hat keinen Antworttext, keine Aktionen und keinen Mailweg. In diesem Augenblick gibt es noch kein Ticket, auf das etwas wirken könnte. Das Formular zeigt deshalb andere Felder als bei einer Antwortvorlage, und der grüne Rahmen sagt dir, dass du eine Ticketvorlage vor dir hast.

Vorbelegen kannst du „Ticket title", „Owning team of the new ticket", „Main category", „Subcategory", „Priority" und die „Ticket description". Jedes Feld darf „Not prefilled" bleiben. Was leer bleibt, füllt später der Mensch am Formular aus.

Achte auf den Unterschied zwischen den beiden Team-Feldern: „Applies to" ganz oben sagt, WER die Vorlage sieht. „Owning team of the new ticket" sagt, WOHIN das neue Ticket geht. Das sind zwei verschiedene Fragen, und sie dürfen verschiedene Antworten haben.

Die Kategorien sind nach Team gruppiert, denn eine Kategorie gehört einem Team. Wählst du eine aus einem anderen Team, sagt das Formular es dir, und das Speichern wird abgelehnt. Im Anlege-Formular des Zielteams stünde diese Kategorie gar nicht zur Wahl. Die Vorbelegung liefe also ins Leere.

Platzhalter gibt es hier nicht, und der Hinweis unter dem Text sagt es: „No placeholders here: the template only prefills the form, nothing is resolved or sent." Ein „{requesterName}" stünde wörtlich im neuen Ticket. Deshalb wird er schon beim Speichern abgelehnt.

Der blaue Kasten fasst auch hier zusammen, was die Vorlage tut: „Prefills the new ticket with title ‚New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description."

Im Formular selbst wählst du die Vorlage über die Schaltfläche „Template". Daneben steht „Prefills the form - nothing is created until you submit." Alles Vorbelegte lässt sich vorher noch ändern, und angelegt wird erst mit dem Absenden.

Mitgeliefert ist die Beispielvorlage „Example: create accounts for a new colleague". Sie zeigt die Bauform und tut von sich aus nichts. Du kannst sie umbauen oder löschen.

Der Editor einer Ticketvorlage mit den rot umrandeten Feldern für Titel, Zielteam, Kategorie und Priorität.
Fünf Vorbelegungen und die Beschreibung. Das Feld „Owning team of the new ticket" ist nicht der Geltungsbereich darüber. Es sagt, wohin das Ticket geht.Bild in voller Größe öffnen
Das Formular „Create new ticket" nach der Wahl einer Vorlage: die Schaltfläche „Template" und der vorbelegte Titel sind rot umrandet.
Dasselbe Formular wie immer, nur schon ausgefüllt: Titel, Team und Priorität stehen bereits. Kategorie und Beschreibung folgen weiter unten auf derselben Seite.Bild in voller Größe öffnen
8

Ticketvorlagen je Vorlage für Kunden freischaltbar

Der Schalter „Offer this template to customers" steht als Werkseinstellung aus. Der Hinweis daneben sagt beides, was du wissen musst: „Customers can pick this template when they create a ticket. A draft stays hidden either way."

Warum als Werkseinstellung aus? Eine Vorlage heißt oft nach internem Vokabular und ist für Kollegen geschrieben. Sie für Kunden sichtbar zu machen, ist eine Aussage nach außen. Die soll jemand ausdrücklich treffen und nicht versehentlich.

Der Kunde sieht dieselbe Schaltfläche „Template" über dem Anlege-Formular, aber nur die freigeschalteten Vorlagen. Ein Entwurf bleibt auch dann verborgen, wenn der Schalter an ist. Die beiden Regeln stehen hintereinander und nicht nebeneinander.

Der Nutzen liegt im ersten Kontakt. Ein Anliegen, das vollständig hereinkommt, spart die Rückfrage, die sonst zwei Tage kostet. Schreib die Fragen in die Beschreibung der Vorlage. Der Kunde beantwortet sie, während er das Ticket anlegt.

Weiter gehen kannst du mit „Fields to ask for". Die Vorlage bestimmt dann, welche Zusatzfelder das Formular abfragt, in welcher Reihenfolge und welche davon Pflicht sind. Diese Auswahl ERSETZT die üblichen Felder des Teams, sie ergänzt sie nicht. Genau das ist ihr Zweck. Zusatzfelder selbst gehören zu Professional; die Karte dazu heißt „Benutzerdefinierte Felder". Die Freischaltung einer Vorlage für Kunden gibt es in jeder Edition.

Ein für Kunden verborgenes Feld bleibt verborgen, auch wenn eine Vorlage es aufführt. Die Feldauswahl ist ein Werkzeug für die Reihenfolge und den Zuschnitt, kein Weg an der Feldsteuerung vorbei.

Der rot umrandete Schalter „Offer this template to customers" mit seinem Hinweistext.
Ein Schalter je Vorlage. Hier ist er an, diese Vorlage wird Kunden also angeboten. Der Hinweis sagt ausdrücklich, dass ein Entwurf trotzdem verborgen bleibt. Darunter steht die Feldauswahl.Bild in voller Größe öffnen
Das Anlege-Formular aus Sicht eines Kunden mit geöffneter Vorlagen-Auswahl, in der die freigegebenen Vorlagen stehen.
Dieselbe Auswahl beim Kunden. In der Liste stehen nur die freigeschalteten Vorlagen. Die übrigen Ticketvorlagen dieser Umgebung tauchen hier nicht auf.Bild in voller Größe öffnen
9

Jede Anwendung nachvollziehbar im Ticketverlauf

Jede Anwendung schreibt EINEN Eintrag in den Verlauf, unter dem Feldnamen „Template". Er nennt die Vorlage beim Namen und zählt auf, was tatsächlich gelaufen ist. Ohne ihn wäre später nicht mehr zu klären, warum ein Ticket auf einmal auf „In Progress" sprang: Die einzelnen Aktionen schreiben zwar ihre eigenen Zeilen, aber keine davon nennt die Vorlage.

Im Bild steht: „Template ‚First reply: we have your ticket’ applied: Assign: already assigned to that user; SetStatus: Assigned -> InProgress". Der erste Teil ist kein Fehler. Das Absenden des Kommentars hatte das Ticket bereits dem Bearbeiter zugewiesen, die Zuweisungs-Aktion hatte also nichts mehr zu tun. Der Eintrag sagt genau das, statt eine Wirkung zu behaupten, die es nicht gab.

Abgewählte Aktionen stehen nicht darin: Sie sind nicht passiert. Ein Fehlschlag steht darin, und zwar ausdrücklich als solcher hinter dem Wort „failed".

Der Eintrag ist INTERN, der Anfragende sieht ihn nicht. Der Name einer Vorlage ist internes Vokabular, etwa „Abweisung Standard", und der Verlauf steht auch dem Ersteller des Tickets offen. Die Feldänderungen selbst sieht er weiterhin, nur nicht, dass sie aus einer Vorlage kamen.

Urheber ist der Bearbeiter, nicht „System" und nicht die Vorlage. Das ist Absicht: Es war seine Entscheidung, sie anzuwenden. Anders als bei einer Automatisierungsregel steht am Ticket deshalb ein Mensch.

Der Verlauf eines Tickets mit dem rot umrandeten Eintrag „Template", der die angewendete Vorlage und die gelaufenen Aktionen nennt.
Ein Eintrag je Anwendung, mit dem Bearbeiter als Urheber. Darüber stehen die Zeilen der einzelnen Aktionen. Der Template-Eintrag sagt, woher sie kamen.Bild in voller Größe öffnen

Automatisierung & Wiedervorlage

Zwei Wege zum selben Ziel: dass kein Vorgang liegen bleibt, weil ihn niemand mehr auf dem Schirm hat. Die Wiedervorlage legst du selbst, sie gehört zu Basic. Die Regeln übernehmen es ohne dich und gehören zu Professional.

1

Wiedervorlage am Ticket von Hand (Datum + Notiz, Filter Heute/Diese Woche/Überfällig)

Voraussetzung: Die Wiedervorlage sehen nur Bearbeiter und Administratoren. Im Ticket steht das auch so: „Only agents and administrators see this — the requester never does." Der Anfragende bekommt sie nie zu Gesicht.

Die Wiedervorlage steht im Ticket rechts in der Karte „Details", unterhalb der Fristen. Ist noch keine gesetzt, steht dort „No follow-up set." und die Schaltfläche „Set follow-up". Datum und Uhrzeit wählst du unter „Date and time". Darunter steht das Feld „Note (optional)" mit dem Platzhalter „Why is this coming back?". Danach heißen die Schaltflächen „Change" und „Remove".

Die Notiz ist der eigentliche Nutzen. Ein Datum allein sagt dir in zwei Wochen nicht mehr, warum das Ticket wieder auf dem Tisch liegt. Deshalb hängt die Notiz am Datum. Nimmst du den Termin weg, ist die Notiz mit weg. Eine Begründung ohne Termin bekäme niemand mehr zu Gesicht.

Über der Ticketliste steht die Zeile „Follow-up:" mit vier Schaltflächen: „No filter", „Today", „This week" und „Overdue". In der Liste selbst gibt es die Spalte „Follow-up". Sie steht bewusst nicht im eingeklappten Filterblock, denn es ist die Frage, mit der ein Bearbeiter den Tag beginnt.

„Overdue" schließt die heutigen mit ein. Sonst verschwände eine Wiedervorlage in dem Moment, in dem ihre Uhrzeit vorbei ist, also genau an dem Tag, an dem sie zählt.

Die Karte „Details" eines Tickets mit dem rot umrandeten Abschnitt „Follow-up", darin die Marke „Overdue", die Notiz und die Schaltflächen „Change" und „Remove".
Der Termin dieses Tickets liegt in der Vergangenheit, deshalb die rote Marke „Overdue". Die Notiz sagt, worum es beim Wiedersehen geht.Bild in voller Größe öffnen
Die Ticketliste mit der rot umrandeten Zeile „Follow-up:" über der Tabelle und der ebenfalls umrandeten Spalte „Follow-up".
Vier Tickets tragen einen Termin: zwei hat ein Bearbeiter von Hand gesetzt, zwei eine Regel. Die Schaltflächen darüber schränken die Liste auf heute, diese Woche oder überfällig ein.Bild in voller Größe öffnen
2

Zeitgesteuerte Regeln – reagieren auf das AUSBLEIBEN einer Handlung

Nur Professional

Voraussetzung: Eine neue Regel wird IMMER ausgeschaltet angelegt. Das gilt auch dann, wenn du sie über die Schnittstelle eingeschaltet anlegen willst. So läuft keine Regel im Moment des Anlegens über den gesamten Bestand. Eingeschaltet wird sie erst beim nächsten „Save".

Die Regeln stehen unter „Settings → Automation". Der Satz unter der Überschrift sagt, worum es geht: „Rules that act when nobody else does." Eine Regel gehört zu einem Team und arbeitet auf dessen Tickets. Oben wählst du unter „Team" aus, welche Regeln du gerade sehen willst.

Der Unterschied zu allem anderen im System: Diese Regeln reagieren nicht auf ein Ereignis, sondern auf sein AUSBLEIBEN. Seit drei Tagen keine Antwort des Anfragenden, seit einer Woche keine Bewegung, vor vier Stunden angelegt und immer noch niemandem zugewiesen. Es gibt keinen Klick, der so etwas auslöst. Genau deshalb fällt es auch niemandem auf.

Ein grünes Band oben sagt dir, dass geprüft wird: „The automation checks every minute. 2 of 6 rule(s) are enabled." Ist keine Regel eingeschaltet, steht dort stattdessen die Warnung „No rule is enabled. Nothing is being checked and tickets behave exactly as before." Dann passiert auch wirklich nichts.

Der Kopf der Seite „Automation" mit dem rot umrandeten grünen Band zum Prüftakt, dem Team-Filter und der Schaltfläche „Add rule".
Sechs Regeln liegen hier, zwei davon laufen. Die vier mitgelieferten Beispiele stehen darunter auf derselben Seite, alle ausgeschaltet.Bild in voller Größe öffnen
3

Regelbaukasten WANN/WENN/DANN mit mitlaufendem Klartextsatz

Nur Professional

Eine Regel besteht aus drei Blöcken. „WHEN" ist das Ausbleiben, auf das reagiert wird („Something has not happened for a while. This is what the automation reacts to."). „IF" schränkt ein, für welche Tickets das gilt („Which tickets it applies to."). Eingeschränkt wird nach Status, Priorität, Team, Kategorie, Bearbeiter oder Bewertung. „THEN" ist, was geschieht.

Über den Blöcken steht die Regel als ganzer Satz, und er schreibt sich bei jeder Änderung neu: „When a ticket has seen no activity for more than 5 minutes and has the priority „High", then set a follow-up in 4 hours." Fehlt einer Regel noch etwas, sagt der Satz das an dieser Stelle statt es zu verschweigen.

Im Block „IF" entscheidest du außerdem, wie die Bedingungen zusammenwirken: „All conditions must apply" oder „Any condition is enough". Der Satz darüber ändert dabei seinen Bau. Mit „and" behauptete er sonst das Gegenteil dessen, was die Regel tut.

Zwei Felder steuern das Zusammenspiel mehrerer Regeln: „Order" legt die Reihenfolge fest, und der Schalter „Skip the following rules for a ticket this rule applies to" hält für ein Ticket, auf das diese Regel zutrifft, alle nachfolgenden an.

Mehr dazu in der Karte: Eine schlechte Bewertung als Auslöser

Eine Regel mit dem rot umrandeten Klartextsatz darüber und den drei Blöcken WHEN, IF und THEN darunter.
Derselbe Inhalt zweimal: einmal als Formular, einmal als Satz. Wer den Satz liest, merkt sofort, wenn er etwas anderes eingestellt hat, als er meinte.Bild in voller Größe öffnen
4

Vier mitgelieferte Beispielregeln (bei der Installation deaktiviert, können nach Belieben aktiviert werden)

Nur Professional

Jede Installation bringt vier Regeln mit: „Example: remind the requester after 3 business days", „Example: close after 10 days without a reply", „Example: raise the priority of unassigned tickets" und „Example: follow up on tickets nobody touched for a week". Sie stehen untereinander auf der Seite „Automation".

Alle vier sind ausgeschaltet. An jeder steht die graue Marke „Off" und „Last run: never". Sie sind ein Startpunkt zum Lesen und Umbauen, kein Verhalten, das dir jemand untergeschoben hat. Du kannst sie umbenennen, ändern, einschalten oder löschen.

Sie gelten außerdem für „Every team". Das ist die einzige Stelle im System, an der das ohne ausdrückliche Wahl entsteht. Wenn du eine davon einschaltest, sieh also zuerst nach, ob sie wirklich für alle deine Teams gedacht ist.

Die erste der vier Beispielregeln mit der rot umrandeten Marke „Off", dem Namen und dem Klartextsatz.
So sieht die erste aus. Die anderen drei stehen darunter auf derselben Seite und sind ebenfalls aus. „Every team" heißt: Sie würde für jedes deiner Teams gelten.Bild in voller Größe öffnen
5

Vorschau vor dem Aktivieren: zeigt, welche Tickets die Regel gerade betreffen würde – ohne etwas zu ändern

Nur Professional

Unter jeder Regel steht die Schaltfläche „Which tickets would this affect?". Ein Klick darauf zeigt die Liste „Tickets this rule would affect right now". Darin stehen die Tickets, auf die die Regel in diesem Moment zutrifft, mit Nummer und Titel.

Darunter steht, was die Vorschau nicht tut: „The preview only reads. It changes nothing and writes no log entry. Unsaved changes are not included." Der letzte Halbsatz ist wichtig: Die Vorschau rechnet mit dem gespeicherten Stand, nicht mit dem, was gerade im Formular steht.

Trifft die Regel gerade auf nichts zu, sagt sie das ebenfalls: „No ticket matches this rule right now." Das ist die Antwort, die du vor dem Einschalten sehen willst und nicht erst danach an den Tickets deiner Kunden.

Die aufgeklappte Vorschau einer Regel mit der Überschrift „Tickets this rule would affect right now", zwei Tickets und dem rot umrandeten Hinweis, dass die Vorschau nur liest.
Zwei Tickets würde diese Regel gerade anfassen. Der Hinweis darunter sagt, dass beim Klick auf die Schaltfläche nichts davon passiert ist.Bild in voller Größe öffnen
6

Aktionen: E-Mail, Status, Priorität, zuweisen, an ein anderes Team abgeben, Wiedervorlage

Nur Professional

Voraussetzung: Die Aktion „Send an e-mail" verschickt über denselben Mailkanal wie der Rest des Systems. Ohne eingerichteten Postausgang passiert nichts. In einer Basic-Installation gibt es diesen Kanal gar nicht.

Im Block „THEN" wählst du aus sieben Aktionen: „Send an e-mail", „Set the status", „Set the priority", „Assign to a user", „Remove the assignee", „Hand over to another team" und „Set a follow-up". Mit „Add action" kommen weitere dazu. Jede hat einen eigenen Schalter „Active". Du kannst also eine einzelne stilllegen, ohne die ganze Regel auszuschalten.

Bei „Send an e-mail" wählst du die Empfänger einzeln an: „the requester", „the assignee", „the observers" und „a fixed address". Die letzte hat ein eigenes Feld für die Adresse. Bei „Set a follow-up" gibst du eine Zahl, eine Einheit und die Notiz an, die später im Ticket steht.

Bei „Hand over to another team" steht der Hinweis gleich darunter: „The ticket moves to that team and the current assignee is cleared. No second ticket is created." Es entsteht also kein Duplikat. Derselbe Vorgang wechselt den Zuständigen.

Der Block „THEN" einer Regel mit dem rot umrandeten Auswahlfeld der Aktion und den Feldern für Zahl, Einheit und Notiz der Wiedervorlage.
Eine Aktion mit ihrem Beiwerk: „Set a follow-up", 4 „hours", dazu die Notiz, die der Bearbeiter später im Ticket liest.Bild in voller Größe öffnen
7

Zeitspannen je Bedingung wählbar: in Geschäftsstunden und -tagen nach dem Kalender des Teams – oder durchlaufend rund um die Uhr

Nur Professional

Jede Zeitbedingung im Block „WHEN" besteht aus drei Teilen: der Art, dem Vergleich „longer than" und einer Zahl mit Einheit. Zur Auswahl stehen fünf Arten: „Time since the ticket was created", „Time without any activity", „Time without a reply from the requester", „Time without a public reply from an agent" und „Time without a status change".

Die Einheit entscheidet je Bedingung einzeln, wie gerechnet wird. „minutes", „hours" und „days" laufen durch, auch nachts und am Wochenende. „business minutes", „business hours" und „business days" rechnen nach dem Geschäftszeiten-Kalender des Teams, zählen also nur, was in den Öffnungszeiten liegt.

Der Unterschied ist im Alltag groß: Drei Tage sind drei Tage, drei Geschäftstage sind bei einer Mo–Fr-Woche von Donnerstag aus gerechnet der folgende Dienstag. Es ist derselbe Kalender, den auch die SLA-Fristen benutzen.

Eine Zeitbedingung im Block „WHEN" mit rot umrandeter Zahl und Einheit, dahinter die Auswahl der Bedingungsart.
Diese Bedingung rechnet in „business days": drei Geschäftstage nach dem Kalender des Teams, nicht drei Kalendertage.Bild in voller Größe öffnen
8

Protokoll je Regel + Regelname als Urheber im Ticket-Verlauf

Nur Professional

Unter jeder Regel steht die Schaltfläche „Log". Sie öffnet die Tabelle „What this rule did" mit einer Zeile je betroffenem Ticket: „When", „Ticket", „Cycle", „Result" und „Details". Unter „Details" steht, was genau getan wurde, etwa „SetFollowUp: 2026-08-20 02:18Z". Hat eine Regel noch nichts getan, sagt sie das: „This rule has not done anything yet."

Die Spalte „Cycle" ist der Grund, warum eine Regel dich nicht jede Minute erinnert. Auf ein Ticket wirkt sie einmal je Zyklus. Ein Zyklus endet erst, wenn die Regel auf das Ticket nicht mehr zutrifft. Antwortet der Kunde also und schweigt danach wieder, beginnt Zyklus 2 und die Regel greift erneut.

Im Ticket selbst steht die Regel als Urheber. Im Verlauf erscheint sie unter ihrem Namen mit dem Vorsatz „Automation:", etwa „Automation: High priority: bring it back to us". Damit ist an jedem Vorgang nachlesbar, ob ein Mensch oder eine Regel gehandelt hat, und wenn eine Regel, dann welche.

In der Kopfzeile jeder Regel steht außerdem „Last run:" mit dem Zeitpunkt des letzten Durchlaufs, bei einer noch nie gelaufenen Regel „never".

Die aufgeklappte Tabelle „What this rule did" mit drei Zeilen und den rot umrandeten Spalten „Cycle" und „Details".
Drei Läufe an zwei Tickets. Am unbeantworteten Ticket #4 hat die Regel ein zweites Mal gegriffen, deshalb steht dort „2" in der Spalte „Cycle". Unter „Details" steht jeweils der gesetzte Wiedervorlage-Termin.Bild in voller Größe öffnen
Der Verlauf eines Tickets mit den beiden rot umrandeten Zeilen, deren Urheber „Automation: High priority: bring it back to us" ist.
Dasselbe Ereignis aus Sicht des Tickets: Termin und Notiz stehen als zwei Zeilen im Verlauf, mit der Regel als Urheber.Bild in voller Größe öffnen

Sammelaktionen auf der Ticketliste

Mehrere Tickets ankreuzen und in einem Zug ändern. Alles davon gehört zu Basic. Nur die Kundenmail einer Vorlage hängt am Mailkanal und damit an Professional. Der eigentliche Punkt ist nicht die Menge, sondern der Umgang mit dem Teilerfolg: Jede Regel gilt für das einzelne Ticket, also sagt das System vorher, auf wie viele die Aktion passt, und hinterher, welche warum nicht mitkamen.

1

Status für mehrere Tickets gleichzeitig ändern

Die Ticketliste hat ganz links eine Spalte mit Kästchen. Sie ist für Administratoren und Bearbeiter da. Ein Kunde sieht sie nie.

Das Kästchen in der Kopfzeile wählt alle Zeilen der angezeigten Seite aus. Es wählt nicht den ganzen Treffersatz. Wer mehr braucht, filtert enger. Der Filter ist die ehrlichere Mengenangabe als ein Kästchen, das auch Tickets erfasst, die du gerade nicht siehst.

Die Auswahl leert sich, sobald du blätterst, filterst, suchst oder das Team wechselst. Damit läuft keine Auswahl mit, die nicht mehr auf dem Bildschirm steht.

Die Liste im Bild zeigt nicht alle Tickets. Oben rechts steht neben „Filter" das Wort „active", daneben „Reset". Geschlossene Tickets sind ausgeblendet, denn eine Sammelaktion zielt auf laufende Vorgänge. Eine Auswahl gilt immer nur für das, was die Liste gerade zeigt.

Ab dem ersten Kreuz erscheint über der Liste eine Leiste. Sie zeigt „20 selected", daneben „Clear selection" und die Schaltflächen „Change status", „Assign", „Assign to me" und „Apply template". Rechts stehen noch „Multiple report" und „Group into incident". Diese beiden gehören zu den Mehrfachmeldungen und werden im nächsten Block erklärt.

„Change status" öffnet einen kleinen Dialog. Du wählst den Zielstatus, darunter steht sofort, für wie viele der ausgewählten Tickets er gilt.

Verlangt der Zielstatus einen Kommentar, erscheint ein Textfeld. Darunter steht, an wie viele Tickets der Text geht. Er geht an jedes geänderte Ticket, nicht nur an das erste.

Nicht jeder Status steht in der Auswahlliste. Systemstatus fehlen, weil sie niemand von Hand setzt. „Waiting for other team" fehlt ebenfalls. Dieser Status legt ein Unterticket für ein Zielteam an, und das Zielteam wählst du je Ticket. Im Bündel gäbe es dafür nur eine einzige Eingabe.

Ein Ticket ohne Bearbeiter wird dir zugewiesen, wenn du seinen Status einzeln änderst. Im Bündel geschieht das nicht. „30 Tickets schließen" hieße sonst nebenbei „30 Tickets an mich" und 30 E-Mails.

Andere Felder ändert dieser Dialog nicht. Priorität, Kategorie und alles Weitere setzt du im Bündel über eine Antwortvorlage.

Mehr dazu in der Karte: Eine zweite Stufe für einzelne Teilaufgaben

Die Ticketliste mit angekreuzten Zeilen und der Leiste darüber, die die Zahl der ausgewählten Tickets und die Schaltflächen der Sammelaktionen zeigt.
Der rote Rahmen liegt auf der Leiste, die erst mit dem ersten Kreuz erscheint. Links steht die Zahl der ausgewählten Tickets, rechts stehen die Aktionen.Bild in voller Größe öffnen
Der Dialog „Change status" mit gewähltem Zielstatus und der Zeile, die die Reichweite nennt.
Der Zielstatus ist gewählt, darunter die Reichweite und der Grund für jedes Ticket, das nicht mitkommt. Beides steht da, bevor du auf „Apply" klickst.Bild in voller Größe öffnen
2

Mehrere Tickets gleichzeitig einem Bearbeiter zuweisen

„Assign" öffnet die Liste der Bearbeiter. Abwesende bleiben wählbar und sind nur gekennzeichnet, genau wie am einzelnen Ticket.

„Assign to me" ist derselbe Dialog mit deinem Namen als Vorauswahl. Es ist kein zweiter Weg, sondern eine Abkürzung. Für ihn gelten dieselben Regeln.

Jede Zuweisung schickt eine E-Mail an den Bearbeiter. Der Dialog nennt die Zahl vorher: „This sends 11 e-mail(s) to the selected agent." Elf Tickets sind elf Mails.

Der Bearbeiter muss zum Team des jeweiligen Tickets gehören. Eine Auswahl aus zwei Teams lässt sich deshalb nicht geschlossen an eine Person hängen. Das ist keine Einschränkung der Sammelaktion. Dieselbe Regel gilt am einzelnen Ticket.

Eine Zuweisung lässt sich nicht auf „niemand" zurücksetzen. Das gibt es am einzelnen Ticket nicht und im Bündel deshalb auch nicht.

Der Dialog „Assign" mit gewähltem Bearbeiter, der Reichweite und dem Hinweis auf die Zahl der E-Mails.
Unter der Auswahl stehen die Reichweite und die Zahl der E-Mails. Der Kasten darunter nennt jedes Ticket, das nicht mitkommt, und den Grund dazu: vier hängen schon an Marco Rossi, drei gehören dem Netzwerk-Team, in dem er nicht ist.Bild in voller Größe öffnen
3

Eine Antwortvorlage auf mehrere Tickets anwenden, Platzhalter je Ticket

„Apply template" wendet eine Antwortvorlage auf alle ausgewählten Tickets an. Je Ticket entsteht derselbe Kommentar wie beim Anwenden von Hand.

Angeboten werden die Vorlagen aller Teams, die in der Auswahl vorkommen. Eine Vorlage steht also schon in der Liste, wenn sie auf mindestens ein ausgewähltes Ticket passt. Auf wie viele sie wirklich passt, sagt danach die Vorschau.

Die Platzhalter löst der Server je Ticket auf. Jeder Kunde bekommt seine eigene Anrede und seine eigene Ticketnummer. Der Hinweis im Dialog sagt das ebenfalls.

Die Feldaktionen der Vorlage laufen mit, und ihre Anhänge werden an jedes Ticket kopiert.

Im Bündel laufen alle Aktionen der Vorlage. Einzelne abwählen kannst du nur am einzelnen Ticket. Wer eine Aktion nicht will, nimmt eine Vorlage ohne sie.

Gibt es für die Teams der Auswahl keine Vorlage, sagt der Dialog das: „No reply template is available for the teams of the selected tickets."

Der Dialog „Apply template" mit gewählter Vorlage und dem Hinweis, dass die Platzhalter je Ticket aufgelöst werden.
Der rote Rahmen liegt auf dem Hinweis zu den Platzhaltern. Er ist der Unterschied zu einem Text, der für alle gleich lautet. Darunter steht, warum die Vorlage auf 14 der 20 Tickets passt: sechs Tickets gehören einem Team, für das sie nicht gilt.Bild in voller Größe öffnen
4

Vorschau vor dem Ausführen, Ergebnis danach, Übersprungene bleiben ausgewählt

Alle drei Dialoge zeigen dieselbe Zeile, bevor etwas passiert: „Applies to 19 of 20 selected ticket(s)".

Darunter steht der Kasten „Übersprungen wird" mit einer Zeile je Ticket, das nicht mitkommt. Jede Zeile nennt die Ticketnummer und den Grund. Du liest also vor dem Klick, warum die Zahl kleiner ist als deine Auswahl.

Nach dem Ausführen steht dort „19 changed, 1 skipped", und aus demselben Kasten wird „Not changed". Der Inhalt ist der gleiche, nur ist er jetzt eine Feststellung und keine Vorhersage mehr.

Die Gründe sind die des einzelnen Tickets. Ein Ticket steht schon auf dem Zielstatus. Der Übergang ist aus seinem aktuellen Status nicht erlaubt. Es gehört einem Team, für das du nicht zuständig bist. Der gewählte Bearbeiter gehört nicht zu seinem Team. Es wartet auf eine Genehmigung. Es ist eine Sammelstörung mit offenen Meldungen. Es ist ein Hauptticket mit einem offenen Unterticket.

Die übersprungenen Tickets bleiben ausgewählt, die geänderten nicht. Der zweite Anlauf mit einem anderen Ziel ist damit ein Klick, und niemand muss raten, welche noch offen sind.

Die Vorschau ist eine zweite Meinung, kein Freibrief. Beim Ausführen prüft der Server jedes Ticket noch einmal. Zwischen Anzeige und Klick kann sich ein Ticket geändert haben.

Ein Aufruf nimmt höchstens 200 Tickets an. Bei 20 Zeilen je Seite ist das weit weg.

Der Dialog nach dem Ausführen: die Zahl der geänderten und übersprungenen Tickets, darunter der Kasten „Not changed" mit den Gründen.
Der Kasten „Not changed" nennt je Ticket den Grund. Hier standen zwei Tickets schon auf dem Zielstatus.Bild in voller Größe öffnen
5

Die E-Mail an die Anfragenden ist als Werkseinstellung aus

Nur Professional

Ein Kästchen für den Mailversand erscheint nur bei Vorlagen, die eine E-Mail verschicken, und nur wenn der Mailkanal offen ist. Es ist als Werkseinstellung leer. Eine Sammelaktion schreibt also nichts nach außen, solange du es nicht setzt.

Ist der Kanal zu, steht an der Stelle des Kästchens der Grund. Entweder ist der E-Mail-Versand abgeschaltet, oder die Postfächer der ausgewählten Teams verschicken keine Aktionsmails. Du liest das vor dem Klick und nicht erst im Ergebnis.

Setzt du es, erscheint ein gelber Hinweis mit der Zahl: „This sends 20 e-mail(s) to customers." Die Zahl kommt aus der Vorschau und ist die Zahl der Tickets, auf die die Vorlage wirklich passt.

Der Statuswechsel und die Zuweisung schreiben nie an Kunden. Die Zuweisung schickt eine E-Mail, aber an den Bearbeiter. Die Sammelanwendung einer Vorlage ist der einzige Weg, auf dem eine Kundenmail entsteht.

Der Versand hängt am Mailkanal und damit an Professional. Ist er aus, geht keine Mail hinaus, und der Verlauf des Tickets sagt, warum. Er behauptet nie einen Versand, den es nicht gab.

Der Dialog „Apply template" mit gesetztem Mail-Kästchen und dem gelben Hinweis auf die Zahl der Kundenmails.
Das Kästchen ist gesetzt, der gelbe Hinweis nennt die Zahl der Mails. Ohne das Kreuz geht keine hinaus.Bild in voller Größe öffnen
6

Jede Sammeländerung steht im Verlauf des einzelnen Tickets

Jede Änderung aus einer Sammelaktion steht im Verlauf des einzelnen Tickets. Sie sieht dort aus wie jede andere Änderung, mit altem und neuem Wert.

Diese Zeilen sieht auch der Anfragende. Eine Statusänderung ist für ihn dasselbe Ereignis, ob sie einzeln oder im Bündel ausgelöst wurde. Etwas davon zu verstecken wäre nicht diskreter, sondern schlechter.

Eine Sammelzuweisung schreibt zwei solche Zeilen. Neben dem neuen Bearbeiter steht der Status, denn ein zugewiesenes Ticket wechselt auf „Assigned".

Dazu kommt eine interne Zeile mit dem Kennzeichen des Laufs. Über dieses Kennzeichen findest du später alle Tickets desselben Laufs wieder. Der Anfragende sieht diese Zeile nicht.

Jede Zeile nennt die Person, die die Sammelaktion ausgelöst hat.

Ein übersprungenes Ticket bekommt keinen Eintrag, auch keinen über den Versuch. Was nicht geschehen ist, steht nicht im Verlauf.

Der Verlauf eines Tickets mit der Zeile der Zuweisung und der internen Zeile darunter, die den Lauf der Sammelaktion nennt.
Die neueste Zeile steht oben: der Status, darunter die Zuweisung, darunter das Kennzeichen des Laufs. Der rote Rahmen liegt auf der internen Zeile, die der Anfragende nicht sieht.Bild in voller Größe öffnen

Mehrfachmeldungen & Störungen

Zwei Lagen sehen gleich aus und sind es nicht. Meldet dieselbe Person zweimal dasselbe, soll eine Meldung verschwinden. Melden viele Menschen denselben Ausfall, darf keine verschwinden. Für beides gibt es einen eigenen Weg, und der Unterschied ist der Anfragende.

1

Zwei Meldungen derselben Person zusammenführen

Kreuze in der Ticketliste die Zeilen an und klicke auf „Multiple report". Der Knopf wird ab zwei angekreuzten Zeilen bedienbar.

Der Dialog fragt zuerst: „Which ticket stays?" Vorausgewählt ist das älteste Ticket. Die Frist läuft dann ab dem ersten Kontakt des Anfragenden und nicht ab seinem zweiten Versuch. Du kannst ein anderes bestimmen.

Darunter steht die Richtung mit beiden Nummern: „#11 will be closed and moved into #10." Damit ist vor dem Klick klar, welches Ticket bleibt.

Es wandert alles mit: Kommentare, Anhänge und die Beschreibung der zweiten Meldung. Die Beschreibung wird zum Kommentar am Original, mit ihrem ursprünglichen Verfasser und ihrem Datum. Der Dialog nennt die Zahlen vorher.

Erfasste Zeiten werden verschoben und nicht kopiert. Sonst stünde derselbe Aufwand an zwei Tickets und die Abrechnung zählte ihn doppelt.

Die zweite Meldung wird nicht gelöscht. Sie wird geschlossen und zeigt dauerhaft auf das Original. Ihre Nummer bleibt gültig.

Der Anfragende bekommt keine gesonderte E-Mail. Er hängt am Original und sieht dort alles. An der geschlossenen Meldung steht ein Kommentar mit der Nummer des Originals, den er lesen kann.

Es gibt kein Rückgängig. Deshalb steht alles im Dialog, bevor du auf „Merge" klickst.

Im Verlauf beider Tickets steht danach, wer wann was zusammengeführt hat.

Die Ticketliste mit drei angekreuzten Zeilen und der Leiste darüber, in der die Knöpfe „Multiple report" und „Group into incident" stehen.
Die roten Rahmen liegen auf den beiden Knöpfen. Sie stehen nebeneinander und meinen zwei verschiedene Dinge. Rechts davon siehst du in den Zeilen 12 bis 14 die Marke der laufenden Störung.Bild in voller Größe öffnen
Der Dialog „Multiple report for the same issue" mit der Auswahl des bleibenden Tickets und der Zusammenfassung.
Der rote Rahmen liegt auf der Richtung. Sie nennt beide Nummern, damit niemand raten muss, welches Ticket verschwindet.Bild in voller Größe öffnen
Die Ticketliste, auf zwei Tickets gesucht: das Original und die zusammengeführte Meldung, die geschlossen ist.
Gesucht wurde nach einem Wort aus beiden Titeln. So stehen das Original und die Meldung nebeneinander. Der rote Rahmen liegt auf der zusammengeführten Meldung. Sie ist geschlossen und steht weiter in der Liste, mit einem Verweis auf das Ticket, in das sie überführt wurde.Bild in voller Größe öffnen
2

Antworten auf die alte Ticketnummer kommen trotzdem an

Nur Professional

Voraussetzung: Voraussetzung ist der E-Mail-Eingang. Ohne ihn gibt es keine Antwort per E-Mail, die zugeordnet werden müsste.

Der Anfragende hat die alte Ticketnummer in seinem Postfach. Er weiß nichts davon, dass zwei Meldungen zusammengeführt wurden, und antwortet auf die Mail, die er hat.

Diese Antwort landet im Original. Das System folgt dem Verweis, den die geschlossene Meldung trägt.

Deshalb wird eine zusammengeführte Meldung nie gelöscht. Ohne sie gäbe es den Verweis nicht, und die Antwort käme nirgends an.

Wer an der alten Meldung beteiligt war, darf auch am Original schreiben. Geprüft wird an dem Ticket, das in der Mail steht.

Die geschlossene Meldung mit dem Verweis auf das Original und dem Kommentar, den der Anfragende dort liest.
Die roten Rahmen liegen auf dem Verweis in der Karte rechts und auf dem Kommentar. Dieser Verweis ist es, dem eine Antwort per E-Mail folgt.Bild in voller Größe öffnen
3

Meldungen verschiedener Personen lassen sich nicht zusammenführen

Wählst du Tickets verschiedener Menschen aus, nimmt der Dialog sie nicht mit. Er nennt jede abgelehnte Zeile und ihren Grund, bevor du klickst.

Der Grund lautet: „Different requester — this is an incident, not a multiple report." Er sagt damit auch, wo es stattdessen weitergeht.

Das ist die wichtigste Sperre dieser Funktion. Würdest du dreißig Meldungen von dreißig Personen zusammenführen, verlören neunundzwanzig Menschen ihr Ticket und hörten nie wieder etwas.

Wer der Anfragende ist, entscheidet das Feld „User" am Ticket. Ist es leer, zählt das Konto, das das Ticket angelegt hat.

Das ist der Grund, warum die Sperre auch am Telefon greift. Erfasst ein Bearbeiter zwei Anrufe, sind beide Tickets von ihm angelegt. Verschiedene Anrufer bleiben trotzdem verschiedene Anrufer, weil ihre Namen im Feld stehen.

Lässt sich der Anfragende an einer Seite gar nicht bestimmen, wird ebenfalls abgelehnt. Unbekannt ist nicht dasselbe wie derselbe.

Weitere Gründe stehen im selben Kasten. Eine Störung lässt sich nicht zusammenführen. Ein geschlossenes Original nimmt nichts mehr auf. Und eine Meldung, an der selbst schon Meldungen hängen, kommt nicht mit, damit keine Ketten entstehen.

Der Kasten „Cannot be merged" im Dialog, mit der Ticketnummer und dem Grund.
Der rote Rahmen liegt auf dem Grund. Ticket 15 gehört einer anderen Person, deshalb bleibt es draußen. Die anderen beiden Tickets werden trotzdem zusammengeführt.Bild in voller Größe öffnen
4

Viele Meldungen zu einem Ausfall unter einer Störung bündeln

Nur Professional

Fällt der Dateiserver aus, melden es zwanzig Leute. Jede dieser Meldungen ist ein eigener Vorgang mit einem eigenen Anfragenden. Zusammenführen wäre hier falsch, denn neunzehn Menschen verlören ihr Ticket.

Kreuze die Meldungen an und klicke auf „Group into incident". Der Dialog bietet drei Wege an. Du hängst sie an eine schon offene Störung. Du erklärst eines der ausgewählten Tickets zur Störung. Oder du legst eine neue Störung mit eigenem Titel an.

Gibt es schon eine offene Störung des Teams, ist dieser Weg vorausgewählt. Er ist der häufigere: Der Ausfall ist längst bekannt, es kommen nur immer neue Meldungen dazu.

Jedes verknüpfte Ticket behält seinen Anfragenden, seinen Status und seine eigene Frist. Es verschwindet nichts. Die Störung bündelt nur die Antwort.

Alle Meldungen einer Störung müssen demselben Team gehören. Betrifft ein Ausfall zwei Teams, bekommt jedes seine eigene Störung. Sonst würde die Auflösung des einen Teams die Warteschlange des anderen leeren.

Nachzügler ordnest du auch am einzelnen Ticket zu. Ist eine Störung des Teams offen, erscheint dort oben ein Hinweis mit „Assign" und „Not related". Das System ordnet nichts von selbst zu. Ein falsch zugeordnetes Ticket bekäme eine Lösung, die es nichts angeht, und würde dabei geschlossen.

Am Störungsticket steht, wie viele Meldungen daran hängen. Verknüpfte Tickets tragen umgekehrt die Nummer ihrer Störung, in der Liste und in der Karte rechts.

„Resolve incident" schließt die Störung und beantwortet alle Meldungen auf einmal. Der Lösungstext ist Pflicht. Er ist der ganze Nutzen der Funktion, denn er geht an jeden Betroffenen.

Jedes verknüpfte Ticket bekommt den Text als öffentlichen Kommentar, wird auf den gewählten Status gesetzt und der Anfragende bekommt seine eigene E-Mail. Keine Sammelmail, denn die legte die Adressen aller Betroffenen offen.

Die Meldung sagt danach, wie viele Tickets geschlossen und wie viele Anfragende benachrichtigt wurden. Beide Zahlen stehen getrennt, denn ein Ticket ohne erreichbare Adresse bekommt Kommentar und Status, aber keine E-Mail.

Ein Ticket, das du zwischendurch selbst beantwortet und geschlossen hast, bleibt unberührt. Es wird nicht ein zweites Mal geschlossen und nicht noch einmal beschrieben.

Solange offene Meldungen an einer Störung hängen, lässt sie sich nicht über den normalen Statuswechsel schließen. Sonst stünden zwanzig Menschen still ohne Antwort da.

Der Dialog „Group into incident" mit den drei Wegen und der offenen Störung samt Zahl der verknüpften Tickets.
Der rote Rahmen liegt auf der offenen Störung. Rechts steht, wie viele Meldungen schon daran hängen. Über den Wegen steht der Satz, der diesen Fall vom Zusammenführen trennt: es verschwindet nichts.Bild in voller Größe öffnen
Die Hinweisleiste am einzelnen Ticket mit der offenen Störung und den Schaltflächen „Assign" und „Not related".
Der rote Rahmen liegt auf der Hinweisleiste. Sie ist ein Vorschlag und keine Handlung. Wer sie wegklickt, ändert am Ticket nichts.Bild in voller Größe öffnen
Das Störungsticket mit der Zahl der verknüpften Meldungen, der Schaltfläche „Resolve incident" und dem Kästchen für das Banner.
Die roten Rahmen liegen auf der Schaltfläche zum Auflösen, auf dem Kästchen für das Banner und auf der Zahl der verknüpften Meldungen.Bild in voller Größe öffnen
Der Dialog „Resolve incident" mit dem Abschlussstatus und dem eingegebenen Lösungstext.
Der rote Rahmen liegt auf dem Hinweis über dem Feld. Er sagt, wohin dieser eine Text geht: an jedes verknüpfte Ticket und an jeden Anfragenden.Bild in voller Größe öffnen
Die Meldung eines Betroffenen nach dem Auflösen: geschlossen, mit dem Lösungstext als öffentlichem Kommentar.
Der rote Rahmen liegt auf der Antwort. Sie steht am Ticket dieses einen Anfragenden, mit seiner Nummer und seinem Verlauf. Dieselbe Antwort steht am Ticket jedes anderen Betroffenen.Bild in voller Größe öffnen
5

Die Störung als Banner und als Hinweis in der Eingangsbestätigung

Nur Professional

Im Dialog und am Störungsticket gibt es das Kästchen „Also show as a banner on the sign-in page". Damit weiß jeder von dem Ausfall, bevor er ein weiteres Ticket schreibt.

Das Banner steht auf der Anmeldeseite und im angemeldeten System. Es nennt „Known incident" und den Titel der Störung. Der Titel ist also ein Text für Kunden.

Sind mehrere Meldungen aktiv, stehen sie untereinander. Eine angekündigte Wartung am Samstag verdrängt den Ausfall von heute nicht, und umgekehrt.

Legt jemand trotzdem ein neues Ticket an, nennt die automatische Eingangsbestätigung die Störung. Das gilt für ein Ticket, das schon zugeordnet ist, und für jedes neue Ticket des Teams, solange die Störung offen und angekündigt ist. Voraussetzung ist der E-Mail-Versand.

Mit der Lösung verschwindet das Banner von selbst. Niemand muss daran denken, es wieder auszuschalten.

Auf der Seite „Maintenance / Incident-Notification" siehst du, welche Störung gerade als Banner läuft. Der Schalter dieser Seite gehört zur geplanten Wartung und gilt nicht für Störungen.

Das Störungsticket mit gesetztem Kästchen und dem Banner, das daraufhin am unteren Rand erscheint.
Der rote Rahmen liegt auf dem Kästchen. Es wirkt sofort: unten läuft die Meldung, und zwar auf jeder Seite des Systems.Bild in voller Größe öffnen
Die Anmeldeseite mit dem laufenden Störungsbanner am unteren Rand.
Der rote Rahmen liegt auf dem Banner. Es steht vor der Anmeldung da, also sieht es auch, wer nur nachsehen will, ob er ein Ticket schreiben muss.Bild in voller Größe öffnen
Das Störungsticket nach dem Auflösen: geschlossen, mit dem Lösungstext als Kommentar.
Der rote Rahmen liegt auf dem Lösungstext. Mit diesem Abschluss ist auch das Banner weg.Bild in voller Größe öffnen

SLA, Kalender & Eskalationen

Fristen, die zu deinen Öffnungszeiten passen: eine Regel sagt, wie schnell geantwortet und gelöst sein muss, ein Kalender sagt, wann die Uhr überhaupt läuft. Alles in diesem Block gehört zu Professional.

1

SLA-Regeln mit Fristen für erste Antwort und Lösung

Nur Professional

Voraussetzung: Ohne aktive Regel misst das System nichts. Es gibt dann keine Frist, keine Spalte und keine Mail. Uhren entstehen bei der ANLAGE eines Tickets. Was vor dem Einschalten der Regel hereinkam, bleibt ohne Frist. Das ist Absicht, sonst stünden am nächsten Morgen tausend Bestandstickets als überschritten da.

Fristen richtest du unter „Settings → SLA" ein. Die Seite sagt dir oben selbst, wenn keine Regel aktiv ist. Eine Regel besteht aus drei Teilen: einem Namen, den Bedingungen und den Zielen. Neue Regeln werden bewusst inaktiv angelegt. Du kannst sie in Ruhe fertig einstellen, bevor sie etwas bewirken.

Bedingungen sind „Team", „Priority", „Main category" und „Subcategory". Leer heißt „Any", also „gilt für alles" und nicht „gilt für nichts". Passen mehrere Regeln, gewinnt die mit der kleinsten Zahl unter „Order". Deshalb steht die enge Regel oben und die allgemeine darunter.

Die beiden Kategoriefelder sind nach Team gruppiert, weil Kategorien einem Team gehören. Angeboten werden dir trotzdem alle, auch die anderer Teams. Das ist Absicht: Bei einer Abgabe wandert das Ticket, die Kategorie nicht. Ein Ticket, das das Helpdesk an das Netzwerk-Team abgegeben hat, trägt weiterhin die Einordnung des Helpdesks, und eine Regel darf genau darauf zeigen. Wählst du eine Hauptkategorie, bietet dir das Feld darunter nur noch die Unterkategorien an, die mit ihr verknüpft sind. Ein Paar, das es am Ticket nicht geben kann, wird beim Speichern abgelehnt.

Jede Regel hat zwei Ziele. „Time to first response" endet mit der ersten öffentlichen Antwort eines Bearbeiters. Eine automatische Empfangsbestätigung und ein interner Kommentar zählen ausdrücklich nicht. „Time to resolution" endet, sobald das Ticket einen Status erreicht, der als gelöst gilt. Welcher das ist, legst du unter „Settings → General → Status" fest. Beide Ziele haben eigene Minuten, einen eigenen Kalender und eine eigene Reaktion auf die Überschreitung.

Am Ticket stehen die Fristen rechts in der Karte „Details", darunter „Show deadline history". Dieses Buch schreibt jeden Schritt mit: gestartet, pausiert, fortgesetzt, eingehalten, überschritten. Zu jedem Schritt stehen der Grund und die verbrauchte Arbeitszeit dabei. Das sehen nur Bearbeiter und Administratoren, für Kunden ist es nicht abrufbar.

Ändert später jemand Priorität oder Team, wechselt die Uhr auf die dann passende Regel. Die bisher verbrauchte Zeit wird noch mit dem alten Kalender abgerechnet, danach gelten die neuen Werte. Passt gar keine Regel mehr, endet die Uhr ohne Urteil. Sie zählt weder als eingehalten noch als überschritten.

Eine SLA-Regel mit Name, Order, Aktiv-Schalter, den vier rot umrandeten Bedingungen Team, Priority, Main category und Subcategory sowie den beiden Zielen darunter.
Die Regel gilt für jedes Team, aber nur für die Priorität „High". Darunter die beiden Ziele: 15 Minuten bis zur ersten Antwort, 240 bis zur Lösung.Bild in voller Größe öffnen
Die Fristen eines Tickets: „Time to first response" mit der Marke „In time", darunter „Time to resolution" mit Restzeit und das aufgeklappte Ereignisbuch.
Die erste Antwort ist rechtzeitig gekommen, die Lösung läuft noch. Das Buch nennt den Grund für jeden Schritt, von unten nach oben gelesen: gestartet gegen die Bürozeit-Regel, dann „ticket fields changed", als die Priorität auf „High" stieg, und schließlich eingehalten mit der ersten öffentlichen Antwort.Bild in voller Größe öffnen
2

Geschäftszeiten-Kalender je Team

Nur Professional

Ein Kalender sagt, wann die Uhr läuft. Er hat einen Namen, eine eigene Zeitzone und je Wochentag beliebig viele Zeitfenster. Eine Mittagspause ist also einfach ein Tag mit zwei Fenstern. Ein Fenster darf über Mitternacht hinausgehen. Dann steht daneben „ends next day".

Welcher Kalender für ein Team gilt, stellst du unter „Settings → Teams" am Team ein. Am einzelnen Ziel einer Regel kannst du ihn übersteuern: „From the team" nimmt den des Teams, oder du wählst einen anderen. So entsteht der übliche Fall: Störungen zählen rund um die Uhr, alles andere nur während der Bürozeit.

Gezählt wird die tatsächlich verstrichene Zeit im Fenster, nicht die Differenz der Uhrzeiten. Bei der Zeitumstellung macht das einen Unterschied: Ein 24/7-Tag im Oktober hat 25 Stunden, eine Nachtschicht von 22 bis 6 Uhr im Frühjahr sieben statt acht. Ein Bürofenster von 9 bis 17 Uhr ist nie betroffen, weil in der EU nachts umgestellt wird.

Findet sich kein Kalender mit offenen Zeiten, entsteht keine Frist. Am Ticket steht dann ein Hinweis statt eines Datums.

Der Kalender „Helpdesk business hours" mit der rot umrandeten Zeitzone Europe/Berlin, den Fenstern Montag bis Freitag 09:00–17:00 und der Schaltfläche „Add opening hours".
Fünf Tage, ein Fenster pro Tag. Die Zeitzone gehört dem Kalender, nicht dem Server. Ein zweiter Standort bekommt einfach einen zweiten Kalender.Bild in voller Größe öffnen
3

Feiertage per .ics-Import oder von Hand

Nur Professional

Voraussetzung: Wir liefern keine Feiertagsdaten mit. Feiertage hängen am ORT und nicht an der Sprache: 16 Bundesländer, 26 Kantone, 50 US-Staaten, und jedes Jahr neu. Eine mitgelieferte Liste wäre irgendwann falsch, ohne dass es jemand merkt. Nimm die amtliche .ics-Datei deiner Region. Das ist ein Vorgang von einer Minute im Jahr.

Unter jedem Kalender steht die Liste „Closed days". Ein Klick auf „Import holidays (.ics)" nimmt eine Kalenderdatei entgegen und meldet danach vier Zahlen: wie viele Tage übernommen, wie viele ersetzt, wie viele unlesbar und wie viele schon vorhanden waren. Einzelne Tage kannst du auch von Hand eintragen.

Das Zeichen ↻ hinter einem Tag heißt „wiederholt sich jährlich". Es ist nur für feste Termine richtig: Der 3. Oktober liegt jedes Jahr auf demselben Datum, Karfreitag und Pfingstmontag hängen am Osterdatum und wandern. Wandernde Feiertage stehen deshalb mit ihrem konkreten Datum je Jahr in der Liste. Im Bild ist das „Good Friday" ohne das Zeichen.

Ein geschlossener Tag schluckt das ganze Fenster dieses Tages, auch den Teil, der in den Folgetag hineinreicht. Kennt ein Kalender für die nächsten zwölf Monate keinen einzigen geschlossenen Tag, sagt die Seite das ausdrücklich. Sonst rechnet das System über Feiertage hinweg und liefert falsche Fristen.

Die rot umrandete Schaltfläche „Import holidays (.ics)" und darunter die ebenfalls umrandete Liste der geschlossenen Tage.
Fünf geschlossene Tage. Vier tragen das Zeichen ↻ für „jedes Jahr am selben Datum". Karfreitag trägt es nicht, denn er wandert.Bild in voller Größe öffnen
Der Kalender „Around the clock" mit dem rot umrandeten gelben Hinweis, dass er für die nächsten zwölf Monate keine geschlossenen Tage kennt.
Der Hinweis ist kein Fehler, sondern eine Warnung: Dieser Kalender rechnet über jeden Feiertag hinweg. Für einen Bereitschaftskalender ist genau das richtig.Bild in voller Größe öffnen
4

Die Uhr pausiert, während auf den Anfragenden gewartet wird

Nur Professional

Der häufigste Streit um Fristen ist der: Das Ticket wartet seit drei Tagen auf eine Antwort des Kunden, und die Uhr läuft trotzdem. Deshalb hat jedes Ziel den Schalter „Pause while waiting for the requester". Er gilt je Ziel und nicht für die ganze Regel.

Ob gewartet wird, entscheidet der Status. Unter „Settings → General → Status" trägt jeder Status eine Marke dafür, ob er als „wartet auf den Anfragenden" gilt. Steht der Schalter an, ruht die Frist, solange das Ticket in einem solchen Status steht. Die Wanduhr läuft dabei weiter. In der Liste steht deshalb „Paused" statt einer Restzeit, und im Ereignisbuch stehen „Paused" und „Resumed" mit Zeitpunkt.

Für die erste Antwort lässt man den Schalter üblicherweise aus: Die erste Antwort schuldest du unabhängig davon, worauf gerade gewartet wird. Für die Lösung steht er meist an. Im Bild ist genau das eingestellt.

Die beiden Ziele einer Regel mit den rot umrandeten Schaltern „Pause while waiting for the requester", beim ersten Ziel aus und beim zweiten an.
Derselbe Schalter, zwei Antworten: Die Uhr für die erste Antwort läuft durch, die für die Lösung ruht, solange der Kunde am Zug ist.Bild in voller Größe öffnen
5

Restzeit in der Ticketliste, mit Filter auf überschrittene Fristen

Nur Professional

Sobald eine Regel aktiv ist, bekommt die Ticketliste die Spalte „Deadline". Sie zeigt die Restzeit der nächsten offenen Frist, zum Beispiel „14h 53m". Läuft am Ticket keine Frist mehr, steht dort das Urteil: die Marke „In time" für eingehalten, das rote „Breached" für überschritten. Ein Ticket ganz ohne Uhr bekommt einen neutralen Strich, und der ist Absicht: Ein Ticket aus der Zeit vor der Regel ist kein Versäumnis.

Ist keine Regel aktiv, fehlt die Spalte ganz. Sie steht nicht leer da. Dasselbe gilt für den Filter: Unter „Filter" erscheint das Kästchen „Breached only" nur dann, wenn es überhaupt Fristen gibt.

Ein Ticket hat zwei Uhren, die Spalte hat aber nur einen Platz. Sie zeigt die dringlichste OFFENE Frist. Ist die erste Antwort überschritten und die Lösung läuft noch, steht in der Spalte die Restzeit der Lösung, daneben ein rotes „!". Das Zeichen sagt, dass an diesem Ticket bereits eine Frist gerissen ist. Genau darüber findet der Filter „Breached only" das Ticket, denn er fragt nach jeder überschrittenen Frist, auch nach einer längst abgeschlossenen. Welche der beiden es getroffen hat, steht im Ticket selbst.

Sortieren kannst du danach ebenfalls. Unter demselben Punkt „Deadline" steht ein Feld mit „Due soonest first" und „Due latest first". Tickets ohne laufende Uhr stehen dabei immer am Ende. Sie sind nicht am wenigsten dringend, sie sind schlicht nicht betroffen. Die Sortierung nach Frist hat Vorrang vor der nach „Updated at", denn zwei Reihenfolgen auf einmal kann keine Liste erfüllen.

Die Ticketliste mit gesetztem Haken „Breached only", dem rot umrandeten Filter und der ebenso umrandeten Spalte „Deadline".
Mit dem Haken bei „Breached only" bleibt nur noch ein Ticket stehen. Bei Ticket 4 ist die erste Antwort überschritten. In der Spalte steht trotzdem eine laufende Restzeit, denn sie zeigt die nächste OFFENE Frist, und das ist hier die Lösung. Das rote „!" daneben nennt den Bruch.Bild in voller Größe öffnen
Ein Ticket mit der roten Marke „Breached" an der ersten Antwort und einer laufenden Restzeit an der Lösung, darunter das Ereignisbuch.
Dasselbe Ticket, zwei Uhren, zwei Zustände. Im Buch steht der Grund: „due date passed", nach 16 Minuten verbrauchter Arbeitszeit.Bild in voller Größe öffnen
6

Bei Überschreitung benachrichtigen oder an ein anderes Team abgeben

Nur Professional

Voraussetzung: Die Weitergabe ist absichtlich nicht die Voreinstellung. Sie verschiebt die Zuständigkeit, leert den Bearbeiter und setzt den Status zurück. Ein Ticket, an dem gerade jemand arbeitet, liegt danach woanders. Wähle sie nur, wenn genau das gewollt ist.

Je Ziel legst du unter „When breached" fest, was beim Überschreiten passiert. „Record only" vermerkt es nur. „Notify assignee and observers" schickt eine Mail an den Bearbeiter und die Beobachter, aber nicht an das ganze Team. „Hand over to another team" gibt das Ticket ab. Bei der Weitergabe musst du ein Zielteam wählen. Eine Regel ohne Zielteam wird beim Speichern abgelehnt, denn sie sähe eingerichtet aus und täte nichts.

Die Aktion läuft genau einmal je Uhr. Ohne diesen Riegel würde ein Neustart des Servers dieselbe Mail noch einmal verschicken. Der Vermerk „schon erledigt" wird auch dann gesetzt, wenn das Verschicken fehlgeschlagen ist. Sonst ginge jede Minute eine neue Mail hinaus.

Der Bruch selbst wird auf den Zeitpunkt der Fälligkeit datiert und nicht auf den Prüflauf. Sonst hinge die Auswertung am Takt des Prüfdienstes. Gemessen wird an der verbrauchten Arbeitszeit: Eine pausierte Uhr kann nicht reißen, auch wenn das Fälligkeitsdatum längst vorbei ist.

Eine inaktive Beispielregel mit der rot umrandeten Auswahl „When breached: Hand over to another team" und dem Zielteam „Network".
Der Satz unter dem Zielteam sagt selbst, was passiert: Das Ticket wandert zum Team, der bisherige Bearbeiter wird geleert. Der Schalter „Active" steht hier aus. Eine inaktive Regel tut nichts.Bild in voller Größe öffnen
7

SLA-Kennzahlen im Reporting

Nur Professional

Unter „Reports" wählst du den Zeitraum und drückst „Generate report". Ohne diesen Klick bleibt die Seite leer. Im Bericht steht dann der Block „Service level agreements" mit einer Zeile je Ziel: eingehalten, überschritten, noch laufend, Erfüllungsgrad und die durchschnittlich verbrauchte Zeit.

Gezählt wird je Ziel und nicht je Ticket. Das steht auch unter der Tabelle. Ein Ticket mit beiden Zielen erscheint also zweimal, einmal in jeder Zeile.

Der Erfüllungsgrad zählt nur entschiedene Uhren. Laufende gehören nicht in den Nenner, sonst sähe jede frisch eingeschaltete SLA erst schlecht aus und würde von selbst besser. Gibt es noch keine einzige entschiedene Uhr, steht dort ein Strich und nicht „0 %".

Arbeitest du mit Sammelstörungen, gibt es zusätzlich die Zeile „Achieved without group incidents": Eine einzige Störung mit hundert angehängten Tickets würde die Quote sonst in beide Richtungen verzerren.

Der Berichtsblock „Service level agreements" mit den Spalten Met, Breached, Still running, dem rot umrandeten Erfüllungsgrad und der durchschnittlich verbrauchten Zeit.
Bei der ersten Antwort sind drei Fristen eingehalten und eine ist überschritten, sechs laufen noch. Das ergibt 75 %. Die beiden Spalten rechts daneben erscheinen nur, wenn es Sammelstörungen gibt. Sie lassen die Meldungen weg, die mit einer Störung geschlossen wurden.Bild in voller Größe öffnen

Zeiterfassung je Ticket

Bearbeiter buchen den Aufwand, den ein Vorgang gekostet hat. Gemeint ist die Arbeit am Ticket und nicht die Anwesenheit einer Person. Eine Stempeluhr ist das hier ausdrücklich nicht. Der ganze Block gehört zu Professional.

1

Erst einschalten, dann buchen

Nur Professional

Als Werkseinstellung ist die Zeiterfassung aus. Solange sie aus ist, gibt es kein Feld, keine Spalte und keine Kachel im Bericht.

Ein totes Feld wäre schlimmer als gar keins. Deshalb verschwindet die Funktion vollständig, statt ausgegraut dazustehen.

Der Schalter steht unter „Settings → General" auf der Karte „Time tracking per ticket". Er heißt „Enable time tracking".

Jedes Team nimmt danach teil. Willst du eines heraushalten, schaltest du es am Team ab. Der Schalter steht unter „Settings → Teams" im Kasten „Team details".

Ein Haus mit einem internen IT-Team und einem Team für Kunden braucht das oft nur beim zweiten.

Schaltest du die Zeiterfassung später wieder aus, bleiben die vorhandenen Einträge lesbar und exportierbar. Sie sind eine Rechnungsgrundlage und kein Komfort. Neu gebucht wird dann nichts mehr.

Die Karte „Time tracking per ticket" unter „Settings → General" mit dem Hauptschalter, der Rundung, den Schnellknöpfen und der Stoppuhr.
Alle Einstellungen der Zeiterfassung auf einer Karte. Der rote Rahmen liegt auf dem Hauptschalter. Unter ihm steht, was ein Ausschalten bedeutet.Bild in voller Größe öffnen
Der Kasten „Team details" mit dem Schalter „Time tracking" und dem erklärenden Satz darunter.
Am Team nimmst du ein einzelnes Team heraus. Der rote Rahmen liegt auf dem Schalter. Vorhandene Einträge bleiben auch dann sichtbar.Bild in voller Größe öffnen
2

Aufwand am Ticket buchen

Nur Professional

Am Ticket steht die Karte „Time spent". Mit „Log time" öffnest du die Eingabe.

Neben dem Feld stehen Schnellknöpfe. Ein Klick auf „30m" bucht dreißig Minuten. Welche Knöpfe dort stehen, legst du in den Einstellungen fest.

Das Feld „Duration" nimmt auch freie Eingaben. „90" sind neunzig Minuten, „1,5h" sind anderthalb Stunden, „1h 30m" ebenfalls. Eine Zahl ohne Einheit sind immer Minuten.

Eine Eingabe, die das System nicht ganz versteht, wird abgelehnt. „1h abends" ergibt keinen Eintrag über eine Stunde, sondern eine Fehlermeldung.

In „What for (optional)" schreibst du, wofür die Zeit war. Der Text reist in den Export mit und steht nicht im Ticket-Verlauf.

Mehrere Bearbeiter buchen auf dasselbe Ticket. Jeder Eintrag trägt seinen Tag, seine Notiz und den Namen dessen, der gearbeitet hat.

Gebucht wird auf einen Tag und nicht auf eine Uhrzeit. Nachtragen für gestern ist der Normalfall, und eine Uhrzeit würde eine Genauigkeit behaupten, die die Eingabe nicht hat.

Die geöffnete Eingabe der Karte „Time spent" mit dem Feld „Duration", den Schnellknöpfen, dem Notizfeld und dem Häkchen „Billable".
Der rote Rahmen liegt auf den Schnellknöpfen. Rechts daneben nimmt das Feld freie Eingaben an. Der Hinweis darunter nennt die erlaubten Formate.Bild in voller Größe öffnen
Die Liste der Zeiteinträge an einem Ticket mit drei Einträgen von zwei Bearbeitern, je mit Datum, Notiz und Name.
Drei Einträge, zwei Bearbeiter, ein Ticket. Der rote Rahmen liegt auf dem Namen und dem Tag. Die Notiz steht darunter.Bild in voller Größe öffnen
3

Die Stoppuhr

Nur Professional

Für lange Sitzungen gibt es eine Uhr am Ticket. „Start timer" startet sie, „Pause" hält sie an.

Die Uhr erzeugt nie selbst einen Eintrag. Sie schlägt die verstrichene Zeit vor, und gespeichert wird erst, wenn du auf „Log" klickst.

Sie ersetzt damit Kopfrechnen und kein Wissen. Ohne sie ist die Funktion vollständig, denn die Handeingabe ist der eigentliche Weg.

Öffnest du ein anderes Ticket, pausiert die laufende Uhr. Am neuen Ticket steht dann, an welchem Ticket sie hängt.

Ein verstecktes Fenster ist keine Pause. Die Uhr läuft weiter, wenn du nur wegklickst.

Gegen die über Nacht vergessene Uhr gibt es eine Höchstlaufzeit. Sie wird gekappt und nie verworfen, und der Bearbeiter erfährt es.

Die Uhr ist als Werkseinstellung aus. Sie steht in den Einstellungen unter „Stopwatch on the ticket".

Die laufende Uhr an der Karte „Time spent" mit dem Stand, „Pause", „Discard" und der Schaltfläche zum Buchen.
Die Uhr läuft. Der rote Rahmen liegt auf der Schaltfläche, die den Stand übernimmt. Bis dahin ist nichts gespeichert.Bild in voller Größe öffnen
4

Abrechenbar oder nicht

Nur Professional

Jeder Eintrag trägt ein Häkchen „Billable". Die Zeit wird nur einmal erfasst, und das Häkchen entscheidet, ob sie auf die Rechnung geht.

Am Ticket stehen deshalb zwei Summen. Links alles Erfasste, rechts die Abrechnungssumme.

Einen eigenen Typ für Kulanz gibt es nicht. Kulanz, Gewährleistung und interne Nacharbeit heißen in jedem Haus anders, und das System kennt nur die eine Unterscheidung, an der Geld hängt.

So buchst du Kulanz: die Zeit ganz normal eintragen, das Häkchen abwählen und den Grund in die Notiz schreiben.

Der Eintrag trägt danach sichtbar „not billable". Die Minuten bleiben in der erfassten Summe, denn die Arbeit hat stattgefunden.

Wer die Zeit gar nicht bucht, verliert genau die Zahl, mit der sich später begründen lässt, warum ein Kunde so wenig berechnet bekommt.

Arbeitest du überwiegend nicht abrechenbar, drehst du die Vorbelegung um. Der Schalter heißt „New entries are billable by default".

Die Karte „Time spent" mit beiden Summen in der Kopfzeile und einem Eintrag, der die Marke „not billable" trägt.
Oben stehen beide Summen nebeneinander. Der rote Rahmen liegt auf dem Eintrag ohne Häkchen. Seine Minuten zählen oben mit und rechts nicht.Bild in voller Größe öffnen
5

Minutengenau oder auf Schrittweite runden

Nur Professional

Als Werkseinstellung wird minutengenau abgerechnet. Wer im Viertelstundentakt abrechnet, stellt zwei Werte ein.

„Rounding increment (minutes)" ist die Schrittweite. Jeder Eintrag wird auf das nächste Vielfache aufgerundet.

„Minimum per entry (minutes)" ist der Sockel. Jeder Eintrag wird mit mindestens diesem Wert berechnet.

Beide zusammen wirken nacheinander. Erst der Sockel, dann die Schrittweite. Bei Sockel 20 und Schrittweite 15 werden aus 5 Minuten 30, weil das Ergebnis beide Bedingungen erfüllen muss.

Unter den beiden Feldern steht ein Beispielsatz mit deinen Werten. Er wird gerechnet und nicht behauptet.

Gerundet wird immer nur der abgerechnete Wert, und zwar je Eintrag. Nie die Summe. Zwei kleine Einträge werden deshalb zweimal aufgerundet.

Die erfasste Zeit bleibt unangetastet. Änderst du die Rundung später, verfälscht das keine alten Daten, denn gerechnet wird beim Anzeigen.

Am Eintrag siehst du beides. Verändert die Rundung den Wert, steht das Ergebnis in Klammern daneben.

Die Felder „Rounding increment" und „Minimum per entry" mit dem gerechneten Beispielsatz und dem Hinweis darunter.
Der rote Rahmen liegt auf dem Beispielsatz. Er rechnet mit den Werten, die darüber stehen. Der Satz darunter sagt, was die Rundung nicht anfasst.Bild in voller Größe öffnen
Ein Zeiteintrag über fünf Minuten, daneben in Klammern der abgerechnete Wert.
Der rote Rahmen liegt auf dem Eintrag, den die Rundung verändert. Links steht, was erfasst wurde, in Klammern, was berechnet wird.Bild in voller Größe öffnen
6

Pflichteintrag vor dem Abschluss

Nur Professional

Ein Dienstleister will oft, dass kein Ticket ohne gebuchte Zeit geschlossen wird. Dafür gibt es einen Schalter.

Er heißt „Require a time entry before resolving or closing" und ist als Werkseinstellung aus.

Er gilt nur, wenn ein Mensch den Status ändert. Ein Bearbeiter ohne Eintrag bekommt eine Meldung und das Ticket bleibt offen.

Automatischer Abschluss, Zusammenführen und Sammelaktionen werden nie blockiert. Sonst gäbe es Tickets, die niemand mehr schließen kann.

Das ist der gefährlichste Schalter dieser Funktion. Schalte ihn erst ein, wenn dein Team wirklich jedes Mal bucht.

Der Schalter „Require a time entry before resolving or closing" mit dem Satz, der die Ausnahmen nennt.
Der rote Rahmen liegt auf dem Schalter. Der Satz darunter nennt die drei Fälle, die nie blockiert werden.Bild in voller Größe öffnen
7

Die Spalte „Zeit" in der Ticketliste

Nur Professional

Die Ticketliste bekommt eine Spalte „Time". Sie zeigt, wie viel an einem Vorgang schon gebucht ist.

Du schaltest sie nicht ein. Sie erscheint, sobald ein Ticket der Liste Zeit trägt.

Auf schmalen Fenstern fällt sie als eine der ersten wieder heraus. Die Liste behält dann die Spalten, ohne die man ein Ticket nicht wiederfindet.

Die Ticketliste mit der Spalte „Time" und Werten an den Tickets, auf die gebucht wurde.
Der rote Rahmen liegt auf der Spalte. Nur die Tickets mit gebuchter Zeit tragen einen Wert.Bild in voller Größe öffnen
8

Die Auswertung

Nur Professional

Erfasste Zeit, die nur am einzelnen Ticket steht, ist keine Abrechnungsgrundlage. Deshalb gibt es auf der Berichtsseite die Karte „Time spent".

Oben stehen vier Zahlen: erfasst, abgerechnet, Zahl der Einträge und die Zahl der Tickets, auf die überhaupt gebucht wurde.

Die letzte Zahl ist die wichtigste nach der Summe. Vierzig Stunden auf drei von fünfhundert Tickets sind keine Auswertung, sondern drei Bearbeiter, die als Einzige buchen.

Darunter folgen die Aufschlüsselungen: nach Anfragendem, nach Team, nach Kategorie und nach Tag.

Dazu je Zusatzfeld eine eigene Tabelle. Das ist der Weg zur Abrechnung nach Firma oder Kostenstelle: du legst ein Zusatzfeld an, trägst es am Ticket ein, und die Auswertung gruppiert danach.

Der Zeitraum oben auf der Seite gilt für den Tag, an dem gearbeitet wurde. Juli-Arbeit an einem Juni-Ticket steht deshalb im Juli-Bericht.

Über den Zahlen steht ein Hinweis, den du ernst nehmen solltest. Sie stammen aus Einträgen von Menschen und aus deinen Rundungsregeln. Sie sind eine Arbeitsgrundlage und keine geprüfte Rechnung.

Die Berichtsseite mit der Karte „Time spent", ihren vier Zahlen und den Tabellen darunter.
Die Karte steht auf der Berichtsseite. Der rote Rahmen zeigt, wo sie liegt.Bild in voller Größe öffnen
Die vier Kacheln der Karte: erfasst, abgerechnet, Einträge und Tickets mit Zeit.
Der rote Rahmen liegt auf der Zahl der Tickets mit Zeit. Sie ordnet die Summe ein, die links daneben steht.Bild in voller Größe öffnen
Die Tabellen „By requester", „By team" und „By category" mit ihren Zeilen, je mit erfasster und abgerechneter Zeit.
Der rote Rahmen liegt auf der Aufschlüsselung nach Kategorie. Jede Zeile nennt beide Summen.Bild in voller Größe öffnen
Die Tabelle zum Zusatzfeld „Cost centre" mit einer Zeile je Kostenstelle.
Je Zusatzfeld eine eigene Tabelle. Der rote Rahmen liegt auf der Aufschlüsselung nach Kostenstelle.Bild in voller Größe öffnen
9

Der Export für die Buchhaltung und für den Kunden

Nur Professional

Unter der Karte stehen drei Schaltflächen. Sie liefern die Einzeleinträge, nicht die Summen von der Seite.

Es sind zwei Empfänger und nicht drei Dateiformate. „Export entries (CSV)" und „Export entries (Excel)" gehen in die Buchhaltung. Beide sind vollständig und werden nie gekürzt.

„Export entries (PDF)" ist der Beleg für einen Menschen. Er geht als Anlage zur Rechnung an den Kunden.

Das PDF ist bei 20.000 Einträgen gedeckelt, und das Dokument sagt es selbst. Eine Rechnung mit mehr Zeilen liest ohnehin niemand.

Alle drei Dateien werden aus derselben Quelle gebaut. Filter, Rundung, Spalten und Kennzahlen stehen einmal, damit die drei nicht auseinanderlaufen können.

Ein nicht abrechenbarer Eintrag hat in der Abrechnungsspalte eine leere Zelle und keine Null. Eine Null würde in einer Pivot-Tabelle mitsummieren.

Die drei Schaltflächen „Export entries (CSV)", „(Excel)" und „(PDF)" mit den Sätzen, die den Unterschied nennen.
Der rote Rahmen liegt auf den drei Schaltflächen. Die Sätze darunter sagen, welche Datei für wen gedacht ist.Bild in voller Größe öffnen
Die erste Seite des erzeugten PDF mit Kopfzeile, Kennzahlen und der Tabelle der Einzeleinträge.
So sieht der Beleg aus, den der Kunde bekommt. Jede Zeile ist ein Eintrag mit Datum, Ticket, Bearbeiter, Notiz und beiden Werten.Bild in voller Größe öffnen
10

Kunden sehen die erfasste Zeit nicht

Nur Professional

Ein Kunde sieht die Zeiteinträge nie, auch nicht an seinem eigenen Ticket.

Das ist keine Einstellung, sondern eine Sperre im Server. Es gibt keinen Schalter, mit dem sie sich öffnen ließe.

Der Grund steht in jedem Eintrag: Notizen sind für das Team geschrieben. Dort steht, was schiefging und wie lange die Fehlersuche gedauert hat.

Andere Systeme dieser Art halten es genauso. Wo Zeit beim Kunden ankommt, kommt sie als Beleg an.

Dafür ist der PDF-Export da. Er geht mit der Rechnung hinaus und nicht ans Ticket im Kundenportal.

Mehr dazu in der Karte: Der Export für die Buchhaltung und für den Kunden

Dasselbe Ticket in der Kundensicht: Beschreibung, Kommentare und Status, aber keine Karte „Time spent".
Dasselbe Ticket, angesehen vom Anfragenden. Die Karte mit der Zeit fehlt vollständig.Bild in voller Größe öffnen
11

Auswertung je Bearbeiter abschaltbar

Nur Professional

Die Auswertung kann zusätzlich zeigen, wer wie viel gebucht hat. Als Werkseinstellung tut sie es nicht.

Zeit je Person ist eine Leistungsangabe. In vielen Betrieben redet die Mitbestimmung darüber mit.

Der Schalter heißt „Per-agent evaluation" und steht in den Einstellungen.

Ist er aus, liefert der Server die Zahlen gar nicht erst aus. Die Tabelle wird nicht ausgeblendet, sondern es gibt sie nicht.

Der Unterschied ist wichtig. Eine Sperre, die nur die Anzeige kennt, ist keine Sperre.

Mehr dazu in der Karte: Kein Anwesenheitsverlauf, keine Auswertung pro Person

Die Auswertung mit den Tabellen nach Team und Tag, ohne eine Tabelle je Bearbeiter.
So sieht die Auswertung als Werkseinstellung aus. Zwischen Kategorie und Tag steht keine Tabelle je Bearbeiter.Bild in voller Größe öffnen
Dieselbe Stelle mit eingeschaltetem Schalter: eine Tabelle „By agent" mit einer Zeile je Bearbeiter.
Dieselbe Stelle, nachdem der Schalter eingeschaltet wurde. Zwischen „By category" und „By day" steht jetzt eine Tabelle je Bearbeiter.Bild in voller Größe öffnen

Auswertungen und Dashboards

Das Dashboard zeigt den Stand eines Teams. Der Bericht beantwortet eine Frage, die du selbst stellst. Beides liest nur, es ändert nie ein Ticket. Bis auf die eigenen Felder gehört der ganze Block zu Basic.

1

Das Dashboard: der Stand auf einen Blick

Oben steht je Status eine Kachel mit der Anzahl. Darunter stehen drei Zahlen für das ganze Team: „Total tickets", „Tickets which are not Closed" und „Avg. resolution time".

Die mittlere Zahl ist die wichtigste. Sie sagt, wie viel Arbeit gerade offen ist.

„Avg. resolution time" bleibt leer, solange kein Ticket gelöst wurde. Ein Strich ist ehrlicher als eine Null.

Die Karte „Top 3 longest open tickets" nennt die drei ältesten offenen Vorgänge mit ihrem Alter. Das sind die Fälle, die sonst niemand mehr anspricht.

Darunter liegen drei Diagramme: „Tickets by status", „Tickets by priority" und „Tickets by category".

Das Dashboard zeigt immer den aktuellen Stand. Einen Zeitraum kannst du hier nicht wählen. Dafür gibt es den Bericht.

Das Dashboard des Teams Helpdesk mit den Statuskacheln oben und den drei Kennzahlen darunter.
Der rote Rahmen liegt auf den drei Kennzahlen. In dieser Beispielwelt hat das Team 22 Tickets, davon 20 nicht geschlossen.Bild in voller Größe öffnen
Die Karte „Top 3 longest open tickets" mit drei Vorgängen und ihrem Alter.
Jeder Eintrag führt mit einem Klick auf das Ticket.Bild in voller Größe öffnen
Die Diagramme „Tickets by status", „Tickets by priority" und „Tickets by category".
Die Kategorien sind die des Teams. Ein anderes Team zeigt hier andere.Bild in voller Größe öffnen
2

Jedes Team hat sein eigenes Dashboard

In der Seitenleiste steht je Team ein eigener Eintrag. Er heißt „Dashboard" und dahinter den Namen des Teams.

Jeder Eintrag zeigt nur die Tickets seines Teams. Die Zahlen, die Kategorien und die ältesten Vorgänge sind deshalb je Team andere.

Die Berechtigung hängt am einzelnen Dashboard. Du kannst einer Rolle den Zugang zum einen Team geben und zum anderen nicht.

Wer kein Recht auf ein Dashboard hat, sieht den Eintrag gar nicht. Ein gesperrter Eintrag, den man trotzdem sieht, wirft nur Fragen auf.

Das Dashboard des Teams Helpdesk, in der Seitenleiste der Eintrag „Dashboard · Helpdesk" hervorgehoben.
Der rote Rahmen liegt auf dem Eintrag in der Seitenleiste. In dieser Beispielwelt zeigt Helpdesk 22 Tickets.Bild in voller Größe öffnen
Dasselbe Dashboard für das Team Network mit anderen Zahlen und anderen Kategorien.
Dieselbe Seite, ein anderes Team. Hier sind es 6 Tickets, und die Kategorien heißen „Wi-Fi" und „Firewall".Bild in voller Größe öffnen
3

Den Bericht erzeugen und filtern

Die Seite „Reports" ist beim Öffnen leer. Es steht nur der Filterkasten da.

Erst der Klick auf „Generate report" rechnet. Das dauert einen Moment, weil alle Bereiche auf einmal berechnet werden.

Das ist Absicht. Ein Bericht, der bei jedem Tastendruck neu rechnet, wäre auf einem großen Bestand nicht zu bedienen.

Danach stehen oben vier Kennzahlen und darunter die Diagramme.

Jedes Diagramm nennt seine Zahlen. Bei den Ringen stehen Anzahl und Anteil in der Legende daneben. Bei den Balken steht die Anzahl über dem Balken.

Im Filterkasten darüber stellst du die Frage. Zur Auswahl stehen der Zeitraum über „From" und „To", das Team, der Status, der Bearbeiter, der Anfragende, der Standort, die Priorität, Haupt- und Unterkategorie sowie der Eingangskanal.

Setzt du mehrere Felder, gelten sie gleichzeitig. „Zeitraum Juli, Team Helpdesk, Priorität High" ist eine einzige Frage.

Der Zeitraum geht nach dem Tag, an dem das Ticket angelegt wurde.

Eine Ausnahme gibt es. Die Zeitauswertung geht nach dem Tag, an dem gearbeitet wurde. Arbeit im Juli an einem Ticket aus dem Juni steht deshalb im Juli-Bericht.

Nach jeder Änderung am Filter musst du wieder auf „Generate report" klicken.

Auf dieser Seite stehen außerdem die Auswertungen anderer Funktionen. Sie erscheinen nur, wenn die Funktion eingeschaltet ist und im gewählten Zeitraum etwas passiert ist.

Erklärt werden sie dort, wo sie hingehören: die Fristen unter „SLA-Kennzahlen im Reporting", die Bewertungen unter „Die Auswertung der Bewertungen", die Verteilung unter „Was die Verteilung getan hat" und der Aufwand unter „Die Zeitauswertung".

Die Berichtsseite direkt nach dem Öffnen: nur der Filterkasten, keine Zahlen.
Der rote Rahmen liegt auf „Generate report". Solange niemand darauf klickt, bleibt die Seite leer.Bild in voller Größe öffnen
Der Filterkasten der Berichtsseite mit Zeitraum, Team, Status, Bearbeiter, Kategorien und Kanal.
Alle Felder gelten gleichzeitig. Leer bedeutet „alle".Bild in voller Größe öffnen
Der erzeugte Bericht mit vier Kennzahlen und den ersten Diagrammen darunter.
In dieser Beispielwelt sind es 28 Tickets. Über jedem Balken steht seine Anzahl, bei den Ringen stehen Anzahl und Anteil daneben.Bild in voller Größe öffnen
4

Nach eigenen Feldern filtern und gruppieren

Nur Professional

Hast du eigene Felder angelegt, stehen sie im Bericht genauso zur Verfügung wie die mitgelieferten.

Jedes eigene Feld bekommt einen Filter im Kasten und ein eigenes Diagramm im Bericht.

Damit lassen sich Fragen beantworten, die nur in deinem Haus gestellt werden. „Wie viele Tickets gehen auf welche Kostenstelle?" ist so eine Frage.

Die Namen der Diagramme sind die Namen deiner Felder. Sie werden nicht übersetzt, weil sie aus deiner Installation kommen.

Wo du eigene Felder anlegst, steht unter „Benutzerdefinierte Felder".

Zwei Diagramme aus eigenen Feldern: „Asset tag" und „Cost centre".
In dieser Beispielwelt gibt es die Felder „Asset tag" und „Cost centre". In deiner Installation stehen hier deine eigenen.Bild in voller Größe öffnen
5

Welche Spalten der Bericht zeigt

Unter „Settings → Report Settings" legst du fest, welche Felder der Bericht anbietet.

Die Seite hat drei Abschnitte: „Admin", „Agent" und „Customer". Jeder Abschnitt trägt dieselbe Liste mit eigenen Schaltern.

Ein Feld, das du hier abschaltest, verschwindet für diese Rolle aus dem Filter und aus dem Export.

Als Werkseinstellung sehen Administratoren und Bearbeiter alles. Kunden sehen weniger, weil sie den Bearbeiter, den Standort und die Priorität nicht brauchen.

Deine eigenen Felder stehen unter „Custom fields" in derselben Liste.

Die Seite „Report Settings" mit den drei Abschnitten „Admin", „Agent" und „Customer".
Der rote Rahmen liegt auf dem Abschnitt „Customer". Jede Rolle hat ihre eigene Liste.Bild in voller Größe öffnen
6

Kunden ziehen ihren eigenen Bericht

Ein Kunde kann denselben Bericht öffnen wie ein Bearbeiter. Er sieht darin nur seine eigenen Tickets.

Die Begrenzung liegt im System und nicht im Filter. Ein Kunde kann sie auch dann nicht umgehen, wenn er die Adresse von Hand eingibt.

Freigeschaltet wird das am Team. Der Schalter steht unter „Settings → Teams" und heißt „Has permission to view their own Tickets in the Dashboard and in Reports for this Team".

Als Werkseinstellung ist er aus. Solange er aus ist, findet ein Kunde weder das Dashboard noch die Berichte.

Welche Spalten der Kunde sieht, kommt aus dem Abschnitt „Customer" der Berichtseinstellungen.

Auch die Ausgabe als Datei steht ihm offen. Ein Kunde kann sich seine eigenen Tickets als CSV, Excel oder PDF herunterladen.

Der Schalter am Team, der einer Kundin Dashboard und Berichte freigibt.
Der Schalter steht im Kasten „Team details". Er gilt für dieses eine Team.Bild in voller Größe öffnen
Die Berichtsseite aus dem Konto einer Kundin, mit weniger Filtern und kleineren Zahlen.
Dieselbe Seite aus dem Konto von Julia Becker. In dieser Beispielwelt sieht sie 8 Tickets statt 28, und der Filter für den Bearbeiter fehlt.Bild in voller Größe öffnen
7

Als CSV, Excel oder PDF ausgeben

Unter dem Filterkasten stehen drei Schaltflächen: „CSV export", „Excel export" und „PDF export".

Alle drei geben aus, was gerade auf dem Bildschirm steht. Der Filter gilt also mit.

Die Excel-Datei hat zwei Tabellenblätter. Auf „Key figures" stehen die Kennzahlen, auf „Tickets" die einzelnen Vorgänge.

Zahlen und Diagramme sind immer dabei. Die Liste der einzelnen Tickets nur dann, wenn du den Haken „Include ticket table in export" setzt.

Setzt du den Haken, steht darunter die echte Ticketzahl und die geschätzte Seitenzahl.

Bei sehr vielen Tickets kommt eine rote Warnung dazu. Sie sagt, dass der Export eine Weile dauern kann.

CSV und Excel enthalten alle Zeilen. Das PDF endet bei 20.000 Tickets und schreibt das ins Dokument.

Die Grenze steht auch schon auf der Seite, bevor du exportierst. Eine Grenze, die man erst im fertigen Dokument erfährt, kommt zu spät.

Die drei Ausgabeschaltflächen und darunter der Haken für die Ticket-Tabelle.
Der rote Rahmen liegt auf dem Haken. Erst wenn er gesetzt ist, erscheint die Zeile mit der Ticketzahl. In dieser Beispielwelt sind es 28 Tickets und rund 4 Seiten.Bild in voller Größe öffnen
8

Im PDF stehen die Zahlen neben den Diagrammen

Das PDF ist zum Vorlegen gedacht. Es enthält dieselben Diagramme, die auf dem Bildschirm stehen.

Neben jedem Diagramm steht die Zahl, aus der es entstanden ist, und der Anteil in Prozent.

Das ist der Grund, warum es sie gibt. Ein Balken lässt sich ansehen, aber nicht nachrechnen.

Auf dem Bildschirm zeigt der Mauszeiger dieselbe Zahl. Auf einem ausgedruckten Blatt gibt es keinen Mauszeiger.

Das Dokument nennt oben den Zeitraum und den Tag, an dem es erstellt wurde.

Eine Seite des erzeugten PDF mit einem Diagramm und den Zahlen daneben.
Das Dokument, wie der Empfänger es bekommt. Neben jedem Balken stehen die Anzahl und der Anteil.Bild in voller Größe öffnen

Zufriedenheitsabfrage (CSAT)

Nach dem Schließen fragst du deine Kunden, wie es gelaufen ist. Der ganze Block gehört zu Professional.

1

Die Umfrage nach dem Schließen

Nur Professional

Voraussetzung: Zwei Dinge müssen stehen, sonst passiert nichts. Der Mailversand muss eingerichtet sein. Und unter „Settings → Security" muss die öffentliche Adresse dieser Installation stimmen. Aus ihr baut das System den Link in der Mail. Ist dort die falsche Adresse hinterlegt, verschickt das System die Umfrage trotzdem, und der Kunde landet auf einer Seite, die es nicht gibt.

Wird ein Ticket geschlossen, bekommt der Anfragende eine E-Mail mit fünf Sternen. Jeder Stern ist ein eigener Link. Ein Klick ist die ganze Antwort.

Die Mail geht nicht sofort hinaus. Nach dem Schließen wartet das System eine Stunde. Danach verschickt ein Dienst die fälligen Umfragen im Zehn-Minuten-Takt. Die Stunde ist Absicht. Ein Ticket, das gleich wieder geöffnet wird, soll keine Umfrage auslösen.

Je Ticket gibt es genau eine Umfrage. Auch wenn ein Ticket später wieder geöffnet und erneut geschlossen wird, fragt das System kein zweites Mal.

Der Link braucht kein Kundenkonto. Er gilt 30 Tage. Bis dahin kann der Kunde seine Bewertung ändern, etwa nach einem Fehlklick auf den falschen Stern.

Ein Kommentar ist freiwillig. Wer nur einen Stern anklickt, hat bewertet. Wer etwas dazuschreiben will, findet auf der Seite ein Feld dafür und bestätigt mit „Update rating".

Die Seite zeigt nur Nummer und Titel des Tickets. Beschreibung, Kommentare und Verlauf stehen dort nicht. Der Link ist ein Bewertungsrecht und kein Leserecht. Er kann weitergeleitet werden oder in einem gemeinsamen Postfach landen.

Der Klick aus der Mail schreibt die Bewertung erst, wenn die Seite geladen ist. Das ist der Grund, warum Virenscanner und Vorschaufunktionen deine Tickets nicht bewerten. Sie rufen die Adresse ab, führen aber kein JavaScript aus. Für den Menschen bleibt es trotzdem ein Klick.

Die abgegebene Bewertung steht am Ticket. Sehen können sie die Bearbeiter und Administratoren des zuständigen Teams. Der Kunde sieht sie dort nie, auch nicht seine eigene.

Nicht jedes geschlossene Ticket wird gefragt. Ohne Adresse des Anfragenden geht keine Mail hinaus. Zusammengeführte Mehrfachmeldungen und die Meldungen an einer Sammelstörung bleiben ebenfalls außen vor. Beim Auflösen einer Sammelstörung schließt ein einziger Klick alle angehängten Meldungen. Ohne diese Ausnahme ginge an jeden Melder eine Umfrage zu derselben Bearbeitung.

Die Umfragemail im Postfach der Kundin mit fünf Sternzeilen und dem Link zur Umfrageseite.
So kommt die Umfrage beim Kunden an. Jede der fünf Zeilen ist ein eigener Link, darunter steht der Weg zur Seite mit dem Kommentarfeld. Die Adresse in den Links ist die, die du unter „Security" hinterlegt hast.Bild in voller Größe öffnen
Die Bewertungsseite mit fünf Sternen, gesetzter Bewertung, Kommentarfeld und der Schaltfläche „Update rating".
Die Seite nach dem Klick auf den fünften Stern. Die Bewertung ist gespeichert, das Kommentarfeld bleibt offen. Zu sehen sind nur Nummer und Titel des Tickets.Bild in voller Größe öffnen
Die Bewertung am Ticket mit fünf Sternen und dem Kommentar der Kundin.
Dasselbe Ergebnis am Ticket. Der rote Rahmen liegt auf der Bewertung. Sie steht hier für das Team, nicht für den Kunden.Bild in voller Größe öffnen
2

Einschalten und begrenzen

Nur Professional

Die Umfrage hat genau eine Stelle zum Einstellen. Sie liegt unter „Settings → General" in der Karte „Customer Satisfaction Score (CSAT)" und trägt drei Bedienelemente. Einen eigenen Einstellungsbereich gibt es nicht.

„Send satisfaction surveys" schaltet den Versand ein. Als Werkseinstellung ist er aus. Gefragt werden nur Tickets, die nach dem Einschalten geschlossen wurden. Sonst bekäme dein gesamter Altbestand auf einen Schlag eine Mail.

Schaltest du wieder aus, bleiben die vorhandenen Bewertungen sichtbar. Es geht nur nichts Neues mehr hinaus.

Über den Schaltern steht die Adresse, aus der die Links gebaut werden. Sie steht dort nur zum Nachsehen. Ändern kannst du sie an der einen Stelle, an der sie gepflegt wird, und der Hinweis daneben führt dich dorthin.

Der Schalter „Per-agent evaluation" in der Mitte gehört zum Bericht. Was er dort tut und warum er als Werkseinstellung aus ist, steht in der Karte über die Bewertungen.

„At most one survey per requester within" begrenzt, wie oft derselbe Mensch gefragt wird. Als Werkseinstellung sind es 7 Tage. Wer in dieser Zeit mehrere Tickets meldet, bekommt trotzdem nur eine Umfrage.

Mit 0 fragst du bei jedem geschlossenen Ticket. Für einen internen Helpdesk ist das meist zu viel, weil dort dieselben Leute immer wieder melden. Ein Kundendienst mit vielen verschiedenen Absendern erreicht die Grenze dagegen selten.

Die Umfrage ist bewusst schlicht gehalten. Die Skala ist fest auf eins bis fünf Sterne eingestellt, die Wartezeit von einer Stunde und die Gültigkeit von 30 Tagen ebenso. Mit zwei verschiedenen Skalen im Bestand würde der Bericht Unvergleichbares mitteln.

Mehr dazu in der Karte: Der Bericht über die Bewertungen

Die Karte „Customer Satisfaction Score (CSAT)" mit zwei Schaltern und dem Zahlenfeld für die Begrenzung.
Die ganze Einstellung auf einer Karte. Die roten Rahmen liegen auf den beiden Schaltern und auf dem Feld für die Begrenzung. Darüber steht die Adresse, aus der die Links gebaut werden.Bild in voller Größe öffnen
Die Karte „Public address of this installation" mit dem Adressfeld und der Zeile „Currently in use".
Die Adresse selbst pflegst du unter „Settings → Security". Die Zeile darunter sagt dir, welche Adresse gerade benutzt wird und woher sie stammt.Bild in voller Größe öffnen
3

Der Bericht über die Bewertungen

Nur Professional

Unter „Reports" steht die Zufriedenheit als eigener Abschnitt „Customer satisfaction (CSAT)". Er erscheint im selben Bericht wie alles andere und richtet sich nach denselben Filtern, also nach Zeitraum, Team, Kategorie und Bearbeiter.

Oben stehen fünf Kacheln. „Average score" ist der Durchschnitt der Sterne. „Satisfaction rate (4-5 stars)" sagt, welcher Anteil zufrieden war. „Response rate" ist der Rücklauf. „Surveys sent" zählt die verschickten Umfragen. Unter den beiden Quoten steht klein der Bruch, aus dem sie entstanden sind.

„Closed without survey" ist die fünfte Kachel. Sie zählt die geschlossenen Tickets, die gar nicht gefragt wurden, und darunter steht, wie viele geschlossene es insgesamt waren. Ohne diese Zahl hältst du eine Quote für das Bild deiner Kunden. Sie beruht dann auf einem Ausschnitt, den du nicht siehst.

Die wichtigste Zahl ist nicht der Durchschnitt, sondern der Rücklauf. Ein guter Schnitt aus wenigen Antworten sagt wenig über deine Kunden.

Darunter steht die Verteilung. Für jede Sternezahl von fünf bis eins zeigt ein Balken, wie oft sie vergeben wurde, und die Zahl steht daneben. Danach folgt „Trend" mit einer Zeile je Tag, an dem jemand geantwortet hat. Dort stehen das Datum, der Durchschnitt des Tages als Balken und die Zahl der Antworten. Den Abschluss machen „By agent" mit einer Zeile je Bearbeiter und „Latest comments" mit den zuletzt geschriebenen Kommentaren im Wortlaut. Eine Aufschlüsselung „By team" kommt dazu, sobald mehr als ein Team bewertete Tickets hat.

Die Aufschlüsselung je Bearbeiter kannst du abschalten. Der Schalter „Per-agent evaluation" steht als Werkseinstellung aus. Bewertungen je Person sind Leistungs- und Verhaltensdaten. In vielen Betrieben redet die Mitbestimmung darüber mit, und bei Anbietern aus der Cloud lässt sich diese Auswertung oft gar nicht abstellen.

Der Schalter wirkt am Server und nicht nur in der Anzeige. Steht er aus, fehlt die Aufschlüsselung auch im Export.

Die einzelne Bewertung am Ticket bleibt davon unberührt. Sie sieht das Team weiterhin. Der Schalter regelt die Auswertung über Personen und nicht die Anzeige am einzelnen Vorgang.

Im Filter „Satisfaction" grenzt du den Bericht auf Bewertungen ein. „Rated only" zeigt nur bewertete Tickets, „Not rated" nur unbewertete. Mit „Score from" und „Score to" siehst du zum Beispiel alle Tickets mit einem oder zwei Sternen. Der Filter wirkt auf die Tabelle und auf beide Exporte.

Der Abschnitt „Customer satisfaction (CSAT)" im Bericht mit fünf Kennzahlen und der Verteilung der Sterne.
Die fünf Kacheln des Abschnitts. Der rote Rahmen liegt auf „Closed without survey", der Zahl, die den Rücklauf einordnet.Bild in voller Größe öffnen
Der Abschnitt „Trend" mit einer Zeile je Tag, dem Durchschnitt als Balken und der Zahl der Antworten.
Der Verlauf über die Zeit. Je Tag stehen das Datum, der Durchschnitt als Balken mit der Zahl daneben und rechts die Zahl der Antworten dieses Tages. Im Beispiel kamen beide Antworten am selben Tag, deshalb steht dort eine Zeile.Bild in voller Größe öffnen
Die Aufschlüsselung „By agent" mit einer Zeile je Bearbeiter und die zuletzt geschriebenen Kommentare.
Die Aufschlüsselung je Bearbeiter, dazu die Kommentare im Wortlaut. Diesen Teil des Berichts kannst du abschalten.Bild in voller Größe öffnen
4

Eine schlechte Bewertung als Auslöser

Nur Professional

Eine Bewertung kann eine Regel auslösen. Im Regeleditor unter „Settings → Automation" gibt es dafür die Bedingung „Satisfaction rating (CSAT)". Daneben wählst du „is at most", „is at least", „is" oder „is not". Im dritten Feld stehen die Sterne, von einem bis fünf, mit der Zahl daneben.

Der übliche Fall ist „is at most 2". Über der Regel steht dann der Satz, den der Editor mitschreibt: „When a ticket was rated 2 stars or fewer, then send an e-mail to the assignee."

Eine Zeitbedingung braucht diese Regel nicht. Der Block „WHEN" bleibt leer. Damit ist sie die Ausnahme unter den Regeln, denn alle anderen warten darauf, dass eine Weile nichts passiert ist. Diese hier wartet auf ein Ereignis.

Als Aktion steht dir alles zur Verfügung, was eine Regel sonst auch kann. Du kannst eine Mail verschicken, die Priorität heben, das Ticket einem anderen Team geben oder eine Wiedervorlage setzen.

Eine Sache arbeitet hier anders als sonst. Regeln lassen geschlossene Tickets normalerweise in Ruhe. Eine Bewertung kommt aber fast immer an einem geschlossenen Ticket an. Eine Regel mit dieser Bedingung erreicht deshalb auch geschlossene Tickets. Alle anderen Regeln tun das weiterhin nicht.

Auf ein unbewertetes Ticket trifft die Bedingung nie zu. Das gilt auch für „is not". Andernfalls träfe „nicht fünf Sterne" deinen gesamten unbewerteten Bestand. Wer wissen will, wie viele nicht geantwortet haben, findet das im Bericht als Rücklaufquote.

Die Regel greift einmal je Bewertung. Unter der Regel öffnet „Log" die Tabelle „What this rule did" mit einer Zeile je Ticket. Dort siehst du, wann sie gelaufen ist und was sie getan hat.

Der Regeleditor mit der Bedingung „Satisfaction rating (CSAT) is at most 2" und dem Satz darüber.
Die Bedingung im Editor. Die roten Rahmen liegen auf der Bedingung und auf dem Satz darüber. Der Satz schreibt sich mit jeder Änderung neu.Bild in voller Größe öffnen
Die Tabelle „What this rule did" mit einer Zeile für das schlecht bewertete Ticket.
Das Protokoll der Regel. Die Zeile zeigt das Ticket, den Zeitpunkt und die ausgeführte Aktion.Bild in voller Größe öffnen

Wissensdatenbank

Der Teil, der Tickets verhindert: einmal aufgeschriebene Lösungen, die dein Team wiederfindet und die dem Anfragenden schon beim Tippen vorgeschlagen werden. Alles in diesem Block gehört zu Basic.

1

Themen-Kacheln mit Artikeln und Anhängen

Die Wissensdatenbank erreichst du über „Knowledge Base" in der linken Leiste. Die Übersicht besteht aus Kacheln, eine je Thema. Die Zahl oben rechts auf der Kachel ist die Anzahl der veröffentlichten Einträge, darunter stehen Name und Beschreibung des Themas. Ein Klick auf die Kachel führt zur Liste der Einträge, jeder mit Verfasser, Änderungsdatum und den ersten Zeilen des Textes.

Die Themen selbst legst du nicht hier an, sondern unter „Settings → Knowledge Base". Wie das geht, steht in der Karte „Sichtbarkeit je Thema". Ohne ein einziges Thema steht auf der Übersicht nur ein Hinweis. Ein Eintrag braucht immer ein Thema.

Geschrieben wird mit „New entry" auf einer Themenseite. Der Editor verlangt drei Dinge: „Title", „Topic" und „Content". Es ist derselbe Editor wie im Ticket, mit derselben Werkzeugleiste: „Bold", „Italic", „Underline", „Strikethrough", „Text color", „Highlight color", „Bullet list", „Numbered list", „Quote", „Link" und „Clear formatting". Ein Link entsteht wie im Ticket: Text markieren, „Link" klicken, Adresse eintragen. Erlaubt sind Web- und Mail-Adressen, also http, https und mailto. „Save" bleibt grau, solange Titel oder Thema fehlen. Ein Eintrag ohne Text wird abgelehnt: Anhänge allein sind kein Eintrag.

Bilder kommen wie im Ticket über die Zwischenablage in den Text: Bildschirmfoto machen, mit Strg+V in den Editor einfügen. Im Text steht danach eine Marke wie „[inline-image:1]". Beim Speichern lädt das System das Bild hoch und zeigt es genau an dieser Stelle. Zusätzlich taucht es unten in „Attachments" auf. Dort löschst du es auch wieder. Eingefügt werden können PNG, JPEG und GIF.

Dateien hängst du erst an, wenn der Eintrag gespeichert ist. Auf der Seite des Eintrags steht unten die Karte „Attachments" mit „Upload file". Erlaubte Dateitypen und Größe sind dieselben wie beim Ticket, also bis 50 MB je Datei. Wer eine Datei hochgeladen hat, kann sie auch wieder entfernen. Administratoren dürfen jede entfernen.

Administratoren dürfen immer schreiben. Bearbeiter dürfen es, solange der Schalter in den Einstellungen es erlaubt. Mehr dazu steht in der Karte „Freigabe". Kunden lesen nur. Löschen darf ein Administrator jeden Eintrag. Der Verfasser darf seinen eigenen löschen, solange er noch auf die Freigabe wartet.

Die Übersichtsseite der Wissensdatenbank mit drei Themen-Kacheln und dem rot umrandeten Menüpunkt „Knowledge Base".
Der Weg hinein: „Knowledge Base" in der linken Leiste. Jede Kachel ist ein Thema. Die Zahl nennt die veröffentlichten Einträge, das gelbe Fähnchen die wartenden.Bild in voller Größe öffnen
Der Editor „New entry" mit den Feldern Title und Topic, der Werkzeugleiste des Editors und der grauen Schaltfläche „Save".
Titel, Thema, Inhalt. Solange kein Thema gewählt ist, bleibt „Save" grau. Im roten Rahmen steht die Auswahl, die hier noch fehlt.Bild in voller Größe öffnen
Ein Eintrag der Wissensdatenbank mit formatiertem Text, einem eingefügten Bild des Druckerdisplays, nummerierter Liste und der Karte „Attachments" mit zwei Dateien.
Ein fertiger Eintrag: Kopfzeile mit Thema, Verfasser und Freigabe, darunter der Text mit einem eingefügten Bild. Unten stehen beide Dateien: die Kurzanleitung zum Herunterladen und das eingefügte Bild.Bild in voller Größe öffnen
3

Sichtbarkeit je Thema: nur intern oder auch für Kunden

Voraussetzung: Die Sichtbarkeit hängt am THEMA, nicht am einzelnen Eintrag. Ein interner Hinweis in einem kundensichtbaren Thema ist für Kunden lesbar, sobald er veröffentlicht ist. Plane die Themen danach. Einen Eintrag verschiebst du notfalls über „Edit" in ein anderes Thema.

Themen pflegst du unter „Settings → Knowledge Base" in der Karte „Topics". Jede Zeile trägt Name, Beschreibung, eine Sortierziffer für die Reihenfolge der Kacheln, den Schalter „Visible to customers" und zwei Schaltflächen zum Speichern und Löschen. Gespeichert wird je Zeile, nicht die ganze Karte.

Steht der Schalter aus, sehen nur Bearbeiter und Administratoren das Thema, seine Einträge und deren Anhänge. Ein Kunde bekommt die Kachel gar nicht erst zu sehen und findet die Einträge auch über die Suche nicht. Steht er an, sehen Kunden das Thema und darin die veröffentlichten Einträge. Entwürfe bleiben trotzdem unsichtbar.

Ein neues Thema legst du in der gestrichelten Zeile darunter an: Name eintragen, Sichtbarkeit wählen, „Add topic". Löschen lässt sich ein Thema nur, solange es leer ist. Sonst würdest du seine Einträge mitlöschen, ohne sie zu sehen.

Die Karte „Topics" mit drei Themen. Der Schalter „Visible to customers" ist beim ersten Thema an und beim Thema „Internal runbooks" aus.
Der Unterschied steht in den beiden roten Rahmen: „Printing" ist für Kunden freigegeben, „Internal runbooks" nicht. Gespeichert wird je Zeile mit dem orangen Knopf rechts.Bild in voller Größe öffnen
4

Lösungsvorschläge schon beim Anlegen eines Tickets

Sobald im Formular „Create new ticket" drei Zeichen im Feld „Title" stehen, sucht das System im Hintergrund und blendet den Kasten „Possible solutions from the knowledge base" ein. Darin stehen bis zu fünf Einträge, die zum Titel passen. Wer dort seine Antwort findet, legt kein Ticket an. Das ist der ganze Zweck.

Gesucht wird nur nach dem TITEL, nicht nach der Beschreibung. Es gilt dieselbe Regel wie in der Suche: Ein Vorschlag muss mindestens die Hälfte der Wörter des Titels enthalten. Je genauer der Titel, desto weniger und desto passendere Vorschläge. Ein Klick auf einen Vorschlag öffnet ihn in einem neuen Tab, damit das halb ausgefüllte Formular nicht verloren geht. „Open knowledge base" ganz unten führt in die vollständige Übersicht.

Auch hier gilt die Sichtbarkeit: Einem Kunden werden nur veröffentlichte Einträge kundensichtbarer Themen vorgeschlagen. Als Bearbeiter siehst du zusätzlich interne Themen und Einträge, die noch auf ihre Freigabe warten.

Das Feld „Title" im Formular für ein neues Ticket mit dem eingeblendeten Kasten „Possible solutions from the knowledge base" und den Vorschlägen darunter.
Getippt ist nur der Titel. Der Kasten darunter erscheint von selbst. Oben stehen die Einträge, die am besten zum Titel passen.Bild in voller Größe öffnen
5

Aus einem gelösten Ticket einen Eintrag machen

Voraussetzung: Übernommen wird ALLES: Beschreibung und sämtliche Kommentare, auch die internen. Der Text ist eine Kopie und kein Verweis. Lies ihn durch und entferne Namen, Telefonnummern, E-Mail-Adressen und Bestellnummern, bevor du speicherst. Danach kann ihn jeder lesen, der das Thema sehen darf.

Oben rechts auf jedem Ticket steht „Add to knowledge base". Die Schaltfläche öffnet den Editor für einen neuen Eintrag, vorausgefüllt mit dem Titel des Tickets und seinem gesamten Verlauf: die Beschreibung als erster Absatz, jeder Kommentar darunter als Zitat.

Damit ist noch nichts gewonnen, das ist erst der Rohstoff. Mach daraus eine Anleitung: Kürze auf das, was beim nächsten Mal hilft, und schreibe den Titel um, wenn er nach einem Einzelfall klingt. Aus „Drucker im 2. Stock zieht zwei Blatt" wird so „Papierstau beheben".

Ein Thema ist nicht vorbelegt, das wählst du selbst. Gespeichert wird der Eintrag wie jeder andere: als Administrator sofort veröffentlicht, als Bearbeiter zur Freigabe. Am Eintrag bleibt danach der interne Verweis „Source: Ticket #1" stehen. Er führt zurück zum Vorgang und ist für Kunden nicht sichtbar.

Ein Ticket mit der rot umrandeten Schaltfläche „Add to knowledge base" oben rechts.
Die Schaltfläche steht auf jedem Ticket oben rechts, unabhängig vom Status. Gedacht ist sie für den Fall, der gelöst ist.Bild in voller Größe öffnen
Der Editor „New entry", vorausgefüllt mit Titel und Verlauf des Tickets, darüber der rot umrandete Hinweis auf das Quell-Ticket.
Der Hinweis im roten Rahmen sagt, worauf es ankommt. Im Text darunter steht die interne Notiz mit der Bestellnummer. Genau das gehört vor dem Speichern heraus.Bild in voller Größe öffnen
6

Freigabe: Einträge eines Bearbeiters warten auf den Administrator

Ob Bearbeiter überhaupt schreiben dürfen, entscheidet der Schalter „Agents can create entries" unter „Settings → Knowledge Base". Als Werkseinstellung steht er an. Steht er aus, verschwindet der Knopf „New entry", und auch der direkte Aufruf des Editors wird abgelehnt.

Zustände gibt es genau zwei: „Awaiting review" und „Published". Einen Entwurf, an dem du in Ruhe schreibst, ohne dass jemand ihn sieht, gibt es nicht. Wer schreibt, bestimmt den Zustand. Ein Administrator veröffentlicht sofort. Ein Bearbeiter erzeugt einen Eintrag mit dem Vermerk „Awaiting review". Er ist für Bearbeiter und Administratoren sichtbar, für Kunden nicht. Auf der Kachel des Themas erscheint dafür das gelbe Fähnchen „1 awaiting review".

Die Administratoren bekommen zusätzlich eine E-Mail, sobald ein Eintrag zur Freigabe ansteht. Sie ist eine Zugabe und keine Voraussetzung. Ohne eingerichteten Mailversand findest du die offenen Freigaben über das Fähnchen. Freigegeben wird auf der Seite des Eintrags mit „Approve & publish". Danach steht dort, wer freigegeben hat.

Ändert ein Bearbeiter später einen veröffentlichten Eintrag, geht dieser zurück in die Freigabe. Die Änderung ist erst nach dem nächsten „Approve & publish" wieder für Kunden sichtbar. Wer bereits wartet und noch einmal speichert, löst keine zweite E-Mail aus.

Die Einstellungsseite der Wissensdatenbank mit dem rot umrandeten Schalter „Agents can create entries".
Der Schalter steht ganz oben auf „Settings → Knowledge Base". Der Satz daneben sagt, was daran hängt: Einträge von Bearbeitern warten auf die Freigabe.Bild in voller Größe öffnen
Ein Eintrag mit dem Vermerk „Awaiting review" und der rot umrandeten Schaltfläche „Approve & publish".
Der Eintrag stammt vom Bearbeiter Marco Rossi und wartet. Ein Klick auf „Approve & publish" macht ihn für alle sichtbar, die das Thema sehen dürfen.Bild in voller Größe öffnen
7

Änderungsverlauf der Wissensdatenbank

Unter „Settings → Knowledge Base" steht ganz unten die Karte „History". Sie führt die letzten 200 Vorgänge, das Neueste oben: was passiert ist, welcher Eintrag oder welches Thema betroffen war, wer es getan hat und wann.

Aufgezeichnet werden sieben Vorgänge: Eintrag angelegt, geändert, freigegeben und gelöscht sowie Thema angelegt, geändert und gelöscht. Ein gelöschter Eintrag verschwindet damit nicht spurlos. Die Zeile bleibt stehen, auch wenn es den Eintrag nicht mehr gibt.

Zwei Zeilen auf einmal sind kein Fehler. Legt ein Administrator einen Eintrag an, steht dort „Entry created" und unmittelbar darüber „Entry approved". Er veröffentlicht ohne den Umweg über die Freigabe. Bei einem Bearbeiter steht zunächst nur „Entry created". Die Freigabe kommt später und mit dem Namen des Administrators.

Den Verlauf sieht nur, wer die Einstellungsseite der Wissensdatenbank öffnen darf. Als Werkseinstellung sind das die Administratoren. Es ist ein Verlauf über die ganze Wissensdatenbank, nicht einer je Eintrag.

Die Karte „History" mit Zeilen wie „Entry created", „Entry approved" und „Topic created", je mit Name und Zeitpunkt.
Ganz oben steht der Eintrag des Bearbeiters, der noch auf Freigabe wartet. Er hat noch keine Zeile „Entry approved". Darunter stehen die Einträge des Administrators, jeweils mit beiden Zeilen.Bild in voller Größe öffnen

Sicherung & Wiederherstellung

Für die Sicherung gibt es eine eigene Anwendung. Sie wird mitgeliefert und bei der Installation eingerichtet, du musst dafür nichts einkaufen und nichts einstellen. Dieser Block zeigt, was sie sichert, wann sie läuft und wie du im Ernstfall alles zurückholst. Der ganze Block gehört zu Basic.

1

Die Anwendung für Sicherung und Wiederherstellung

Die Anwendung heißt „Ticket System Backup & Restore". Sie liegt neben dem Ticket-System und hat eine eigene Verknüpfung auf dem Desktop.

Es gibt sie für Windows und für Linux. Sie ist dieselbe Anwendung, nur für das jeweilige Betriebssystem gebaut.

Sie hat fünf Reiter. „Restore" listet die vorhandenen Sicherungen, „Create Backup" legt eine neue an, „Schedule" regelt den Zeitplan, „Settings" zeigt die Pfade und „Log" das Protokoll.

Die Einstellungen sind bereits ausgefüllt. Die Anwendung sucht sich beim ersten Start selbst, wo das Ticket-System liegt.

Der Ordner für die Sicherungen steht unter „Backup directory". Du kannst ihn ändern, zum Beispiel auf ein anderes Laufwerk.

Der Reiter „Restore" mit zwei Sicherungen, je mit Zeitpunkt, Größe und Art.
Der rote Rahmen liegt auf der Liste. In der Spalte „Type" steht, ob die Sicherung vom Zeitplan kam oder von Hand angelegt wurde.Bild in voller Größe öffnen
Der Reiter „Settings" mit Ordner, Datenbank und den drei Datenträgern.
Der rote Rahmen liegt auf dem Namen der Datenbank. Darunter stehen die Datenträger, die mitgesichert werden.Bild in voller Größe öffnen
2

Der Zeitplan läuft ab der Installation

Voraussetzung: Unter Windows braucht das Eintragen eines Zeitplans Administratorrechte. Ohne sie legt die Anwendung eine Aufgabe an, die nur bei angemeldetem Benutzer läuft, und sagt es dir.

Die Installation richtet die tägliche Sicherung selbst ein. Sie läuft um 23:00 Uhr nach der Zeit des Servers.

Der Zeitplan liegt im Betriebssystem. Unter Windows ist das die Aufgabenplanung, unter Linux der Cron-Dienst. Es läuft also kein zusätzlicher Dienst nur für die Sicherung.

Die Sicherung braucht keinen angemeldeten Benutzer. Auf einem Server, an dem sich nie jemand anmeldet, läuft sie trotzdem.

Die Zeile unter den Schaltflächen sagt dir, ob die Aufgabe im Betriebssystem wirklich steht. Ein gesetztes Häkchen sagt nur, was gespeichert wurde.

Aufbewahrt wird in fünf Staffeln: 14 Tage, 4 Wochen, 12 Monate, 4 Quartale und 5 Jahre. Eine Sicherung bleibt, solange sie in einer dieser Staffeln die jüngste ihres Zeitraums ist.

Gezählt werden Kalendertage, nicht Dateien. Zwei Sicherungen an einem Tag sind ein Tag.

Sicherungen, die du von Hand anlegst, werden nie automatisch gelöscht. Dafür steht die 0 bei „Keep manual".

Änderst du den Zeitplan, bleibt deine Änderung bei einem Update erhalten. Die Installation setzt ihn nur, wenn noch keiner da ist.

Der Reiter „Schedule" mit angehaktem „Daily" und der Uhrzeit 23:00.
Die roten Rahmen liegen auf „Daily" und auf der Uhrzeit. Der Satz darüber nennt beide Wege: Aufgabenplanung und Cron.Bild in voller Größe öffnen
Die Zeile „Registered with the operating system: yes (Daily)" unter den Schaltflächen.
Diese Zeile wird bei jedem Start neu geprüft. Steht dort „NO", läuft nichts von selbst — dann hilft „Apply schedule" als Administrator.Bild in voller Größe öffnen
Die sechs Felder der Aufbewahrung: 14, 4, 12, 4, 5 und 0.
Der rote Rahmen liegt auf den Staffeln. „Keep manual (0 = keep all)" heißt: von Hand angelegte Sicherungen bleiben.Bild in voller Größe öffnen
3

Was in einer Sicherung steckt

Eine Sicherung enthält alles, was den Zustand deines Systems ausmacht. Das sind die Datenbank, die Datei-Anhänge, das Archiv und die Schlüssel.

Die Schlüssel sind der Punkt, den man leicht übersieht. Mit ihnen werden gespeicherte Zugangsdaten entschlüsselt, etwa die deines Mailkontos. Ohne sie käme eine Wiederherstellung mit toten Zugangsdaten zurück.

Jede Sicherung ist eine einzelne ZIP-Datei. Sie enthält die Datenbank als Textdatei, je einen Datenträger und eine Liste mit Prüfsummen.

Das System läuft dabei weiter. Deine Bearbeiter merken von einer Sicherung nichts.

„Estimate size" sagt dir vorher, wie groß die Datenbank ist. Die fertige Datei ist kleiner, weil sie gepackt wird.

Überschrieben wird nie etwas. Jede Sicherung ist eine eigene Datei, und erst die Aufräumung entfernt alte.

Der Reiter „Create Backup" mit den Schaltflächen „Estimate size" und „Create backup now".
Der rote Rahmen liegt auf beiden Schaltflächen. Der Satz darüber zählt auf, was mitgesichert wird.Bild in voller Größe öffnen
Die Meldung am unteren Rand mit dem vollständigen Pfad der erzeugten Datei.
Nach dem Anlegen steht der Dateiname unten im Fenster. Der Zeitpunkt steckt im Namen.Bild in voller Größe öffnen
4

Alles zurückholen

Voraussetzung: Eine Wiederherstellung überschreibt den heutigen Stand. Alles, was seit der gewählten Sicherung entstanden ist, ist danach weg.

Im Reiter „Restore" wählst du die Sicherung aus, die zurück soll. Dann klickst du auf „Restore".

Vorher fragt die Anwendung nach. Sie sagt dabei, was passiert: Der heutige Stand wird überschrieben, und die Anwendung startet die Container neu.

Das Häkchen „Wipe target volumes before restore" räumt die Datenträger vorher leer. So bleibt keine Datei liegen, die es zum Zeitpunkt der Sicherung noch nicht gab.

Der Ablauf steht im Reiter „Log". Dort siehst du Schritt für Schritt, was die Anwendung getan hat.

Zurück kommt der komplette Stand. Tickets, Kommentare, Verlauf, Datei-Anhänge, erfasste Zeiten und die Wissensdatenbank stehen wieder so da wie zum Zeitpunkt der Sicherung.

Danach ist das System wieder benutzbar. Bei einer kleinen Installation dauert das keine Minute.

Eine ausgewählte Sicherung in der Liste, darunter das Häkchen und die Schaltfläche „Restore".
Die roten Rahmen liegen auf dem Häkchen und auf „Restore". Ohne ausgewählte Zeile bleibt die Schaltfläche aus.Bild in voller Größe öffnen
Die Rückfrage vor der Wiederherstellung mit den Schaltflächen „Yes" und „No".
Die Rückfrage nennt beide Folgen: Der heutige Stand wird überschrieben, und die Container werden neu gestartet.Bild in voller Größe öffnen
Das Protokoll nach der Wiederherstellung, unten die Meldung „Restore complete."
Jeder Schritt steht mit Uhrzeit da. Am Ende meldet die Anwendung „Restore complete."Bild in voller Größe öffnen
5

Auf einem Server ohne Oberfläche

Auf einem Server gibt es oft keine Oberfläche. Dieselbe Anwendung kann deshalb auch als Befehl.

Fünf Befehle brauchst du: „backup" sichert, „list" zeigt die vorhandenen Sicherungen, „restore" holt eine zurück, „schedule" setzt den Zeitplan und „config" zeigt die Einstellungen.

Dahinter steckt dieselbe Anwendung wie im Fenster. Es gibt keinen zweiten Weg, der etwas anderes tut.

Die Anwendung liegt in „/opt/smitey/Backup". Du rufst sie mit „sudo" auf und hängst den Befehl an. Die Container laufen als „root", deshalb braucht auch die Sicherung diese Rechte.

Die vier Kästen unten kannst du kopieren. Sie decken ab, was im Betrieb wirklich gebraucht wird.

Eine Wiederherstellung fragt auch hier nach. Sie läuft erst mit dem Zusatz „--yes".

Zum Nachlesen liegt eine Datei auf dem Server. Sie heißt „BACKUP-RESTORE.txt" und liegt in „/opt/smitey". Darin stehen der Zeitplan, alle Befehle und der Weg zurück noch einmal in Ruhe. Sie ist in der Sprache, die du bei der Installation gewählt hast. Die übrigen Sprachen liegen unter „/opt/smitey/docs".

Vorhandene Sicherungen anzeigen

sudo /opt/smitey/Backup/TicketSystemBackup list

Je Zeile stehen Zeitpunkt, Anlass, Größe und Dateiname. Es ist dieselbe Liste wie im Fenster.

Den Zeitplan anzeigen

sudo /opt/smitey/Backup/TicketSystemBackup schedule --show

Die erste Zeile nennt die eingestellte Uhrzeit. Die letzte sagt, ob die Aufgabe wirklich im Betriebssystem steht. Steht dort „NO", läuft nichts von selbst.

Den Zeitplan ändern

sudo /opt/smitey/Backup/TicketSystemBackup schedule --daily 23:00 --keep 14

Die Uhrzeit ist die des Servers. „--keep" sagt, wie viele tägliche Sicherungen bleiben. „schedule --off" schaltet die tägliche Sicherung ab.

Sofort eine Sicherung anlegen

sudo /opt/smitey/Backup/TicketSystemBackup backup

Diese Sicherung zählt als „Manual". Von Hand angelegte Sicherungen werden nie automatisch gelöscht.

Eine Befehlszeile auf einem Linux-Server mit dem Ablauf von „backup" und darunter der Liste von „list".
Oben läuft „backup" durch: Datenbank sichern, die drei Datenträger sichern, packen. Darunter zeigt „list" die fertige Datei an erster Stelle. Die Zeilen mit dem Pfeil sind die Aufrufe, die die Anwendung dabei selbst macht.Bild in voller Größe öffnen
6

Die Sicherungen liegen auf derselben Maschine

Voraussetzung: Eine Sicherung neben dem System schützt nicht vor einem Plattenausfall. Kopiere die Dateien regelmäßig an einen anderen Ort.

Die Sicherungen liegen als Dateien im eingestellten Ordner. Der liegt auf derselben Maschine wie das Ticket-System.

Gegen die häufigen Fälle hilft das gut. Ein versehentlich gelöschter Bestand, ein misslungenes Update oder ein Fehler in den Daten sind damit abgedeckt.

Gegen einen Ausfall der Platte hilft es nicht. Ist die Platte weg, sind die Sicherungen mit weg.

Kopiere die Dateien deshalb woanders hin. Ein Netzlaufwerk, ein zweiter Server oder ein Speicher im Netz reichen dafür.

Eine kopierte Datei lässt sich überall wieder einspielen. Über „Import backup file…" holst du sie zurück in die Liste.

Der Reiter „Settings" mit dem Feld „Backup directory".
Unter „Backup directory" steht, wo die Dateien liegen. Genau diesen Ordner solltest du regelmäßig woandershin kopieren.Bild in voller Größe öffnen
7

Vor jedem Update sichert das System selbst

Ein Update legt vorher eine eigene Sicherung an. Das passiert unabhängig von deinem Zeitplan und ohne dass du etwas anhakst.

Gesichert wird dasselbe wie sonst: die Datenbank, die Anhänge, das Archiv und die Schlüssel.

Diese Sicherung gehört zum Update. Sie liegt in einem eigenen Ordner neben dem System und taucht deshalb nicht in der Liste der Anwendung auf.

Der Hinweis vor dem Update sagt es dir. Du musst also nicht daran denken, vorher selbst zu sichern.

Mehr dazu in der Karte: Ein Update auf Knopfdruck

Die Rückfrage vor dem Update mit dem Hinweis auf die Sicherung.
Der Satz „A full backup is taken automatically beforehand" steht in der Rückfrage. Die Sicherung läuft, bevor irgendetwas ausgetauscht wird.Bild in voller Größe öffnen

Wichtige Befehle (Linux)

Zum Kopieren. Alles mit sudo – Installer und Container brauchen Root-Rechte.

Voraussetzung installieren

sudo apt install -y unzip

Ohne unzip kann der Installer das Paket nicht auspacken.

Ticket-System installieren

curl -fsSL https://files.smitey.eu/download/get-smitey.sh | sudo bash

Lädt das Paket und führt durch die Fragen. Ein zweiter Aufruf ist gefahrlos: Konfiguration und Daten bleiben erhalten.

HTTPS prüfen

sudo /opt/smitey/smitey-install check-https

Nur bei öffentlicher Domain. Sagt, ob das Zertifikat da ist – und wenn nicht, den Grund aus dem Protokoll. Das Zertifikat kann auch Minuten nach der Installation noch kommen.

Erstzugang nachlesen

sudo cat /opt/smitey/SMITEY-credentials.txt

Nach dem ersten Login das Passwort ändern und die Datei löschen.

Laufen die Container?

sudo podman ps

Zeigt alle Teile des Systems mit ihrem Zustand.

Protokoll mitlesen

sudo podman logs -f container-backend-1

Zeigt laufend, was das Backend meldet. Beenden mit Strg+C.

Wächter prüfen

systemctl status smitey-supervisor

Der Dienst hält das System am Laufen und spielt Updates ein, die du in der Anwendung anstößt.

Support-Paket erzeugen

sudo /opt/smitey/install.sh --support-bundle

Sammelt Protokolle und Systemzustand in einer ZIP-Datei. Passwörter und Schlüssel werden entfernt.

Öffentliche Adresse ändern

sudo /opt/smitey/install.sh --reconfigure

Setzt eine neue Domain und startet neu, damit das Zertifikat für den neuen Namen angefordert wird.

Entfernen

sudo /opt/smitey/install.sh --uninstall

Fragt getrennt nach Daten und nach Podman – nichts wird ungefragt gelöscht.

Sicherungen steuerst du mit /opt/smitey/Backup/TicketSystemBackup (list, backup, restore); die tägliche Sicherung läuft von selbst. Einzelheiten stehen in /opt/smitey/docs/de/BACKUP-RESTORE.txt.

Zurück zum FunktionsvergleichDie Bilder stammen aus Version 0.46.0.