Service Request Management: Ablauf, Beispiele & ITIL

Neuer Laptop, Zugang zum CRM, zweiter Monitor, Passwort vergessen: Solche Anfragen landen jeden Tag bei deinem IT-Team, per Mail, im Chat oder auf dem Flur. Service Request Management sorgt dafür, dass diese Anfragen einen festen Weg gehen, statt im Postfach zu versanden. Dieser Artikel erklärt, was ein Service Request ist, wie er sich von einem Incident unterscheidet, wie der Ablauf aussieht und woran du siehst, ob dein Prozess funktioniert.

Was ist Service Request Management?

Service Request Management ist der Prozess, mit dem IT-Teams alltägliche Anfragen von Mitarbeitenden nach Zugängen, Ausstattung oder Informationen standardisiert annehmen, freigeben, erfüllen und abschließen. Ziel ist, dass wiederkehrende Anfragen über einen festen, wiederholbaren Ablauf laufen statt über Zuruf und E-Mail-Ketten. Dahinter stecken standardisierte Workflows für Einreichung, Priorisierung, Erfüllung und Kommunikation. Weil sich die meisten Anfragen ständig wiederholen, lohnt sich ein reproduzierbares Verfahren schnell: Was einmal sauber definiert ist, muss niemand mehr neu erfinden.

Was ist ein Service Request?

Ein Service Request ist eine formelle Anfrage eines Users nach etwas Neuem, zum Beispiel einem Gerät, einem Zugang oder einer Information. Er ist geplant und wiederkehrend: Nichts ist kaputt, es wird etwas gebraucht.

Auf Deutsch heißt der Service Request meist Serviceanfrage. Typische Beispiele:

• Zugriff auf eine Anwendung oder eine Softwarelizenz
• Passwort zurücksetzen
• neue Hardware wie Laptop, Monitor oder Headset
• Arbeitsplatz für eine neue Kollegin einrichten

Auch Fragen nach einer Information oder Beratung gehören dazu. Das gemeinsame Merkmal: Die Anfrage ist vorhersehbar, und es gibt einen bekannten Weg, sie zu erfüllen.

Was ist der Unterschied zwischen Service Request und Incident?

Ein Service Request ist eine geplante Anfrage nach etwas Neuem, ein Incident dagegen eine ungeplante Störung, die so schnell wie möglich behoben werden muss. "Ich brauche einen neuen Laptop" ist ein Service Request, "Mein Laptop startet nicht mehr" ist ein Incident. Die Unterscheidung ist nicht nur Theorie. ITIL hat Service Requests genau deshalb einen eigenen Prozess gegeben, getrennt vom Incident Management. Wer beides in eine Queue wirft, priorisiert am Ende nach Lautstärke statt nach Dringlichkeit.

Wie diese Prozesse insgesamt zusammenspielen, liest du in unserem Artikel zu den ITSM-Prozessen.

Wie läuft ein Service Request ab?

Ein Service Request läuft in vier Schritten: Anfrage einreichen, prüfen und freigeben, erfüllen, abschließen. Jeder Schritt hat einen klaren Owner, damit keine Anfrage zwischen zwei Teams liegen bleibt.

In der einfachsten Form sieht das so aus:

1. Einreichen: Die Mitarbeiterin stellt ihre Anfrage über ein Serviceportal oder per E-Mail.
2. Prüfen und freigeben: Das IT-Team bewertet die Anfrage nach vordefinierten Genehmigungsregeln und holt bei Bedarf die Freigabe von Finance oder dem Fachbereich ein.
3. Erfüllen: Jemand im Service Desk erledigt die Anfrage oder gibt sie an das zuständige Team weiter.
4. Abschließen: Das Ticket wird geschlossen, und die Mitarbeiterin wird gefragt, ob sie zufrieden ist.

Wichtig ist der Schritt ganz am Anfang: Prüf schon bei der Erfassung, ob die Person die Anfrage überhaupt stellen darf. Das spart später Rückfragen und verhindert, dass Zugänge an die falschen Leute gehen.

Was bedeutet Request Fulfillment in ITIL 4?

