Am Limit und doch alles im Griff

Die Komplexität des technischen Supports bewältigen

Mitarbeiter im technischen Support finden sich routinemäßig in den unbekannten Gewässern zunehmend komplexer und heterogener Anwendungen und Hardwareplattformen wieder. Das den Kunden gegenüber vermarktete Versprechen ist die Bequemlichkeit von „was auch immer, wann auch immer und wo auch immer“; doch es wird kaum darüber nachgedacht, wie wir dieses Versprechen unterstützen.

Der technische Support ertrinkt in verstopftem Netzwerkverkehr, einem Meer aus konvergierenden Technologien, Daten und Medien, die um Systemressourcen konkurrieren, und einzigartigen Konfigurationslandschaften für jeden Kunden. Am Ende der Wertschöpfungskette positioniert, hat der technische Support kaum Mitspracherecht bei dem, was verkauft wird und wie es konzipiert und implementiert wird.

Incident-Management und Fehlerbehebungsaktivitäten können zu einem Schuldzuweisungsspiel nach dem Motto „ihr Fehler, nicht unserer“, zu persönlichen Vermutungen oder zu Problem-Eskalationen durch erzürnte Kunden werden. Die Problemlösung wird zu einer Wahrscheinlichkeit – nicht zu einer Gewissheit.

Durch den Einsatz zunehmend vernetzter und dennoch unterschiedlicher Technologien erwarten Kunden, dass ihr Geschäft trotz der Komplexität ihrer IT-Infrastruktur homogen unterstützt wird. Organisationen, welche die Realität der komplexen, vernetzten IT-Umgebungen ihrer Kunden ignorieren, gehen ein Risiko ein – ebenso wie jene, die glauben, sie könnten diese Komplexität auslagern.

Ein gemeinsames Thema, das sich durch unsere gesamte Kundenlandschaft zieht, ist, dass die technische Supportfunktion am Limit lebt. Können sie die Kontrolle behalten? Wir glauben ja.

Dieser Artikel erörtert die Schwächen von Supportfunktionen aus der Perspektive geschäftskritischer Supportfunktionen und stellt einen skalierbaren Lösungsprozess vor, der auf jedes Produkt, jede Plattform und jede Technologie angewendet werden kann.

Support verbessern: Ansätze, die zu kurz greifen

Die gute Nachricht ist, dass Manager und Entscheidungsträger innerhalb der Kundensupportfunktion mittlerweile erkennen, dass die Supportwelt immer komplexer wird. Die schlechte Nachricht ist, dass der Erfolg von Verbesserungsinitiativen nur sporadisch eintritt. Selbst in den besten Organisationen stagniert der Erfolg von Initiativen schnell, und die Investitionsrendite bleibt hinter den ursprünglichen Versprechen zurück.

Hier ist das, was bisher nicht gut funktioniert hat:

1. Erhöhung der technischen Schulungen
2. Verlass auf skriptbasierten Support
3. Hinzufügen von weiteren Wissens-Tools
4. Verwendung von Leistungsdurchschnitten als Hauptmaßstab für den Erfolg

Ironischerweise folgen diese scheinbar „richtigen Schritte“ einer logischen Abfolge, die Organisationen in eine Endlosschleife aus ineffektiven Reformen und neuen Initiativen treibt, die Ressourcen verbrauchen und Kunden frustrieren.

1. Technische Schulungen sind für die effektive Steuerung des Supportprozesses von entscheidender Bedeutung. In der Regel machen Schulungen 5–6 % des Budgets eines Support-Centers aus, und die Mitarbeiter verbringen durchschnittlich etwa drei Arbeitswochen pro Jahr mit der Kompetenzentwicklung. Die meisten Schulungen finden während der Einarbeitung neuer Mitarbeiter und bei der Einführung neuer Produkte statt. Trotz bester Absichten greifen Schulungen aufgrund der Kapazitätsgrenzen des menschlichen Lernens zu kurz. Ein Support-Mitarbeiter kann für zwei, drei oder vielleicht vier Produkte zertifiziert sein, aber diese Zertifizierung bringt noch keine Expertise mit sich. Kein technisches Schulungshandbuch kann die Konfigurationskomplexität und Dynamik der einzigartigen IT-Infrastruktur eines Kunden simulieren, und der Analyst ist gezwungen zu improvisieren. Dies führt zu inkonsistentem Support, dem Hauptgrund für sinkende Kundenzufriedenheitswerte.

