Services in OFORK verwalten

Services beschreiben in OFORK die Leistungen, zu denen Kunden oder interne Benutzer Tickets erstellen können. Sie helfen dabei, Anfragen fachlich einzuordnen, Zuständigkeiten zu klären und Service Level Agreements gezielt anzuwenden.

Während Queues vor allem die Bearbeitung im Team organisieren, beschreiben Services den fachlichen Gegenstand des Tickets: also was betroffen ist.

In diesem Guide: Service-Struktur, Aktivierung, Serviceanlage, Kundenzuordnung, SLAs, Eskalationszeiten, Kim-KI-Unterstützung und Auswertung.

Was ist ein Service?

Ein Service ist eine angebotene Leistung oder ein betreuter Bereich innerhalb von OFORK.

Beispiele:

Microsoft 365
E-Mail
Arbeitsplatz-PC
Drucker
Netzwerk
VPN
Benutzerkonto
Rechnungsfragen
Vertragsservice
Kundenportal

Wenn ein Ticket einem Service zugeordnet wird, ist sofort klarer, welches Thema betroffen ist und welche Regeln für die Bearbeitung gelten.

Unterschied zwischen Queue und Service

Queues und Services haben unterschiedliche Aufgaben.

Bereich	Bedeutung
Queue	Wer bearbeitet das Ticket?
Service	Worum geht es fachlich?
Priorität	Wie dringend ist es?
SLA	Welche Fristen gelten?

Beispiel:

Ein Ticket zum Thema “Microsoft 365 Anmeldung funktioniert nicht” kann in der Queue IT-Support liegen, dem Service Microsoft 365 zugeordnet sein und je nach Auswirkung die Priorität Hoch erhalten.

Warum Services wichtig sind

Services machen Tickets genauer auswertbar und steuerbar.

Sie helfen bei:

fachlicher Einordnung von Tickets
gezielter SLA-Anwendung
besserer Statistik
klarerer Kundenkommunikation
Priorisierung nach betroffener Leistung
Servicekatalogen für Kunden
Automatisierung und Kim-KI-Zuordnung

Ohne Services sieht man nur, dass ein Ticket existiert. Mit Services wird sichtbar, welche Leistung betroffen ist.

Services aktivieren

Damit Services in Ticketmasken verwendet werden können, muss die Service-Funktion in der Systemkonfiguration aktiv sein.

Der relevante Systemparameter ist:

Ticket::Service

Wenn diese Einstellung nicht aktiv ist, können Services in den Ticketbildschirmen nicht sinnvoll ausgewählt oder verwendet werden.

Service-Struktur planen

Vor dem Anlegen sollte festgelegt werden, welche Leistungen überhaupt abgebildet werden sollen.

Sinnvolle Fragen:

Welche Leistungen werden Kunden oder internen Benutzern angeboten?
Welche Leistungen brauchen eigene SLAs?
Welche Services sollen statistisch ausgewertet werden?
Welche Services sollen nur bestimmten Kunden sichtbar sein?
Welche Services erkennt Kim-KI automatisch?
Welche Services benötigen Eskalationsregeln?

Die Service-Struktur sollte nicht zu fein und nicht zu grob sein. Zu viele Services machen die Auswahl unübersichtlich. Zu wenige Services bringen kaum Mehrwert.

Beispiel für eine einfache Service-Struktur

Eine einfache Struktur kann so aussehen:

IT-Support
E-Mail
Microsoft 365
Hardware
Software
Netzwerk
Kundenportal
Rechnungen
Verträge

Diese Struktur ist für viele Organisationen verständlich und kann später erweitert werden.

Beispiel für eine hierarchische Struktur

Bei größeren Installationen kann eine Hierarchie sinnvoll sein.

Beispiel:

IT
IT::Arbeitsplatz
IT::Microsoft 365
IT::Netzwerk
IT::VPN
IT::Drucker
Verwaltung
Verwaltung::Rechnung
Verwaltung::Vertrag
Verwaltung::Kundendaten

