Produkt
Problemmanagement: denselben Vorfall nicht zehnmal lösen
Ein Problem ist in KairosLink eine Ursache, die Tickets bündelt. Statt zehn Vorfälle mit derselben eingefügten Erklärung zu schließen, erstellen Sie ein Problem, verknüpfen diese zehn Tickets damit, und die Untersuchung bekommt ein eigenes Leben, mit ihrer Nummer, ihrem Status, ihrem zugewiesenen Techniker und ihren Daten. Ist die Ursache beseitigt, bietet das Schließen des Problems an, die noch offenen Tickets in einem Zug zu lösen.
Jedes Problem trägt eine eigene fortlaufende Nummer innerhalb Ihrer Organisation, im Format P-Organisation-0001, erzeugt unter einer Sperre, die garantiert, dass zwei Techniker, die in derselben Sekunde ein Problem erstellen, sich nicht dieselbe Nummer greifen.
Sechs Status, die die Untersuchung beschreiben, nicht die Laune des Technikers
Es gibt sechs Status, und sie liegen fest: identifiziert, in Untersuchung, Ursache identifiziert, Übergangslösung verfügbar, gelöst und geschlossen. Die Liste zeigt die Anzahl der Probleme je Status und filtert außerdem nach betroffenem Kunden und über den Text von Nummer und Titel.
Die Datumsangaben werden von selbst gesetzt, während das Problem wandert: Erkennung, Ursache identifiziert, Lösung und Abschluss. Das Datum der Ursache wird beim ersten Mal geschrieben, wenn das Problem diesen oder einen späteren Status erreicht, und es wird nicht zurückgesetzt, falls das Problem später wieder geöffnet wird: Es misst, wie lange das Team gebraucht hat, um das Problem zu verstehen, und das ist die Zahl, auf die es ankommt.
Die Priorität nutzt dieselbe Skala wie Tickets, mit vier Stufen: niedrig, normal, hoch und dringend. Ein dringendes Problem liest sich genau wie ein dringendes Ticket, und es gibt keine Kriterien, die zwischen zwei Bildschirmen übersetzt werden müssten.
Tickets und Probleme verknüpfen sich von beiden Seiten
Vom Problem aus suchen Sie Tickets nach Nummer oder Betreff und verknüpfen sie; aus der Ticketansicht heraus suchen Sie das Problem und verknüpfen es dort. Es ist dieselbe Beziehung, von beiden Seiten gesehen, sodass ein Techniker im Ticket nie heraus muss, um etwas zu finden. Ein Problem bündelt viele Tickets, und ein Ticket kann zu mehr als einem Problem gehören.
Gibt es das Problem noch nicht, erstellen Sie es direkt aus dem Ticket: Das Formular kommt mit Titel und Kunde bereits ausgefüllt, und beim Speichern wird dieses Ticket verknüpft. Die Suche schließt immer aus, was schon verknüpft ist, sodass keine Verknüpfung doppelt entsteht.
Der Zugriff wird über vier getrennte Berechtigungen gesteuert: ansehen, erstellen, bearbeiten und schließen. Ein Techniker kann ein Problem untersuchen und dokumentieren, ohne die Befugnis zu haben, es zu schließen und die Tickets der Kunden mitzuziehen.
Das Schließen bietet an, die Tickets zu lösen, es schließt sie nie von selbst
Wenn Sie ein Problem schließen, listet der Bildschirm die verknüpften Tickets auf, die noch offen sind, und Sie haken an, welche gelöst werden sollen. Die angehakten erhalten eine gemeinsame Lösungsnachricht als für den Kunden sichtbare Antwort und wechseln auf Gelöst. Die nicht angehakten bleiben genau so, wie sie waren.
Nichts schließt sich stillschweigend: Ohne Lösungsnachricht wird kein Ticket angerührt, und ein bereits geschlossenes Problem wird nicht erneut geschlossen. Der Kunde sieht nie, dass ein Ticket den Status wechselt, ohne dass eine Antwort das erklärt.
Der Kunde sieht die Übergangslösung, nie die Untersuchung
Das Problem hat zwei eigene Felder: die Ursache und die Übergangslösung. Steht der Status auf Übergangslösung verfügbar, ist dieser Text das, womit das Team antworten muss, solange die Ursache noch steht.
Steht das Problem in diesem Status und ist das Feld gefüllt, erscheint diese Übergangslösung von selbst in jedem Portal-Ticket, das mit diesem Problem verknüpft ist, in einem eigenen Block über der Konversation. Der Kunde öffnet sein gewohntes Ticket und findet dort den Weg, weiterzuarbeiten, ohne dass ein Techniker sie in jede Antwort kopiert.
Mehr geht nicht hinüber. Die Ursache, der interne Titel des Problems, seine Nummer und die Tickets der anderen betroffenen Kunden bleiben auf der Seite der Konsole: Ihr Kunde erfährt nie, dass sein Vorfall einer von zwölf ist. Und ist beim Problem keine Übergangslösung eingetragen oder steht es in einem anderen Status, sieht das Portal-Ticket genau so aus wie immer, ohne leeren Block und ohne Überschrift, die irgendetwas ankündigt.
Die Ursache landet in einem Artikel, nicht in einem losen Feld
Vom Problem aus verknüpfen Sie einen bereits veröffentlichten Artikel der Wissensdatenbank, oder Sie erzeugen mit einem Klick einen neuen Entwurf. Diesen Entwurf schreibt keine künstliche Intelligenz: Er wird aus den Feldern zusammengesetzt, die Sie ohnehin ausgefüllt haben, in drei Abschnitten (Symptom, Ursache und Übergangslösung), und die Felder, die Sie leer gelassen haben, erscheinen als fehlende Information markiert, sodass der Entwurf nie fertig aussieht, wenn er es nicht ist.
Der Entwurf landet als Entwurf mit interner Sichtbarkeit in einer eigenen Kategorie, und das Problem zeigt anschließend auf diesen Artikel. Ihn zu veröffentlichen und zu entscheiden, ob der Kunde ihn sehen darf, ist immer die Entscheidung eines Menschen.
Ein Bericht, der die Untersuchung misst, nicht das Gefühl
Der Bereich Berichte hat einen eigenen Bericht zum Problemmanagement, filterbar nach Kunde und Zeitraum, mit den letzten 90 Tagen als Voreinstellung. Ganz oben stehen sechs Zahlen für den Zeitraum: eröffnete Probleme, geschlossene Probleme, durchschnittliche Zeit von der Eröffnung bis zur identifizierten Ursache, durchschnittliche Zeit bis zum Abschluss, verknüpfte Vorfälle und Probleme mit verfügbarer Übergangslösung.
Darunter folgen die Verteilung über die sechs Status und die Aufstellung Problem für Problem: Nummer, Kunde, Status, wie viele Vorfälle es bündelt und die drei Datumsangaben, auf die es ankommt, also Eröffnung, Ursache und Abschluss. Der Durchschnitt der Vorfälle je Problem steht neben der Gesamtzahl, und das ist die Zahl, die Ihnen sagt, ob Sie wirklich bündeln oder ein Problem je Ticket eröffnen.
Die Zeiten werden in Stunden ausgegeben und über die Daten berechnet, die der Ablauf von selbst setzt, nicht über eine manuelle Eingabe. Der Bericht exportiert nach CSV, mit einer Zeile je Problem, und nach PDF mit dem Logo Ihrer Organisation und ohne KairosLink-Branding, sodass er genau so an den Kunden geht, wie er heruntergeladen wird.
Problemmanagement ist in KairosBusiness, KairosEnterprise und KairosEnterpriseFlex enthalten.
Häufige Fragen
Worin unterscheidet sich ein Problem von einem Ticket?
Kann ich ein Problem aus einem Ticket erstellen, das ich gerade bearbeite?
Schließt das Schließen eines Problems die Tickets der Kunden?
Was geschieht mit der Untersuchung, wenn ein Problem wieder geöffnet wird?
Ist Problemmanagement in jedem Plan enthalten?
Wird das Problem außerhalb der Konsole irgendwo dokumentiert?
Erfährt der Kunde, dass sein Ticket Teil eines größeren Problems ist?
Wie messe ich, ob das Problemmanagement funktioniert?
Standard-Softwaremodule inklusive. Keine Kreditkarte.