Request Fulfillment ist der alte ITIL-Name für Service Request Management. In ITIL 4 ist daraus eine Practice geworden, die offiziell "Service request management" heißt. ITIL 4 hat Request Fulfilment umbenannt und behandelt es nicht mehr als Prozess, sondern als Service-Management-Practice. Inhaltlich bleibt das Ziel gleich: vordefinierte Anfragen von Usern so zu bearbeiten, dass die vereinbarte Servicequalität stimmt und die Bearbeitung für alle einfach bleibt. ITIL 4 ist allerdings nicht mehr die neueste Version: ITIL (Version 5) wird gerade schrittweise eingeführt, ITIL 4 bleibt parallel verfügbar. Für deinen Alltag ändert das wenig: Der Begriff Service Request Management bleibt der gängige.

Wann braucht ein Service Request eine Freigabe?

Eine Freigabe braucht ein Service Request immer dann, wenn er Geld kostet, Risiken birgt oder Zugriff auf sensible Daten gibt. Risikoarme Standardanfragen kannst du dagegen vorab genehmigen und automatisch erfüllen. Ein typisches Muster: Ein Ersatzmonitor ist vorab genehmigt, eine neue Softwarelizenz gibt die Führungskraft frei. Der Zugang zu den Standard-Apps für eine neue Mitarbeiterin kann direkt mit dem Onboarding vergeben werden, ohne dass jemand einzeln zustimmen muss. In der Praxis hängt die Freigabe aber selten nur an einer Regel. Laptops, Lizenzen, Zubehör: Bevor jemand "ja" sagt, muss klar sein, ob das Gerät auf Lager ist, ob noch eine freie Lizenz existiert und welche Kostenstelle zahlt. Fehlt dieser Überblick, wird aus einer Standardanfrage eine Rückfrage-Schleife.

Wie hängen Servicekatalog und IT-Service-Portal zusammen?

Der Servicekatalog legt fest, welche Services Mitarbeitende anfragen können, und das IT-Service-Portal ist der Ort, an dem sie das tun. Ohne Katalog weiß niemand, was er bestellen darf, ohne Portal landet alles wieder im Postfach. Der Servicekatalog beschreibt die IT-Services, die gerade verfügbar sind. Im Portal sollten User auf einen Blick sehen, was sie anfordern können, wie das geht und wie lange es ungefähr dauert.

Ein Portal allein reicht aber nicht. Ein Self-Service-Portal, das niemand findet oder das zu viele Pflichtfelder hat, bleibt ungenutzt, und die Anfragen kommen wieder per Mail. Starte deshalb klein:

• Definiere zuerst die häufigsten und einfachsten Anfragen.
• Frag im Formular nur ab, was du für die Erfüllung wirklich brauchst.
• Verlinke das Portal dort, wo deine Leute ohnehin arbeiten.

Welche KPIs misst du im Service Request Management?

Die wichtigsten KPIs sind Kundenzufriedenheit (CSAT), Antwortzeit, Zeit bis zur Lösung und Zeit bis zum Abschluss einer Anfrage. Dazu kommt, ob deine vereinbarten SLAs eingehalten werden. Für die SLAs brauchst du passende Messungen und Benachrichtigungen, damit eine Anfrage nicht unbemerkt über die Frist rutscht. Wichtiger als die Zahl der KPIs ist, dass du sie pro Anfragetyp auswertest: Ein Laptop für eine neue Kollegin braucht andere Zeiten als ein Passwort-Reset.

Welche Software brauchst du für Service Request Management?

Für Erfassung, Queue und SLAs brauchst du ein Service-Desk- oder ITSM-Tool mit Portal. Für alle Anfragen rund um Geräte, Lizenzen und Zubehör brauchst du zusätzlich einen verlässlichen Asset-Überblick, sonst bleibt die Erfüllung Handarbeit. Genau dort setzt equipme an. equipme ist kein Ticketsystem und ersetzt keins. Aber Anfragen nach Assets laufen bei equipme durch automatische Freigabe-Workflows, mit Anbindung an Lieferanten und Lieferverfolgung, und On- und Offboarding laufen automatisiert. Jede Freigabe sieht, was schon da ist und wem es gehört. Warum dieser Datenbestand auch für deine CMDB zählt, liest du in unserem eigenen Artikel dazu.

‍

Fazit

Service Request Management macht aus täglichen Einzelanfragen einen planbaren Ablauf: einreichen, freigeben, erfüllen, abschließen. Der größte Hebel liegt bei den häufigen Standardanfragen, die du vorab genehmigen und automatisieren kannst. Und bei allem, was mit Hardware und Lizenzen zu tun hat, entscheidet dein Asset-Überblick darüber, ob die Freigabe in Minuten oder Tagen durch ist.