Guten Morgen liebe Community,
da wir in nächster Zeit planen auf OTRS als Ticketlösung umzusteigen sind wir gerade in der Phase angekommen in der wir alle noch offenen Fragen und Problemstellungen klären wollen. Bei der Auswahl des Ticketsystems ist es für uns sehr wichtig, dass wir automatisiert unsere Supportagents wechseln können. Um dies besser zu verstehen möchte ich dies einmal an einem Beispiel (über zwei Wochen) erläutern:
Am Montag den 01.01.2014 ab 00:00 Uhr hat Person A Primärsupport. Dies bedeutet, dass bei einem eingehenden Ticket Person A mit einem Mail über das neue Ticket benachrichtigt wird. Nun hat er 15 Minuten Zeit zu reagieren und das Ticket zu übernehmen. Falls er innerhalb dieser 15 Minuten nicht reagiert spring Person B als Backupsupporter (Esklation) für ihn ein und erhält eine Mail. Diesmal sind es 20 Minuten bis eine Aktion von Person B erfolgt sein muss. Ist dies auch nicht der Fall wird eine Mail an alle Mitarbeiter in unserer Abteilung gesendet (erneute Eskalation).
Der Supportdienst von Person A und Person B endet am 04.01.2014 um 23:59 und Person D und K haben nun für 96 Stunden Support. Wer nun wann Primärsupport oder Backup hat wird aktuell über einen Kalender im Ticketsystem gemanaged.
Besteht die Möglichkeit diese Funktionalität auch so in OTRS umzusetzen? Ich würde mich freuen wenn ihr mir in diesem Fall helfen etwas unter die Arme greifen könntet. Es besteht auch die Möglichkeit dies testweise umzusetzen, da gestern ein Testticketsystem installiert worden ist an welchem ich eure Vorschläge umsetzen kann.
Mit freundlichem Gruß
Xenome
Wechselnder Support automatisieren
Re: Wechselnder Support automatisieren
Hi,
dann schaumer mal ob ich bisschen was beitragen kann.

Allerdings ist ein "Einspringen" nicht der Gedanke von OTRS. Eine automatische Vertreterregelung gibt es erstmal im Standard nicht.
Ich schreibe bewusst 'evtl' weil es verschiedene Ansätze gibt.
Allerdings geht das mit Einschränkungen. OTRS ist bisschen anders strukturiert. (wie gesagt, keine Vetreterregelung)
Wenn Du von dem System verlangst, dass eine bestimmte Person A oder Person B spezielle Funktionen übernimmt z.b. eine Aktion an einem neuen Ticket (darauf raegieren, dem Kunden antworten) geht das zwar, aber prinzipiell arbeitet das OTRS Team-/Rollenorientiert.
Es gibt also 1-n Personen in einem Team/Rolle welche alle die Aufgabe haben. Dass es am Ende eine Person machen wird, ist klar, aber
die Aufgabe verteilt sich im Regelfall über ein Team. (sofern mehr als eine Person da ist)
Also in der Summe kriegst Du das schon auch mit einer Person wenn Du diese Person als ein ein Mann Team siehst
Ich schreib das nur
deshalb, weil es erstmal in der Standardvariante kein aktives Dispatching an Personen gibt. Ich hoffe, das ist Verständlich.
Das zweite ist, dass der zeitliche Eskalationsmechanismus losgelöst ist von einem hierarchischen Eskalationsmechanismus. Beides
ist aber (auch in Kombination) mit OTRS möglich. Wer also wann welches Ticket bekommt, wer wie informiert wird, dass Tickets
eskalieren ist mehr oder weniger frei definierbar.
Schwerer wirds, wenn Du Deine Personen einen Schicht übernehmen, so wie Du das beschreibst (96 Stunden Schicht). Sowas kann
OTRS meines Wissens nicht im Standard. OTRS kennt zwar Arbeitszeitenkalender, aber keinen Schichtkalender. Und auch keine Zuweisung
von Agenten zu einem Kalender, sondern lediglich Queues und SLAs werden Arbeitszeitkalendern zugeordnet.
Du kannst trotzdem Deine Anforderung umsetzen, auch wenn es am Ende eine gedankliche Strukturänderung Deines Supportgedanken
erfordert.
In der Summe heisst das die Standardvariante KANN es, erfordert aber viel Konfiguration und v.a. Verständnis über die Eskalationsmechanismen.
Besser sieht es aus, wenn Du bestimmte Funktionen, welche Du einforderst, aber nicht Standard sind, entwickelst oder entwickeln lässt.
Helfen tun Dir unter Umständen Feature Add Ons wie "OTRSAdvancedEscalations" mit dem ist so ziemlich alles möglich wenn man das
so ansieht.
http://www.otrs.com/feature-add-on/adva ... calations/
ich habe das aber selber noch nie eingerichtet.
Insgesamt: Keine Garantie auf Korrektheit
Achso... es gibt IMHO auch aktives Dispatching. Aber das hab ich auch nur gehört. Vielleicht weiß jemand anders was darüber.
Flo
dann schaumer mal ob ich bisschen was beitragen kann.
das ist fast StandardXenome wrote: Am Montag den 01.01.2014 ab 00:00 Uhr hat Person A Primärsupport. Dies bedeutet, dass bei einem eingehenden Ticket Person A mit einem Mail über das neue Ticket benachrichtigt wird. Nun hat er 15 Minuten Zeit zu reagieren und das Ticket zu übernehmen.