Mitarbeiter im technischen Support schwimmen fachmännisch in bekannten Gewässern, aber wenn sie Situationen ausgesetzt sind, in denen es ihnen an Wissen und Erfahrung mangelt, gehen sie unter. Fragen Sie einen beliebigen Support-Analysten – das größte Berufsrisiko, dem Analysten heute gegenüberstehen, ist die fast sichere Gewissheit, dass das nächste Ticket außerhalb ihrer Expertise liegen wird.

Kompetenzbasiertes Routing (Skills-based Routing) ist eher ein Pflaster als eine dauerhafte Lösung für Zuweisungs- und Planungsherausforderungen. Die Routing-Regel weist Probleme zu einem Produkt normalerweise einem definierten Experten zu. ACDs (Automatic Call Distributors) werden installiert, um diesen Prozess zu erleichtern. Dies führt oft zu Situationen von Überlastung oder Leerlauf, in denen „gute“ Ressourcen ausbrennen, während „andere“ Ressourcen unterausgelastet sind. Die Nutzung der Historie zur Planung der richtigen Produktspezialisten in Erwartung des nächsten geschäftskritischen Support-Tickets mangelt an Effizienz und Effektivität. Trotz der Bemühungen, Technologien und Systeme bereitzustellen, sinkt der Rückstau an Fällen nie. Und wenn komplexe Probleme auftreten, versagt das Routing.

2. Produktbasiertes Scripting wird vom Management eingesetzt, um den Leistungsdurchschnitt zu verbessern, und ist das Grundprinzip des Outsourcing-Modells. Alles, was man tun muss, um den Glauben des Managements an Skripte zu erschüttern, ist, sich einen skriptbasierten Versuch zur Lösung eines geschäftskritischen Tickets anzuhören.

Mitarbeiter an vorderster Front haben kein Problem damit, dem Skript zu folgen, oft bis zum Exzess. Scripting funktioniert für bekannte oder routinemäßige Situationen. Sobald die Situation jedoch leicht vom Skript abweicht oder der Kunde ein komplexes Problem anspricht, bricht das Skript zusammen. Der Kunde, der das Scripting und die mangelnde Logik bemerkt, geht davon aus, dass das Problem außerhalb der Kapazitäten des Analysten liegt, und stellt die Glaubwürdigkeit des Helpdesks infrage. Das Vertrauen ist dahin.

Angesichts der wachsenden Komplexität des Supports ist ein Skript bereits am Tag seiner Erstellung veraltet, und sein Nutzen nimmt von da an stetig ab.

Eine Analyse der Garantiekosten verdeutlicht ebenfalls das Scheitern von Scripting. Die Verwendung von Skripten zeigt eine nahezu perfekte Korrelation zum Volumen der versandten Ersatzteile und der geplanten Vor-Ort-Einsätze. Anrufe werden auf Helpdesk-Ebene abgeschlossen, was für das Unternehmen mit hohen Kosten verbunden ist, und in vielen Fällen ist die Diagnose falsch.

3. Wissensmanagement-Tools (KM-Tools) bieten eine Lösung, wenn Schulungen und Wissensaustausch nicht funktionieren und die Servicekosten eskalieren. Das Management gerät unter Druck, das menschliche Element zu minimieren und KM-Tools zu installieren. Servicetechnologie macht 6–7 % der Budgets von Support-Centern aus, und fast 70 % der Organisationen führen jedes Jahr KM-Projekte durch. Wissensmanagement ermöglicht selten Quantensprünge bei der Kundenzufriedenheit oder eine Reduzierung der mittleren Lösungszeit (MTTR). Im Gegenteil: Mehr Technologie legt Support-Fehler offen und beschleunigt sie.

