Status im Ticketing: Unterschied zwischen den Versionen

Aus Service Champion-Wiki
Wechseln zu: Navigation, Suche
(Einfache Verwendung Status Feld)
(Erweiterte Verwendung Status Feld)
Zeile 7: Zeile 7:
  
 
== Erweiterte Verwendung Status Feld ==
 
== Erweiterte Verwendung Status Feld ==
# '''Rückmeldung'''
+
# '''Rückmeldung''' setzen, wenn von Externer Quelle /Person / Firma noch auf eine Rückmeldung gewartet wird. Wenn z.B. erst per Datum x etwas gemacht werden soll, wird auch Rückmeldung genutzt und diese Deadline / Fälligkeit eingetragen. Rückmeldung hilft einem, das Ticket auf dem Radar zu behalten und zu wissen, dass hier von Extern d.h. von jemandem der nicht ins Ticketing reinschauen kann, ein Feedback benötigt wird (E-mail Antwort, Entscheid, Rückruf am Telefon). Ein Ticket auf Rückmeldung immer mit einem Zieldatum versehen. So weiss man, ab wann man beim Kunden nachfassen muss, falls er sich nicht meldet.  
## Setzen, wenn von Externer Quelle noch m Kunden noch auf eine Rückmeldung gewartet wird, kommt dieser Status zur Anwendung. Wenn erst per Datum x etwas gemacht werden soll, wird auch Rückmeldung genutzt. Der Status hilf einem, das Ticket auf dem Radar zu behalten und zu wissen, dass hier von Extern d.h. von jemandem der nicht ins Ticketing reinschauen kann, ein Feedback benötigt wird (E-mail Antwort, Entscheid, Rückruf am Telefon). Ein Ticket auf Rückmeldung immer mit einem Zieldatum versehen. So weiss man, ab wann man beim Kunden nachfassen muss, falls er sich nicht meldet. Vorteil: Tickets auf "Rückmeldung" muss man nicht aktiv bearbeiten, da sich ja im Normalfall der Kunde wieder meldet (Tel, E-Mail, Brief, etc.). Ein Beispiel ist: Der Kunde muss einen Vertrag unterschrieben zurücksenden. In diesem Fall lasse ich das Ticket bei mir (oder Rolle) und setzte es mit Zieldatum z.B. in einer Woche, auf "Rückmeldung". Falls der Vertrag dann nach 1 Woche nicht eintrifft, wechselt das Ticketdatum auf Rot (overdue). Ich kontaktiere dann den Kunden und frage nach. Rückmeldung ist wie ein Parkplatz für Tasks, die in der Zukunft weiterbearbeitet werden müssen.
+
## Vorteil: Tickets auf "Rückmeldung" muss man nicht aktiv bearbeiten, da sich ja im Normalfall der Kunde wieder meldet (Tel, E-Mail, Brief, etc.). Ein Beispiel ist: Der Kunde muss einen Vertrag unterschrieben zurücksenden. In diesem Fall lässt man das Ticket bei sich (oder auf einer Rolle) und setzt es mit Zieldatum z.B. in einer Woche, auf "Rückmeldung". Falls der Vertrag dann nach 1 Woche nicht eintrifft, wechselt das Ticketdatum / Fälligkeit auf Rot (overdue). Dann den Kunden kontaktieren und nachfragen. Rückmeldung ist wie ein Parkplatz für Tasks, die in der Zukunft weiterbearbeitet werden müssen.
# '''anerkannt'''<br>
+
# '''anerkannt''' setzen, wenn bei dem Ticket von der bearbeitenden Person ein Handlungsbedarf festgestellt wird. Der Fall/Anfrage wird so für alle anderen User als "anerkannt" gekennzeichnet d.h. man weiss die Person wird zu dem Thema etwas tun.
Wurde bei dem Ticket von der bearbeitenden Person ein Handlungsbedarf festgestellt, wird das Ticket auf anerkannt gestellt. Der Fall/Anfrage wird so für alle anderen User als "anerkannt" gekennzeichnet d.h. man wird etwas tun müssen.
+
# '''bestätigt''' setzen, wenn an einem Ticket nicht nach "anerkannt" nun auch aktiv daran gearbeitet wird. Das Ticket / Anfrage ist in der Realisation / Umsetzung.
# '''bestätigt'''<br>
+
# '''erledigt''' setzen, falls jemandem das Ticket noch prüfen & gutgeheissen muss. Z.B. noch etwas testen / approven oder zur Kenntnis nehmen. Diese Person stellt das Ticket dann nach der Überprüfung auf "geschlossen". Falls das Ticket nicht ok gelöst ist, weist man es mit einer Bemerkung an eine Person für weitere Arbeiten zu (Status: zugewiesen).
Dieser Status kann benutzt werden, um auszusagen, dass ein Ticket nicht nur erkannt wurde, sondern nun aktiv daran gearbeitet wird. Das Ticket / Anfrage ist in der Realisation / Umsetzung.
 
