Hallo pascom,
einige unserer User befinden sich in mehreren Warteschlangen gleichzeitig(Auftragsannahme, Beratung, … etc.).
Zuvor verwendeten wir eine Voxtron-Anlage und in deren Desktop-Client war es so, dass wenn man sich als Benutzer auf Pause gesetzt hat, dies auch in allen Warteschlangen gleichzeitig galt.
Dass dies beim Classic Client nicht der Fall war und sich User nun “manuell” in allen Teams auf Pause setzen müssen, stört diese natürlich.
Eigentlich hatte ich gehofft, dass dies nur ein Denkfehler war und es dann im neuen Client nach der Überarbeitung auch anders sein würde nur leider musste ich nun nach dem Testen feststellen dass sich an der Funktion nichts geändert hat.
Zur “Abhilfe”, damit die User erstmal eine Möglichkeit besitzen habe ich eine Tray-Anwendung geschrieben mit der sie ihren Pause-Status steuern können.
Natürlich ist das aber sehr unhandlich und auch nicht sehr sauber eine externe dritte Anwendung extra dafür zu verwenden anstelle des Clients der dies mitbringen sollte.
Dass man auch nur in einzelnen Warteschlangen seinen Status setzen kann ist zwar schön, erscheint mir allerdings mehr wie ein “Feature”.
Da der Pause-Status (z.B. “Mittagspause”, “Schulung”, …) logisch näher am User (der Person, übergeordnet aller Agents / Warteschlangen) ist, als am jeweiligen Agent (Repräsentation des Users in einer spezifischen Warteschlange).
Schließlich wäre der zu erwartende Standardfall ansonsten, dass ein User (wenn er keinen Fehler macht, zumindest kurzzeitig) multiple Status hat (sowohl in der Mittagspause als auch am Arbeitsplatz) während er selbstständig durch alle Teams geht um seinen Status zu setzen.
Genau dieses Verhalten von multiplen Status empfinde ich aber mehr als einen Sonder- als Standardfall, somit ein “Feature”.
Um den Status mit der Tray-Anwendung zu setzen verwende ich bereits vorhandene REST-Calls:
**Setzen eines vordefinierten Grundes**
/services/queue/action
{"action":"pause","identity":"username","code":"10"}
**Setzen eines selbst definierten Grundes via Texteingabefeld**
/services/queue/action
{"action":"pause","identity":"username","reason":"Mein persönlicher Grund"}
**Zurücksetzen des Pause-Status**
/services/queue/action
{"action":"unpause","identity":"username"}
Dass die Grundfunktion bereits in der REST-API vorhanden war, zeigt mir eigentlich dass jemand bereits anfangs denselben Gedanken hatte und es eigentlich nur in der Implementierung gescheitert haben sollte.
Grüße aus dem Norden
Arcson