Betrachten Sie ein typisches Szenario: Analyst A löst ein Problem und trägt die Lösung in die KM-Lösungsdatenbank ein. Analyst B stößt auf ein ähnliches Problem (vielleicht passend, vielleicht auch nicht), nutzt aber weder die Lösung von A noch das Kernproblem, weil B den eigenen Weg der Fehlerbehebung für den richtigen hält. Also fügt B eine eigene Version der Lösung hinzu. Oder Analyst B glaubt, dass beide Probleme identisch sind, findet die Lösung von A und sendet denselben Patch, obwohl es nicht der richtige ist, was folglich zu weiteren Problemen für den Kunden führt.

KM-Tools sind, ungeachtet ihrer Ausgereiftheit, wahrscheinlich die am meisten missbrauchten Technologien in Support-Organisationen.

4. Durchschnittsbasierte Leistungskennzahlen verschleiern das Scheitern von Skripten bei der Verbesserung der Zufriedenheitswerte und von KM-Tools beim Schließen dieser Lücken. Eine Organisation kann eine reasonably gute MTTR (Mean Time-to-Resolve) vorweisen, aber unter dieser Statistik verbergen sich die extremen Tickets. Dies sind die Probleme, die sich in die Länge ziehen, Energie und Ressourcen verschlingen und die Kundenzufriedenheit schädigen (Extremwerte, die in den durchschnittlichen Kundenzufriedenheitswerten untergehen).

Durchschnittsbasiertes Reporting schafft einen Kreislauf, der die Einstellung „erst flicken, später Probleme lösen“ belohnt. Sobald das Ticket geöffnet ist, liegt kaum noch Gewicht auf Bewertung und Prozess – die Ziele bestehen darin, das SLA (Service Level Agreement) einzuhalten und die Dringlichkeit der Situation zu verringern, anstatt die Fehlerbehebung bis zum Abschluss durchzuführen. Die Fallprotokolle werden zu endlosen E-Mail-Threads mit Anfragen nach Protokolldateien, die verschwenderische Leerlaufzeiten erzeugen, in denen nichts zur Lösung des Falls getan wird.

Der Incident-Management-Prozess von ITIL hat großes Potenzial, aber die Standardisierung des Incident-Management-Prozesses auf Basis eines unzusammenhängenden Fehlerbehebungsprozesses wird wahrscheinlich keine nachhaltigen Ergebnisse liefern. Die langfristige Lösung für Helpdesk- und technische Supportfunktionen ist ein definierter Prozess, der unabhängig von Technologie, Plattform, Sprache oder Geografie ist.

Bevor wir diesen Prozess etablieren, lade ich Sie ein, die Supportfunktion durch die Augen Ihrer Kunden zu betrachten.

Die Supportfunktion – Warum Kunden eskalieren

Untersuchungen zum Kundenfeedback in verschiedenen Branchen und Regionen zeigen, dass Kunden sieben Hauptprobleme mit dem Support haben.

Diese sind:

1. „Mein geschäftliches Bedürfnis wird nicht berücksichtigt.“ Wenn ein System, eine Software, ein Netzwerk oder ein Dienst ausfällt, steht das Geschäft des Kunden still. Sie unterstützen mehr als nur Ihr Produkt; Sie unterstützen deren Geschäft. Unterstützen Sie Ihren Kunden, nicht Ihr Produkt.
2. „Die Qualität des Supports ist inkonsistent.“ Ihre Kunden verlangen jedes Mal den gleichen hohen Standard. Liefern Sie konsistent.
3. „Ich weiß nicht, was Sie an meinem Problem tun.“ Kunden werden unzufrieden, wenn sie nicht wissen, was vor sich geht, oder glauben, dass Sie nicht wissen, wohin die Reise geht. Führen Sie den Kunden.
4. „Mein Problem wird nicht gelöst.“ Kunden benötigen die korrekte Fehlerbehebung. Gehen Sie bei der Fehlersuche präzise vor.
5. „Sie brauchen zu lange, um es zu beheben.“ Kunden brauchen ihr Geschäft sofort zurück. Seien Sie schnell.
6. „Ich möchte eine dauerhafte Lösung, keinen Workaround.“ Kunden brauchen eine dauerhafte Behebung ihrer Probleme. Beweisen Sie es.
7. „Warum bekomme ich überhaupt Probleme?“ Kunden möchten Probleme lieber vermeiden: Vorbeugen ist besser als Heilen. Seien Sie einen Schritt voraus.

