Zwischen Weihnachten und Neujahr war wenig los im Support. Trotz der verschiedenen Kunden hat das Telefon zwischen dem 22.12. und dem 2.1. nur 31-mal geklingelt.
Bei uns waren Lena und Fernando im Dienst. Somit war die Erreichbarkeit sichergestellt und die Anrufenden sind ihre Probleme losgeworden. Also konnten unsere Kunden getrost ihre freien Tage genießen. Viele haben sogar Betriebsruhe zwischen den Jahren.
Das meiste sind ganz normale IT-Probleme gewesen, an die sich heute niemand mehr erinnert. Zwei Situationen sind den Beiden im Kopf hängen geblieben. Da waren einmal ein sehr verzweifelter Buchhalter und ein echter Cyber-Security-Vorfall. Von diesen beiden Erlebnissen möchte ich dir heute berichten.
Fall 1: Ein Cyber-Angriff im Tarnumhang
Einer dieser beiden Anrufe war ein klassischer Supportfall – zumindest auf den ersten Blick. Kein Security-Alarm, keine Warnmeldung, sondern eine Nutzerin, die schlicht sagte: „Heute ist hier alles unglaublich langsam. Ich kann kaum arbeiten.“
Es war der 27. Dezember, kurz nach halb neun. Fernando nahm den Anruf entgegen.
Die Nutzerin war allein im Büro, wollte die ruhige Zeit nutzen und hatte den Eindruck, dass ihr Rechner plötzlich kaum noch benutzbar war. Das Notebook war laut, Programme reagierten verzögert. Fernando hörte sich ruhig an, womit die Nutzerin arbeitet und was sie bereits versucht hatte. Parallel schaute er sich über das RMM die Systemauslastung und die laufenden Prozesse an. Dabei fielen ihm mehrere Prozesse auf, die viel CPU-Leistung verbrauchten. Unter anderem lief mehrfach die defrag.exe.
Auf Nachfrage verneinte die Nutzerin, eine Laufwerksoptimierung angestoßen zu haben. Um seinen Verdacht weiter einzugrenzen, startete Fernando eine Suche nach Dateien mit mehreren Punkten im Dateinamen – ein typisches Muster bei Verschlüsselungsvorgängen.
Während diese Suche lief, stellte er der Nutzerin gezielte Fragen zu ihrem bisherigen Arbeitstag. Als die ersten Treffer erschienen, war klar: Das war kein normales Performanceproblem.
Die entscheidende Minute: Erkennen und Handeln
An dieser Stelle hat Fernando eine Entscheidung getroffen, die für den weiteren Verlauf entscheidend war: Er unterbrach das Gespräch und forderte die Nutzerin auf, das Notebook sofort zuzuklappen und vom Netzwerk zu trennen.
Die Nutzerin war zunächst irritiert und zögerte. Fernando erklärte ruhig, was gerade passiert: Dass sich jemand unbefugt Zugriff auf ihren Rechner verschafft hatte und damit begann, Dateien zu verschlüsseln. Und dass jede weitere Minute Online-Zeit den Schaden vergrößern würde.
Das reichte. Die Nutzerin klappte das Notebook zu. Fernando versprach, sich gleich wieder zu melden, da er nun weitere Schritte einleiten müsse.
Er kontaktierte daraufhin die bei uns hinterlegte Rufbereitschaft unseres MSP-Kunden. Beim ersten, zweiten und auch dritten Versuch erreichte er niemanden. Damit die Nutzerin in dieser Situation nicht alleinblieb, bat er Lena, sie zwischenzeitlich anzurufen und zu beruhigen. Beim fünften Versuch meldete sich schließlich ein Techniker des MSPs.
Fernando schilderte sachlich, was vorgefallen war, welche Maßnahmen bereits ergriffen worden waren und warum er von einem laufenden Angriff ausging. Ab diesem Moment übernahm das Systemhaus die weitere Bearbeitung.
In der Nachbesprechung stellte sich heraus, dass der Schaden begrenzt geblieben war. Einige Dateien auf dem Notebook waren verschlüsselt worden, auf den Netzlaufwerken war der Angreifer zu einem sehr frühen Zeitpunkt gestoppt worden. Ursache war eine Phishing-Mail, auf die die Nutzerin am Morgen hereingefallen war.
Warum der Prozess wichtiger ist als die Technik
Der entscheidende Punkt an diesem Vorfall ist nicht, dass ein Angriff stattgefunden hat. Sondern dass er früh erkannt, richtig eingeordnet und sauber übergeben wurde.
Der eigentliche Wert lag nicht in der technischen Analyse, sondern in der Entscheidung zur richtigen Zeit: wann zu stoppen, wann zu eskalieren und wann Verantwortung weiterzugeben.
Jetzt stell dir mal vor, was passiert wäre, wenn die Nutzerin direkt bei der Rufbereitschaft hätte anrufen müssen. Hätte sie die Geduld gehabt, das fünfmal zu versuchen?
Fall 2: Der geschäftskritische Notfall am Silvestertag
Der zweite Anruf war weniger spektakulär, aber nicht weniger relevant. Er kam am 31. Dezember. Lena nahm das Gespräch entgegen. Am anderen Ende war ein Buchhalter eines Produktionsbetriebs.
Der erste Satz war bezeichnend: „Toll, dass ich jemanden erreiche. Ich weiß ja, dass zwischen den Jahren eigentlich niemand arbeitet.“
Der Kunde erklärte, dass er die Buchhaltung für den Dezember abschließen müsse. Der Betrieb hatte zwar ebenfalls Betriebsruhe, aber dieser Abschluss war notwendig. DATEV ließ sich allerdings nicht starten. Es erschien eine Fehlermeldung im Zusammenhang mit der SmartCard. Kein Notfall im klassischen Sinn. Aber für den Kunden dennoch geschäftskritisch.
Lena nahm das Anliegen auf und erstellte ein Ticket. Sie wusste, dass beim zuständigen Systemhaus trotz Betriebsruhe einige Techniker im Einsatz waren. Die ruhige Zeit wurde dort gezielt für Wartungsarbeiten genutzt. Statt das Thema zu vertagen oder an eine Rufbereitschaft weiterzugeben, kontaktierte Lena über Teams direkt einen Techniker, der sich mit DATEV auskennt. Kurze Rücksprache, kurze Klärung – und der Kunde konnte weiterarbeiten.
Supportqualität jenseits von Ticketzahlen
Was an diesem Vorfall wichtig ist, ist nicht die technische Lösung. Sondern die Tatsache, dass der Kunde in einer Situation, in der er nicht mit Unterstützung gerechnet hatte, schnell und ohne Umwege Hilfe bekommen hat. Für ihn ging es nicht um eine Software. Es ging um Abschlüsse, Termine und Verantwortung.
Auch hier zeigt sich: Guter Support bedeutet nicht, möglichst viele Tickets zu bearbeiten. Sondern zur richtigen Zeit erreichbar zu sein – und das Anliegen ohne Reibungsverluste an die richtige Stelle zu bringen.
Wenn du diese beiden Anrufe nebeneinanderlegst, dann hatten sie auf den ersten Blick wenig gemeinsam. Hier ein Cybervorfall, dort ein DATEV-Problem. Ausnahme einerseits, Alltag andererseits.
Und trotzdem zeigen beide Situationen sehr deutlich, worum es im IT-Support wirklich geht. In beiden Fällen war nicht entscheidend, wie viele Menschen erreichbar waren oder wie viele Tickets an diesem Tag eingegangen sind. Entscheidend war, dass jemand erreichbar war, der das Anliegen einordnen konnte – und der wusste, was als Nächstes zu tun ist.
Im ersten Fall ging es darum, früh zu erkennen, dass hier mehr als ein Performanceproblem vorliegt, und die Verantwortung zur richtigen Zeit an das Systemhaus zu übergeben. Im zweiten Fall ging es darum, ein geschäftskritisches Thema korrekt einzuordnen und ohne Umwege dorthin zu bringen, wo es gelöst werden konnte.
Beide Situationen zeigen: Guter Support entsteht nicht durch Zufall. Er entsteht durch klare Abläufe, saubere Übergaben und Menschen, die wissen, welche Rolle sie gerade haben.
Fazit: Funktioniert dein Support, wenn es darauf ankommt?
Vielleicht nimmst du aus dieser Folge einmal die Frage mit, wie das bei euch im Alltag geregelt ist:
- Wer ist bei euch der erste Ansprechpartner, wenn es ruhig ist – und plötzlich doch etwas passiert?
- Wie niedrig ist die Hürde, diesen Ansprechpartner tatsächlich zu erreichen?
- Und wie klar ist geregelt, wann ein Thema weitergegeben wird und an wen?
Das sind keine theoretischen Fragen. Sie entscheiden darüber, ob Support in dem Moment funktioniert, in dem er gebraucht wird.
Dein nächster Schritt
Du erkennst in dieser Episode deine aktuelle Situation wieder und merkst, dass Support und Serviceerbringung im Alltag zunehmend Druck erzeugen, dann lohnt es sich, konkrete Entlastungsmöglichkeiten zu prüfen. Gern können wir uns dazu austauschen: Buche dir unkompliziert und schnell einen Termin.