Antwort- & Ticketvorlagen

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 Aktion „Set the status" folgt denselben Regeln wie ein Statuswechsel von Hand. Wendest du die Vorlage auf mehrere Tickets an, überspringt sie gesperrte Tickets und nennt den Grund.

Auch das Fenster „Close ticket" bietet Antwortvorlagen an, im Feld „Template". Es zeigt nur Vorlagen, deren eingeschaltete Aktion „Set the status" auf einen Status stellt, der als gelöst oder geschlossen zählt. Interne Vorlagen bietet es nicht an. Wählst du eine davon, übernimmt das Fenster ihren Text als Kommentar. Verschickt die Vorlage eine Mail und bietet das Fenster den Mailversand an, übernimmt es den Empfänger nur, wenn er „Requester" oder eine feste Adresse ist. Die übrigen Aktionen und die Anhänge der Vorlage laufen dort nicht. Das Ticket wird wie gewohnt geschlossen.

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.

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. „{ticketRef}" geht dort ebenfalls und bedeutet dasselbe wie „{ticketTag}". „{requesterName}", „{ticketTitle}" und „{agentName}" gehen im Betreff nicht und werden ebenso abgelehnt.

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. Steht im Feld „User" ein Name ohne Adresse, geht keine Mail an den Anfragenden. Sie geht auch nicht ersatzweise an den, der das Ticket erfasst hat.

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. Eine Vorlage mit dem Häkchen „Internal note" hängt keine Dateien an.

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. Das Symbol sehen nur Personen, die Vorlagen verwalten dürfen.

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.

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

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

Jede Anwendung, die mehr tut als Text einzufügen, schreibt EINEN Eintrag in den Verlauf, unter dem Feldnamen „Template". Er nennt die Vorlage beim Namen. Die gelaufenen Aktionen schreiben eigene Zeilen. 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". Was die Vorlage bewirkt hat, steht in den eigenen Zeilen ihrer Aktionen, etwa der Wechsel des Status.

Abgewählte Aktionen stehen nicht darin: Sie sind nicht passiert. Ein Fehlschlag steht darin, und zwar ausdrücklich als solcher hinter dem Wort „failed". Eine reine Textvorlage ohne Aktionen, Mail und Anhänge hinterlässt am einzelnen Ticket keinen Eintrag „Template". Sie hat nur Text eingefügt. Bei der Anwendung auf mehrere Tickets steht der Eintrag dagegen immer da, zusammen mit der internen Zeile „Bulk".

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.