Alle Initiativen innerhalb der Kundenbetreuungsfunktion müssen diese sieben Problembereiche jederzeit in den Mittelpunkt stellen. Diese Kundenanliegen sind die Plattform, auf der der geschäftskritische Supportprozess aufgebaut ist.

Widerstand: Wir haben einen Prozess; warum brauchen wir einen weiteren?

Die Behauptung, bereits einen Fehlerbehebungsprozess zu haben, wird durch die Konsistenz des Supports geprüft. Stellen Sie die Lösungszeiten nach Produkt und Support-Mitarbeiter grafisch dar. Die Normalkurve wird die Variabilität verdeutlichen. Die Variabilität zeigt auf, dass – falls tatsächlich ein Prozess existiert – dieser nicht befolgt wird.

Oft glauben Analysten nicht an den vorhandenen Prozess und nutzen ihren eigenen Weg der Fehlerbehebung. Solche eigenmächtigen Prozesse sind nicht nur unsichtbar, sondern brechen häufig zusammen, sobald etwas Außergewöhnliches passiert.

Viele Organisationen scheinen sich mit Mittelmäßigkeit abgefunden zu haben. Sie brauchen etwas grundlegend anderes, um den Kundensupport als gewinnbringendes Element ihrer Geschäftsstrategie zu etablieren.

Eine branchenweite Umfrage zur Selbsteinschätzung der Leistung von Support-Centern zeigt, dass viele Organisationen sich offenbar mit Mittelmäßigkeit abgefunden haben. Es besteht eindeutig Raum und Bedarf für etwas grundlegend anderes, um den Kundensupport als gewinnbringendes Element ihrer Geschäftsstrategie zu etablieren.

Am Limit und doch alles im Griff: Der Prozess

Überlegenes Wissen und Verständnis von Kundenproblemen und deren Lösung ist durch einen rationalen Prozessansatz möglich. Dies geschieht durch den Erwerb von Fähigkeiten in strukturierten Fragetechniken, die Verbesserung der Fähigkeit, diese Fähigkeiten in Echtzeit einzusetzen, und den Aufbau von Kompetenz durch wiederholte Anwendung.

Diese strukturierte Fragestellung wird integraler Bestandteil der Kundeninteraktion. Professionalität wird durch die Schaffung eines Leistungssystems erreicht, das die Nutzung rationaler Prozesse in jeder Supportfunktion fördert. Unabhängig von Plattform, Technologie und Supportsystem kann der rationale Prozessansatz skaliert werden, um die komplexesten Herausforderungen der Helpdesk- und Kundenbetreuungslandschaft zu bewältigen.

Der Prozess baut auf vorhandenem Wissen und gängigen Praktiken auf, da er die persönliche und organisatorische Effektivität verbessert. Er unterstützt und integriert alle guten organisatorischen Lernprozesse, Systeme und Kundenmanagementpraktiken, die bereits vorhanden sind.

Ein rationaler Prozessansatz zur Fehlerbehebung geschäftskritischer Probleme beginnt mit der Bewertung (Appraisal), einer Einschätzung der Situation des Kunden. Die Bewertung nutzt Logik, um Daten zusammenzustellen und das Problem zu definieren. Darauf folgt die Lösung (Resolution), ein Prozess zur Identifizierung möglicher Ursachen, deren Prüfung gegen die Problemspezifikation sowie die Auswahl und Prüfung der wahrscheinlichsten Ursache.

Getrieben von der Dringlichkeit, die schnellstmögliche Lösung zu finden und das Ticket zu schließen, ist die Bewertung oft das fehlende Puzzleteil in einer typischen Supportumgebung. Doch eine richtig durchgeführte Bewertung kann die Lösung beschleunigen, indem sie diese häufigen Fallstricke verhindert:

