Zum Inhalt der Seite
  • NETZWERK



Animexx Helpdesk – Das Helpdesk-System in Bildern Animexx, Animexx, Ehrenamt, Helpdesk

Autor:  animexx

Dein Fanart wurde zurückgestellt?
Du bist über einen fragwürdigen Weblogeintrag gestoßen und möchtest diesen melden.
Dir ist aufgefallen, dass ein Charakter fehlt, zu dem du etwas geschrieben, gezeichnet, gebastelt oder von dem du ein Cosplay angefertigt hast?
Du hast ein technisches Problem mit der Seite?
Dir ist eine Verbesserung für einen Fanwork-Bereich eingefallen oder generell eine Verbesserung?
Der Preis bei einem Manga, einer CD, einem Artbook oder einer DVD stimmt nicht oder fehlt? Vielleicht ist sogar der Erscheinungstermin komplett falsch?
Oder hast du ein ganz anderes Problem auf Animexx?


Bei diesen und anderen Anliegen, kannst du dich an den Helpdesk wenden.

In einer kleinen Eintragsreihe möchten wir euch kurz und (hoffentlich) verständlich darüber informieren, wie der Helpdesk generell aufgebaut ist und wie manche Abläufe geregelt sind oder allgemein einen Einblick hinter die Kulissen geben.

Wir haben ein paar Einträge für diese Reihe vorbereitet, falls möglich gehen wir aber auch gerne auf spezielle Wunschbereiche/Abläufe von euch genauer ein. 
Wir halten uns somit auch die Anzahl der Teile dieser Reihe offen und hoffen, dass wir die ein oder andere Ungereimtheit bezogen auf den Helpdesk hiermit aufklären können.

Teil 1: Allgemeine Informationen

Teil 2: Fragen und Missverständnisse

Teil 3: 
Das Helpdesk-System in Bildern

 

In diesem Teil werden wir euch einen Einblick in den Arbeitsbereich "Helpdesk" geben und anhand von Screenshots zeigen, wie ihr euch die Arbeitsmaske der Helpdesk-Mitarbeiter vorstellen könnt, wenn eure Anfragen bei uns eingehen.

 

Fragen zu Einzelheiten auf den Screenshots bitte in die Kommentare posten. Wir haben die Screenshots absichtlich ohne große Erklärungen gelassen, da wir die Bilder nicht überladen wollten und viele Funktionsmöglichkeiten in unseren Augen auch selbsterklärend sind. Die gestellten Fragen und Antworten werden wir dann in dem Eintrag unter den Screenshots einfügen/sammeln. Bitte beachtet aber, dass aufgrund der Connichi und der Vorbereitungen dazu, die Beantwortung der Fragen auch einige Zeit dauern kann.

 

Ein Klick auf die Bilder vergrößern die Ansichten. 

Bild 1: Die Übersichtsmaske eines jeden Helpdesk-Mitarbeiters mit seinen jeweils zugeordneten Helpdesk-Bereichsboxen. (hier:  Saiki)

roter Text = manuell eingefügte Anmerkungen

 

Bild 2: Die Übersichtsmaske eines jeden Helpdesk-Mitarbeiters mit seinen jeweils zugeordneten Helpdesk-Bereichsboxen. (hier: Ganondorf)

 

Bild 3: Die Anfrage aus Bild 2: Von Ganondorf als Bearbeiter übernommen.

 

Bild 4: Die Anfrage aus Bild 2: Von Ganondorf als Bearbeiter beantwortet.

 

Bild 5: Die Anfrage aus Bild 2: Von Ganondorf mit Anmerkung/Notiz an einen anderen Bearbeiter weitergegeben.

 

Bild 6: Die Anfrage aus Bild 2:  Saiki schreibt eine neue Notiz an Ganondorf.

 

Bild 7: Die Anfrage aus Bild 2:  Saiki hat die Anfrage mit der Notiz zwar an Ganondorf übergeben, aber Ganondorf kann darauf nicht zugreifen, weil die Anfrage in der Box "Allgemeines/Inbox" liegt.  Saiki wählt im Indicent nun also noch einen Bereich aus, auf den Ganondorf Zugriffsrechte hat ( Saiki kann die Anfrage nach Übergabe nicht mehr aufrufen).

 

