Ticket Eskalation nach 3 Customer Anfragen

[MarvZiege]

Hallo zusammen, und vorneweg vielen Dank für die Hilfe.
Kurz zur Situation. Es gibt momentan ca. 200 Tickets im System. Status neu und offen.
Es gibt 3 Agenten, die die Tickets abarbeiten. Es ist ganz verständlich, dass diese 3 Agenten nicht alle Tickets sperren können.
Nun möchte ich aber die nicht gesperrten Tickets eskalieren lassen, bei denen ein Kunde 3 mal nachgefragt hat. Z.B. nach dem Stand der Bearbeitung.
Ich vermute mal, dass ich so etwas über eine Datenbank Anfrage erledigen muss. Und zwar über die Artikel. Aber wie?
Hier komme ich leider nicht weiter und hoffe auf Unterstützung aus der Community.

Wenn ich noch weitere Infos beitragen soll, dann mache ich das natürlich gerne.

Viele Dank
Marvin

[wurzel]

Hi,

Artikel zählen (Kunden Artikel) habe ich mal gesehen mit Webservices und xlst. Aber das ist mir zu hoch (bzw. wüsste nicht wie das genau geht)


'ne Andere Anmerkung: Nur weil Du Tickets gezielt eskalieren kannst, heisst ja nicht, dass Deine Agenten mehr abbarbeiten können. Stelle Dir also mehr Agenten ein. Oder was versprichst Du Dir von den Eskalationen?

viele Grüße
Flo

[MarvZiege]

Hi Flo, danke für die schnelle Antwort.
Ja genau, dein Ansatz ist genau der Weg, den ich auch gehe. Ich versuche die Anzahl der Artikel zu zählen. Und zwar aufeinanderfolgende Artikel, die in der Datenbank in der Spalte Change_by in der Tabelle Article als Wert immer die '1' stehen haben.
Z.B. Bin ich schon soweit.
Zähle die Anzahl der Artikel, die jede Ticket_ID hat.
SELECT `ticket_id`, COUNT(*) FROM article GROUP BY `ticket_id`;

Nun benötige ich noch den Trick, dass er nur aufeinanderfolgende Werte zählt. Ist das nicht was für den OTRS Guru?

Und nun zu deiner Anmerkung.

'ne Andere Anmerkung: Nur weil Du Tickets gezielt eskalieren kannst, heisst ja nicht, dass Deine Agenten mehr abbarbeiten können. Stelle Dir also mehr Agenten ein. Oder was versprichst Du Dir von den Eskalationen?

Das ist richtig. Die Agenten können dadurch nicht mehr abarbeiten...ABER..dadurch können die Agenten gezielter abarbeiten;)
Thats the Trick....
Mehr Agenten einstellen? Wenn das so einfach gehen würde...

[wurzel]

Hi,

Im SQL bin ich leider ne Pfeiffe.

Aber ich werd Kunde bei Dir. Da ich jetz Deinen Eskalationsmechanismus kenne, werden meine Sachen gezielter abgearbeitet.

Sorry, aber ich denke dass Deine Idee nicht gut ist.

Viele Grüße
Flo

[MarvZiege]

Hi, ok danke für die ehrliche Rückmeldung. Was genau findest du denn an dieser "Eskalationsstrategie" nicht gut. Und was würdest du mir empfehlen?
Kurz zum Hintergrund.
Es ist bei uns nicht die einzige Eskalationsstufe.
Wir eskalieren zusätzlich nach Queue. Z.B. Restore und/oder Password Reset.
Und zusätzlich wird nach Ticket Alter eskaliert.
Natürlich wird nicht der Kunde bevorzugt der am lautesten Ruft....
Wir wollen es als zusätzlichen Eskalationspunkt nehmen. Nehmen wir an es gibt Tickets, die nun 30 Tage Alt sind. Und keinen Bearbeiter haben.
Nach 30 tage, kommt eine Rückfrage vom Kunden zum Stand der Bearbeitung. Ticket ist nicht gelocked, also geht die Anfrage bei knapp 200 Ticktes unter. Nach 40 tagen fragt der Kunde ein 2.tes mal nach.
Nun wäre der Punkt, bei dem man eskalieren lassen könnte.