• Übermäßige Verallgemeinerung – Informationsüberflutung in umfangreichen Fallprotokollen und Daten-Dumps verschleiert die Details, die für die Effektivität nachfolgender Maßnahmen erforderlich sind. Achten Sie auf Terminologie, die Absichten und Realität verschleiert. Annahme von Ursache-Wirkungs-Beziehungen – Der Drang, Ereignisse in gewünschten Beziehungen aneinanderzuketten, untergräbt die Effizienz und führt auf den falschen Weg. Achten Sie auf die verbreitete Tendenz, voreilig auf die Ursache zu schließen, und auf Aussagen wie „verursacht durch…“, „aufgrund von…“, „…verursacht gerade“.
• Realitätskonfusion – Da Support-Mitarbeiter in einem 24/7-Follow-the-Sun-Modell mit Kunden von überall auf dem Planeten arbeiten, führen unterschiedliche Wahrnehmungen zu Verwirrung. Achten Sie auf mehrere Versionen, die dasselbe Ereignis definieren.
• Emotionen verdrängen die Rationalität – Starke Gefühle bei jedem Schritt der Fehlerbehebung trüben die Art und Weise, wie Daten interpretiert werden. Achten Sie auf irrationale Aussagen, die mündlich oder in Fallprotokoll-E-Mails getätigt werden, sowie auf trotziges Schweigen.
• Überwältigendes Ausmaß des Chaos – Ein Problem wird zu groß, um von einer Person oder sogar einer Gruppe bewältigt zu werden. Achten Sie auf die Anzahl der Beteiligten und die Häufigkeit von Tech-Support-Bridges.

Bewertung ist kein fertiges Produkt: Sie ist der Grundstein für eine effektive Fehlerbehebung. Bewertung ist ein Dialog zwischen Kunden sowie Frontline- und Backline-Support. Es ist eine Zusammenarbeit, die den technischen Support von einer komplexen, oft undurchsichtigen Realität zu umsetzbaren Schritten führt. Wenn sie richtig gemacht wird, überwindet die Bewertung die Verwirrung am Scheideweg zwischen adaptiven Lösungen und effektiver Behebung.

Eine effektive Bewertung hilft dem Support-Personal, Probleme mit gezielten Fragen und Techniken zu durchdringen:

• „Was meinen Sie mit…?“, „Was meinen Sie noch mit…?“ bricht Verallgemeinerungen auf und konkretisiert Maßnahmen.
• „Wie sicher sind wir uns, dass dies darauf zurückzuführen ist?“, „Welche Tests wurden durchgeführt, um dies zu beweisen?“ vermeidet die Annahme von Ursache-Wirkungs-Beziehungen.
• „Welche Beweise haben Sie…?“ unterscheidet das, was tatsächlich passiert, von dem, was passieren sollte.
• „Was bedrückt Sie sonst noch…?“ erkennt das Gefühl der Überlastung an und ermutigt zum Nachdenken.

Getrieben von der schnellstmöglichen Lösung ist es leicht, voreilig auf die Ursache zu schließen. Ein Prozessansatz zur Lösung kann die Fehlerbehebung beschleunigen, wenn Sie diese häufigen Fallstricke vermeiden:

• Symptom-oder-Ursache-Dilemma – Für das eine oder das andere Partei ergreifen. Achten Sie darauf, nicht versehentlich die Geschäftsprioritäten des Kunden zu ignorieren.
• Schlechte oder unzureichende Definition des Problems – Zu viele irrelevante Daten oder sehr wenige Fakten. Achten Sie auf wiederholte und zweideutige Datenanfragen, vage beschriebene Soll- und Ist-Leistungen sowie sich ständig ändernde Fakten.
• Voreingenommenheit setzt Fehlerbehebungslogik außer Kraft – Der Drang, Annahmen, die Vermutungen stützen, zu beweisen, statt sie zu prüfen. Achten Sie auf mögliche Ursachen, die auf schwachen, faktenfreien oder unvernünftigen Annahmen basieren.
• Abschluss vor der Bestätigung – Zulassen, dass die MTTR-Metrik den Abschluss erzwingt. Achten Sie darauf, ein Ticket nicht zu schließen, ohne die Lösung zuvor dem Kunden gegenüber nachgewiesen zu haben.

