JIRA Service Desk (Update 2017)

Nach der Umstellung des Lizenzmodells im Jahr 2014, wurde JIRA Service Desk für zahlreiche Unternehmen als Lösung für die Abwicklung von Supportfällen interessant. Für mich der richtige Zeitpunkt, die Kernpunkte der Service Desks sowie meine Erfahrungen damit zu schildern.

Was ist JIRA Service Desk

JIRA Service Desk ist eine der 3 sogenannten Anwendungen des JIRA Kernsystems. Jede Anwendung beinhaltet individuelle Projekttypen, welche dem Nutzer jeweils unterschiedliche Funktionen zur Verfügung stellen. Das Ziel von JIRA Service Desk ist es, die Abwicklung von internen und externen Support-Anfragen in einem Unternehmen zu unterstützen. Der Ursprung von JIRA Service Desk ist das ehemalige VertygoSLA-Plugin von Valiantys, das von Atlassian übernommen und als eigenes Produkt weiterentwickelt wird.

JIRA Anwendungen

Grundprinzip

In einer JIRA-Instanz können beliebig viele sogenannte Service Desks erstellt werden. Jeder Service Desk wird auf ein konkretes Projekt „aufgesetzt“ und erweitert dieses um verschiedene Support-Funktionen. Jedem Service Desk werden Agenten (d.h. Support-Mitarbeiter) zugeordnet, welche die eingehenden Tickets bearbeiten können. Jeder Service Desk stellt darüber hinaus ein flexibel konfigurierbares Kundenportal bereit (siehe Punkt „Kundensicht“) und kann frei definierbare SLAs mit jeweils eigenen Zielsetzungen umsetzen (siehe „Administraor-Sicht“).

Supporter-Sicht

Aus Sicht eines Support-Mitarbeiters bietet JIRA Service Desk im Wesentlichen 2 Kernfunktionen. Alle in einen Service Desk eingehenden Tickets werden in frei definierbaren Queues sortiert – es kann es z.B jeweils eine Queue für jeden Support-Mitarbeiter geben sowie Queues für jedes SLA-Level, jedes Produkt, jede Komponente usw. Die Queues basieren auf standardmäßigen JIRA-Filtern und bieten demzufolge alle von dort gewohnten Funktionen. Natürlich sind Queues sortierbar, z.B. nach der verbleibenden Zeit bis zum Ablauf einer in einem SLA definierten Zeitspanne.

Queues in Service Desk

Queues in Service Desk

Alle eingehenden Support-Anfragen – egal ob per E-Mail oder Kundenportal erstellt – sind normale JIRA-Vorgänge und werden aus Supporter-Sicht auch als solche bearbeitet.

Für die Kommunikation mit dem Kunden werden Kommentare verwendet: deren Eingabemaske unterscheidet in einem Service Desk zwischen einem „Internen Kommentar“, der nur für Support-Agenten und projektbeteiligte Rollen sichtbar ist, und einem „Kundenkommentar“, der auch für den Ersteller der Support-Anfrage sichtbar ist. Dies gilt auch, wenn die Anfrage per E-Mail erstellt wurde: der Autor der E-Mail wird als Autor des entsprechenden Tickets eingetragen und erhält Benachrichtigungen über Kommentare oder Statusänderungen an seinem Ticket per E-Mail.

Kundensicht

Für die Kunden eines Service Desks stehen 3 Wege zum Erstellen von Tickets offen:

  • Über die standardmäßige „Vorgang erstellen“ Funktion von JIRA, falls der Kunde Zugriff auf JIRA und das entsprechende Projekt besitzt.
  • Über ein (im Service Desk konfiguriertes) Kundenportal, welches eine vereinfachte Maske zum Erstellen von Support-Anfragen bereitstellt.
  • Per E-Mail an eine vorgegebene E-Mail Adresse, die einem Service Desk zugewiesen wurde.

