Status im Ticketing: Unterschied zwischen den Versionen
Markus (Diskussion | Beiträge) |
Roger (Diskussion | Beiträge) (→Ablauf des Status im Ticketing) |
||
(18 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | == Einfache Verwendung | + | == Einfache Verwendung Status Feld == |
− | '''neu''' | + | # '''neu''', Status setzen, wenn ein Ticket erfasst wird und niemandem zugewiesen ist. |
− | + | # '''offen''' (früher zugewiesen) Status setzen, wenn Ticket einer verantwortlichen Person / Rolle zugewiesen wird. Wichtig: Rollen arbeiten nicht, das sind nur Warteschlangen, Verteilgefässe. Zum abarbeiten an eine Person zuweisen / sich selbst zuweisen. Die eingetragene Person hat den Lead. | |
+ | # '''geschlossen''' Status setzen, wenn Ticket / Fall abgeschlossen ist. | ||
+ | == Status Wechsel bei Inbound E-Mail== | ||
+ | # Ticket auf Rückmeldung / Pending stellen, wenn man auf eine Antwort eines Kunden per E-mail wartet - zudem das Fälligkeitdatum setzen. | ||
+ | ## Wird das Fälligkeitsdatum erreicht, springt die Ticketfarbe auf ROT. Hier ist Handlungsbedarf notwendig. | ||
+ | # Sobald eine Rückantwort / E-Mail ins Ticket reinkommt, springt der Status wieder auf "offen" | ||
+ | # Generell: Wenn eine Nachricht (E-Mail Antwort mit [Ticket 123456] via Inbox Automat / Verarbeitungs-Engine) automatisch an ein Ticket gehängt wird, welches Status Erledigt, Geschlossen oder Wartend/Pending hat, wird der Status wieder auf "Offen" gestellt". | ||
+ | # Bei Status Bestätigt und In Bearbeitung wird der Status nicht verändert. Wichtig: Das kann auch geändert werden pro Mandant, das z.B. auch bei den beiden Stati dieser wieder auf "Offen" springt. | ||
+ | == Wie erkennt der Mitarbeiter im Ticketing Monitor (view Ticket), dass eine Rückmeldung eingegangen ist? == | ||
+ | # In der View Ticket Übersicht, wird per Standard auf "Zuletzt aktualisiert" sortiert | ||
+ | ## d.h. oben sind die Tickets mit den neusten Updates, Notizen, Emails, Änderungen - Empfehlung immer ab dieser Ansicht arbeiten | ||
+ | # Man sieht in der View, welche Tickets z.B. heute aktualisiert wurden (top down) | ||
+ | # Mans sieht (fett Anzeige, bold), welche Tickets in den letzten 6 Stunden (einstellbar im Filter) eine Änderung hatten. | ||
+ | # So sieht der Benutzer sofort, was in seinen Tickets neu ist (Statuswechsel, Notizen, E-Mails, Zudweisungsänderungen usw.) | ||
+ | == Erweiterte Verwendung Status Feld == | ||
+ | # '''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. | ||
+ | ## 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''' 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. | ||
+ | # '''bestätigt''' setzen, wenn an einem Ticket nicht nach "anerkannt" nun auch aktiv daran gearbeitet wird. Das Ticket / Anfrage ist in der Realisation / Umsetzung. | ||
+ | # '''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). | ||
+ | [[File:TicketingStati.jpg|1000px]] | ||
+ | old: | ||
+ | [[Image:Mantis_status.jpg]] | ||
+ | === Ablauf des Status im Ticketing === | ||
+ | # Zugewiesen heisst nun "Offen / Open" | ||
+ | [[Image:Mantis_explanation2.png]] | ||
− | + | [[Kategorie:Ticketing]] | |
− | |||
− | + | === Ablauf inkl. Status "Rückmeldung" === | |
− | + | [[Image: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 | ||
− | + | [[Kategorie:Ticketing]] | |
− | |||
− | + | == Suchbegriffe == | |
− | + | Ablauf, Ticket, Status, Stati, Erklärung Prozess, Flow, Ablauf, Pending, Rückmeldung | |
− | + | [[Category:Ticketing]] | |
− | |||
− | + | [[Kategorie:Ticketing]] | |
− | |||
− | |||
− | |||
− | [[ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Aktuelle Version vom 18. November 2022, 10:30 Uhr
Inhaltsverzeichnis
Einfache Verwendung Status Feld
- neu, Status setzen, wenn ein Ticket erfasst wird und niemandem zugewiesen ist.
- offen (früher zugewiesen) Status setzen, wenn Ticket einer verantwortlichen Person / Rolle zugewiesen wird. Wichtig: Rollen arbeiten nicht, das sind nur Warteschlangen, Verteilgefässe. Zum abarbeiten an eine Person zuweisen / sich selbst zuweisen. Die eingetragene Person hat den Lead.
- geschlossen Status setzen, wenn Ticket / Fall abgeschlossen ist.
Status Wechsel bei Inbound E-Mail
- Ticket auf Rückmeldung / Pending stellen, wenn man auf eine Antwort eines Kunden per E-mail wartet - zudem das Fälligkeitdatum setzen.
- Wird das Fälligkeitsdatum erreicht, springt die Ticketfarbe auf ROT. Hier ist Handlungsbedarf notwendig.
- Sobald eine Rückantwort / E-Mail ins Ticket reinkommt, springt der Status wieder auf "offen"
- Generell: Wenn eine Nachricht (E-Mail Antwort mit [Ticket 123456] via Inbox Automat / Verarbeitungs-Engine) automatisch an ein Ticket gehängt wird, welches Status Erledigt, Geschlossen oder Wartend/Pending hat, wird der Status wieder auf "Offen" gestellt".
- Bei Status Bestätigt und In Bearbeitung wird der Status nicht verändert. Wichtig: Das kann auch geändert werden pro Mandant, das z.B. auch bei den beiden Stati dieser wieder auf "Offen" springt.
Wie erkennt der Mitarbeiter im Ticketing Monitor (view Ticket), dass eine Rückmeldung eingegangen ist?
- In der View Ticket Übersicht, wird per Standard auf "Zuletzt aktualisiert" sortiert
- d.h. oben sind die Tickets mit den neusten Updates, Notizen, Emails, Änderungen - Empfehlung immer ab dieser Ansicht arbeiten
- Man sieht in der View, welche Tickets z.B. heute aktualisiert wurden (top down)
- Mans sieht (fett Anzeige, bold), welche Tickets in den letzten 6 Stunden (einstellbar im Filter) eine Änderung hatten.
- So sieht der Benutzer sofort, was in seinen Tickets neu ist (Statuswechsel, Notizen, E-Mails, Zudweisungsänderungen usw.)
Erweiterte Verwendung Status Feld
- 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.
- 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 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.
- bestätigt setzen, wenn an einem Ticket nicht nach "anerkannt" nun auch aktiv daran gearbeitet wird. Das Ticket / Anfrage ist in der Realisation / Umsetzung.
- 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).
Ablauf des Status im Ticketing
- Zugewiesen heisst nun "Offen / Open"
Ablauf inkl. Status "Rückmeldung"
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, Pending, Rückmeldung