Im nächsten Teil gibt es voraussichtlich ein paar Zahlen rund um den Helpdesk (etwa: "Wie viele Bereichsboxen gibt es?", "Wie viele Mitarbeiter arbeiten im Helpdesk?").

 

 

FAQ,

gesammelt aus den Kommentaren:

 

 

 KarlE: Hmm, das Weiterleiten sieht ja mühsam und fehlerträchtig aus. Wenn man jetzt vergisst, passend zum Bearbeiter den Bereich umzuschießen, dann hängt der Incident im Nichts, oder wie?

Antwort: Wenn man den Bereich ändert, dann springt das Feld mit dem Bearbeiter wieder auch "noch nicht übernommen" und kein Bearbeiter ist ausgewählt. Die Anfrage landet also in der Box, ohne Zuordnung zu einem Bearbeiter. Also kann das so herum nicht passieren, dass ein Incident verwaist.
Andersherum, wenn ein Bearbeiter ausgewählt ist, der die zugeordnete Box nicht hat, dann sieht der Bearbeiter, dass er einen Incident hat, aber kann diesen eben nicht öffnen. Dann meldet sich der Bearbeiter i.d.R. schon, dass da beim Weiterleiten was schief gegangen ist.

 

 KarlE: Angenommen, du hättest vor dem Abgeben "Incident beobachten" angehakt, dann könntest du ihn aber weiterhin anschauen, egal in welcher Gruppe er grad lagert? 

Antwort: Nein. Der taucht in der Liste der beobachteten Incidents dann nur mit dem Titel auf. Wenn man dann versucht die Anfrage zu öffnen, hat man keinen Zugriff (in der "beobachten" Übersicht kann man solche Incidents dann auswählen und wieder "entbeobachten"

 

 KarlE: Und was ist das  -  0  +  da rechts? Wenn plus rot ist und minus grün, dann dürfte es ein Maß für was Schlechtes sein, oder?

Antwort: Das wurde damals NUR für den Feature Request Ordner eingeführt und wird eben auch nur dort genutzt. Das ist in dem Fall dafür da, dass mehrere Bereichsleiter (oder auch Bereichsübergreifend) Vorschläge entsprechend als "gut" oder "schlecht" bewerten können, damit der Programmierer direkt in der Übersicht sieht "ah ja gut, da haben 5 Admins für "gut" gestimmt, das sollte man priorisiert umsetzen".
Da man die Funktion leider bei den anderen Boxen nicht ausblenden kann, ist sie eben da mit angezeigt. Es passiert aber selbst nix mit der Anfrage, wenn man da jetzt votet. Lediglich in der Übersicht ist der Incident dann entweder grün oder rot hinterlegt.

 

 KarlE: Mit 388 Bugreports und 962 Feature Requests ist man sicher um etwas Struktur dankbar... wobei, Moment mal, da steht ja "nicht übernommene" davor, das sind dann noch nicht alle? 

Antwort: Nein. Die Boxen Bugreports, FR und Technik funktionieren ganz anders wie die normalen Boxen. Hier landen automatisch KEINE Anfragen. Ein Bearbeiter muss die Anfrage also manuell rein schieben. Das heißt dass der Vermerk vorne "nicht übernommene" in dem Fall nicht stimmt.

 

Avatar
Datum: 17.09.2017 17:55
Das habe ich mich auch bereits gewundert, denn manche User, die trotzdem abgemeldet sind, aber deren Namen noch da steht, bekommt man ja trotzdem zu sehen, dass der User abgemeldet ist und Steckbrief etc. nicht mehr aufrufen kann.

Manche Namen verschwinden, andere nicht...
Avatar
Datum: 17.09.2017 18:22
Hallo.

SmilingMana:
> Eule hat im Februar oder März ihren Account gelöscht, indem sie auf den entsprechenden Button gedrückt hat. Zeitweise war der Name kursiv, dann kurz "abgemeldet". Nun sieht der Name wieder ganz normal aus, als würde er zu einem User gehören, der noch angemeldet ist.
> Ich stehe mit Luftschlosseule in Kontakt und sie findet diese "Accountleiche" nicht gut. Woran liegt das, dass der Name trotz korrekter Abmeldung auf diese Art angezeigt wird, und kann das nicht auf "abgemeldet" geändert werden?

Das ist in der Tat seltsam :( Ich habe die Angelegenheit auch direkt an unsere Programmierer weitergegeben. Ich fürchte aber, anhand der Beschreibung, dass die Fehlersuche hier nicht ganz so einfach sein wird. ^^"
Wenn Luftschlosseule möchte, dass ihr Account jetzt aufgrund dieses Fehlers vollständig gelöscht wird, dann geht das selbstverständlich manuell. Dafür müsste Luftschlosseule selber aber bitte noch eine kurze E-Mail an uns richten, bitte. :)

Aurora-Silver:
> Manche Namen verschwinden, andere nicht...

Hast du da noch weitere Beispiele? Das hilft vielleicht bei der Fehlersuche im Fall von Luftschlosseule. ^^

 KarlE:
> Hmm, das Weiterleiten sieht ja mühsam und fehlerträchtig aus. Wenn man jetzt vergisst, passend zum Bearbeiter den Bereich umzuschießen, dann hängt der Incident im Nichts, oder wie?

Ok, mein Screenshot war jetzt vielleicht an der falschen Stelle gemacht. ;) Wenn man den Bereich ändert, dann springt das Feld mit dem Bearbeiter wieder auch "noch nicht übernommen" und kein Bearbeiter ist ausgewählt. Die Anfrage landet also in der Box, ohne Zuordnung zu einem Bearbeiter. Also kann das so herum nicht passieren, dass ein Incident verwaist.
Andersherum, wenn ein Bearbeiter ausgewählt ist, der die zugeordnete Box nicht hat, dann sieht der Bearbeiter, dass er einen Incident hat, aber kann diesen eben nicht öffnen. Dann meldet sich der Bearbeiter i.d.R. schon, dass da beim Weiterleiten was schief gegangen ist. ^^