Für jeden Service Desk kann ein Kundenportal definiert werden, in dem Kunden auf einfache Weise Support-Anfragen erstellen können. Dabei wird intern jeweils ein „Anfragetyp“ einem JIRA-Vorgangstyp zugewiesen. Möchte man z.B. ein Formular für das Erstellen von Dienstreiseanträgen bereitstellen, kann man einen Anfragetyp „Dienstreise“ erstellen und diesem dem Vorgangstyp „Interne Anfrage“ zuordnen (sofern es keinen eigenen Vorgangstyp „Dienstreiseantrag“ geben soll). Die Eingabemaske des Kundenportals ist flexibel konfigurierbar, verschiedene Anfragetypen können u.a. gruppiert und mit unterschiedlichen Pflichtfeldern versehen werden. Ebenso kann für jeden Anfragetyp definiert werden, welche Status des Arbeitsablaufes für den Kunden sichtbar sein sollen – auf diese Weise kann man zwischen internen und kundensichtbaren Status unterscheiden.

Besonders hervorzuheben ist die Möglichkeit, einen Confluence-Bereich als Knowledge Base an einen Service Desk anzubinden. Tut man dies, wird das Kundenportal um eine Vorschlagsfunktion bei der Eingabe der Support-Anfrage erweitert. Fängt ein Kunde an, etwas einzutippen, werden ihm sofort passende Inhalte aus der angebundenen Knowledge-Base angezeigt. Im besten Fall erhält der Kunde dadurch bereits die gewünschte Information und muss kein eigenes Ticket erstellen.

Service Desk Kundenportal

Service Desk Kundenportal

 

Eine weitere Möglichkeit, Tickets zu erstellen, ist die Anbindung eines Service Desks an ein bestehendes POP- oder IMAP-Konto. JIRA ruft die E-Mails aus diesem Postfach regelmäßig ab und erstellt daraus Tickets mit dem vorgegebenen Anfrage-Typ. Der Autor der E-Mail wird automatisch als „Kunde“ in diesen Service Desk aufgenommen und als Autor des Tickets eingetragen. Er erhält dadurch Benachrichtigungen über Änderungen oder Kommentare an seinem Ticket, kann auf diese Mails antworten und damit mit dem Support-Agenten kommunizieren.

Administrator-Sicht

Projektadministratoren können die SLA-Levels des Service Desks bestimmen, die beteiligten Personen verwalten (Support-Agenten, Kunden, weitere Beteiligte) sowie das Kundenportal konfigurieren und die allgemeinen Einstellungen (Anbindung E-Mail Postfach usw.) vornehmen.

Das Einrichten von SLAs funktioniert absolut intuitiv: für jedes SLA können Start- und Stopp-Ereignisse ausgewählt werden sowie Ereignisse, in denen die Zeitberechnung des SLAs pausieren soll (z.B. im Status „Warte auf Kundenantwort“). Per JQL-Abfrage wird vorgegeben, welche Vorgänge in welches SLA-Level fallen, sowie die für jedes Level vorgegebene Zeitspanne und der anzusetzende Kalender mit den Arbeitszeiten der Support-Agenten.

Service Desk SLA-Level

Service Desk SLA-Level

Der Projektadministrator legt weiterhin fest, welche Support-Agenten diesen Service Desk verwenden können und ob es sich um einen offenen oder geschlossenen Desk handelt. In geschlossenen Service Desks können nur registrierte JIRA-Nutzer sowie Kunden, welche manuell zu einer Kundenliste hinzugefügt wurden, Tickets erstellen. In offenen Service Desks können sich beliebige Personen als Kunde dieses Service Desks registrieren und entsprechende Anfragen eröffnen – diese Einstellung ist z.B. für externe Supportsysteme mit beliebig vielen Endkunden geeignet.

Agenten und Lizenzplätze

JIRA Service Desk berechnet für jeden Support-Agenten einen Lizenzplatz; die Kunden sind kostenlos. Support-Agenten können in beliebig vielen Service Desks tätig sein und müssen nur einmal lizensiert werden. Auch normale JIRA-Nutzer können Service Desk Projekte sowie die darin enthaltenen Vorgänge sehen (wenn man das möchte). Allerdings: nur Agenten können Tickets bearbeiten, Kundenkommentare erstellen sowie die Queues und SLAs sehen.

Automatisierungen

JIRA Service Desk bietet sogenannte Automatisierungsregeln an, mit denen sich sehr elegante Automatismen einrichten lassen. Unter anderem können bestimmte Personen vor Erreichen einer SLA-Grenze benachrichtigt werden; Vorgänge können anhand der durch den Kunden ausgewählten Feldwerte automatisiert bearbeitet werden und vieles mehr. Sollten diese Funktionen nicht ausreichen, lassen sich per Plugin zahlreiche Automatisierungen in einem Service Desk nachrüsten.

Fazit

JIRA Service Desk ist eine leicht konfigurierbare Lösung für Supportprojekte, die sowohl von Support-Agenten wie auch von Kunden intuitiv bedient werden kann. Insbesondere, wenn JIRA bereits für andere Anwendungsfälle im Unternehmen verwendet wird, macht die Ausweitung auf den Support durchaus Sinn, da auf diese Weise z.B. Support-Anfragen und Bugs miteinander verknüpft werden können.

Potential für Verbesserungen besteht aber durchaus. Obwohl in den letzten Jahren essentielle Funktionen wie mehrsprachige Benachrichtigungen, Textbausteine, Freigabeprozesse und Automatisierungen eingeführt wurden, bleiben viele Funktionen leider noch offen. Beispiele dafür sind: Mehrsprachigkeit innerhalb eines Kundenportals, Vertretungs- und Anwesenheitsregelungen sowie Schemas für Anfragetypen. Da Atlassian allerdings weiterhin intensiv an der Funktionalität des Service Desks arbeitet, gehe ich von einer stetigen Verbesserung der genannten Funktionen aus.

12. September 2017 von Sebastian Höhne
Kategorien: Jira | Schlagwörter: , , | 2 Kommentare

Kommentare (2)

  1. Guten Tag,

    Ich bin bei der Suche nach „JIRA Service Desk“ auf Ihren Beitrag gestoßen. Er gibt eine sehr schöne Übersicht über das neue Service Desk Plugin. Allerdings habe ich immer noch einen Punkt der mir etwas unklar ist und irgendwie nirgends wirklich erklärt wird. Das ist das Konzept der Agenten. Ist jeder interne Nutzer der in dem Projekt arbeitet, auf das der Service Desk aufsetzt, ein Agent? Oder ist ein Agent jemand, der die Tickets annimmt und an die richtigen Stellen leitet? Angenommen ich habe nur eine Person, die dafür zuständig ist die Tickets zu bewerten und zu verteilen, reicht mir dann rein theoretisch ein Agent? Kann ich das nach dem Prinzip der zwei Projekte, ServiceDesk und Interne Bearbeitung ablaufen lassen oder kann ein „Nicht-Agent“ auf die verlinkten Tickets des Service-Desk nicht zugreifen?

    Vielen Dank und Gruß,
    Steven

    • Hallo,

      da würde ein einzelner Agent ausreichen. Die Agenten sind diejenigen, die die Support-Ansicht des Projektes sehen (also die Queues, SLA-Levels etc.), Tickets bearbeiten können, sowie per Kommentar mit dem Autor des Tickets kommunizieren können. Die eingehenden Tickets werden also von den Agenten bewertet, ggf. gleich beantwortet, oder der Agent erstellt z.B. in einem anderen Projekt einen entsprechenden internen Vorgang (Bug, CR, Feature Request o.ä.) und verknüpft diesen mit dem offenen Ticket.

      Das Service-Desk Projekt (und die Vorgänge darin) sehen nur diejenigen Nutzer, die entweder in der Rolle „Administrator“, „Agent“ oder „Beteiligter“ eingetragen sind. Um also die ganz normalen Jira-Nutzer ebenfalls in das Service-Desk Projekt reinholen, muss man diese (z.B. per Gruppenzuweisung) zu „Beteiligten“ machen. Jeder in diese Rolle kann die Tickets sehen, Anhänge hochladen und interne Kommentare hinzufügen. Die Beteiligten können aber u.a. nicht: Tickets bearbeiten, als Bearbeiter eingetragen werden, den Status ändern, dem Kunden antworten. Das können nur die Agenten – am besten ist es also, wenn die Agenten eine Verteilfunktion haben. Wenn ein Agent ein Ticket nicht selbst klären kann, kann er entweder einen der „Beteiligten“ um Unterstützung bitten (Kommentar, darin per @username benachrichtigen) und der Beteiligte kann dann einen internen Kommentar als Antwort hinterlassen. Oder der Agent erstellt einen internen Vorgang in einem anderen Projekt und verküpft diesen mit dem Ticket.

      Eine gute Übersicht über die 4 Rollen und die entsprechenden Funktionen / Rechte gibt es auch unter https://confluence.atlassian.com/servicedesk/jira-service-desk-permissions-660967494.html.

      Beste Grüße,
      Sebastian

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert


feedback