{"id":45980,"date":"2025-08-13T09:08:00","date_gmt":"2025-08-13T07:08:00","guid":{"rendered":"https:\/\/www.flexus.de\/?p=45980"},"modified":"2025-08-13T09:08:00","modified_gmt":"2025-08-13T07:08:00","slug":"ticketerstellung-und-bearbeitung-in-zammad-ein-leitfaden","status":"publish","type":"post","link":"http:\/\/s523026439.online.de\/en\/ticketerstellung-und-bearbeitung-in-zammad-ein-leitfaden\/","title":{"rendered":"Ticketerstellung und -bearbeitung in Zammad \u2013 ein Leitfaden"},"content":{"rendered":"

Der Support der Flexus AG wickelt die Anfragen seiner Kunden \u00fcber das Ticketsystem Zammad ab. Dies ist unter https:\/\/support.flexus.net\/<\/a> abrufbar. Falls der Kunde noch kein Passwort f\u00fcr seinen Zugang hat, muss er seine individuelle Mail-Adresse eintragen und auf \u201ePasswort vergessen\u201c klicken und bekommt so ein neues Passwort geschickt. Dies muss er im Nachhinein \u00e4ndern und ein neues pers\u00f6nliches Passwort vergeben. Eine detaillierte Anleitung hierzu finden Sie hier<\/a>. <\/p>\n\n\n\n

Im Folgenden wird eine prototypische Ticketanlage beschrieben:<\/strong><\/p>\n\n\n\n

    \n
  1. Bevor der Kunde vom Projekt an den Support \u00fcbergeben wird, wird ihm mitgeteilt, dass er zuk\u00fcnftige Anfragen \u00fcber das Ticketsystem Zammad<\/strong> stellen muss.

    <\/li>\n\n\n\n
  2. Der Kunde schreibt sein Anliegen also bestenfalls via https:\/\/support.flexus.net\/<\/a> ans Ticketsystem oder schickt eine Mail an support@flexus.net<\/a>, dann wird auch automatisch ein neues Ticket erstellt. Falls er eine Mail mit einer Anfrage an einen pers\u00f6nlichen Kontakt oder einen Verteiler schickt, muss dieser Kontakt bzw. jemand aus dem Verteiler die Mail an support@flexus.net<\/a> weiterleiten und dem Kunden das \u00fcbliche Prozedere mitteilen.

    <\/li>\n\n\n\n
  3. Dadurch wird automatisch ein neues Ticket<\/strong> mit einer individuellen Ticketnummer angelegt.

    <\/li>\n\n\n\n
  4. Hat der Kunde einen Themenbereich \/ eine Gruppe ausgew\u00e4hlt, wird das Ticket automatisch dem richtigen Besitzer<\/strong> zugewiesen. Dies geschieht jedoch in den seltensten F\u00e4llen.

    <\/li>\n\n\n\n
  5. Hat der Kunde keinen Themenbereich \/ keine Gruppe ausgew\u00e4hlt, muss dies h\u00e4ndisch geschehen und das Ticket dem richtigen Besitzer zugewiesen werden.

    <\/li>\n\n\n\n
  6. Der Besitzer des Tickets kann gleichzeitig der Bearbeiter<\/strong> sein. Der Besitzer kann die Bearbeitung aber auch auf einen anderen Mitarbeitenden \u00fcbertragen und trotzdem den \u00dcberblick \u00fcber die Bearbeitung behalten.

    <\/li>\n\n\n\n
  7. Die Gruppen<\/strong> bzw. Themenbereiche<\/strong> werden hier<\/a> genauer beschrieben.

    <\/li>\n\n\n\n
  8. Der Status<\/strong> wird festgelegt und besagt z. B., ob das Ticket in Bearbeitung ist oder der Supportler auf R\u00fcckmeldung des Kunden wartet. Alle verf\u00fcgbaren Status und deren Bedeutung finden Sie hier<\/a>.

    <\/li>\n\n\n\n
  9. Als n\u00e4chstes wird die Priorit\u00e4t der Anfrage festgelegt. Hier gibt es folgende M\u00f6glichkeiten:

    1 niedrig<\/strong>: Als \u201e1 niedrig\u201c gelten alle Tickets, die eine neue Anforderung betreffen, die warten kann, f\u00fcr die ein extra Angebot erstellt werden muss oder wenn keine produktionsrelevanten Abl\u00e4ufe beim Kunden betroffen sind und sie keinen Support- und Wartungsvertrag haben.

    2 normal<\/strong>: Prio-2-Tickets betreffen die meisten Anfragen. Dieser Tag wird ausgew\u00e4hlt, wenn der Kunde einen Wartungs- oder Supportvertrag hat und die Anfrage schnellstm\u00f6glich abgearbeitet werden soll, je nach Aufwand und Kommunikation mit dem Kunden. W\u00e4hlt der Kunde keine Prio aus, wird das Ticket automatisch als \u201e2 normal\u201c angelegt. Dies kann nat\u00fcrlich je nach Thema oder Dringlichkeit h\u00e4ndisch im Nachhinein ge\u00e4ndert werden.

    3 hoch<\/strong>: Ist die Produktion beim Kunden betroffen und es k\u00f6nnen z. B. keine Fahrauftr\u00e4ge mehr gefahren oder Warenausg\u00e4nge gebucht werden, so wird das Ticket als \u201e3 hoch\u201c eingestuft. Hier muss so schnell wie m\u00f6glich gehandelt und dem Kunden geholfen werden. In vielen F\u00e4llen m\u00fcssen daf\u00fcr andere Tickets und deren Entwicklungen pausiert werden.

    <\/li>\n\n\n\n
  10. Als Letztes muss noch die Ticketart festgelegt werden. Einen detaillierten \u00dcberblick \u00fcber die verschiedenen Kategorien und deren Bedeutung finden Sie hier<\/a>.

    <\/li>\n\n\n\n
  11. Nach Einsch\u00e4tzung und Kategorisierung des einzelnen Tickets wird ein Due Date festgelegt und so dem Kunden der Bearbeitungszeitraum mitgeteilt.

    <\/li>\n\n\n\n
  12. Dieses Datum gilt es einzuhalten. Falls dies nicht m\u00f6glich ist, wird in R\u00fccksprache mit dem Kunden ein neues Due Date festgelegt.

    <\/li>\n\n\n\n
  13. Danach kann mit der Abarbeitung (nach Prio) begonnen werden.<\/li>\n<\/ol>\n\n\n\n

    ACHTUNG<\/strong>: Ist kein Kontingent verf\u00fcgbar \u2013 sei es Supportkontingent oder ein Angebot wurde vom Kunden noch nicht bestellt \u2013 so kann keine Bearbeitung starten. Erst nachdem die Beauftragung stattgefunden hat und somit das \u201eGo\u201c vom Kunden kam, darf mit der Entwicklung begonnen werden. Ausgenommen sind hierbei Bugtickets.<\/p>\n\n\n