Ticketsystem – Grundlagen & Best Practices

Was ist ein Ticketsystem und warum brauchst du es?

Wenn du im IT-Support arbeitest, weisst du wie schnell die Übersicht verloren geht: Ein Kollege schreibt dir eine WhatsApp, jemand anderes stoppt dich im Gang, drei E-Mails warten im Postfach – und irgendwo dazwischen geht die Anfrage von letzte Woche unter. Genau hier setzt ein Ticketsystem an.

Ein Ticketsystem (auch: Helpdesk-Software oder Issue Tracker) ist eine Anwendung, die jede eingehende Supportanfrage als eigenständigen Datensatz – das Ticket – erfasst, verwaltet und nachverfolgt. Jedes Ticket bekommt eine eindeutige Nummer, einen Status, eine Priorität und einen Bearbeiter zugewiesen. So weiss jeder im Team, was offen ist, wer woran arbeitet und was noch aussteht.

Typische Anfragen, die als Ticket landen:

• Drucker druckt nicht mehr
• Passwort zurücksetzen
• Neue Software installieren
• VPN-Verbindung funktioniert nicht
• E-Mail-Konto einrichten für neuen Mitarbeiter
• Netzwerkausfall im zweiten Stock

Selbst wenn du das Problem in zwei Minuten löst: Ticket aufmachen, lösen, schliessen. Dieser Grundsatz klingt bürokratisch, ist aber Gold wert – für Auswertungen, für Übergaben, für Reklamationen und für deine eigene Rechtssicherheit.

Gängige Ticketsysteme im Überblick

Es gibt eine grosse Auswahl an Tools – von kostenlos und selbst gehostet bis hin zu Enterprise-SaaS. Hier die wichtigsten für den KMU-Alltag:

Empfehlung für KMU ohne Budget:

• osTicket oder Zammad auf einem eigenen Server (z.B. auf einem bestehenden Linux-VM) – kostenlos, vollständig, DSGVO-konform
• Freshdesk Free für den absoluten Einstieg ohne Installation

Empfehlung wenn bereits Atlassian-Tools im Einsatz:

• Jira Service Management – nahtlose Integration mit bestehenden Jira-Projekten und Confluence als Wissensdatenbank

Der Ticket-Lebenszyklus

Jedes Ticket durchläuft einen definierten Prozess – vom ersten Eingang bis zur finalen Lösung. Diesen Ablauf nennt man den Ticket-Lebenszyklus:

Eingang → Triage → Zuweisung → In Bearbeitung → Lösung → Abschluss → Nachverfolgung

Die einzelnen Phasen im Detail:

1. Eingang (Intake) Das Ticket wird erstellt – durch den User selbst über ein Self-Service-Portal, per E-Mail, Telefon oder durch den Support-Mitarbeiter. Alle Kanäle landen im selben System.

2. Triage Schnelle Ersteinschätzung: Ist das ein Incident (etwas funktioniert nicht) oder ein Service Request (etwas soll eingerichtet werden)? Wie dringend ist es? Gibt es andere offene Tickets zum gleichen Thema (möglicher Major Incident)?

3. Zuweisung Das Ticket wird dem richtigen Team oder der richtigen Person zugewiesen. Viele Systeme erlauben automatische Zuweisung basierend auf Kategorien (z.B. alle Druckerprobleme gehen zu Team-Mitglied A).

4. In Bearbeitung Der zugewiesene Techniker arbeitet am Problem. Jeder Schritt, jedes Ergebnis und jede Kommunikation mit dem User wird als Notiz oder Kommentar im Ticket festgehalten.

5. Lösung Das Problem ist behoben. Der Techniker dokumentiert die Lösung und setzt das Ticket auf “Gelöst”. Der User wird benachrichtigt.

6. Abschluss Der User bestätigt die Lösung oder das Ticket wird nach einer definierten Frist automatisch geschlossen. Viele Systeme senden danach eine Kundenzufriedenheitsumfrage (CSAT).

7. Nachverfolgung Regelmässige Auswertung: Welche Probleme kommen häufig vor? Gibt es wiederkehrende Fehler, die durch ein Problem-Ticket gelöst werden könnten?

Prioritäten richtig setzen

Die Priorität eines Tickets bestimmt, wie schnell du reagieren und lösen musst. Sie ergibt sich aus zwei Faktoren:

• Dringlichkeit: Wie schnell muss das Problem gelöst werden, damit der Schaden nicht grösser wird?
• Impact (Auswirkung): Wie viele User oder wie kritische Prozesse sind betroffen?

Standard-Prioritätsschema (P1–P4):

Praxistipp: Die häufigste Fehleinschätzung ist es, alles auf P1 oder P2 zu setzen, weil sich jeder wichtig fühlt. Halte die Prioritäten konsequent ein – sonst verlieren sie ihre Bedeutung. Wenn ein User darauf besteht, dass sein Problem P1 ist, obwohl es P3 ist, erkläre ruhig den Unterschied und warum das fair für alle ist.

Ticket-Typen nach ITIL

Wenn du mit ITIL-orientierten Systemen wie Jira Service Management arbeitest, begegnest du unterschiedlichen Ticket-Typen. Der wichtigste Unterschied:

Warum der Unterschied wichtig ist:

• Incidents haben SLA-Zeiten und erfordern schnelle Reaktion
• Service Requests können in Queues gesammelt und gebündelt werden
• Problem-Tickets helfen, Wiederholungen dauerhaft zu eliminieren
• Change-Tickets gehen durch einen Genehmigungsprozess (Change Advisory Board)

Auf der Seite ITIL-Grundlagen findest du eine ausführlichere Erklärung dieser Konzepte.

Gute Ticket-Dokumentation schreiben

Die Qualität der Ticket-Dokumentation ist der Unterschied zwischen einem professionellen IT-Support und einem Chaos. Ein gut dokumentiertes Ticket muss so geschrieben sein, dass ein Kollege ohne Rückfragen weiterarbeiten kann.

Das Bewährte Template:

SYMPTOM:    Was wurde gemeldet? Wie genau äussert sich das Problem?
            → "Outlook startet nicht mehr seit heute Morgen, Absturz beim Laden des Profils"

UMGEBUNG:   PC-Name, OS-Version, Softwareversion, Abteilung
            → "Windows 11 22H2, Outlook 2021, PC-Name: WS-MUSTER-01, Buchhaltung"

SCHRITTE:   Was wurde unternommen (chronologisch, auch was NICHT geholfen hat)
            → 1. Neustart durchgeführt – Problem weiterhin vorhanden
               2. Office-Online-Reparatur gestartet – kein Erfolg
               3. Outlook im abgesicherten Modus getestet – startet
               4. Outlook-Profil in %appdata%\Microsoft\Outlook gelöscht
               5. Neues Profil erstellt – Problem behoben

URSACHE:    Was war das eigentliche Problem?
            → "Korruptes Outlook-Profil, vermutlich durch unterbrochenes Update verursacht"

LOESUNG:    Was hat das Problem behoben (mit konkreten Pfaden/Befehlen)?
            → "Profilordner C:\Users\mmuster\AppData\Roaming\Microsoft\Outlook
               umbenannt, Outlook neu gestartet, neues Profil automatisch erstellt"

DAUER:      45 Minuten

Was du NICHT machen solltest:

• Nur “Problem gelöst” als Lösungstext eintragen
• Anrufe und Vor-Ort-Besuche nicht dokumentieren
• Passwörter oder vertrauliche Daten im Ticket speichern
• Interne Bemerkungen über den User im öffentlichen Kommentarfeld schreiben (die sieht er)

SLA – Service Level Agreements

Ein SLA (Service Level Agreement) ist eine schriftliche Vereinbarung zwischen dem IT-Team und den Usern (oder dem Management), in der definiert wird, wie schnell auf Anfragen reagiert und wie schnell sie gelöst werden müssen.

