Hi,
ncmbu wrote:reneeb wrote:Punkt 2 kannst Du doch auch in der Free-Variante mit einem Dynamischen Feld erledigen...
Klar kann ich ein dynamisches Feld anlegen und dann da "1st Level" oder "3rd Level" reinschreiben. Aber das ist ja von der Funktion her nicht vergleichbar mit unterschiedlichen Queues. Eine Queue "3rd Level" könnte man z.B. einer bestimmten Gruppe an Bearbeitern zuweisen; diese könnten die Queue dann abonnieren um Benachrichtigungen über neue Tickets o.ä. zu erhalten. Ich wüsste nicht, wie ich Tickets, die einen festgelegten Wert in einem dynamischen Feld haben, abonnieren sollte.
Das "Problem" ist, dass Du entweder Queues oder Services abonieren kannst. Wenn Du jetzt über dynamische
Felder Deine Ansichten definierst, wirst Du umbauen müssen
- eigene Suchvorlagen (Ansicht nach Queues oder Services bringt Dir nichts mehr)
- eigene Dashbaord Widgets
- eigene Ticket Notifications
- ...
Das ist machbar, bedarf aber einer sehr guten und genauen Konfiguration. Ich für meinen Teil versuche, das
zu vermeiden.
Zu Punkt 1: Du kannst ja ein eigenes Attribut für die Kunden anlegen. Weiterhin kannst Du Services nutzen und bei den Services unterschiedliche SLAs für Privat- und Geschäftskunden erstellen. Mit ACLs kannst Du dann je nach Wert des Kundenattributs die SLA-Auswahl einschränken.
Die Services wollen wir nach der Umstrukturierung für unsere Produkte nutzen, insofern kommen diese für die Privat-/Business-Kunden-Unterscheidung eigentlich nicht in Frage. Zudem besteht ja auch eine der Haupt-Anforderungen in "Unterschiedliche Signatur für Business-/Privatkunden" und Signaturen lassen sich meines Wissens (in der Free Variante) nicht über Services beeinflussen.
Die Signaturen sind im OTRS erstmal immer Queue gebunden. Wenn Du also verschiedene Signaturen brauchst,
musst Du erstmal verschiedene Queues dafür bauen.
Es gibt die Alternative, dass Du Dir die Signaturen zusammenbaust aus Dynamischen Feldern. Dann kannst
Du halt die Standard Funktionen Queues <-> Signaturen nicht nutzen sondern musst in jedes Template
halt Deine Werte von dynamischen Feldern drinstehen haben, als Variable.
Die Variable befüllt sich auf Grund der Kunden Infos. Du kannst Werte aus der CustomerUser Mapping Table
in dynamische Felder schreiben.
Auch hier - genauso wie oben - ist es erheblicher Aufwand, muss genau konfiguriert werden.
Die Alternative = Kundenbezogene Queues sind aber am Ende auch übles Queue Design.
Wenn ich die Geschäftsführung richtig verstanden habe, dann soll es letzenendes darauf hinaus laufen, dass jedes einzelne Ticket in der Auswertung unterschieden werden kann nach Produkt (ca. 14 Stück, wollen wir über Services definieren), Privat-/Business-Kunde und 1st/2nd/3rd-Level, also letztlich 14×2×3 Möglichkeiten.
Kannst Du über Queues, Services, Dynamische Felder konfigurieren. Für Auswertungen garnicht mal so schwer.
Ich denke, Dein Problem ist "nur" die Signatur.
Achso... in dem Fall ist es auch egal ob Free oder Business.
Die Business Solution hat die gleichen grundsätzlichen Ansätze.
wurzel wrote:Kurz: Kann man Kunden in der Business-Variante in verschiedene Kategorien einteilen und diesen Kategorien Signaturen / Eskalationszeiten zuweisen, ohne separate Queues zu benötigen? (Außerdem soll das ganze auch bei der Auswertung verwertbar sein)
Das sollte auch in der Free gehen. Sei es mit dynmischen Feldern oder mit spezifischen Prozesstickets.
Das klingt interessant. Kannst du mir da weitere Informationen zu geben? Also ich denke ich bekomme es hin den Kundeninformationen die Unterscheidungskriterien hinzuzufügen und diese im Ticket in ein dynamisches Feld zu übernehmen. Ich weiß allerdings nicht, wo ich dann ansetzen soll, um Signatur oder Eskalationszeit nach dem dynamischen Feld festzulegen.
Das ist eine Kombi aus CustomerUser Data mapping Informationen in dynamische Felder schreiben,
Generic Agents, ggf. Ticket Notifications. Wie oben beschrieben, sehr aufwändig. Vieles muss der
Generic Agent übernehmen.
Wenn ihr den Weg gehen wollt, OK. Ich würde mir überlegen, ob ich nicht doch eine Signatur verwende für alle
Kunden. Das würde viel Arbeit ersparen. SLAs, Services, sind sowieso Kundenbenutzer-bezogen, das sollte klappen.
Eine (unschöne) Alternative ist, zwei Instanzen aufzubauen.
Eine für privatkunden, eine für Geschäftskunden.
Vorteil -> Saubere Trennung, einfache Konfig
Nachteil -> zwei Instanzen
viele Grüße
Flo