Mein Unternehmen hat sich entschieden, von Jira auszutreten. Wir sind auf der Suche nach einer Alternative und sind dabei auf OTOBO gestoßen. Ich habe mal eine OTOBO 10.1.6 Testumgebung aufgesetzt und ich bin persönlich damit zufrieden, aber es gibt noch einige offene Punkte die wir klären müssen.
1. Workflows
In Jira konnten wir Workflows einrichten, die definieren, wie ein Ticket verlaufen kann, z.B. muss ein offenes Ticket erst auf „in Bearbeitung“ gesetzt werden, damit es geschlossen werden kann. Ich denke mir, sowas wäre mit etwas Aufwand mit den ACLs umsetzbar, bin mir aber nicht so sicher.
2. Zugriff auf Kunden(benutzer)verwaltung
Wir möchten die Verwaltung der Kundenbenutzer den Admins überlassen, wissen aber nicht, wie wir den Zugriff darauf beschränken.
3. Vereinfachung der Agentenoberfläche
Die Kundenoberfläche ist sehr ansprechend, besser sogar als Jira. Dagegen die Agentenoberfläche… gewöhnungsbedürftig. Im welchen Umfang kann man die Agentenoberfläche vereinfachen, damit es annähernd so einfach zu bedienen ist wie Jira? Wir verwirren uns vor allem in der Ticketansicht bei Begriffen wie „Telefon-Ticket“ und „Besitzer“ und „Verantwortlicher“.
4. Teilen der Tickets unter mehreren Kundenbenutzern
In Jira können mehrere Agenten und Kunden ein Ticket abonnieren und Benachrichtigungen erhalten. Nach meinem Wissensstand können Kunden im selben Unternehmen untereinander Tickets sichten, aber es wird z.B. nur der Ersteller des Tickets benachrichtigt, nicht andere Beobachter.
5. Migration von Jira-Tickets nach OTOBO
Ist es möglich, Tickets von Jira (automatisch) nach OTOBO zu importieren?
6. Avatare
Dass Avatare nur über Gravatar gesetzt werden können, finden wir unglücklich. Gibt es da einen Umweg?
Falls mich jemand zu diesen Punkten aufklären kann, wird es uns deutlich leichter fallen, eine Entscheidung zu treffen. Danke im Voraus!
-Meik
This topic was modified 6 months, 3 weeks ago by Meik Krzykala. Reason: Rechtschreibkorrektur im Titel
Zu 2. sofern das Voll Admins sind, die auch das Gesamte System konfigurieren dürfen, sollten diese ja in der Gruppe „admin“ sein. Die Agenten Zuordnung macht man ja dann über den Punkt „Agenten <-> Gruppen“
Zu 6. da gab es mal ein Addon von maxence.de , das ist aber scheinbar für Otobo nicht auf dem aktuellen Stand.
danke für die Antwort. Zu 2: Das Problem ist eigentlich dass normale Agenten (in der Gruppe „users“) die Kundenbenutzer verwalten können (erstellen, bearbeiten, gültig oder ungültig setzen etc.) und das möchten wir verhindern.
Zu 6: Beim Versuch das Paket zu installieren bekomme ich die Meldung: „Dieses Paket kann nur mit OTOBO-Version 6.0.x oder neuer verwendet werden“ Eigentlich habe ich ja 10.1.6 was das Kriterium erfüllt aber es scheint trotzdem nicht kompatibel zu sein.
genau, das kann auf verschiedene Arten und weisen gehen – bspw. mit ACLs, ggf. kann hier auch das Prozessmanagement unterstützen.
Kleiner persönlicher Hinweis: ein Status „in Bearbeitung“ kann weggelassen werden, weil durch die Kombination von Status (bspw. „offen“) und der Ticketsperre schon ersichtlich sein sollte, ob das Ticket bearbeitet wird. Aber das nur aus Beratungssicht am Rande.
Die Agenten-Zuordnung bitte über „Agenten <-> Rollen“ und „Rollen <-> Gruppen“ lösen, statt über „Agenten <-> Gruppen“ => den Button blende ich gerne aus.
Zum eigentlichen Problem: die Gruppe „users“ steuert standardmäßig die Aktionen. Du kannst entweder
den normalen Agenten diese Gruppen-Berechtigungen wegnehmen oder
eine andere (neue) Gruppe hinter diese Aktionen packen
Vereinfachen lässt sich vieles. Bspw. ist der Verantwortliche standardmäßig überhaupt nicht aktiviert, das kann man einfach wieder deaktivieren. Schau gerne mal in die Systemkonfiguration unter Core > Ticket, da findest du einige Einstellungen zu grundlegenden Funktionen, die man deaktivieren kann.
Sollte es dir um die Benamung gehen, so kann man das bspw. über die Übersetzungen regeln und für das englische Original „Owner“ bspw. als deutsche Übersetzung „aktueller Bearbeiter“ o.ä. eintragen.
Außerdem kannst du in der Systemkonfiguration viele Aktionen oder Knöpfe einfach deaktivieren (bspw. unter Frontend > Agent > Toolbar oder wenn du nach den „ModuleRegistration“-Optionen schaust). Hier lässt sich sehr vieles anpassen.
Das ist alles Einstellungssache. Um ein Team abzubilden, werden bspw. die Queues verwendet. Um bspw. Benachrichtigungen zu steuern, gibt es in den persönlichen Einstellungen die Möglichkeit (bspw.) Queues zu abonnieren. Außerdem findest du in den Einstellungen für die Ticket-Benachrichtigungen für jede einzelne die Möglichkeit, den/die Empfänger auszuwählen.
Zusätzlich könnte hier ggf. noch die Beobachten-Funktion (Ticket::Watcher) interessant sein.
Es gibt einen Standard-Konnektor in den Webservices. Der ist für eine dauerhafte Anbindung konzipiert, aber vielleicht findest du da ein bisschen Inspiration, wie du Daten (auch einmalig) austauschen kannst.
Unter Frontend::AvatarEngine kannst du Gravatar deaktivieren, dann sieht man grafisch dargestellt die Initialen der Benutzer. Ansonsten müsste man hier eine Lösung noch entwickeln lassen. Da OTOBO open source ist, ist das ja grundsätzlich kein Problem.
Wir verwenden Cookies, um diese Website optimal gestalten und laufend verbessern zu können. Für Analyse und Statistik nutzen wir Google Analytics (anonymisiert).
Unsere Website verwendet Cookies. Cookies sind kleine Textdateien, die beim Aufruf von Websites im Internetbrowser bzw. vom Internetbrowser auf Ihrem Endgerät gespeichert werden. Diese Cookies enthalten eine charakteristische Zeichenfolge, die eine eindeutige Identifizierung des Browsers beim erneuten Aufrufen der Website ermöglichen.
Sie können das Setzen von Cookies jederzeit über eine entsprechende Einstellung in Ihrem Internetbrowser verhindern. Bereits gesetzte Cookies können jederzeit manuell oder automatisiert gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Wird das Setzen von Cookies im Browser deaktiviert, sind unter Umständen nicht alle Funktionen der Website vollumfänglich nutzbar.
Wir gehen grundsätzlich sehr sparsam mit Cookies um.
Detaillierte Informationen finden Sie in Abschnitt 4 unserer Hinweise zum Datenschutz.
Technisch erforderliche Cookies
Diese Cookies sind erforderlich, um die Darstellung dieser Website und einiger ihrer Features zu gewährleisten.
Deshalb bieten wir hier auch keine Möglichkeit an, diese Cookies zu deaktivieren.
Dessen ungeachtet können Sie jederzeit durch entsprechende Einstellungen in Ihrem Browser alle Cookies deaktivieren. Unter Umständen stehen Ihnen dann nicht mehr alle Funktionalitäten dieser Website zur Verfügung.
Weitere Informationen zu den gesetzten Cookies und zur Speicherdauer finden Sie in Abschnitt 4 unserer Hinweise zum Datenschutz.
Cookies von Google Analytics
Beim Besuch der Website werden Cookies von Google Analytics gesetzt, die eine Analyse der Benutzung unserer Website durch Sie ermöglichen. Ihre IP-Adresse wird dabei durch technische Vorkehrungen pseudonymisiert (IP-Anonymisierung und Deaktivierung der User-ID). Eine Zuordnung der Daten zum aufrufenden Nutzer ist daher nicht mehr möglich. Die Daten werden nicht gemeinsam mit anderen personenbezogenen Daten der Nutzer gespeichert.
Wenn Sie nicht möchten, dass wir Ihren Besuch auf unserer Website verfolgen, können Sie das Tracking in Ihrem Browser hier deaktivieren:
Hinweise zum Datenschutz
Detaillierte Informationen zum Einsatz von Cookies sowie unsere Datenschutzerklärung finden Sie hier: