Ein Service Ticket ist ein protokollierter Datensatz eines gemeldeten Problems oder einer Anfrage, vom Erstellen bis zur Lösung durch das Support- oder Wartungsteam verfolgt.
Ein Service Ticket ist ein protokollierter Datensatz eines gemeldeten Problems oder einer Anfrage, verfolgt vom Moment der Meldung bis zur Lösung. Das Ticket gibt dem Problem eine Nummer, einen Verantwortlichen und einen Status, sodass es nicht im Sande verläuft wie eine Meldung im Vorbeigehen oder eine weitergeleitete E-Mail. Im IT-Support kann das Ticket „kann mich nicht anmelden” lauten; in der Geräteverwaltung „der Mixer verliert Öl” - derselbe Mechanismus, nur auf physische Assets gerichtet.
Was ein Service Ticket erfasst
Ein brauchbares Ticket hält mindestens fest:
- Den Meldenden - wer das Problem bemerkt hat und Rückfragen beantworten kann.
- Die Beschreibung - was nicht stimmt, in den Worten des Meldenden, idealerweise mit Fotos an der Maschine.
- Den Gegenstand - das betroffene Asset, verknüpft über die ID, nicht „einer der Bohrer”.
- Eine Kategorie - Schaden, fehlt, Wartung nötig, Ersatz nötig - damit die Triage es richtig zuordnen kann.
- Priorität und Status - damit alle sehen, ob es wartet, bearbeitet wird oder auf Teile wartet.
Die wertvollste Gewohnheit: den Aufwand für eine Meldung senken. Ein Fehler, dessen Meldung ein Formular, einen Login und zehn Minuten kostet, wird erst freitags oder gar nicht gemeldet; ein Fehler, der nur ein Foto und zwei Sätze braucht, wird gemeldet, sobald jemand ihn sieht.
Der Ticket-Lebenszyklus
Tickets durchlaufen einige wenige Zustände: neu, in Prüfung (während jemand triagiert), in Arbeit (während die Behebung läuft), wartet auf Teile (oder auf Informationen, bei einer Unterbrechung von außen) und schließlich gelöst. Ein Kommentar-Verlauf hält Fragen, Befunde und Entscheidungen am Ticket fest, statt sie über Postfächer zu verstreuen. Zwei Details trennen funktionierende Systeme von reinen Alibi-Systemen: Die Wartezustände müssen ehrlich gepflegt sein, weil dort die meiste Behebungszeit steckt, und ein gelöstes Ticket muss festhalten, was tatsächlich getan wurde - „behoben” allein ist kein Nachweis.
Service Ticket vs. Work Order
Beide überschneiden sich und werden oft verwechselt. Ein Service Ticket erfasst das Problem aus Nutzersicht; eine Work Order (Arbeitsauftrag) autorisiert und verfolgt die Behebung aus Wartungssicht. In großen Betrieben wird ein Ticket triagiert und kann eine oder mehrere Work Orders erzeugen, gegebenenfalls teamübergreifend. In kleinen Teams übernimmt ein einziger Datensatz beide Rollen, von der Meldung bis zur Reparatur - völlig in Ordnung, solange er am Asset hängt und mit Notizen statt nur einem „erledigt” geschlossen wird.
Warum Tickets zum Asset gehören
Ein Ticket löst einen einzelnen Vorfall; eine ganze Ticket-Historie charakterisiert eine Maschine. Landet jede Meldung am Asset-Datensatz, wird der Wiederholungstäter mit fünf Tickets in diesem Jahr sichtbar, der Garantiestatus lässt sich prüfen, bevor Geld für eine Reparatur fließt, die eigentlich der Lieferant schuldet, und Entscheidungen über Ersatz oder Aufarbeitung - ob ein müdes Gerät schon das Lebensende erreicht hat - beruhen auf Belegen statt auf Eindrücken. Bei regulierten Geräten wie gemeinsam genutzten Medizingeräten ist diese Störungs-Spur nicht optional; sie belegt, dass das Gerät sicher nutzbar war. In AMPthilly öffnet das Scannen des QR-Etiketts am defekten Artikel den Datensatz im Handy-Browser, wo jeder ein Ticket mit Fotos und Kategorie anlegen kann, und das gelöste Ticket bleibt dauerhaft in der Asset-Historie.
Verwandte Begriffe
- Warranty Tracking - die erste Prüfung, bevor eine im Ticket erfasste Reparatur bezahlt wird
- Useful Life - die geplante Spanne, die eine wachsende Ticket-Datei infrage stellt
- End of Life (EOL) - wohin eine sich verschlechternde Ticket-Historie führen sollte
- Refurbishment - die Alternative zum Ersatz, die eine Ticket-Historie rechtfertigt
- Asset Decommissioning - Ausmustern des Assets, dessen Tickets Reparatur nicht mehr rechtfertigen