Vorschläge für das Ticket System

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Vorschläge für das Ticket System

      Guten Abend ähm. Morgen,

      ich beschreibe einmal kurz, wie ich mir den Ablauf des Ticket System vorstelle:

      Kunde (nachfolgend XYZ) und Reseller (nachfolgend ABC)

      XYZ stellt eine Support Anfrage (das aktuelle Formal finde ich schon gut, evtl. noch eine ''Kategorie'' z.B.: Technik, Vertrieb, ...), dadrauf hin erhält XYZ eine E-Mail von z.B.: KEINE-ANTWORT@deinedomain.tld mit dem Text (nur als Beispiel): Sehr geehrter Herr XYZ, wir haben Ihre Anfrage erhalten und werden uns schnellstmöglich mit Ihnen in Verbindung setzen, bitte haben Sie bis dahin Geduld. Mit freundlichen Grüßen Ihr ISP

      ABC loggt sich ein und sieht sich das Ticket an, er kann das Ticket auf ''Bearbeitet'' stellen, für Anfragen die evtl. längere Zeit bearbeitet werden. Nun kann er XYZ antworten, wenn alles geklärt wurde, kann entweder XYZ das Ticket auf ''Geschlossen'' stellen oder ABC.

      XYZ erhält natürlich, wenn ABC antwortet, eine E-Mail dadrüber.

      Alle Reseller sollen alle Tickets bearbeiten können und nicht nur die der eigenst angelegten Kunden.

      Es sollte möglich sein die E-Mail Antworten bearbeiten zu können (Absenderadresse, Absendername, Signatur, ...).

      Danke, xcore

      The post was edited 1 time, last by xcore ().

    • Vielen Dank für deinen Vorschlag.
      Wir werden uns ganz gewiss darüber Gedanken machen.

      Aber wenn ich ehrlich bin, eins versteh ich nicht ganz.
      Warum sollte ein Reseller die Tickets anderer Reseller bearbeiten können?
      Das ist ja gegen den Grundsatz des Postgeheimnisses.
      Res A: unbekannt
      Res B: unbekannt
      Beide kennen sich nicht. Aber Res A bearbeitet die Kunden von Res B?

      Du meinst bestimmt eine Ticket Zuordnung für Mitarbeiter. Oder täusche ich mich da?
      Notice:
      Please Complete your profile with your server data ...
    • Genau das meine ich! :)

      Das Reseller A von Reseller B die Tickets lesen kann ist natürlich teilweise Schwachsinn, außer z.B. in meiner Situation, wir haben 3 Reseller Accounts dann und da wäre es blöd, wenn nur einer die ganzen Anfragen bekommt und der jenige Mal 1 Woche nicht da ist.. :whistling: Da könnte man natürlich auch intern Lösungen finden, jedoch glaube ich ist es bei EasySCP so geregelt das immer nur einer gleichzeitig online sein kann oder täusche ich mich da?
    • Es können mehrere gleichzeitig Online sein über ein Account. Der eine hier und der eine da.
      Der Nachteil ist halt das derzeit immer nur "ein Reseller-Name" den ganzen zugehörigen Tickets zugeordnet ist.
      Sprich man müsste Mitbenutzer für das Ticketsytem und eventuell für den Reseller Account anlegen.

      Na wollen wir mal sehen was der Programmierer dazu sagt.
      Notice:
      Please Complete your profile with your server data ...
    • Der Programmierer freut sich! :)

      Was mir gerade einfällt: Man könnte doch einen Reseller anlegen, dieser läuft dann über den Firmen / Projektnamen und unter diesem Reseller gibt es Mitarbeiter Accounts, der Reseller übernimmt im Prinzip die administrative Funktion und die Mitarbeiter den Rest, dann wäre das Problem mit der Ticket Zuordnung nicht all zu groß, da die Tickets ja innerhalb des Resellers bleiben und die Mitarbeiter drauf zugriff hätten, in dem Moment wird auch kein Kunde dem Mitarbeiter zugeordnet, sondern dem Reseller. Jeder Mitarbeiter würde eine eigene E-Mail bekommen und eine eigene Standard Signatur für das Ticket System.

      Oder habe ich wieder einen Denkfehler?
    • Hey, ein Forum ist zum diskutieren da. Mach dir da mal keine Gedanken drüber.

      Übrigens, auf der schnelle kannst du es wohl lösen wenn du einfach einen weiteren Administrator Account anlegst.
      Der ist für dich dann halt dein Haupt-Reseller. (Sprichwörtlich)

      Nachtrag:
      Das Ticketproblem bleibt dennoch bestehen.
      Man hätte jetzt nur eigenständige Mitarbieter welche Domain bezogen arbeiten.
      Notice:
      Please Complete your profile with your server data ...

      The post was edited 2 times, last by vivanco1705 ().

    • Hi,

      auf die "schnelle" ist das nicht zu lösen. Das war bisher auch kein Thema, weil in solchen Fällen alle beteiligten den gleichen Account benutzt haben. Firma A z.b. ist Reseller, und dort arbeiten 3 Leute, warum sollten diese dann nochmals 3 getrennte Accounts haben? Aus Sicht des Endkunden ist er Kunde von Firma A, und nicht Kunde von Mitarbeiter X der bei Firma A angestellt ist.

      Auch ist es so, das der Grundgedanke (und damit auch das Ziel an welchem wir konsequent arbeiten) der ist das ganze System zu vereinfachen.

      Welchen Sinn sollte es auch haben das die Leute jeder einen eigenen Account haben, statt einen gemeinsam zu benutzen? Jeder hätte alle rechte, d.h. wenn einer was löschen wollte ist es egal ob er das unter dem aktuellen gemeinsamen Reseller Account, oder unter einem eigenen macht. Und ein Rechte System würde das ganze dann wiederum nur unnötig verkomplizieren, was das Gegenteil von Easy ist ;)

      Das einzige was in naher Zukunft geändert wird ist das es nur noch Kunden gibt, die Domains haben, und nicht wie aktuell das Domain == Kunde ist. Damit soll es dann ermöglicht werden das ein Kunde beliebig viele Domains/Webspaces etc. unter einem Kundenlogin verwalten kann. Aktuell ist es noch etwas unglücklich gelöst (aus historischen gründen) wenn ein Kunde mehrere Domains hat.
      Gruss
      Shadow
    • Hallo,

      Ich ging noch von dem Punkt aus, dass immer nur einer, in einem Account eingeloggt sein kann, da bei IspCP Omega, das ja damals so weit ich mich erinnere, so war.
      Die Lösung jedem einen Administration Account zu geben halte ich nicht für all zu ideal, ich denke dann werde ich, wenn die ''Mitarbeiter'' Accounts unterhalb des Resellers nicht realisierbar werden einfach einen Reseller Account nehmen. Hat natürlich den Nachteil, dass der Mitarbeiter Hans Maulwurf unter dem Reseller Namen Jürgen Schmidt (nur Beispiele) agiert ...


      Was dann evtl. trotzdem allgemein schöne Punkte wären:
      • Änderung von Absendername (von automatisierten Antworten, nicht nur im Ticket System)
      • Änderung von der Absenderadresse (von automatisierten Antworten, nicht nur im Ticket System)
      • Änderung von automatischen Antworten (den Inhalt kann man bei z.B. Passwort vergessen ja schon bearbeiten, wäre im Ticket System auch schön)
      • Kategorien im Ticket System (wie z.B. vertrieb, Technik, ...)
      • Mitarbeiter können Status vom Ticket auf bearbeitet setzen.
    • Hi,

      wie gesagt sind wir dabei das gesamte System soweit wie möglich bzw. soweit sinnvoll zu vereinfachen. Zu diesem Zweck wurde z.b. die Basis der 1.2 vollständig neu geschrieben. Da die 1.2 aber schon soweit fertig ist kommen dort keine neuen Funktionen dazu, bis auf Ausnahmen im Zuge der Pflege der 1.2.x Reihe. Das muss man dann aber vom Aufwand her sehen.

      Das Ziel der jeweiligen Reihe soll es ja sein das nur Updates kommen die der Sicherheit dienen (z.b. PhpMyAdmin, RoundCube etc.) aber welche die grundlegende Funktionalität nicht beeinflussen. Das ist für einen stabilen Betrieb unerlässlich, vor allem wenn man ein eigenes Theme verwendet. Dann hat man auf Dauer sicherlich keine Lust das bei jedem Update anpassen bzw. kontrollieren zu müssen.

      Von daher werden aktuelle Vorschläge erst zur 1.3 bzw. 1.4 Reihe Berücksichtigung finden können. Wobei die Entwicklung der 1.3 Reihe ebenfalls schon sehr weit fortgeschritten ist.

      Wir nehmen das auf jeden Fall auf die Liste der Wünsche auf, und werden dann prüfen in wie weit das für alle beteiligten sinnvoll zu realisieren ist. Wie gesagt ist das Ziel ja eine möglichst einfach und Intuitiv benutzbare Oberfläche für alle beteiligten (Admin, Reseller, Endkunde) zu schaffen.
      Gruss
      Shadow