Was meinst Du? Macht das Sinn?

Viele Grüße
Marvin

[wurzel]

Hi,

ich denke halt, dass Die Ticket Bearbeitung trotz der Meldung "Ticket ist eskaliert" nicht besser wird.

Wenn die Agenten jetzt schon nicht nachkommen (30 Tage lang Tickets nicht anfassen) warum sollte es mit Eskalationen besser werden? Am Ende eskalieren eh auch alle Tickets. Dann hast Du nix gewonnen.

viele Grüße
Flo

[Charmacas]

Ich verfolge die Diskussion und möchte an dieser Stelle Flo vollkommen zustimmen.

[MarvZiege]

Vielen Dank für die hilfreichen Rückmeldungen. Ob und in welchen Umfang dies eine sinnvolle Eskalation ist, steht allerdings auf einer anderen Karte.
Natürlich haben wir ganz klassisch eine Eskalation auf bestimmten Queues in Zusammenhang mit dem Ticketalter.

Ich möchte es von nun an auch nicht mehr Eskalation sondern Beschwerdemanagement nennen.
Konkret zu mir. Wir haben knapp 200 Tickets(Status Neu, Offen) im System.
Davon sind knapp 70 gesperrt verteilt auf 3 Agenten. Nun kommt es vor, dass von den restlichen 130, die momentan nicht gesperrt sind.
Ca. 5 bis 10 Kunden zum Stand des Tickets nachfragen. Also max. 10 Tickets, bei denen der Kunde mehrmals zum Bearbeitungsstand nachfragt.

Im Sinne eines Beschwerdemanagement ist es doch sinnvoll, diese 10 Tickets zu heraus zu filtern. Und sei es nur um eine automatische Antwort zu versenden. "Wir haben Sie nicht vergessen, wir werden das Ticket bald bearbeiten....oder so ähnlich". Aber gar nicht auf diese Tickets zu antworten halte ich persönlich auch nicht für den richtigen Weg.

Die technische Umsetzung habe ich nun versucht über eine Datenbankabfrage. Und zwar in der Tabelle article
Dort habe ich mir zum Beispiel das Ticket mit der Ticket ID 29 herausgesucht.

Code: Select all

SELECT * FROM `article` WHERE `ticket_id` =29 ORDER BY `ticket_id` ASC 

Jeder Artikel zur Artikel ID hat eine fortlaufenden Nummer: id
Und das Feld Change_by gibt darüber Auskunft, wer das Ticket geändert hat.
Change_by gleich 1 heißt, dass das System geändert hat.
Und damit sollte ich es herausfinden. Nur wie lautet die korrekt DB Abfrage.

Vielen Dank

[wurzel]

Hi,

das würde ich dann evtl. anders lösen.

Die Tickets, die nicht gesperrt sind würde ich über einen Generic Agent entweder
- in eine Queue verschieben (z.B. zu Beantworten)
- in einen speziellen Status setzen (z.B. neu - nicht beantwortet) oder so
- oder in einer anderen Form kennzeichnen (setzen eines dynamischen Feldes)

Wenn dann eine Rückmeldung vom Kunden kommt auf diese Tickets, kann der Generic Agent die Prio hochsetzen. Oder auch sonstwas am Ticket vermerken. z.B. 1x Rückmeldung, oder zweite Rückmeldung (über z.B. 10 dynamische Felder)

und entsprechend ist die Auswertung dann leichter (ohne SQL)


Wenn sich Agenten die Tickets sperren müssen sie diese dann aus der Queue (oder Status, oder was auch immer) rausnehmen - oder ein Generic Agent übernimmt das.


Das würde ICH machen (weil ich SQL nicht kann)


viele Grüße
Flo

[MarvZiege]

Hi, vielen Dank. Ein hilfreicher Hinweis, es über den Generic Agent zu machen.
Nun muss ich nur noch heraus finden, welcher Event-Trigger es ist, wenn sich ein Kunde erneut auf ein nicht gesperrtes Ticket meldet.
Es sollte aber doch wenn dann nur ArticleCustomerNotifcation oder Article Update sein.

Ich werde das ganze einmal testen. Und wieder berichten

Event-Trigger-Artikel.jpg