Das kann evtl. über einen Standard First Response Escalation Warning Time Regelung eingestellt werden.Xenome wrote: Falls er innerhalb dieser 15 Minuten nicht reagiert spring Person B als Backupsupporter (Esklation) für ihn ein und erhält eine Mail.
Allerdings ist ein "Einspringen" nicht der Gedanke von OTRS. Eine automatische Vertreterregelung gibt es erstmal im Standard nicht.
Das geht evtl. über Standard First Response Time Escalation.Xenome wrote: Diesmal sind es 20 Minuten bis eine Aktion von Person B erfolgt sein muss. Ist dies auch nicht der Fall wird eine Mail an alle Mitarbeiter in unserer Abteilung gesendet (erneute Eskalation).
Ich schreibe bewusst 'evtl' weil es verschiedene Ansätze gibt.
Das geht.Xenome wrote: Der Supportdienst von Person A und Person B endet am 04.01.2014 um 23:59 und Person D und K haben nun für 96 Stunden Support. Wer nun wann Primärsupport oder Backup hat wird aktuell über einen Kalender im Ticketsystem gemanaged.
Allerdings geht das mit Einschränkungen. OTRS ist bisschen anders strukturiert. (wie gesagt, keine Vetreterregelung)
Wenn Du von dem System verlangst, dass eine bestimmte Person A oder Person B spezielle Funktionen übernimmt z.b. eine Aktion an einem neuen Ticket (darauf raegieren, dem Kunden antworten) geht das zwar, aber prinzipiell arbeitet das OTRS Team-/Rollenorientiert.
Es gibt also 1-n Personen in einem Team/Rolle welche alle die Aufgabe haben. Dass es am Ende eine Person machen wird, ist klar, aber
die Aufgabe verteilt sich im Regelfall über ein Team. (sofern mehr als eine Person da ist)

Also in der Summe kriegst Du das schon auch mit einer Person wenn Du diese Person als ein ein Mann Team siehst

deshalb, weil es erstmal in der Standardvariante kein aktives Dispatching an Personen gibt. Ich hoffe, das ist Verständlich.
Das zweite ist, dass der zeitliche Eskalationsmechanismus losgelöst ist von einem hierarchischen Eskalationsmechanismus. Beides
ist aber (auch in Kombination) mit OTRS möglich. Wer also wann welches Ticket bekommt, wer wie informiert wird, dass Tickets
eskalieren ist mehr oder weniger frei definierbar.
Schwerer wirds, wenn Du Deine Personen einen Schicht übernehmen, so wie Du das beschreibst (96 Stunden Schicht). Sowas kann
OTRS meines Wissens nicht im Standard. OTRS kennt zwar Arbeitszeitenkalender, aber keinen Schichtkalender. Und auch keine Zuweisung
von Agenten zu einem Kalender, sondern lediglich Queues und SLAs werden Arbeitszeitkalendern zugeordnet.
Du kannst trotzdem Deine Anforderung umsetzen, auch wenn es am Ende eine gedankliche Strukturänderung Deines Supportgedanken
erfordert.

In der Summe heisst das die Standardvariante KANN es, erfordert aber viel Konfiguration und v.a. Verständnis über die Eskalationsmechanismen.
Besser sieht es aus, wenn Du bestimmte Funktionen, welche Du einforderst, aber nicht Standard sind, entwickelst oder entwickeln lässt.
Helfen tun Dir unter Umständen Feature Add Ons wie "OTRSAdvancedEscalations" mit dem ist so ziemlich alles möglich wenn man das
so ansieht.
http://www.otrs.com/feature-add-on/adva ... calations/
ich habe das aber selber noch nie eingerichtet.
Insgesamt: Keine Garantie auf Korrektheit

Achso... es gibt IMHO auch aktives Dispatching. Aber das hab ich auch nur gehört. Vielleicht weiß jemand anders was darüber.
Flo
OTRS 2025 SILVER (Prod)
OTRS 2025 auf Debian 12 (Test)
Znuny 7.x latest version testing auf Debian 12
-- Ich beantworte keine Forums-Fragen PN - No PN please
I won't answer to unfriendly users any more. A greeting and regards are just polite.
OTRS 2025 auf Debian 12 (Test)
Znuny 7.x latest version testing auf Debian 12
-- Ich beantworte keine Forums-Fragen PN - No PN please
I won't answer to unfriendly users any more. A greeting and regards are just polite.