Ein SPoC im IT Service Management sorgt dafür, dass Incidents, Service Requests, Rückfragen und andere IT-Anliegen über einen kontrollierten Eingang in die richtigen Prozesse gelangen. Diese Rolle übernimmt in der Praxis häufig der Service Desk. Er nimmt Anfragen nicht nur entgegen, sondern dokumentiert, klassifiziert, priorisiert und koordiniert sie über den gesamten Bearbeitungsverlauf.
Während der Begriff Single Point of Contact grundsätzlich eine zentrale Anlaufstelle beschreibt, geht es im ITSM vor allem um die operative Umsetzung: Welche Eingangskanäle werden angeboten? Wie werden Störungen von Service Requests unterschieden? Wer übernimmt die Bearbeitung? Wann wird eskaliert? Welche Service Level gelten? Und wie bleibt der Anwender während der Bearbeitung informiert?
Ein wirksam organisierter SPoC verbindet Anwender, Service Desk, IT-Betrieb, Fachbereiche und nachgelagerte Support-Ebenen. Dadurch werden aus einzelnen Meldungen nachvollziehbare Vorgänge, die systematisch bearbeitet, ausgewertet und verbessert werden können.
Eine allgemeine Erläuterung des Begriffs finden Sie im Beitrag SPoC: Bedeutung, Aufgaben und Vorteile des Single Point of Contact.
Was ist ein SPoC im IT-Service-Management?
Ein SPoC im IT-Service-Management ist der festgelegte Kontaktpunkt für IT-bezogene Anliegen von Anwendern, Kunden, Partnern und Fachbereichen. Er stellt sicher, dass Anfragen nicht unkoordiniert an einzelne IT-Mitarbeitende gesendet werden, sondern zentral erfasst und in einen definierten ITSM-Prozess überführt werden.
Der SPoC kann über mehrere technische Kanäle erreichbar sein. Dazu gehören beispielsweise:
- Self-Service-Portal
- Telefon
- Chat
- Webformular
- mobile Anwendungen
- Schnittstellen zu anderen Systemen
Single Point of Contact bedeutet daher nicht zwangsläufig, dass nur ein einziger Kommunikationskanal zulässig ist. Entscheidend ist, dass alle Eingänge in einem gemeinsamen Prozess und einer zentralen Datenbasis zusammenlaufen.
Der SPoC schafft damit einen verbindlichen Zugang zur IT-Organisation. Anwender müssen nicht wissen, welches Team für eine Anwendung, einen Arbeitsplatz, eine Berechtigung oder einen IT-Service zuständig ist. Sie wenden sich an den zentralen Kontaktpunkt. Die interne Zuordnung übernimmt die IT-Organisation.
Welche Rolle übernimmt der Service Desk als SPoC?
In vielen Unternehmen übernimmt der Service Desk die Rolle des SPoC. Der Service Desk ist die operative Einheit, die Anwenderanfragen entgegennimmt und die Bearbeitung innerhalb des IT Service Managements koordiniert.
Dabei ist zwischen Kontaktverantwortung und Lösungsverantwortung zu unterscheiden.
Der Service Desk muss nicht jedes Anliegen selbst lösen. Er bleibt aber häufig für die strukturierte Aufnahme, Kommunikation und Koordination verantwortlich. Die fachliche Bearbeitung kann durch den First-Level-Support, spezialisierte Support-Teams, externe Dienstleister oder verantwortliche Fachbereiche erfolgen.
Ein Service Desk als SPoC übernimmt typischerweise folgende Aufgaben:
- Anfragen und Störungen entgegennehmen
- vollständige Ticketinformationen erfassen
- betroffene Anwender und Services zuordnen
- Anliegen klassifizieren
- Auswirkung und Dringlichkeit bewerten
- Prioritäten festlegen
- Service Level berücksichtigen
- Erstdiagnosen durchführen
- Standardlösungen bereitstellen
- Vorgänge an zuständige Teams weiterleiten
- Eskalationen anstoßen
- Bearbeitungsstände überwachen
- Anwender informieren
- Lösungen und Erkenntnisse dokumentieren
Damit wird der Service Desk zur operativen Schaltstelle zwischen Anwendern und ITSM-Prozessen.
„Ein SPoC ist im IT Service Management nicht nur eine zentrale Anlaufstelle. Er ist der Punkt, an dem aus einer Anfrage ein steuerbarer, nachvollziehbarer Serviceprozess wird." Ralph Bockisch
Erfahren Sie, wie EcholoN zentrale Eingangskanäle, Ticketsteuerung, Eskalationen und Serviceprozesse auf einer Plattform verbindet.
So läuft eine Anfrage über den SPoC durch das ITSM
Ein SPoC entfaltet seinen Nutzen erst dann vollständig, wenn hinter der Kontaktstelle ein definierter Prozess steht. Eine gemeinsame E-Mail-Adresse allein reicht nicht aus. Entscheidend ist, wie ein Anliegen nach dem Eingang verarbeitet wird.
-
Eingang
1
Anfrage oder Störung geht ein
Ein Anwender meldet ein Anliegen über das Self-Service-Portal, per E-Mail, telefonisch, über einen Chat oder einen anderen freigegebenen Kanal.
Zusätzlich können Monitoring- und Drittsysteme über Schnittstellen technische Events oder Tickets erzeugen. Solche Systemmeldungen ergänzen die nutzerbezogenen Eingangskanäle, gehören aber nicht zur klassischen Kontaktaufnahme durch Anwender.
-
Erfassung
2
Vorgang wird zentral dokumentiert
Der SPoC legt einen nachvollziehbaren Vorgang in der ITSM- oder Service-Desk-Lösung an. Bereits vorhandene Tickets werden identifiziert, damit Meldungen nicht doppelt bearbeitet werden.
Zu den grundlegenden Informationen gehören:
- meldende Person
- betroffene Organisation oder Abteilung
- betroffener IT-Service
- Beschreibung des Anliegens
- Zeitpunkt des Auftretens
- betroffene Nutzer oder Standorte
- mögliche Auswirkungen
- vorhandene Fehlermeldungen
- bereits durchgeführte Maßnahmen
- Anhänge oder ScreenshotsJe vollständiger die Informationen sind, desto schneller kann die weitere Bearbeitung erfolgen.
-
Klassifizierung
3
Anliegen wird klassifiziert
Der SPoC prüft, um welche Art von Vorgang es sich handelt. Besonders wichtig ist die Unterscheidung zwischen Incident und Service Request.
Darüber hinaus kann ein Anliegen Hinweise auf ein Problem, einen notwendigen Change oder einen Informationsbedarf enthalten.
-
Bewertung
4
Auswirkung und Dringlichkeit werden bewertet
Die Priorität sollte nicht allein nach der subjektiven Einschätzung des Anwenders vergeben werden. Stattdessen werden Auswirkung und Dringlichkeit nach definierten Kriterien bewertet.
Typische Fragen sind:
- Wie viele Nutzer sind betroffen?
- Welche Geschäftsprozesse sind beeinträchtigt?
- Ist ein kritischer IT-Service ausgefallen?
- Gibt es eine Ausweichmöglichkeit?
- Besteht ein Sicherheits- oder Compliance-Risiko?
- Muss eine vertragliche Reaktionszeit eingehalten werden?Auswirkung und Dringlichkeit bilden zusammen die Grundlage für die Priorität.
-
Wer ist zuständig?
5
Zuständigkeit und Service Level werden ermittelt
Anhand des betroffenen Services, der Kategorie, der Organisation und weiterer Merkmale wird bestimmt, welches Team den Vorgang bearbeitet.
Gleichzeitig wird geprüft, welche Reaktions-, Bearbeitungs- und Lösungszeiten gelten. Diese können sich beispielsweise aus Service Level Agreements, internen Vereinbarungen oder Kundenverträgen ergeben.
-
Direktlösung / Delegation
6
Erstlösung oder Weiterleitung erfolgt
Der Service Desk prüft, ob das Anliegen direkt gelöst werden kann. Standardisierte Lösungen, Wissensartikel, Checklisten und Automatisierungen unterstützen eine schnelle Bearbeitung.
Kann der SPoC das Anliegen nicht selbst abschließen, wird es gezielt an das zuständige Support-Team weitergegeben.
Eine Weiterleitung sollte nicht nur aus dem Wechsel einer Zuständigkeit bestehen. Sie muss alle bereits erfassten Informationen enthalten, damit der Anwender sein Anliegen nicht erneut erklären muss.
-
laufende Überwachung
7
Bearbeitung wird überwacht
Auch nach der Weiterleitung bleibt der Vorgang im ITSM-System sichtbar. Fristen, Statusänderungen, Eskalationsgrenzen und Rückfragen werden überwacht.
Dadurch wird verhindert, dass Tickets zwischen Teams liegen bleiben oder ohne nachvollziehbaren Bearbeitungsstand weitergegeben werden.
-
Anwender informieren
8
Anwender erhält Statusinformationen
Der SPoC bestätigt den Eingang, fordert bei Bedarf fehlende Informationen an und informiert über relevante Statusänderungen.
Eine gute Statuskommunikation beantwortet insbesondere folgende Fragen:
- Ist die Anfrage angekommen?
- Wie wurde sie eingeordnet?
- Wer bearbeitet den Vorgang?
- Gibt es eine bekannte Lösung oder einen Workaround?
- Wann ist mit dem nächsten Bearbeitungsschritt zu rechnen?
- Wurde das Anliegen gelöst oder abgeschlossen? -
Erledigung
9
Lösung und Abschluss werden dokumentiert
Nach der Bearbeitung wird dokumentiert, welche Lösung umgesetzt wurde. Der Anwender erhält eine Abschlussinformation und kann gegebenenfalls bestätigen, ob das Anliegen vollständig gelöst ist.
Ein Ticket sollte erst abgeschlossen werden, wenn die Lösung nachvollziehbar dokumentiert ist.
-
Erkenntnisse nutzen und Prozesse verbessern
10
Erkenntnisse werden weiterverwendet
Wiederkehrende Fragen, häufige Störungen und erfolgreiche Lösungswege liefern wichtige Informationen für:
- Wissensmanagement
- Self-Service
- Problem Management
- Prozessverbesserungen
- Automatisierungen
- Reporting
- ServiceverbesserungenSo wird der SPoC nicht nur zur Annahmestelle, sondern zu einem zentralen Informationspunkt für die gesamte IT-Organisation.
Incident, Service Request, Problem oder Change?
Eine der wichtigsten Aufgaben des SPoC ist die korrekte Einordnung eines Anliegens. Werden unterschiedliche Vorgangsarten vermischt, entstehen falsche Prioritäten, unnötige Weiterleitungen und unklare Erwartungen.
| Anliegen | ITSM-Einordnung | Beispiel |
|---|---|---|
| Ein IT-Service funktioniert nicht oder nur eingeschränkt | Incident | Das ERP-System ist nicht erreichbar |
| Eine standardisierte Leistung wird benötigt | Service Request | Ein neuer Softwarezugang wird beantragt |
| Die Ursache wiederkehrender Störungen soll untersucht werden | Problem Management | Eine Schnittstelle fällt regelmäßig aus |
| Eine kontrollierte Veränderung ist erforderlich | Change | Eine produktive Systemkonfiguration soll angepasst werden |
| Eine allgemeine Information wird benötigt | Informationsanfrage | Ein Anwender fragt nach einem verfügbaren IT-Service |
| Ein System meldet einen technischen Zustand | Event Management | Das Monitoring erkennt eine kritische Kapazitätsgrenze |
Incident
Ein Incident liegt vor, wenn ein IT-Service ungeplant unterbrochen ist oder nicht wie vorgesehen funktioniert. Ziel des Incident Managements ist es, die normale Servicebereitstellung so schnell wie möglich wiederherzustellen.
Der SPoC erfasst den Incident, bewertet seine Auswirkung und Dringlichkeit und leitet die erforderlichen Bearbeitungsschritte ein.
Weitere Informationen finden Sie im Beitrag Incident Management.
Service Request
Ein Service Request ist eine standardisierte Anfrage nach einer Leistung, Information oder Bereitstellung.
Typische Beispiele sind:
- neues Benutzerkonto
- Softwarebereitstellung
- Berechtigungsanfrage
- Hardwarebestellung
- Passwortzurücksetzung
- Auskunft zu einem IT-Service
Service Requests sollten über definierte Workflows bearbeitet werden. Dazu können Genehmigungen, Prüfungen, automatische Aufgaben und standardisierte Bereitstellungen gehören.
Problem
Ein Problem ist die zugrunde liegende oder noch unbekannte Ursache eines oder mehrerer Incidents.
Der SPoC führt in der Regel nicht selbst das Problem Management durch. Er erkennt jedoch Muster, dokumentiert wiederkehrende Störungen und liefert die Daten, die für eine Ursachenanalyse erforderlich sind.
Weitere Informationen finden Sie im Beitrag Problem Management.
Change
Ein Änderungswunsch wird nicht automatisch zu einem formalen Change. Der SPoC nimmt den Bedarf auf und veranlasst seine Einordnung.
Ob daraus ein Change entsteht, hängt von den definierten Prozessen, Risiken, Freigaberegeln und Verantwortlichkeiten ab.
Weitere Informationen finden Sie im Beitrag Change Management.
Aufgaben des SPoC entlang des Ticketlebenszyklus
Die Aufgaben des SPoC lassen sich am besten entlang des gesamten Ticketlebenszyklus betrachten.
Annahme und Dokumentation
Der SPoC sorgt dafür, dass alle erforderlichen Informationen vollständig und strukturiert vorliegen. Freitext allein reicht häufig nicht aus. Formulare, Pflichtfelder und geführte Erfassungsdialoge verbessern die Datenqualität.
Klassifizierung
Anliegen werden einer Vorgangsart, einem Service, einer Kategorie und gegebenenfalls einem betroffenen Configuration Item zugeordnet.
Eine gute Klassifizierung ist wichtig für:
- automatische Zuweisungen
- Priorisierung
- SLA-Ermittlung
- Reporting
- Wissensmanagement
- Problem Management
Priorisierung
Die Priorität bestimmt, wie schnell ein Vorgang bearbeitet werden muss. Sie sollte auf einheitlichen Regeln beruhen.
Eine häufige Grundlage ist eine Impact-Urgency-Matrix, bei der geschäftliche Auswirkung und zeitliche Dringlichkeit kombiniert werden.
Erstdiagnose
Der Service Desk prüft bekannte Lösungen, Wissensartikel, bestehende Störungen und mögliche Workarounds.
Je mehr Anliegen beim ersten Kontakt gelöst werden, desto geringer ist der Aufwand für nachgelagerte Support-Ebenen.
Zuweisung
Kann der Vorgang nicht direkt gelöst werden, wird er an das zuständige Team weitergegeben. Automatische Zuweisungsregeln können dabei Kategorien, Services, Standorte, Organisationen oder Kompetenzen berücksichtigen.
Überwachung
Der SPoC überwacht offene Vorgänge, Rückfragen, Bearbeitungsfristen und SLA-Grenzen.
Besondere Aufmerksamkeit benötigen:
- überfällige Tickets
- Tickets ohne zuständige Bearbeitung
- Vorgänge mit hohem geschäftlichem Einfluss
- fehlende Rückmeldungen
- wiederholt weitergeleitete Tickets
- kurz vor der Verletzung stehende Service Level
Eskalation
Der SPoC erkennt definierte Eskalationssituationen und stößt die erforderlichen Schritte an.
Bei einer funktionalen Eskalation wird ein Vorgang an ein Team mit zusätzlicher Expertise weitergegeben.
Bei einer hierarchischen Eskalation werden verantwortliche Leitungs- oder Managementrollen einbezogen, wenn Risiko, Priorität oder geschäftliche Auswirkungen dies erfordern.
Die fachliche Verantwortung für eine Eskalation kann bei Service Ownern, Process Ownern, Supportleitungen oder einem Major Incident Manager liegen. Der SPoC sorgt dafür, dass der Vorgang nach den festgelegten Regeln weitergeführt wird.
Kommunikation
Der SPoC stellt sicher, dass der Anwender nicht selbst nach dem Bearbeitungsstand suchen muss. Dazu gehören Eingangsbestätigungen, Rückfragen, Statusmeldungen, Hinweise zu Workarounds und Abschlussinformationen.
Abschluss
Vor dem Abschluss wird geprüft, ob:
- die Lösung dokumentiert ist
- der Anwender informiert wurde
- offene Aufgaben abgeschlossen sind
- die richtige Abschlusskategorie gewählt wurde
- relevante Erkenntnisse in das Wissensmanagement übernommen werden sollten
Welche Eingangskanäle gehören zu einem SPoC?
Ein moderner SPoC kann mehrere Eingangskanäle anbieten. Entscheidend ist nicht die Anzahl der Kanäle, sondern deren gemeinsame Steuerung.
Self-Service-Portal
Ein Self-Service-Portal ermöglicht Anwendern, Anfragen strukturiert zu erfassen, Services auszuwählen, den Bearbeitungsstand einzusehen und Wissensartikel zu nutzen.
Geführte Formulare verbessern die Datenqualität und reduzieren Rückfragen.
E-Mail bleibt in vielen Unternehmen ein wichtiger Eingangskanal. Ohne automatische Zuordnung, Regelwerke und strukturierte Verarbeitung besteht jedoch die Gefahr, dass wichtige Informationen nur als unstrukturierter Freitext vorliegen.
Telefon
Telefonische Kontaktaufnahme ist besonders bei dringenden Störungen oder komplexen Sachverhalten hilfreich. Die Inhalte des Gesprächs müssen anschließend vollständig im ITSM-System dokumentiert werden.
Chat
Chat bietet einen schnellen Kommunikationsweg und kann bei einfachen Fragen oder Erstdiagnosen unterstützen. Auch hier sollte aus einem bearbeitungsrelevanten Anliegen ein nachvollziehbarer Vorgang entstehen.
Schnittstellen
Andere Systeme können über Schnittstellen Tickets, Ereignisse oder Aufgaben erzeugen. Beispiele sind:
- Monitoring-Systeme
- Fachanwendungen
- E-Commerce-Systeme
- HR-Systeme
- Gebäude- und Anlagentechnik
- externe Kundenportale
Ein SPoC ist damit nicht auf einen einzelnen technischen Eingang beschränkt. Er bildet vielmehr den zentral gesteuerten Zugang zu den dahinterliegenden Serviceprozessen.
Rollen und Zuständigkeiten im SPoC-Modell
Ein SPoC funktioniert nur, wenn Zuständigkeiten eindeutig geregelt sind.
| Rolle | Typische Verantwortung |
|---|---|
| Service-Desk-Agent | Annahme, Dokumentation, Klassifizierung, Erstdiagnose und Kommunikation |
| First-Level-Support | Bearbeitung standardisierter und häufig auftretender Anliegen |
| Second-Level-Support | Bearbeitung spezialisierter technischer oder fachlicher Vorgänge |
| Service-Desk-Leitung | Steuerung von Auslastung, Qualität, Eskalationen und Kennzahlen |
| Service Owner | Verantwortung für Qualität, Leistung und Weiterentwicklung eines IT-Service |
| Process Owner | Verantwortung für Gestaltung und Wirksamkeit eines ITSM-Prozesses |
| Major Incident Manager | Koordination geschäftskritischer Störungen |
| Knowledge Manager | Aufbau, Qualität und Nutzung des Wissensbestands |
| Fachbereich oder externer Dienstleister | Bearbeitung definierter fachlicher oder technischer Aufgaben |
Wichtig ist, dass die Weitergabe eines Tickets nicht zu einem Verlust der Verantwortung führt. Jeder Vorgang benötigt jederzeit einen nachvollziehbaren Status, eine zuständige Bearbeitung und einen definierten nächsten Schritt.
Welche Kennzahlen zeigen die Wirksamkeit des SPoC?
Ein SPoC sollte nicht nur erreichbar, sondern messbar wirksam sein. Kennzahlen helfen dabei, Qualität, Auslastung und Verbesserungspotenziale zu erkennen.
First Contact Resolution Rate
Die First Contact Resolution Rate zeigt, welcher Anteil der Anliegen bereits beim ersten Kontakt gelöst wird.
Eine hohe Quote kann auf eine gute Wissensdatenbank, klare Prozesse und ausreichende Kompetenzen im Service Desk hinweisen.
Berechnung: Beim Erstkontakt gelöste geeignete Tickets / alle geeigneten Tickets x 100
Reaktionszeit
Die Reaktionszeit misst, wie schnell nach Eingang einer Anfrage eine qualifizierte Bearbeitung beginnt.
Eine automatische Eingangsbestätigung allein ist noch keine fachliche Reaktion.
Lösungszeit
Die Lösungszeit zeigt, wie lange ein Vorgang vom Eingang bis zur vollständigen Lösung benötigt.
Dabei sollte nach Priorität, Service, Kategorie und Vorgangsart unterschieden werden.
SLA-Erfüllungsquote
Die SLA-Erfüllungsquote zeigt, welcher Anteil der Vorgänge innerhalb der vereinbarten Zeiten bearbeitet oder gelöst wurde.
Berechnung: Innerhalb des vereinbarten Service Levels bearbeitete Tickets / alle SLA-relevanten Tickets x 100
Weiterleitungsquote
Die Weiterleitungsquote macht sichtbar, wie häufig Tickets an andere Teams übergeben werden.
Eine sehr hohe Quote kann auf fehlende Kompetenzen, unklare Zuständigkeiten oder eine zu grobe Klassifizierung hinweisen.
Wiedereröffnungsquote
Die Wiedereröffnungsquote zeigt, wie viele bereits abgeschlossene Tickets erneut geöffnet werden.
Eine hohe Quote kann auf unvollständige Lösungen, unklare Kommunikation oder verfrühte Abschlüsse hinweisen.
Anzahl überfälliger Tickets
Überfällige Tickets zeigen unmittelbaren Handlungsbedarf. Sie sollten nach Ursache, zuständiger Gruppe, Priorität und betroffenem Service ausgewertet werden.
Anwenderzufriedenheit
Eine kurze Bewertung nach Ticketabschluss liefert Hinweise darauf, wie Anwender Erreichbarkeit, Kommunikation und Lösung wahrnehmen.
Self-Service-Quote
Die Self-Service-Quote zeigt, welcher Anteil der Anliegen über ein Portal, standardisierte Formulare, Wissensartikel oder automatisierte Prozesse abgewickelt wird.
Wissensnutzung
Auch die Nutzung und Wirksamkeit von Wissensartikeln sollte betrachtet werden:
- Wie häufig werden Artikel aufgerufen?
- Welche Artikel führen zur Ticketvermeidung?
- Welche Lösungen werden vom Service Desk genutzt?
- Welche Inhalte sind veraltet oder unvollständig?
Beispiel für ein SPoC-Dashboard
Ein Dashboard für den SPoC und Service Desk sollte operative und qualitative Kennzahlen miteinander verbinden.
Sinnvolle Elemente sind:
- offene Tickets nach Status
- Tickets nach Priorität
- Ticketvolumen nach Zeitraum
- Tickets nach Eingangskanal
- Tickets nach Service und Kategorie
- SLA-gefährdete Vorgänge
- überfällige Tickets
- durchschnittliche Reaktionszeit
- durchschnittliche Lösungszeit
- First Contact Resolution Rate
- Weiterleitungsquote
- Wiedereröffnungsquote
- Anwenderzufriedenheit
- Auslastung der Support-Gruppen
- häufigste Störungen und Service Requests
Ein Dashboard sollte nicht nur Zahlen darstellen. Es muss deutlich machen, wo Handlungsbedarf besteht. Dazu gehören beispielsweise steigende Ticketvolumen, wiederkehrende Störungen, überlastete Teams oder gefährdete Service Level.
Praxisbeispiel: Störung eines geschäftskritischen IT-Service
Ein Anwender meldet, dass er nicht auf das ERP-System zugreifen kann.
Der SPoC erfasst zunächst:
- betroffenen Nutzer
- Standort
- betroffenen Service
- Fehlermeldung
- Zeitpunkt des Auftretens
- mögliche Auswirkungen
- bereits durchgeführte Maßnahmen
Anschließend prüft der Service Desk, ob bereits ähnliche Meldungen vorliegen.
Ist nur ein einzelner Anwender betroffen, kann ein normaler Incident eröffnet und zunächst eine standardisierte Diagnose durchgeführt werden.
Sind mehrere Abteilungen oder Standorte betroffen, steigt die geschäftliche Auswirkung. Die Priorität wird entsprechend angepasst. Je nach Umfang kann der Major-Incident-Prozess angestoßen werden.
Der SPoC sorgt in diesem Fall nicht nur für die Aufnahme. Er koordiniert auch die Kommunikation, informiert betroffene Anwender über den Status und dokumentiert Workarounds oder Lösungen.
Nach Abschluss können die Daten für das Problem Management ausgewertet werden, wenn die Störung wiederholt aufgetreten ist oder ihre Ursache noch nicht dauerhaft beseitigt wurde.
SPoC im ITSM einführen: Vorgehen in der Praxis
Die Einführung eines SPoC sollte nicht mit einer neuen E-Mail-Adresse beginnen. Zuerst müssen Prozesse, Rollen und Zuständigkeiten geklärt werden.
-
Anfragearten analysieren
1
Zunächst wird untersucht, welche Anliegen regelmäßig auftreten.
Dazu gehören beispielsweise:
- Incidents
- Service Requests
- Berechtigungsanfragen
- Informationsanfragen
- Änderungsbedarfe
- Rückfragen zu bestehenden Tickets
- Meldungen externer SystemeErgebnis: definierte Vorgangs- und Prozessarten.
-
Eingangskanäle festlegen
2
Unternehmen müssen entscheiden, welche Kanäle verbindlich angeboten werden und wie diese technisch zusammengeführt werden.
Ergebnis: ein verbindliches Kanalkonzept.
-
Rollen und Zuständigkeiten definieren
3
Es muss eindeutig geregelt sein:
- Wer nimmt Anfragen entgegen?
- Wer klassifiziert und priorisiert?
- Welche Anliegen löst der First Level?
- Wann erfolgt eine Weitergabe?
- Wer überwacht Eskalationen?
- Wer kommuniziert mit dem Anwender?Ergebnis: ein nachvollziehbares Verantwortlichkeitsmodell.
-
Services und Kategorien aufbauen
4
Anfragen sollten nicht nur allgemeinen technischen Kategorien zugeordnet werden. Eine serviceorientierte Struktur schafft bessere Auswertungsmöglichkeiten.
Ergebnis: ein Service- und Kategoriekatalog.
-
Prioritäten und Eskalationsregeln festlegen
5
Auswirkung und Dringlichkeit müssen nach einheitlichen Kriterien bewertet werden.
Ergebnis: eine Prioritätsmatrix mit definierten Eskalationswegen.
-
Service Level definieren
6
Für unterschiedliche Services und Vorgangsarten werden Reaktions-, Bearbeitungs- und Lösungszeiten festgelegt.
Ergebnis: messbare Serviceziele.
-
ITSM-Workflows konfigurieren
7
Die definierten Regeln werden in einer ITSM-Lösung abgebildet.
Dazu gehören:
- Formulare
- Statusmodelle
- Pflichtfelder
- Zuweisungsregeln
- Genehmigungen
- Eskalationen
- Benachrichtigungen
- Automatisierungen
- AuswertungenErgebnis: ein technisch ausführbarer ITSM-Prozess.
-
Wissen und Self-Service integrieren
8
Häufige Fragen und standardisierte Leistungen sollten über Wissensartikel, Servicekataloge und Self-Service bereitgestellt werden.
Ergebnis: Entlastung des Service Desks und bessere Nutzerorientierung.
-
Anwender und Support-Teams schulen
9
Anwender müssen wissen, wie der SPoC genutzt wird und welche Informationen für eine schnelle Bearbeitung erforderlich sind.
Support-Teams müssen verstehen, wie Klassifizierung, Priorisierung, Weiterleitung und Dokumentation erfolgen.
Ergebnis: ein einheitlich gelebter Prozess.
-
Kennzahlen auswerten und Prozesse verbessern
10
Nach der Einführung werden Ticketdaten, Service Level, Weiterleitungen und Nutzerfeedback regelmäßig ausgewertet.
Ergebnis: kontinuierliche Verbesserung auf Basis belastbarer Daten.
Mit EcholoN lassen sich Eingangskanäle, Rollen, Prioritäten, SLAs, Eskalationen und Workflows in einer zentralen ITSM-Lösung verbinden.
Typische Fehler bei der SPoC-Umsetzung – und wie Sie sie vermeiden
Ein SPoC liefert keinen automatischen Mehrwert. Häufig scheitert die Umsetzung an organisatorischen Lücken.
Der SPoC wird nur als E-Mail-Adresse verstanden
Eine gemeinsame Mailbox bündelt zwar Nachrichten, erzeugt aber noch keinen steuerbaren ITSM-Prozess.
Besser: E-Mails automatisch in strukturierte Vorgänge überführen und mit Kategorien, Prioritäten, Zuständigkeiten und Fristen verbinden.
Direktkommunikation umgeht den Prozess
Anwender wenden sich weiterhin an einzelne IT-Mitarbeitende. Dadurch fehlen Tickets, Kennzahlen und transparente Bearbeitungsstände.
Besser: klare Kommunikationsregeln etablieren und Direktanfragen konsequent dokumentieren.
Kategorien sind unklar oder zu umfangreich
Zu viele Kategorien erschweren die Auswahl. Zu wenige Kategorien verhindern eine sinnvolle Zuordnung.
Besser: Kategorien anhand tatsächlicher Services und Anfragearten entwickeln und regelmäßig überprüfen.
Prioritäten werden subjektiv vergeben
Wenn jede Anfrage als dringend eingestuft wird, verliert die Priorisierung ihre Wirkung.
Besser: Auswirkung und Dringlichkeit nach definierten Kriterien bewerten.
Tickets werden ohne Informationen weitergeleitet
Nachgelagerte Teams müssen erneut beim Anwender nachfragen.
Besser: Pflichtinformationen und Übergabekriterien definieren.
Anwender erhalten keine Statusinformationen
Auch eine fachlich korrekte Bearbeitung wird negativ wahrgenommen, wenn die Kommunikation fehlt.
Besser: automatisierte und manuelle Statusmeldungen miteinander verbinden.
Wiederkehrende Störungen werden nicht ausgewertet
Identische Incidents werden immer wieder einzeln gelöst, ohne die Ursache zu untersuchen.
Besser: Ticketdaten mit Problem Management und Wissensmanagement verbinden.
SLAs werden definiert, aber nicht überwacht
Vereinbarte Zeiten bleiben wirkungslos, wenn keine Warnungen oder Eskalationen ausgelöst werden.
Besser: Schwellenwerte, Benachrichtigungen und Eskalationsregeln technisch abbilden.
EcholoN als Plattform für SPoC, Service Desk und ITSM-Prozesse
Ein SPoC benötigt eine gemeinsame Daten- und Prozessbasis. Werden Telefonate, E-Mails, Portalvorgänge und direkte Meldungen getrennt verwaltet, bleibt die zentrale Anlaufstelle organisatorisch unvollständig.
EcholoN unterstützt Unternehmen dabei, unterschiedliche Eingangskanäle und Serviceprozesse auf einer gemeinsamen Plattform zusammenzuführen.
Anfragen können zentral erfasst, betroffenen Services zugeordnet, klassifiziert und nach definierten Regeln priorisiert werden. Zuständigkeiten, Service Level, Eskalationen und Bearbeitungsstände bleiben über den gesamten Vorgang hinweg nachvollziehbar.
Zu den möglichen Funktionen gehören:
- zentrale Ticket- und Vorgangserfassung
- Service- und Kategoriekataloge
- Zuordnung zu Kunden, Organisationen und Anwendern
- Zuordnung zu IT-Services und Configuration Items
- Priorisierung nach Auswirkung und Dringlichkeit
- automatische Zuweisungsregeln
- SLA-Überwachung
- funktionale und hierarchische Eskalationen
- Aufgaben und Genehmigungsworkflows
- Statuskommunikation
- Wissensmanagement
- Self-Service
- Reporting und Dashboards
- Anbindung weiterer Systeme und Fachbereiche
Dadurch wird der Service Desk nicht nur zur Kontaktstelle, sondern zur steuerbaren operativen Einheit im IT Service Management.
Die Verbindung mit Wissensmanagement, Self-Service, Configuration Management, Workflows und weiteren Enterprise-Service-Management-Prozessen ermöglicht es, Informationen mehrfach zu nutzen und Abläufe schrittweise zu verbessern.
Weitere Informationen finden Sie unter:
Fazit: Ein SPoC macht ITSM-Prozesse nachvollziehbar und steuerbar
Ein SPoC im IT Service Management schafft einen verbindlichen Zugang zu IT-Services, ohne Anwender mit internen Zuständigkeiten zu belasten.
Sein Nutzen entsteht jedoch nicht allein durch einen zentralen Kontaktkanal. Entscheidend sind die dahinterliegenden Prozesse: strukturierte Erfassung, korrekte Klassifizierung, nachvollziehbare Priorisierung, klare Zuständigkeiten, überwachte Service Level, gezielte Eskalationen und eine verlässliche Kommunikation.
In der Praxis übernimmt häufig der Service Desk diese Rolle. Er löst Anliegen direkt oder koordiniert die Bearbeitung durch nachgelagerte Teams. Gleichzeitig liefert er die Datenbasis für Reporting, Wissensmanagement, Problem Management und kontinuierliche Serviceverbesserungen.
Für Unternehmen bedeutet das:
- weniger unstrukturierte Direktanfragen
- klarere Zuständigkeiten
- bessere Datenqualität
- transparentere Bearbeitungsstände
- verlässlichere Service Level
- schnellere und nachvollziehbare Lösungen
- bessere Steuerbarkeit der IT-Organisation
Mit einer geeigneten ITSM-Plattform wird aus einer zentralen Kontaktstelle ein durchgängiger Serviceprozess.
Ein wirksamer SPoC benötigt mehr als einen zentralen Eingangskanal. Entscheidend sind strukturierte Prozesse, klare Zuständigkeiten, automatisierte Eskalationen, überwachte Service Level und eine transparente Kommunikation.
Mit EcholoN bilden Unternehmen Service Desk, Ticketmanagement, Self-Service, Wissensmanagement und weitere ITSM-Prozesse auf einer gemeinsamen Plattform ab.
Sie möchten prüfen, wie sich ein SPoC in Ihrer IT-Organisation umsetzen oder verbessern lässt?
FAQ: Häufige Fragen zum SPoC im IT Service Management
Was ist ein SPoC im IT Service Management?
Ein SPoC im IT Service Management ist die zentrale Anlaufstelle für IT-Anfragen, Störungen und Service Requests. Er nimmt Anliegen entgegen, dokumentiert sie, klassifiziert sie und überführt sie in den passenden ITSM-Prozess.
Ist der Service Desk immer der SPoC?
In vielen Unternehmen übernimmt der Service Desk die Rolle des SPoC. Grundsätzlich beschreibt SPoC jedoch ein Organisationsprinzip. Auch andere zentrale Serviceeinheiten können diese Funktion übernehmen.
Bedeutet SPoC, dass nur ein Eingangskanal erlaubt ist?
Nein. Ein SPoC kann über mehrere Kanäle wie Portal, E-Mail, Telefon oder Chat erreichbar sein. Entscheidend ist, dass alle Vorgänge zentral dokumentiert und nach einheitlichen Prozessen bearbeitet werden.
Wie unterscheidet der SPoC Incidents und Service Requests?
Ein Incident beschreibt eine ungeplante Störung oder Einschränkung eines IT-Service. Ein Service Request ist eine standardisierte Anfrage nach einer Leistung, Information oder Bereitstellung.
Muss der SPoC jedes Ticket selbst lösen?
Nein. Der SPoC kann Tickets direkt lösen oder an spezialisierte Support-Teams weitergeben. Er sorgt jedoch dafür, dass der Vorgang vollständig dokumentiert, korrekt zugewiesen und nachvollziehbar bearbeitet wird.
Welche Informationen sollte der SPoC bei einer Störung erfassen?
Wichtige Informationen sind der betroffene Service, die betroffenen Anwender, der Zeitpunkt des Auftretens, die Fehlermeldung, die geschäftlichen Auswirkungen und bereits durchgeführte Maßnahmen.
Welche Kennzahlen sind für einen SPoC relevant?
Wichtige Kennzahlen sind unter anderem First Contact Resolution Rate, Reaktionszeit, Lösungszeit, SLA-Erfüllungsquote, Weiterleitungsquote, Wiedereröffnungsquote, Anzahl überfälliger Tickets und Anwenderzufriedenheit.
Wie unterstützt ITSM-Software einen SPoC?
ITSM-Software bündelt Eingangskanäle, dokumentiert Tickets, unterstützt Klassifizierung und Priorisierung, steuert Zuständigkeiten, überwacht Service Level und ermöglicht Eskalationen, Reporting, Wissensmanagement und Self-Service.
Ist ein SPoC ein Single Point of Failure?
Nein. Ein Single Point of Contact ist ein zentraler organisatorischer Kontaktpunkt. Er sollte nicht von einer einzelnen Person oder einem einzigen nicht abgesicherten System abhängen. Vertretungsregeln, mehrere Eingangskanäle und technische Ausfallsicherheit verhindern, dass aus dem SPoC ein Single Point of Failure wird.
Wie führt man einen SPoC im ITSM ein?
Ein SPoC im IT Service Management wird eingeführt, indem Unternehmen zunächst die bestehenden Anfragearten, Kontaktwege und Zuständigkeiten analysieren. Anschließend werden zentrale Eingangskanäle, Rollen, Priorisierungsregeln, Service Levels und Eskalationswege festgelegt und im ITSM-System abgebildet. Mitarbeitende werden geschult, Anwender über die neuen Kontaktwege informiert und der Betrieb zunächst kontrolliert gestartet. Kennzahlen wie Erstlösungsquote, Reaktionszeit, Weiterleitungsquote und Anwenderzufriedenheit zeigen danach, wo der SPoC weiter verbessert werden muss.