Wie steuert ein rationaler Prozess Eskalationen? Eskalationen treten normalerweise auf, wenn die Frontline an die Grenzen ihres Wissens und ihrer Erfahrung stößt. Durch einen rationalen Prozessansatz übergibt die Frontline ein Ticket, das genau so strukturiert ist, wie die Backline es strukturiert hätte. Dies reduziert repetitive Interaktionen mit Kunden und vermeidet Leerlaufzeiten.

Kunden: Logik schafft Verständnis

Mitarbeiter identifizieren die Grundursache durch diese logikgesteuerten Fragen und Techniken:

• Formulieren Sie das Problem in einem leicht verständlichen Objekt-/Abweichungsformat.
• Spezifizieren Sie das Problem, indem Sie vergleichbare Fakten zu Identifikation, Ort, Zeit und Ausmaß für das betroffene Objekt sowie für ähnliche, aber nicht betroffene Objekte zusammenstellen.
• Nutzen Sie Wissen und Erfahrung, um die Ursache in einer bekannten Umgebung zu ermitteln. Nutzen Sie fortgeschrittene Techniken für Neuland.
• Prüfen Sie die mögliche Ursache anhand von Fakten, bevor Sie die Umgebung nachstellen.
• Bestätigen Sie die wahre Ursache durch Fakten, Beobachtung, Recherche und Experimente.
• Die Anwendung eines logikgesteuerten Bewertungs- und Lösungsprozesses hat tiefgreifende Auswirkungen auf die Kundeninteraktion.

Wenn Kunden erkennen, dass ihnen zugehört wird und nicht nach Skript verfahren wird und dass der Analyst logische Fragen stellt, baut dies Vertrauen in den Analysten und die Organisation auf.

Jederzeit kann jedes Mitglied des Helpdesks, nicht nur der Produktspezialist, einen Kundenanruf entgegennehmen und derselben Logik folgen, um signifikante Fortschritte in die richtige Richtung zu erzielen.

Prozessanwendung: Wann, wo, wie viel

Der Fehlerbehebungsprozess kann in vollem Umfang oder in einem informellen Schnellreaktionsmodus angewendet werden.

Geschäftskritische Supportsituationen, die Hauptkandidaten für eine umfassende Anwendung sind, können sein:

• Hohe Priorität – Hohe Dringlichkeit
• Wiedereröffnete Tickets
• Hochkomplexe Probleme
• Ungewöhnliche Fälle ohne offensichtliche Lösung
• Teure Fälle, die eine große Investition an Zeit und Ressourcen erfordern

Je nach Branche und Produktreife fallen 5–10 % der Tickets in diese Kategorie. Diese Tickets verbrauchen jedoch 30–50 % der Ressourcen der Organisation. Die umfassende Nutzung des Prozesses kann einen großen Einfluss auf Zufriedenheits-, Lösungs-, Verlängerungs- und Kostenmetriken haben.

Die überwiegende Mehrheit der Helpdesk-Situationen ist normalerweise:

• Hohe Priorität, aber bekannt
• Benötigt eine sofortige Reaktion
• Leicht mit Wissen und Erfahrung zu lösen

In der Regel fallen 15–50 % der Fälle in diese Kategorie. Eine informelle Prozessanwendung kann zu erheblichen Verbesserungen bei den Zufriedenheitswerten, der Konsistenz und dem Aufbau von Glaubwürdigkeit führen.

Ergebnisse

Kepner-Tregoe bietet einen logischen Rahmen für die Fehlerbehebung. Durch Schulungen, Geschäftsprozessintegration und Verbesserung des Leistungssystems hat der KT-Prozess in Support-Umgebungen für Sun Microsystems, Dell, Cisco, EMC und andere hervorragende Ergebnisse geliefert. Repräsentative Kennzahlen umfassen:

