Auch anspruchsvoller Produktsupport lässt sich auslagern. Voraussetzung ist, dass ein externes Team das Produkt verstehen, auf die benötigten Systeme zugreifen und im vereinbarten Rahmen Entscheidungen treffen kann. Für neue oder außergewöhnliche Fälle braucht es geregelte Wege zu Produktmanagement, Entwicklung oder anderen Fachbereichen.
Die Schwierigkeit einer Kundenfrage allein entscheidet nicht darüber, ob sie extern bearbeitet werden kann. Wichtiger ist, ob das nötige Wissen verfügbar ist, der Vorgang nachvollziehbar beschrieben werden kann und das Support-Team die erforderlichen Befugnisse erhält.
Was mit Produktsupport gemeint ist
Produktsupport beantwortet Fragen zur Nutzung eines Produkts und begleitet Kunden bei konkreten Problemen. Bei einer Software kann das die Einrichtung eines Kontos, eine fehlerhafte Buchung, den Import von Daten, eine Vertragsänderung oder eine unerwartete Programmmeldung betreffen. Bei anderen Produkten geht es zum Beispiel um Konfiguration, Bestellung, Lieferung, Bedienung oder Reklamation.
Damit unterscheidet sich Produktsupport vom allgemeinen IT-Support. Ein IT-Dienstleister betreut häufig Arbeitsplätze, Netzwerke, Geräte oder interne Unternehmenssysteme. Produktbezogener Support vertritt dagegen den Hersteller oder Anbieter gegenüber dessen Kunden und Anwendern.
Auch die Bezeichnung First Level greift oft zu kurz. Sie beschreibt zunächst nur die erste Anlaufstelle. Ob dieses Team einen Fall selbst abschließt oder lediglich Daten für eine weitere Bearbeitung sammelt, hängt vom aufgebauten Wissen, den Zugriffsrechten und den vereinbarten Befugnissen ab.
Welche anspruchsvollen Supportfälle ausgelagert werden können
Ein externer Dienstleister kann mehr übernehmen als Passwort-Resets und bekannte Standardfragen. Geeignet sind auch fachlich anspruchsvolle Vorgänge, wenn das Team sie zuverlässig erkennen, bearbeiten und dokumentieren kann.
Typische Beispiele sind:
- Anwenderfragen zu Funktionen und Arbeitsabläufen
- Unterstützung bei Einrichtung, Konfiguration und Datenübernahme
- Prüfung von Konten, Verträgen oder Bearbeitungsständen
- Backoffice-Vorgänge und Vertragsänderungen innerhalb festgelegter Befugnisse
- Aufnahme und Eingrenzung von Fehlermeldungen
- Begleitung bei bekannten Produktproblemen und freigegebenen Zwischenlösungen
- Terminierung und Übergabe an Fachabteilungen bei nicht abschließbaren Fällen
Ein externer Support kann dabei unterschiedlich tief eingebunden sein. Manche Vorgänge werden vollständig abgeschlossen. Bei anderen übernimmt das Team Diagnose, Datenerfassung und Kommunikation, während eine technische oder geschäftliche Entscheidung an eine zuständige Stelle geht.
Auch ein internes Serviceteam benötigt bei Produktfehlern, Sicherheitsvorfällen oder grundlegenden Vertragsentscheidungen die Unterstützung anderer Abteilungen. Kunden sollten trotzdem nicht selbst herausfinden müssen, wer zuständig ist. Bei einer Übergabe muss der bisherige Verlauf erhalten bleiben.
Nicht die Supportstufe, sondern die Bearbeitungsbefugnis zählt
Die klassische Einteilung in First, Second und Third Level kann bei der Organisation helfen. Für die Frage, was ausgelagert werden kann, ist sie aber nicht ausreichend.
Ein externes Team kann einen vermeintlichen Second-Level-Fall abschließend bearbeiten, wenn das Wissen dokumentiert und der notwendige Systemzugriff vorhanden ist. Umgekehrt kann eine einfache Anfrage intern bleiben müssen, wenn dafür eine besondere Freigabe erforderlich ist.
Für jede Fallart sollten deshalb vier Fragen beantwortet werden:
- Woran erkennt das Team den Fall?
- Welche Informationen und Systeme werden für die Bearbeitung benötigt?
- Welche Entscheidung darf das Team selbst treffen?
- Mit welchem Ergebnis gilt der Vorgang als abgeschlossen oder übergabefähig?
Aus diesen Antworten entsteht eine konkrete Aufgabenbeschreibung. Sie ist genauer als eine pauschale Vorgabe, nach der ein Dienstleister nur First Level übernehmen darf.
Produktwissen für ein externes Team aufbauen
Die Einarbeitung beginnt nicht mit einem langen Handbuch, das anschließend unverändert bleibt. Ein Support-Team benötigt Wissen in einer Form, die während eines konkreten Falls schnell auffindbar und anwendbar ist.
Hilfreich sind unter anderem:
- Produktübersichten und zentrale Begriffe
- häufige Anliegen mit geprüften Lösungswegen
- echte oder anonymisierte Beispielfälle
- bekannte Fehler und freigegebene Zwischenlösungen
- Regeln für Vertrags- und Backoffice-Vorgänge
- klare Hinweise auf Fälle, die eine Rückfrage benötigen
- Ansprechpartner für Produktänderungen und neue Probleme
Vor dem Start sollte das Team typische Fälle in einer Testumgebung oder anhand vorbereiteter Beispiele bearbeiten. Dabei zeigt sich, ob Informationen fehlen, Anweisungen missverständlich sind oder ein Systemzugriff noch nicht ausreicht.
Wissen muss im laufenden Support gepflegt werden
Produkte ändern sich. Neue Funktionen, Tarife, Fehlerbilder oder interne Prozesse machen selbst eine gute Anfangsdokumentation mit der Zeit unvollständig. Wissenspflege gehört deshalb in den laufenden Supportprozess.
Der KCS v6 Practices Guide des Consortium for Service Innovation ordnet Wissen als Nebenprodukt der Bearbeitung von Anfragen ein. Im sogenannten Solve Loop sollen vorhandene Wissensartikel wiederverwendet und verbessert oder neu erstellt werden, wenn noch kein passender Artikel existiert.
Die Technik “Reuse is Review” verbindet Nutzung und Prüfung: Mitarbeitende tragen bei der Fallbearbeitung Verantwortung für die Qualität der Artikel, mit denen sie arbeiten, und verbessern diese bei Bedarf. Die anschließende Technik “Flag It or Fix It” sieht zwei Wege vor. Wer sich sicher ist und die nötige Berechtigung hat, korrigiert den Artikel. Andernfalls wird er markiert, damit ein Fachexperte ihn prüft.
Für die Zusammenarbeit sollten deshalb Änderungsrechte und Feedbackwege feststehen:
- Wer darf einen Wissenseintrag direkt korrigieren?
- Welche Änderungen benötigen eine fachliche Freigabe?
- Wie werden neue Fehlerbilder dokumentiert?
- Wer entscheidet bei widersprüchlichen Informationen?
- Wie erreicht eine Produktänderung alle betroffenen Mitarbeitenden?
Welche Systemzugänge der Produktsupport benötigt
Fehlt dem Support-Team der Zugriff auf den Bearbeitungsstand, muss es Rückfragen stellen oder Fälle unnötig weitergeben. Das kann die Bearbeitung selbst dann verzögern, wenn das nötige Produktwissen vorhanden ist.
Je nach Aufgabe können Zugänge zu folgenden Systemen nötig sein:
- CRM oder Kundenverwaltung
- Ticket- und Helpdesk-System
- Vertrags- oder Bestellverwaltung
- Produktadministration
- Wissensdatenbank
- Fehler- und Entwicklungsverfolgung
- Telefonie, E-Mail und Chat
- Reporting oder Kampagnensteuerung
Nicht jedes Teammitglied benötigt dieselben Rechte. Das im NIST-Glossar beschriebene Least-Privilege-Prinzip besagt, dass Benutzer nur die Zugriffe erhalten sollen, die sie für ihre zugewiesenen Aufgaben benötigen. Praktisch bedeutet das: Rollen werden an Fallarten und Bearbeitungsschritte gekoppelt, statt externen Mitarbeitenden pauschal weitreichende Zugänge zu geben.
Vor dem Start sollte außerdem geklärt werden, wie Zugriffe beantragt, geändert und bei einem Rollenwechsel oder Projektende entzogen werden. Wenn mehrere Systeme beteiligt sind, kann eine Integration der Kundenservice-Systeme doppelte Eingaben und Medienbrüche reduzieren.
Befugnisse und Übergaben eindeutig festlegen
Ein Team kann einen Fall nur dann abschließen, wenn es neben Wissen und Zugriff auch handeln darf. Das betrifft zum Beispiel Vertragsänderungen, Gutschriften, Terminverschiebungen, Datenkorrekturen oder freigegebene technische Maßnahmen.
Für jede Fallart sollte beschrieben sein:
- welche Angaben geprüft werden
- welche Änderungen das Team durchführen darf
- welche Grenzen oder Höchstwerte gelten
- welche Dokumentation erforderlich ist
- wann eine zweite Prüfung nötig ist
- an wen der Fall bei einer Ausnahme geht
Eine Übergabe sollte den bisherigen Verlauf, bereits geprüfte Angaben, durchgeführte Schritte und die noch offene Entscheidung enthalten. So beginnt die Fachabteilung nicht wieder bei null und der Kunde muss sein Anliegen nicht erneut erklären.
Für sicherheitsrelevante Meldungen empfiehlt sich ein eigener Bearbeitungsweg. Die NIST SP 800-61 Rev. 3 ordnet Incident Response in das übergreifende Cybersecurity-Risikomanagement ein. Für den Produktsupport lässt sich daraus praktisch ableiten, dass verdächtige Vorfälle nicht wie normale Produktfehler behandelt werden sollten. Meldeweg, zuständige Stelle und die Informationen für eine Übergabe sollten vor dem Betrieb feststehen. Der Verweis dient als fachliche Orientierung und ist keine Zertifizierungsempfehlung.
Qualität bei anspruchsvollem Support prüfen
Eine kurze Bearbeitungszeit beweist noch keine fachlich richtige Antwort. Bei komplexem Produktsupport sollten quantitative Kennzahlen mit Fallprüfungen kombiniert werden.
Sinnvolle quantitative Werte können sein:
- eingegangene und abgeschlossene Vorgänge
- offene Fälle und Rückstände
- Bearbeitungs- und Reaktionszeiten
- Eskalationen und Wiedereröffnungen
- Verteilung nach Fallart und Abschlussgrund
Die fachliche Qualität lässt sich durch vollständige Fallprüfungen oder Stichproben kontrollieren. Dabei wird geprüft, ob die Diagnose nachvollziehbar war, der Wissensstand passte, Befugnisse eingehalten und nächste Schritte vollständig dokumentiert wurden.
Auch Rückmeldungen aus Produktmanagement, Entwicklung oder Vertrieb sind relevant. Wenn übergebene Fälle regelmäßig Informationen vermissen lassen, sollten zunächst Fallbeschreibung, Wissenseintrag und Eingabefelder geprüft werden.
Typische Fehler bei der Übergabe
Eine umfangreiche Dokumentensammlung reicht nicht aus, wenn dem Team die Einordnung fehlt. Probleme können zum Beispiel an diesen Stellen entstehen:
- Der Umfang lautet nur “alle Produktfragen”, ohne konkrete Fallarten und gewünschte Ergebnisse zu benennen.
- Anleitungen werden einmal übergeben, aber Änderungen am Produkt erreichen den Support nicht.
- Das Team sieht Kundendaten, darf notwendige Änderungen im System jedoch nicht durchführen.
- Eine Eskalation ist vorgesehen, aber Ansprechpartner, Rückmeldefrist oder Verantwortung für die Kundenantwort fehlen.
- Die Auswertung misst vor allem Geschwindigkeit und prüft fachliche Antworten nur nach Beschwerden.
Testfälle können solche Lücken vor dem Start sichtbar machen. Sie sollten als Prozessproblem behoben werden, statt später mit zusätzlichen Einzelfallregeln darauf zu reagieren.
So kann die Übergabe in den laufenden Betrieb ablaufen
Die Dauer der Vorbereitung hängt von Produktumfang, Fallarten, Systemzugängen und vorhandenem Wissen ab. Ein fester Zeitraum lässt sich ohne diese Angaben nicht seriös nennen. Ein möglicher Ablauf umfasst folgende Schritte:
1. Aufgaben aufnehmen
Zunächst werden Kanäle, Fallarten, Volumen, Servicezeiten und gewünschte Ergebnisse erfasst. Dabei wird sichtbar, welche Vorgänge vollständig übernommen werden können und welche weitere Stellen einbeziehen.
2. Wissen und Zugänge vorbereiten
Das Team erhält Produktinformationen, Beispieldaten, Systemrollen und Bearbeitungsregeln. Fehlende Inhalte werden bei der Arbeit mit Testfällen ergänzt.
3. Bearbeitung testen
Typische, schwierige und außergewöhnliche Fälle werden durchgespielt. Beide Seiten prüfen Ergebnisse, Dokumentation und Übergaben.
4. Betrieb kontrolliert starten
Der Start kann mit ausgewählten Kanälen oder Fallarten erfolgen. Bei einem vollständigen Supportbereich ist auch ein direkter Übergang möglich, wenn Wissen, Team und Systeme ausreichend vorbereitet sind.
5. Wissen und Ablauf weiterentwickeln
Im laufenden Betrieb zeigen Rückfragen, Fehler und Eskalationen, wo Informationen oder Befugnisse fehlen. Änderungen werden dokumentiert und in die Bearbeitung übernommen.
Den Termitel-Ablauf von Aufgabenaufnahme bis Betrieb beschreibt die Seite Wie wir arbeiten.
Vollständiger Supportbereich oder hybrides Modell?
Unternehmen müssen nicht automatisch mit einem kleinen Teilbereich beginnen. Wenn Produktwissen, Systeme und Befugnisse gut vorbereitet sind, kann ein Dienstleister einen vollständigen Supportbereich übernehmen. Das ist zum Beispiel bei einem klar abgegrenzten Produkt, einer Nutzergruppe oder einem Kontaktkanal möglich.
Ein hybrides Modell eignet sich, wenn interne und externe Teams dauerhaft zusammenarbeiten sollen. Denkbare Aufteilungen sind:
- nach Kontaktkanal
- nach Servicezeit
- nach Produkt oder Kundengruppe
- nach Fallart
- nach erforderlicher Entscheidung
Damit kein Kunde zwischen Teams verloren geht, benötigen beide Seiten einen gemeinsamen Bearbeitungsstand und eindeutige Übergaberegeln. Die Aufteilung sollte nicht allein organisatorisch bequem sein, sondern für den Kunden einen durchgängigen Ablauf ergeben.
Für Softwareanbieter zeigt die Branchenlösung SaaS-Support und Onboarding, welche Aufgaben sich im laufenden Kundenkontakt verbinden lassen.
Checkliste vor dem Outsourcing von Produktsupport
Vor einer Anfrage sollten Unternehmen diese Punkte zumindest grob beschreiben können:
- Welche Produkte, Nutzergruppen und Kontaktkanäle gehören zum Umfang?
- Welche Fallarten treten regelmäßig auf?
- Welche Fälle soll das externe Team vollständig abschließen?
- Welche Systeme und Daten werden dafür benötigt?
- Welche Änderungen und Entscheidungen darf das Team durchführen?
- Welche Wissensquellen und Beispielfälle sind vorhanden?
- Wie werden Produktänderungen und neue Fehlerbilder weitergegeben?
- Welche Fälle benötigen eine Übergabe und welche Informationen gehören dazu?
- Wie werden fachliche Qualität und Dokumentation geprüft?
- Wer entscheidet über Anpassungen im laufenden Betrieb?
Für ein erstes Gespräch müssen diese Antworten noch nicht vollständig sein. Schätzwerte und typische Beispiele reichen aus, um Umfang, offene Fragen und den nötigen Vorlauf einzugrenzen.
Fazit: Komplexität verhindert Outsourcing nicht
Produktsupport muss nicht auf einfache Standardfragen reduziert werden. Ein externer Dienstleister kann auch anspruchsvolle Anwenderfragen, Backoffice- und Vertragsvorgänge oder vollständige Supportbereiche übernehmen.
Ob das funktioniert, hängt nicht an der Bezeichnung First oder Second Level. Ein externer Mitarbeiter sollte bei jedem Fall erkennen können, was zu prüfen ist, was er selbst tun darf und wen er bei einer offenen Frage einbezieht. Dafür braucht das Team anwendbares Produktwissen, passende Systemrechte und eine vollständige Dokumentation des Bearbeitungsstands.
Wer zunächst das grundsätzliche Betriebsmodell prüfen möchte, findet im Vergleich Call Center: Inhouse oder Outsourcing? die wichtigsten Unterschiede bei Kosten, Kapazität und Steuerung.
Quellen und weiterführende Hinweise
- KCS v6 Practices Guide, Consortium for Service Innovation
- KCS Technique 4.1: Reuse is Review, Consortium for Service Innovation
- KCS Technique 4.2: Flag It or Fix It, Consortium for Service Innovation
- NIST Glossary: Least Privilege, National Institute of Standards and Technology
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, National Institute of Standards and Technology