> Und wer in welchem Bereich ist, das muss man im Kopf haben, um mit dem Tool umzugehen, denn der Dropdown scheint ja keineswegs passend zum Bearbeiter eingeschränkt zu sein?

Ja, das muss man im Kopf haben. Aber eigentlich müssen das nur die Leute in der "Allgemeines/Inbox" wissen. In seltenen Fällen passieren Weiterleitungen innerhalb anderer Bereiche.

> Angenommen, du hättest vor dem Abgeben "Incident beobachten" angehakt, dann könntest du ihn aber weiterhin anschauen, egal in welcher Gruppe er grad lagert?

Nein. Der taucht in der Liste der beobachteten Incidents dann nur mit dem Titel auf. Wenn man dann versucht die Anfrage zu öffnen, hat man keinen Zugriff (in der "beobachten" Übersicht kann man solche Incidents dann auswählen und wieder "entbeobachten"

> Und was ist das - 0 + da rechts? Wenn plus rot ist und minus grün, dann dürfte es ein Maß für was Schlechtes sein, oder?

Das wurde damals NUR für den Feature Request Ordner eingeführt und wird eben auch nur dort genutzt. Das ist in dem Fall dafür da, dass mehrere Bereichsleiter (oder auch Bereichsübergreifend) Vorschläge entsprechend als "gut" oder "schlecht" bewerten können, damit der Programmierer direkt in der Übersicht sieht "ah ja gut, da haben 5 Admins für "gut" gestimmt, das sollte man priorisiert umsetzen".
Da man die Funktion leider bei den anderen Boxen nicht ausblenden kann, ist sie eben da mit angezeigt. ^^ Es passiert aber selbst nix mit der Anfrage, wenn man da jetzt votet. Lediglich in der Übersicht ist der Incident dann entweder grün oder rot hinterlegt.

> >Können Incidents auch einander zu-/untergeordnet werden? Gerade bei Bugs, wo ja mehrere Meldungen erwünscht sind (und unabhängig davon ohnehin passieren werden), wär es doch praktisch, wenn man einen "Master-Incident" hat, dem weitere Meldungen dann untergeordnet werden können? Oder werden Folgemeldungen dann einfach im ersten vermerkt und geschlossen?
> Edit: ah, grad seh ichs selber, da ist ein "In den Incident ID verschieben", das wird genau das sein.

Zugeordnet ja, aber das machen wir eigentlich nur, wenn ein User zu einer Sache mehrere Anfragen schickt. Z.B. Will er eine ENS von einem User melden und schickt später noch eine weitere neue Anfrage, weil er noch eine ENS bekommen hat. Dann fügen wir die Zusammen, weil ist ja die gleiche Angelegenheit.
In dem von dir beschrieben Szenario hätten wir dann nämlich sonst das Problem, dass man, will man wegen dem Fehler/Vorschlag antworten, weil man etwa mehr Infos braucht, man NUR dem ersten Incident antwortet, dem alle anderen gleichen Fehler zugeordnet werden.
Es kann hier also sein, dass von den 388 Bugreports mehrere gleiche Fehlermeldungen drin sind. Das ist ja eben auch erwünscht, weil (wie in einem Kommentar in einem der anderen Einträge schon erwähnt) so auch gesehen werden kann, dass mehrere das Problem haben. Und der Programmierer freut sich, wenn er mit einer Fehlerbehebung 10 Incidents abschließen kann, die in der Box liegen. ;)