• 40 % Reduzierung des Rückstaus
• 58 % Reduzierung der durchschnittlichen Zeit bis zum Abschluss
• 41 % Verbesserung der Erstlösungsrate
• 25 % Reduzierung der Fall-Eskalationen an die Produktentwicklungsgruppe
• 12.000 Tage pro Jahr weniger Wartezeit für Kunden
• 37 % Reduzierung der Incident-/Dispatch-Raten
• 10 Millionen US-Dollar Reduzierung der Kosten für kritische Kundenreferenzen.

Stellen Sie sich vor, welche Verbesserungen dies für die Kundenzufriedenheit bringt.

Bereit – Was muss sich ändern?

Mehrere philosophische und strukturelle Änderungen müssen erfolgen, um eine Best-Practice-Nutzung des Prozesses zu entwickeln.

Philosophisch gesehen brauchen wir einen Paradigmenwechsel: Der Helpdesk sollte aufhören zu behaupten, ein Produkt oder eine Anwendung zu unterstützen. Beim Helpdesk geht es darum, das Geschäft des Kunden zu unterstützen. Es geht darum, Fehler präzise zu beheben, während man den Kunden durch den Prozess führt und anschließend beweist, dass das Problem gelöst ist.

Um einen strukturellen Wandel zu realisieren, konzentrieren Sie sich darauf, die wenigen kritischen Bereiche zu identifizieren und zu definieren, die verbessert werden müssen – nicht alles Erdenkliche. Ein potenzieller Ansatz könnte darin bestehen, sich auf eskalierte Fälle zu konzentrieren, deren Lösung länger dauert, oder auf Fälle, die aufgrund ihrer katastrophalen Dringlichkeit normalerweise schneller gelöst werden könnten, aber einen übermäßigen Aufwand seitens der Organisation erfordern. Legen Sie spezifische Kennzahlen und Kausalfaktoren für diese Bereiche fest und bilden Sie dann Ihren aktuellen Prozess ab. Investieren Sie Zeit und Ressourcen in die Beseitigung von Leerstellen oder Lücken im Prozess, während Sie kontinuierlich Schritte ohne oder mit geringem Mehrwert entfernen. Wenn der Fokus auf den wenigen kritischen Punkten liegt, erzielt die Kundensupportfunktion schnelle Ergebnisse und beginnt, dauerhaften Wert zu realisieren.

Fazit – Es ist eine Reise

Das Endziel ist eine Reise über drei Dimensionen:

Kompetenzentwicklung – Um sicherzustellen, dass die Mitglieder des Kundensupport-Teams über die Fähigkeiten und die Coaching-Unterstützung verfügen, die für den Erfolg erforderlich sind.

Prozessintegration – Um sicherzustellen, dass klare Verbindungen zwischen den erworbenen Fähigkeiten und den Geschäftsprozessen bestehen.

Integration des Leistungssystems – Um sicherzustellen, dass das Arbeitsumfeld (Erwartungen, Kennzahlen, Tools/Ressourcen, Konsequenzen und Feedback) der Nutzung der neuen Fähigkeiten und des Prozesses förderlich ist.

Ein rationaler Prozess, der unabhängig von einem spezifischen Produkt oder einer Technologie ist, ermöglicht es der Kundenbetreuung, Produkte, Plattformen und Technologien übergreifend zu bearbeiten. Er bietet einen soliden Rahmen für die Unterstützung des Kundengeschäfts, indem er die wachsende Komplexität und den ständigen Wandel der technischen Supportumgebung bewältigt.

 

Über Kepner-Tregoe

Kepner-Tregoe ist führend in der Problemlösung. Seit über sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Organisationen weltweit geholfen, Millionen von Problemen durch effektivere Ursachenanalyse und bessere Entscheidungsfähigkeiten zu lösen. Kepner-Tregoe arbeitet mit Organisationen zusammen, um Kosten deutlich zu senken und die operative Leistung zu verbessern – durch Trainings zur Problemlösung, Technologie und Beratungsleistungen.