# '''erledigt'''<br>
 
Ist ein Ticket erledigt, muss aber noch von jemandem gutgeheissen, getestet oder zur Kenntnis genommen werden, wird es dieser Person mit dem Status erledigt zugewiesen. Diese Person stellt das Ticket dann auf "geschlossen". Falls das Ticket nicht gelöst ist, weist man es mit einer Bemerkung an eine Person für weitere Arbeiten zu (Status: zugewiesen).
 
 
[[Image:Mantis_status.jpg]]<br><br>
 
[[Image:Mantis_status.jpg]]<br><br>
 
=== Ablauf des Status im Ticketing ===
 
=== Ablauf des Status im Ticketing ===
Zeile 20: Zeile 17:
 
=== Ablauf inkl. Status "Rückmeldung" ===
 
=== Ablauf inkl. Status "Rückmeldung" ===
 
[[Image:Mantis_explanation.png]]
 
[[Image:Mantis_explanation.png]]
=== Farbcode im Ablauf ===
+
=== Farbcode im Ablauf (State engine) Status Diagramm===
 
* rot -> typischer Ablauf
 
* rot -> typischer Ablauf
 
* grün -> erweiterter Ablauf
 
* grün -> erweiterter Ablauf
 
* blau -> Expertenablauf
 
* blau -> Expertenablauf
* orange -> Falls Tickets nicht von Anfang an zugeordnet werden
+
* orange -> Falls Ticket nicht von Anfang an zugeordnet wurde
 +
 
 +
[[Kategorie:Ticketing]]
 +
 
 
== Suchbegriffe ==
 
== Suchbegriffe ==
 
Ablauf, Ticket, Status, Stati, Erklärung Prozess, Flow, Ablauf
 
Ablauf, Ticket, Status, Stati, Erklärung Prozess, Flow, Ablauf

Version vom 6. Mai 2020, 15:05 Uhr

Einfache Verwendung Status Feld

  1. neu, Status setzen, wenn ein Ticket erfasst wird und niemandem zugewiesen ist.
  2. zugewiesen Status setzen, wenn Ticket einer verantwortlichen Person / Rolle zugewiesen wird. Wichtig: Rollen arbeiten nicht, das sind nur Warteschlangen. Zum abarbeiten an eine Person zuweisen / sich selbst zuweisen. Die eingetragene Person hat den Lead.
  3. geschlossen Status setzen, wenn Ticket / Fall abgeschlossen ist.

Erweiterte Verwendung Status Feld

  1. Rückmeldung setzen, wenn von Externer Quelle /Person / Firma noch auf eine Rückmeldung gewartet wird. Wenn z.B. erst per Datum x etwas gemacht werden soll, wird auch Rückmeldung genutzt und diese Deadline / Fälligkeit eingetragen. Rückmeldung hilft einem, das Ticket auf dem Radar zu behalten und zu wissen, dass hier von Extern d.h. von jemandem der nicht ins Ticketing reinschauen kann, ein Feedback benötigt wird (E-mail Antwort, Entscheid, Rückruf am Telefon). Ein Ticket auf Rückmeldung immer mit einem Zieldatum versehen. So weiss man, ab wann man beim Kunden nachfassen muss, falls er sich nicht meldet.
    1. Vorteil: Tickets auf "Rückmeldung" muss man nicht aktiv bearbeiten, da sich ja im Normalfall der Kunde wieder meldet (Tel, E-Mail, Brief, etc.). Ein Beispiel ist: Der Kunde muss einen Vertrag unterschrieben zurücksenden. In diesem Fall lässt man das Ticket bei sich (oder auf einer Rolle) und setzt es mit Zieldatum z.B. in einer Woche, auf "Rückmeldung". Falls der Vertrag dann nach 1 Woche nicht eintrifft, wechselt das Ticketdatum / Fälligkeit auf Rot (overdue). Dann den Kunden kontaktieren und nachfragen. Rückmeldung ist wie ein Parkplatz für Tasks, die in der Zukunft weiterbearbeitet werden müssen.
  2. anerkannt setzen, wenn bei dem Ticket von der bearbeitenden Person ein Handlungsbedarf festgestellt wird. Der Fall/Anfrage wird so für alle anderen User als "anerkannt" gekennzeichnet d.h. man weiss die Person wird zu dem Thema etwas tun.
  3. bestätigt setzen, wenn an einem Ticket nicht nach "anerkannt" nun auch aktiv daran gearbeitet wird. Das Ticket / Anfrage ist in der Realisation / Umsetzung.
  4. erledigt setzen, falls jemandem das Ticket noch prüfen & gutgeheissen muss. Z.B. noch etwas testen / approven oder zur Kenntnis nehmen. Diese Person stellt das Ticket dann nach der Überprüfung auf "geschlossen". Falls das Ticket nicht ok gelöst ist, weist man es mit einer Bemerkung an eine Person für weitere Arbeiten zu (Status: zugewiesen).

Mantis status.jpg

Ablauf des Status im Ticketing

Mantis explanation2.png

Ablauf inkl. Status "Rückmeldung"

Mantis explanation.png

Farbcode im Ablauf (State engine) Status Diagramm

  • rot -> typischer Ablauf
  • grün -> erweiterter Ablauf
  • blau -> Expertenablauf
  • orange -> Falls Ticket nicht von Anfang an zugeordnet wurde

Suchbegriffe

Ablauf, Ticket, Status, Stati, Erklärung Prozess, Flow, Ablauf

Einfache Verwendung Status Feld[Quelltext bearbeiten]

  1. neu, Status setzen, wenn ein Ticket erfasst wird und niemandem zugewiesen ist.
  2. zugewiesen Status setzen, wenn Ticket einer verantwortlichen Person / Rolle zugewiesen wird. Wichtig: Rollen arbeiten nicht, das sind nur Warteschlangen. Zum abarbeiten an eine Person zuweisen / sich selbst zuweisen. Die eingetragene Person hat den Lead.
  3. geschlossen Status setzen, wenn Ticket / Fall abgeschlossen ist.

Erweiterte Verwendung Status Feld[Quelltext bearbeiten]

  1. Rückmeldung setzen, wenn von Externer Quelle /Person / Firma noch auf eine Rückmeldung gewartet wird. Wenn z.B. erst per Datum x etwas gemacht werden soll, wird auch Rückmeldung genutzt und diese Deadline / Fälligkeit eingetragen. Rückmeldung hilft einem, das Ticket auf dem Radar zu behalten und zu wissen, dass hier von Extern d.h. von jemandem der nicht ins Ticketing reinschauen kann, ein Feedback benötigt wird (E-mail Antwort, Entscheid, Rückruf am Telefon). Ein Ticket auf Rückmeldung immer mit einem Zieldatum versehen. So weiss man, ab wann man beim Kunden nachfassen muss, falls er sich nicht meldet.
    1. Vorteil: Tickets auf "Rückmeldung" muss man nicht aktiv bearbeiten, da sich ja im Normalfall der Kunde wieder meldet (Tel, E-Mail, Brief, etc.). Ein Beispiel ist: Der Kunde muss einen Vertrag unterschrieben zurücksenden. In diesem Fall lässt man das Ticket bei sich (oder auf einer Rolle) und setzt es mit Zieldatum z.B. in einer Woche, auf "Rückmeldung". Falls der Vertrag dann nach 1 Woche nicht eintrifft, wechselt das Ticketdatum / Fälligkeit auf Rot (overdue). Dann den Kunden kontaktieren und nachfragen. Rückmeldung ist wie ein Parkplatz für Tasks, die in der Zukunft weiterbearbeitet werden müssen.
  2. anerkannt setzen, wenn bei dem Ticket von der bearbeitenden Person ein Handlungsbedarf festgestellt wird. Der Fall/Anfrage wird so für alle anderen User als "anerkannt" gekennzeichnet d.h. man weiss die Person wird zu dem Thema etwas tun.
  3. bestätigt setzen, wenn an einem Ticket nicht nach "anerkannt" nun auch aktiv daran gearbeitet wird. Das Ticket / Anfrage ist in der Realisation / Umsetzung.
  4. erledigt setzen, falls jemandem das Ticket noch prüfen & gutgeheissen muss. Z.B. noch etwas testen / approven oder zur Kenntnis nehmen. Diese Person stellt das Ticket dann nach der Überprüfung auf "geschlossen". Falls das Ticket nicht ok gelöst ist, weist man es mit einer Bemerkung an eine Person für weitere Arbeiten zu (Status: zugewiesen).

Mantis status.jpg

Ablauf des Status im Ticketing[Quelltext bearbeiten]

Mantis explanation2.png

Ablauf inkl. Status "Rückmeldung"[Quelltext bearbeiten]

Mantis explanation.png

Farbcode im Ablauf (State engine) Status Diagramm[Quelltext bearbeiten]

  • rot -> typischer Ablauf
  • grün -> erweiterter Ablauf
  • blau -> Expertenablauf
  • orange -> Falls Ticket nicht von Anfang an zugeordnet wurde

Suchbegriffe[Quelltext bearbeiten]

Ablauf, Ticket, Status, Stati, Erklärung Prozess, Flow, Ablauf