> Mit 388 Bugreports und 962 Feature Requests ist man sicher um etwas Struktur dankbar... wobei, Moment mal, da steht ja "nicht übernommene" davor, das sind dann noch nicht alle?

Nein. Die Boxen Bugreports, FR und Technik funktionieren ganz anders wie die normalen Boxen. Hier landen automatisch KEINE Anfragen. Ein Bearbeiter muss die Anfrage also manuell rein schieben. Das heißt dass der Vermerk vorne "nicht übernommene" in dem Fall nicht stimmt. ^^

Ich hoffe, dass ich nichts vergessen habe X3 Falls ja, bitte nochmal anstoßen. Danke.
If you give me interesting questions...
I'll give you interesting answers...
Avatar
Datum: 17.09.2017 18:30
 Saiki

Also einige User sieht man deren Namen in Kursiv, sie zb hier:
https://ssl.animexx.de/fanart/favoriten/359234/2626747/
https://ssl.animexx.de/fanart/favoriten/359234/2627059/

In der Liste der Favoriten, wo ich sie fand, werden die User allgemein als "Abgemeldet" in Grau gezeigt. Beim Klicken kommt der Name dann zum Vorschein.

Auf der letzten Seite der AL zb sieht man:

https://ssl.animexx.de/fanart/aikofav/?seite=78
Manche Namen sind in grau geschrieben, andere jedoch fehlen komplett. zb hier
https://ssl.animexx.de/fanart/aikofav/5104/ - fehlt komplett, steht nur eine Nr. des Users in Klammern.

Bei manchen kommt es also vor und bei anderen ists ganz weg. Ich weiß, dass es noch andere User gibt, bei denen es so ist wie bei Luftschlosseule aber kann mich nicht erinnern, wo es war D:
Avatar
Datum: 17.09.2017 18:52
 Saiki

> Ich habe die Angelegenheit auch direkt an unsere Programmierer weitergegeben.

Vielen Dank!
Habs Luftschlosseule ausgerichtet und sie wünscht den Programmierern viel Erfolg bei der Fehlersuche.
Datum: 19.09.2017 09:22
Mir fällt gerade auf, dass allein 4 mal am selben Tag Probleme mit der Volljährigkeit gibt, funktioniert die so schlecht? Und wenn ja wird über eine Altanative nach gedacht?
Avatar
Datum: 19.09.2017 09:44
FlowerFay Das hat etwas mit der Umstellung der Personalpässe zutun.

Früher hat man dafür in die Kästchen eine Nummer eingegeben, die auf dem Perso eingetragen war.
Irgendwann aber hat der Perso nen "Update" bekommen, sodass die Nr. nicht mehr passte. Entsprechend musste man das manuell schalten lassen und ans HD schreiben, ich hatte das selbe Problem vor Jahren :)

Was mir eher Sorgen bereitet sind die fast 400 Bug-Reports.
Und wow, so viele Vorschläge? Fände ich ganz schön spannend, da etwas umgesetzt gesehen zu bekommen, gerade wenn es so viele Vorschläge sind :D
Datum: 19.09.2017 10:04
Aurora-Silver interessant

Naja die fast 400 Bug-Repots finde ich nicht so schlimm, weil 1 Bug ja von mehrern Personen gleichzeitig und wenn es nicht schnell genug geht vermutlich auch mehrfach eingereicht wird. Und welche lassen sich halt nicht sdhnell lösen.
Aber du hast recht fast 1000 Vorschläge das ist viel und mit Sicherheit auch was sinvolles dabei.




Zum Weblog