Typische SLA-Metriken:

• First Response Time (FRT): Wie schnell erhält der User eine erste Rückmeldung?
• Time to Resolution (TTR): Wie lange dauert die Lösung insgesamt?
• SLA-Erfüllungsrate: Wie viel Prozent aller Tickets wurden innerhalb der SLA-Zeit gelöst?

SLAs in Jira Service Management konfigurieren:

In Jira Service Management erstellst du SLA-Definitionen unter Project Settings > SLAs. Dort legst du fest:

• Welche Tickets die SLA betrifft (z.B. alle Incidents)
• Wann die Zeit zu laufen beginnt (z.B. bei Ticket-Erstellung)
• Wann sie stoppt (z.B. wenn auf User-Antwort gewartet wird)
• Wann der SLA-Timer eskaliert (z.B. bei 80% der Frist eine Notification)

Eskalation – wann und wie: Wenn ein Ticket kurz davor ist, die SLA-Zeit zu überschreiten, musst du eskalieren. Das heisst: deinen Vorgesetzten informieren, externe Hilfe hinzuziehen oder den User proaktiv über die Verzögerung informieren. Ein verpasster SLA ist kein Versagen – ein verpasster SLA ohne Kommunikation ist eines.

Automatisierungen und Workflows

Moderne Ticketsysteme bieten leistungsstarke Automatisierungen, die Routinearbeiten abnehmen:

Typische Automatisierungen:

# Beispiel Jira-Automation-Regel (konzeptuell)
Trigger:   Neues Ticket wird erstellt
Bedingung: Ticket-Kategorie = "Passwort-Reset"
Aktion:    Automatisch zuweisen an Tier-1-Queue
           Ticket-Priorität setzen auf P4
           Vordefinierte Antwort senden an User

Weitere sinnvolle Automationen:

• Auto-Close nach 7 Tagen ohne User-Antwort auf Status “Gelöst”
• Eskalation nach X Stunden wenn Ticket bei P1/P2 noch nicht in Bearbeitung
• Round-Robin-Zuweisung – neue Tickets automatisch gleichmässig auf Teammitglieder verteilen
• Benachrichtigungen – User automatisch über Statusänderungen informieren
• SLA-Alerts – Team bei 75% der SLA-Zeit benachrichtigen

Self-Service-Portal: Biete deinen Usern ein einfaches Web-Portal, über das sie Tickets erstellen und deren Status verfolgen können. Das reduziert Rückfragen (“Wie ist der Stand meines Tickets?”) erheblich. Alle grossen Ticketsysteme bieten das out-of-the-box.

Auswertungen und Reporting

Regelmässige Auswertungen helfen dir, den IT-Support kontinuierlich zu verbessern. Die wichtigsten Kennzahlen:

Auswertungen in osTicket per SQL (Beispiel):

-- Offene Tickets pro Priorität
SELECT priority_desc, COUNT(*) AS anzahl
FROM ost_ticket t
JOIN ost_ticket_priority p ON t.priority_id = p.priority_id
WHERE t.status = 'open'
GROUP BY priority_desc
ORDER BY anzahl DESC;

-- Durchschnittliche Lösungszeit in Stunden (letzte 30 Tage)
SELECT AVG(TIMESTAMPDIFF(HOUR, created, closed)) AS avg_loesungszeit_std
FROM ost_ticket
WHERE status = 'closed'
AND closed >= DATE_SUB(NOW(), INTERVAL 30 DAY);

Trend erkennen – Beispiel: Wenn du siehst, dass 30% aller Tickets im letzten Monat das Schlagwort “VPN” enthielten, ist das ein klares Signal: Schreib einen Artikel in die Wissensdatenbank, veranstalte eine kurze Schulung oder überprüfe die VPN-Infrastruktur. Ticketsysteme sind nicht nur Verwaltungs-Tools – sie sind dein wichtigstes Diagnose-Instrument für die Gesundheit der gesamten IT-Umgebung.

