Checkliste & Best Practices: Third-Level-Support

Eine Checkliste mit Best Practices für den Third-Level-Support bei kundenindividuellen Entwicklungen kann dem Support-Team helfen, strukturiert und effizient zu arbeiten – besonders in komplexen oder sensiblen Kundensituationen. Die folgende Checkliste ist nicht in Stein gemeißelt und soll lediglich als Anregung dienen, denn jedes Team im Third-Level-Support hat individuelle Aufgaben.

Dokumentation & Wissensmanagement

Gibt es eine strukturierte Dokumentation der kundenindividuellen Lösung (Architektur, Schnittstellen, Besonderheiten)?
Ist der Quellcode kommentiert und versioniert?
Gibt es ein Wiki oder eine Knowledge Base, die regelmäßig gepflegt wird?
Existieren System- oder Datenflussdiagramme, die Zusammenhänge veranschaulichen?
Wurde Wissen dokumentiert, das aktuell nur in Köpfen einzelner Entwickler existiert?

Am sinnvollsten wäre es, nach jeder Problemlösung oder weiteren Entwicklung ein Lessons Learned zu erfassen oder die einzelnen Schritte und Programmierungen zu dokumentieren. So ist das Wissen noch frisch und es wird nichts vergessen. Idealerweise enthalten die Dokumentationen Screenshots, Logs, Codebeispiele oder Links zu Commits.

Testbarkeit & Qualitätssicherung

Gibt es eine Testumgebung, die möglichst realitätsnah ist?
Können reproduzierbare Fehler in einer sicheren Umgebung nachgestellt werden?
Sind automatisierte Tests für die Anwendung vorhanden?
Ist klar dokumentiert, wie ein Rollback bei Fehlern durchgeführt werden kann?

Vor einem Deployment von Änderungen sollte eine Risikobewertung sowie eine Rollback-Planung durchgeführt werden. Zudem ist auch bei kleinen Fixes an Regressionstests zudenken.

Kommunikation & Kundenabstimmung

Gibt es einen eindeutigen Ansprechpartner auf Kundenseite für Rückfragen und Freigaben?
Sind die Verantwortlichkeiten und Kommunikationswege klar definiert (z. B. Ticket, E-Mail, Bereitschaftstelefon)?
Wird der Kunde verständlich über Ursachen, Risiken und geplante Maßnahmen informiert?
Wurde ein Change Request-Verfahren mit dem Kunden etabliert?

Eine transparente Kommunikation über Fortschritt, Zeitrahmen und Nebenwirkungen ist wichtig, besonders, wenn die Bearbeitung länger dauert. Bei Bedarf müssen technische Inhalte in „Business-Sprache“ übersetzt werden.

Fehleranalyse & Debugging

Ist der Fehler durch Logs, Screenshots oder konkrete Beschreibungen ausreichend belegt?
Können alle Abhängigkeiten und Schnittstellen nachvollzogen werden (z. B. andere Systeme, externe APIs)?
Gibt es ein strukturiertes Vorgehen zur Analyse?
Wurde geprüft, ob ähnliche Probleme bereits früher aufgetreten sind?

Fehler und deren Lösungen sind immer zu dokumentieren: Ursache, Lösung, betroffene Komponenten und ein Lessons Learned sind hier von Bedeutung. Gegebenenfalls ist ein standardisiertes Schema für Support-Tickets hilfreich.

Sicherheit & Datenschutz

Wird mit Live-Daten gearbeitet und wenn ja, sind Datenschutzaspekte berücksichtigt?
Gibt es Zugriffsregelungen für produktive Systeme oder sensible Kundendaten?
Wird die Änderung im Kontext von IT-Sicherheitsstandards geprüft?
Ist klar dokumentiert, wie Logfiles und sensible Daten zu behandeln sind?

Änderungen sollten – wenn möglich – zuerst in einer Testumgebung geprüft werden. Zugriffe auf produktive Systeme von Kunden sind nur mit klarer Genehmigung und Protokollierung durchzuführen.

Nachhaltigkeit & Verbesserungspotenzial

Wurde der Fehler nur gefixt oder auch ursächlich beseitigt?
Besteht Potenzial für eine Code- oder Architektur-Optimierung?
Kann aus dem Fall eine generische Lösung entstehen (z. B. für ähnliche Kunden)?
Wurden Empfehlungen an Entwicklung oder Kunden abgeleitet?

Der Support sollte nicht nur reaktiv, sondern auch proaktiv denken. So können zukünftige Probleme schneller gelöst und Entwicklungen zügiger abgewickelt werden. Technische Schulden sollten also sichtbar gemacht und gut dokumentiert werden.

Tools & Infrastruktur

Werden alle Änderungen mit einem Ticket-System erfasst?
Gibt es einen Zugriff auf verschiedene Versionen und Build-Prozesse?
Werden Debugging-, Logging- und Monitoring-Tools effektiv genutzt?
Ist das Deployment automatisiert oder dokumentiert?

Ein zentrales System für die Ticketverfolgung, Statusupdates und Code-Links schafft eine gute Übersicht und Verlässlichkeit. Auch können so mehrere Entwickler und Kundenkontakte gleichzeitig den Fortschritt der Entwicklungen überwachen und ggf. einschreiten.

Übergabe & Nachsorge

Wurde der Fall sauber abgeschlossen und dokumentiert?
Gibt es einen Plan für mögliche Folgeprobleme?
Wurde das Wissen ins Team zurückgespielt (z. B. in ein internes Review, Wiki-Einträge)?
Hat der Kunde Feedback gegeben – und wurde es dokumentiert?

Nach jedem größeren gelösten Fall sollte sich das Support-Team für ein kurzes internes Review zusammensetzen – was lief gut, was war schwierig, was lernen wir daraus? So können zukünftige Kundenanfragen besser und ggf. auch schneller gelöst werden.

Erfahren Sie mehr über unseren FlexSupport!

Checkliste & Best Practices: Third-Level-Support bei Individualentwicklungen