Eine Hierarchie sollte nur verwendet werden, wenn sie Agenten und Kunden tatsächlich hilft.

Service anlegen

Beim Anlegen eines Services sollten Name, Gültigkeit und spätere Verwendung sauber festgelegt werden.

Wichtige Angaben:

eindeutiger Name
Gültigkeit
optionale Beschreibung
Zuordnung zu Kunden oder Kundengruppen
mögliche Verbindung mit SLA
Verwendung in Formularen und Prozessen

Services sollten klar und kurz benannt werden. Ein Agent oder Kunde muss sofort verstehen, wann der Service ausgewählt werden soll.

Service bearbeiten

Bestehende Services können angepasst werden. Dabei ist Vorsicht notwendig, wenn der Service bereits in Tickets, Statistiken oder SLAs verwendet wird.

Vor Änderungen prüfen:

Wird der Service in bestehenden Tickets genutzt?
Gibt es SLAs für diesen Service?
Wird der Service in Statistiken verwendet?
Gibt es Prozessregeln oder Automatisierungen?
Ist der Service Kunden zugeordnet?

Wenn ein Service nicht mehr verwendet werden soll, ist Deaktivieren meist besser als Entfernen.

Gültigkeit von Services

Die Gültigkeit bestimmt, ob ein Service im System verwendet werden kann.

Typische Zustände:

gültig
ungültig
temporär ungültig

Nur gültige Services sollten in der aktiven Ticketerstellung auswählbar sein. Ungültige Services können für historische Tickets erhalten bleiben, ohne für neue Tickets genutzt zu werden.

Services und Kunden

Ein Service ist nur dann sinnvoll auswählbar, wenn er dem betreffenden Kunden oder Kundenbenutzer zugeordnet ist oder als allgemein verfügbarer Service eingerichtet wurde.

Typische Varianten:

Service für alle Kunden
Service nur für bestimmte Kunden
Service nur für interne Benutzer
Service je Vertrag oder Paket
Service je Standort oder Organisation

Dadurch sehen Kunden nur die Leistungen, die für sie relevant sind.

Services und SLAs

Services bilden die Grundlage für Service Level Agreements. Ein SLA legt fest, welche Reaktions- und Lösungszeiten für einen Service gelten.

Beispiel:

Service: Microsoft 365
SLA: Business Support
Reaktionszeit: 60 Minuten
Aktualisierungszeit: 240 Minuten
Lösungszeit: 1 Arbeitstag

So kann OFORK erkennen, wann ein Ticket rechtzeitig bearbeitet wurde und wann eine Eskalation notwendig ist.

Was ist ein SLA?

Ein SLA ist eine Dienstleistungsvereinbarung. Es beschreibt, welche Servicequalität zugesichert oder intern angestrebt wird.

Typische SLA-Werte:

erste Reaktion
regelmäßige Aktualisierung
maximale Lösungszeit
Servicezeitkalender
Eskalationsverhalten
Gültigkeit
Dialoghinweis für Kunden

SLAs helfen, Erwartungen messbar zu machen.

SLA anlegen

Vor dem Anlegen eines SLA sollten Services bereits vorhanden sein.

Beim Anlegen werden typischerweise festgelegt:

Name des SLA
zugeordnete Services
Kalender oder Servicezeiten
Eskalation für erste Reaktion
Eskalation für Aktualisierung
Eskalation für Lösung
Gültigkeit
optionale Kundeninformation

Ein SLA sollte verständlich benannt werden, zum Beispiel Standard, Premium, 24x7 oder Business Support.

SLA-Zeiten verstehen

OFORK kann mehrere Zeitwerte auswerten.

Zeitwert	Bedeutung
Erstantwortzeit	Zeit bis zur ersten Reaktion eines Agenten
Aktualisierungszeit	maximaler Abstand zwischen Agentenrückmeldungen
Lösungszeit	maximale Zeit bis zur Lösung des Tickets

Diese Werte sollten realistisch gewählt werden. Zu enge Zeiten führen zu unnötigen Eskalationen. Zu weite Zeiten verlieren ihren Steuerungswert.