Best Practices im Überblick

Zusätzliche Empfehlungen:

• Kategorisierung konsequent nutzen: Nur mit sauberer Kategorisierung kannst du sinnvolle Auswertungen machen
• Tags/Labels verwenden: Für schnelles Filtern und Suchen (z.B. “vpn”, “outlook”, “passwort”)
• Interne Kommentare vs. öffentliche Antworten trennen: Die meisten Systeme unterscheiden zwischen internen Notizen und Antworten, die der User sieht – nutze das aktiv
• Templates für häufige Anfragen: Vorgefertigte Antworten für Standardfälle sparen Zeit und sorgen für konsistente Kommunikation
• Integration mit Monitoring: Wenn dein Monitoring-System (z.B. Nagios, Zabbix) automatisch Tickets bei Alerts erstellt, sparst du wertvolle Minuten bei kritischen Vorfällen – siehe auch Monitoring-Grundlagen

Ticketsystem in der Praxis: Erstkonfiguration

Wenn du ein neues Ticketsystem einrichtest, empfiehlt sich diese Reihenfolge:

Schritt 1 – Kategorien definieren Überlege welche Kategorien in deinem Umfeld sinnvoll sind. Beispiel:

• Endgeräte (PC, Laptop, Drucker)
• Software (Office, ERP, Browser)
• Netzwerk & Konnektivität
• Benutzerkonten & Zugriffsrechte
• E-Mail & Kommunikation
• Sonstiges

Schritt 2 – Prioritätsschema festlegen Definiere P1–P4 mit konkreten Beispielen aus deinem Unternehmen. Lass das Management absegnen – dann hast du Rückendeckung.

Schritt 3 – E-Mail-Integration einrichten Richte eine dedizierte Support-E-Mail-Adresse ein (z.B. support@firma.ch), die automatisch Tickets erstellt. Das ist der wichtigste Kanal für die meisten User.

Schritt 4 – SLAs konfigurieren Trage die vereinbarten Reaktions- und Lösungszeiten ein. Aktiviere automatische Eskalations-Benachrichtigungen.

Schritt 5 – Team schulen 30 Minuten reichen für die Grundlagen. Fokus: Ticket erstellen, kommentieren, zuweisen, schliessen. Den Rest lernt man im Alltag.

Schritt 6 – User informieren Kommuniziere dem Rest des Unternehmens, wie sie Tickets erstellen können. Erkläre, warum das für sie von Vorteil ist (Nachverfolgbarkeit, keine Anfragen die untergehen).

Verknüpfte Themen

Das Ticketsystem ist eingebettet in einen grösseren IT-Prozess-Rahmen. Diese Seiten helfen dir, den Kontext zu verstehen:

• ITIL-Grundlagen – Das Prozessframework hinter den Ticket-Typen (Incident, Problem, Change)
• Troubleshooting-Methodik – Wie du Probleme strukturiert analysierst, bevor du sie im Ticket dokumentierst
• Monitoring-Grundlagen – Automatische Ticket-Erstellung aus Monitoring-Alerts
• IT-Dokumentation & Inventar – Tickets sind Teil des grösseren Dokumentations-Ökosystems

Weiterlernen

• osTicket – Offizielle Dokumentation – Vollständige Dokumentation für die Open-Source-Lösung
• Jira Service Management – Atlassian-Dokumentation – Offizielle Atlassian-Dokumentation für JSM
• Zammad – Dokumentation (Deutsch verfügbar) – Deutsches Open-Source-Helpdesk-System
• ITIL Incident Management – IT Process Wiki – Detaillierte Erklärung des ITIL-Incident-Management-Prozesses auf Deutsch
• Freshdesk – Best Practices für Ticketsysteme – Herstellerunabhängige Übersicht über Ticketsystem-Konzepte
• audius – Effiziente Ticketbearbeitung im IT-Support – Praxisnaher Artikel zur Priorisierung im KMU-Alltag

Videos

YouTube