Services, Prioritäten und Eskalationen

Services können mit Prioritäten kombiniert werden. Dadurch lässt sich unterscheiden, ob ein Service betroffen ist und wie kritisch die konkrete Situation ist.

Beispiel:

Service: Drucker
Priorität niedrig: Tonerfrage
Priorität normal: einzelner Drucker druckt nicht
Priorität hoch: zentrale Druckumgebung ausgefallen

Der Service beschreibt das Thema, die Priorität beschreibt die Dringlichkeit.

Kim-KI und Services

Kim-KI kann bei der automatischen Service-Zuordnung unterstützen. Dazu analysiert Kim-KI den Ticketinhalt und schlägt einen passenden Service vor.

Kim-KI kann erkennen:

betroffenes System
genannte Anwendung
technische Stichworte
Kundenkontext
Servicebereich
mögliche Störung
passende Kategorie

Beispiel:

Eine Nachricht mit “Teams startet nicht und Outlook synchronisiert nicht” kann dem Service Microsoft 365 zugeordnet werden.

Automatisierung mit Services

Services können als Auslöser oder Bedingung für Automatisierungen dienen.

Beispiele:

Service bestimmt die Queue
Service bestimmt das SLA
Service setzt eine Standardpriorität
Service löst eine Benachrichtigung aus
Service steuert Pflichtfelder
Service beeinflusst Eskalationen

Dadurch wird OFORK stärker prozessorientiert und weniger abhängig von manueller Auswahl.

Services in Formularen

Wenn Kunden oder Agenten Tickets erstellen, kann die Serviceauswahl Teil des Formulars sein.

Wichtig:

nur relevante Services anzeigen
verständliche Namen verwenden
zu lange Listen vermeiden
Services nach Kunden oder Bereich begrenzen
Pflichtfeld nur verwenden, wenn die Auswahl klar ist

Wenn Benutzer nicht wissen, welchen Service sie auswählen sollen, entstehen falsche Daten und schlechte Auswertungen.

Services auswerten

Services sind besonders wertvoll für Statistiken.

Sinnvolle Auswertungen:

Anzahl Tickets pro Service
offene Tickets pro Service
Bearbeitungszeit pro Service
SLA-Verletzungen pro Service
Eskalationen pro Service
Ticketvolumen je Kunde und Service
häufige Störungsthemen
Anteil automatisch erkannter Services

Diese Daten helfen zu erkennen, welche Leistungen besonders viele Anfragen verursachen.

Best Practices

Empfehlungen für eine saubere Serviceverwaltung:

Services an echten Leistungen orientieren
nicht zu viele Services anlegen
klare Namen verwenden
Services mit Kunden und SLAs abstimmen
alte Services deaktivieren statt entfernen
Kim-KI-Zuordnung mit echten Tickets testen
Serviceberichte regelmäßig prüfen
Servicekatalog dokumentieren

Eine gute Service-Struktur wächst kontrolliert und bleibt für Agenten und Kunden verständlich.

Häufige Fehler

Typische Probleme:

Services werden wie Queues verwendet
zu viele ähnliche Services
keine Kundenzuordnung
Services sind nicht in Ticketmasken sichtbar
SLAs sind zu streng eingestellt
alte Services bleiben aktiv
Serviceauswahl ist für Kunden unverständlich
Statistiken werden durch unklare Namen unbrauchbar

Diese Fehler lassen sich vermeiden, wenn Services vor dem Anlegen fachlich geplant werden.

Fazit

Services in OFORK verbinden Tickets mit den tatsächlich betroffenen Leistungen. Sie machen Supportfälle genauer steuerbar, schaffen die Grundlage für SLAs und liefern wichtige Daten für Auswertungen.

Mit einer klaren Service-Struktur, passenden Kundenzuordnungen, realistischen SLAs und optionaler Unterstützung durch Kim-KI wird OFORK zu einem strukturierten Service-Desk-System, das nicht nur Tickets verwaltet, sondern Servicequalität messbar macht.