Wie KI-ready ist Ihr Unternehmen? Der Self-Check für Service und Support
Der Fachkräftemangel im Service wächst, die Ticketmengen steigen, und viel Wissen steckt in den Köpfen erfahrener Mitarbeitender. KI kann hier spürbar entlasten. Ob sie das im eigenen Haus wirklich tut, hängt weniger von der Technik ab als von den Voraussetzungen, die ein Unternehmen mitbringt. Genau die beschreibt KI-Readiness.
KI-Readiness lässt sich an vier Punkten festmachen: am Datenfundament, an der technischen Anbindung, an einem klar benannten Use-Case und an der Bereitschaft der Organisation. Bereit sind Sie, wenn vier Dinge stimmen. Ihr servicerelevantes Wissen ist auffindbar. Die Systeme lassen sich anbinden. Ein erster Anwendungsfall steht fest. Das Team trägt einen ehrlichen Start mit, auch bei noch unvollständigen Daten. Fehlt einer der Punkte, ist das kein Ausschlusskriterium. Es zeigt nur, wo die erste Arbeit liegt.
Wie gut Ihr Unternehmen bei diesen vier Punkten aufgestellt ist, klärt unser KI-Readiness Self-Check mit sechzehn Fragen. Dieser Beitrag zeigt, worauf es dabei ankommt. Den vollständigen Check finden Sie hier:
Warum scheitern KI-Projekte im Support?
KI-Readiness beschreibt, ob ein Unternehmen die datenseitigen, technischen und organisatorischen Voraussetzungen erfüllt, um KI produktiv einzusetzen. Der Begriff bezieht sich auf das Unternehmen, nicht auf die Technologie. Geprüft wird entlang von vier Komponenten: Datenfundament, technische Anbindung, Use-Case-Klarheit sowie Organisation und Veränderung.
Zwei Abgrenzungen helfen beim Verständnis. Ein hoher Digitalisierungsgrad bedeutet noch keine KI-Readiness, denn ein Unternehmen kann jedes Dokument digital ablegen und trotzdem keine verbindliche Leitquelle haben. Readiness bedeutet zugleich nicht Perfektion, denn wer wartet, bis alle Daten sauber sind, startet nie.
Warum scheitern KI-Projekte im Support?
Der Markt liefert dazu klare Zahlen. MIT NANDA hat in The GenAI Divide, State of AI in Business 2025 untersucht, was aus den geschätzten 30 bis 40 Milliarden US-Dollar geworden ist, die Unternehmen weltweit in generative KI investiert haben. Das Ergebnis: 95 Prozent der GenAI-Pilotprojekte liefern keinen messbaren P&L-Effekt. Nur 5 Prozent der evaluierten Enterprise-Systeme erreichen den Produktivbetrieb.
S&P Global Market Intelligence kommt in Voice of the Enterprise 2025 aus anderer Perspektive zu einem ähnlichen Befund. 42 Prozent der Unternehmen verwerfen die Mehrheit ihrer KI-Initiativen, bevor sie in Produktion gehen. Im Vorjahr waren es 17 Prozent. Im Schnitt landen 46 Prozent aller Proof-of-Concepts nie im produktiven Einsatz.
Auch die Reifegradseite zeigt eine Lücke. McKinsey berichtet im State of AI trust in 2026, dass nur rund 30 Prozent der Organisationen in den Dimensionen Strategie, Governance und Agentic-AI-Kontrollen einen Reifegrad von drei oder höher erreichen. Als häufigstes Hindernis bei der Umsetzung nennen knapp 60 Prozent der Befragten Wissens- und Trainingslücken. Die Studie beruht auf der 2026 AI Trust Maturity Survey mit rund 500 Organisationen.
Hinter diesen Zahlen steckt ein wiederkehrendes Muster. Die Projekte scheitern selten am Budget und selten an der Modellqualität. Sie scheitern an der Lücke zwischen der Demo und dem täglichen Betrieb.
Genau hier setzt ein Readiness-Check an. Er dreht die Perspektive um, weg von der Technologie, zurück auf das eigene Haus.
Die vier Komponenten der KI-Readiness im Überblick
KI-Readiness verteilt sich auf vier Komponenten. Jede steht für einen anderen Engpass, an dem KI-Vorhaben im Support typischerweise hängen bleiben. Die Übersicht zeigt, was jede Komponente prüft und welches Risiko dahintersteckt.
| Komponente | Was sie prüft | Typisches Risiko |
|---|---|---|
| 1. Datenfundament und Wissensbasis | Was sie prüftWo servicerelevantes Wissen liegt und in welcher Form | Typisches RisikoWissen steckt in Köpfen und verstreuten Ablagen |
| 2. Technische Anbindung und Systeme | Was sie prüftSchnittstellen, Rechte, DSGVO-Rahmen, Betreuungskapazität | Typisches RisikoHalb geklärte Rechtelage, unklare Zuständigkeit |
| 3. Use-Case-Klarheit und Zielbild | Was sie prüftKonkreter Auslöser, erster Use-Case, Erfolgsmessung | Typisches RisikoKI im Support als Sammelbegriff ohne Ausgangswerte |
| 4. Organisation und Veränderung | Was sie prüftErwartungshaltung im Team, Rückhalt im Management | Typisches RisikoPerfektionsvorbehalt verhindert den Start |
Komponente 1: Datenfundament und Wissensbasis
Die erste Komponente prüft, wo Ihr servicerelevantes Wissen liegt und in welcher Form. Wissen Sie, in welchen Systemen es liegt, und welcher Teil davon nur in den Köpfen einzelner steckt? Gibt es eine verbindliche Leitquelle, also eine single source of truth, oder verteilt sich dasselbe Wissen über mehrere Ablagen? Liegen Ihre Dokumente überwiegend digital und maschinenlesbar vor, und lassen sie sich einem Produkt eindeutig zuordnen? Ist geregelt, wer Inhalte pflegt und in welchem Takt sie aktualisiert werden?
Ist das Datenfundament schwach, liegt die Arbeit noch vor dem KI-Projekt. Ein Modell kann nur ausgeben, was es findet und eindeutig zuordnen kann. Fehlt diese Ordnung, beschleunigt die Automatisierung vor allem die falschen Antworten. Eine Schwäche im Datenfundament wiegt deshalb schwerer als in jeder anderen Komponente. Sie zieht alle übrigen Antworten mit nach unten.
Komponente 2: Technische Anbindung und Systeme
Hier geht es um die Frage, ob ein KI-System technisch an Ihre Landschaft andocken kann. Lässt sich Ihr Ticket- und Servicesystem grundsätzlich über eine Schnittstelle anbinden? Sind Zugriffe, Rechte und der DSGVO-Rahmen so weit geklärt, dass ein KI-Zugriff auf Ihre Daten grundsätzlich möglich wäre? Gibt es intern oder über einen Partner die Kapazität, eine solche Anbindung umzusetzen und zu betreuen? Können Sie neue Datenquellen anbinden, ohne dass daraus jedes Mal ein monatelanges IT-Projekt wird?
Das größere Risiko steckt hier nicht in einer fehlenden Anbindung, sondern in einer halben. Wo eine Schnittstelle schlicht fehlt, kennen Sie das Problem und können es einplanen. Eine halb geklärte Rechtelage oder eine vage Betreuungszusage bleibt dagegen unsichtbar. Sie zeigt sich erst, wenn das Projekt läuft, und dann wird die Nacharbeit teuer. Prüfen Sie deshalb genau, ob solche halben Klärungen wirklich tragen oder nur höflich klingen.
Komponente 3: Use-Case-Klarheit und Zielbild
Diese Komponente entscheidet, ob Sie messen können, was Sie tun. Kennen Sie Ihren konkreten Auslöser, also Wachstum, Recruiting, Kostendruck oder Ticketvolumen? Könnten Sie einen ersten Use-Case benennen, der häufig und gleichförmig auftritt und Volumen hat, statt KI im Support als Sammelbegriff zu verwenden? Ist definiert, woran Sie Erfolg messen würden? Liegen die dafür nötigen Ausgangswerte vor? Ist Ihnen bewusst, dass ein solches Vorhaben iterativ verläuft und dauerhaften Betrieb sowie Pflege braucht?
An dieser Komponente entscheidet sich, ob Sie Ihren Fortschritt überhaupt belegen können. Ohne einen klar benannten Use-Case bleibt jede Bewertung Ansichtssache. Ohne Ausgangswerte lässt sich später nur behaupten, dass etwas besser geworden ist. Ein Nein heißt hier nicht, dass ein Start unmöglich wäre. Es heißt, dass Sie hinterher nicht wüssten, ob er gelungen ist.
Komponente 4: Organisation und Veränderung
Die vierte Komponente scheitert am seltensten an der Technik und am häufigsten am Anspruch. Ist im Team die Erwartung verankert, dass KI Routine abnimmt und keine Personen ersetzt? Wären erfahrene Mitarbeitende bereit, ihr Wissen einzubringen und eine KI anzulernen, statt jeden Fall selbst zu lösen? Sind Sie bereit, mit mittelguten Daten zu starten? Gibt es Rückhalt im Management für einen mehrmonatigen, iterativen Weg?
An der Technik scheitert diese Komponente selten, am eigenen Anspruch dagegen häufig. Der Wunsch, erst bei perfekter Ausgangslage loszulegen, klingt seriös, sorgt aber meistens dafür, dass gar nichts anfängt. Fehlt es hier, geht es weniger um die technische Eignung Ihres Hauses als um seine Bereitschaft, sich zu verändern.
KI-Readiness bewerten: was tun bei schwachen Komponenten?
Für jede der vier Komponenten gibt es einen konkreten ersten Schritt. Er kostet wenig und bringt Sie spürbar voran, unabhängig davon, wie weit Ihr Service heute schon ist.
Beim Datenfundament besteht der erste Schritt darin, eine Leitquelle festzulegen. BORA hat diesen Schritt früh gemacht und die Ablage über SharePoint durch das zentrale PIM als single source of truth ersetzt. Aus dem Projekt bei der ANWR GROUP kommt eine zweite Erkenntnis: Wenn die Datenbasis nicht stimmt, wird das über den Chatbot sichtbar. Das ist kein Nachteil. Es ist eine Chance zur Korrektur.
Entscheidend ist dabei der Umfang. Die Leitquelle muss nicht von Anfang an vollständig aufgeräumt sein. Es genügt, die Daten für den einen wertvollen Use-Case erreichbar, strukturiert und nutzbar zu machen. Ein Sprachmodell erkennt selbst, was Rauschen ist und was nicht. Das Warten auf einen perfekten Datenstand ist einer der häufigsten Gründe, warum Unternehmen gar nicht erst beginnen.
Bei der technischen Anbindung hilft ein bewusst enger Start. Katja Fröhlich, Tech Leader IT und Digital Products bei hepster, rät dazu, für den Anfang möglichst wenig an Drittsysteme anzubinden. Wählen Sie stattdessen einen begrenzten Fall, der vor allem statische Informationen aus Dokumenten und Wissensdatenbanken abbildet. Wichtig ist außerdem, dass jede Antwort ihre Quelle ausweist. So bauen interne Anwender Vertrauen in die Antwortqualität auf.
Bei der Use-Case-Klarheit besteht der erste Schritt darin, den Erfolg messbar zu machen. Legen Sie ganz am Anfang fest, woran Sie den Piloten bewerten wollen. Wählen Sie dazu einen Fall mit Ausbaustufen. Katja Fröhlich beschreibt den Vorteil so: „Ein Case mit 4 Ausbaustufen ist da leichter als 4 kleinere und unterschiedliche Themen.“
Bei der Organisation ist der erste Schritt, schnell sichtbare Ergebnisse zu schaffen. Lars Wolfram, Co-Gründer der talentsconnect Group, empfiehlt: „Schneidet den Elefanten in Scheiben. Und produziert schnell erste Erfolge. Damit baut man Vertrauen auf und nimmt das Team mit auf die Change-Reise.“ Dazu passt ein Befund aus dem ANWR-Projekt: KI ist kein reines IT-Thema und kein reines Fachthema. Der Mehrwert entsteht in der Zusammenarbeit beider Seiten.
Wo im Kundenservice mit KI anfangen?
Ein Beispiel dafür liefert BORA, ein Hersteller von Premium-Kücheneinbaugeräten aus dem Inntal. Der Weg dort zeigt eine Reihenfolge, die sich übertragen lässt. Gestartet wurde bewusst intern, im Innendienst, um Qualität kontrolliert zu prüfen. Danach folgte die Website als öffentlicher Kanal. Aktuell arbeitet BORA an der Stufe für Techniker, mit Schritt-für-Schritt-Anleitungen. Den vollständigen Fall lesen Sie in der BORA Case Study.
Der Weg dorthin war iterativ. Florian Plenk beschreibt ihn so: „Es geht die ganze Zeit: testen, testen, testen.“ Auf eine erste Version mit wenig Daten folgt der Test, dann ein besserer Prompt und die Schnittstellen, wieder ein Test, schließlich Feinschliff und erste Automatisierungen. Bis das System im Alltag trägt, braucht es mindestens drei bis vier größere Schleifen.
Ein Learning betrifft den Kanal. Der Website-Chatbot funktionierte technisch, doch die Kunden nahmen ihn nicht an, weil sie E-Mail und Telefon bevorzugen. Also wanderte Gregario ins Ticketsystem. Die KI entwirft, ein Mensch prüft, die Antwort geht raus. Human-in-the-loop ist ein guter Startmodus, gerade wenn das Datenfundament noch nicht vollständig belastbar ist.
Der enge Start ist kein Nachteil, sondern das übliche Muster. Raj Khamkar vergleicht den Einstieg mit einem kalten Bergsee, in den man zunächst nur die Füße hält. Kunden beginnen mit einem kleinen, aber wertvollen Use-Case. Sobald die ersten Ergebnisse überzeugen, binden sie weitere Daten und Nutzer an. Das Wachstum verläuft dann eher exponentiell als linear, weil die einmal aufgebaute Wissensstruktur jede weitere Erweiterung beschleunigt.
Drei Muster, in denen sich die meisten wiederfinden
Diese Reihenfolge ist die eine Seite. Die andere ist die Haltung, mit der ein Unternehmen startet. Ob es mit KI im Support vorankommt, hängt oft weniger vom Raster ab als von der Art, wie es an das Thema herangeht. Drei Anläufe begegnen uns dabei immer wieder. Erkennen Sie sich in einem, ist das kein Urteil, sondern nur der ehrlichere Ausgangspunkt.
Der erste Anlauf ist IT-getrieben. Die IT sucht eine Plattform aus, verbindet die Systeme und übergibt dem Service ein fertiges Werkzeug. Technisch funktioniert das, nur hat vorher niemand geklärt, welche wiederkehrende Aufgabe es eigentlich abnehmen soll. Das Symptom zeigt sich später: Das System ist live, wird kaum genutzt, und niemand im Service kann in einem Satz erklären, wofür es gedacht ist.
Der zweite Anlauf kommt von der Führungsebene. Eine Zusage oder ein Kostenziel setzt eine Frist, noch bevor Datenfundament und Use-Case stehen. Das Team arbeitet dann gegen die Uhr statt gegen ein konkretes Problem. Ein solider erster Zwischenstand gilt nicht mehr als Anfang, sondern als Misserfolg. Das Symptom: ein ehrgeiziger Termin, ein Pilot, der ins Stocken gerät, und die Frage, warum die KI noch nicht liefert.
Der dritte Anlauf ist das Warten auf den richtigen Moment, und er begegnet uns in Projekten am häufigsten. Man wartet, bis die Daten sauber sind, die Rechtslage vollständig geklärt ist und kaum noch ein Risiko bleibt. Dieser Anspruch fühlt sich verantwortungsvoll an, blockiert aber genau die Iteration, aus der Qualität erst entsteht. Das Symptom: immer neue Prüfrunden, viele Gründe fürs Abwarten und kein erster Use-Case, der wirklich produktiv geht.
KI-Readiness und Reifegrad des Systems: zwei Seiten einer Entscheidung
Ein Readiness-Check betrachtet Ihr Unternehmen. Für das Ergebnis zählt aber noch eine zweite Frage, und die ist mindestens ebenso entscheidend. Kann das gewählte System mit dem Wissen umgehen, das Sie tatsächlich haben?
Der Unterschied ist messbar. Die Tolly Group hat im März 2026 einen unabhängigen Benchmark durchgeführt, dokumentiert in Testreport #226106. Grundlage war ein reales technisches Servicehandbuch mit über 1.000 Seiten und 50 Fragen aus dem operativen Betrieb. octonomy erreichte 96 Prozent Antwortgenauigkeit. Microsoft Copilot in der Direct-Upload-Variante kam auf 58 Prozent, ein führender KI-Chatbot-Anbieter auf 34 Prozent, Microsoft Copilot über SharePoint auf 26 Prozent.
Entscheidend ist die Erklärung dahinter. octonomy und Microsoft Copilot nutzten in einer Testkonfiguration des Tolly-Benchmarks dasselbe Basismodell, Anthropic Claude Sonnet. Der Unterschied betrug trotzdem 38 Prozentpunkte. Das Basismodell ist damit nicht der limitierende Faktor. Oliver Trabert, CTO von octonomy, nennt den Grund: „Circa 40 Prozent des Unternehmenswissens liegt nicht als Text vor. Wenn ein System nur den Textanteil verarbeitet und alles andere ignoriert, kann es per Definition keine guten Antwortquoten erreichen.“
Für Ihre Evaluation heißt das: Testen Sie mit Ihren eigenen Dokumenten. Bereinigte Testdaten sagen wenig über den Betrieb aus.
Was Sie vor dem Start messen sollten
Steht die Systemwahl, folgt der letzte Schritt vor dem Start: die Messung. Ohne Ausgangswerte lässt sich Fortschritt später nur behaupten. octonomy erstellt deshalb vor jeder Implementierung gemeinsam mit dem Kunden einen Testsatz aus realen Betriebsfragen. Fachexperten des Kunden bewerten die Antworten. Das Ergebnis ist die Grundlage für den Go-Live-Entscheid. Bei Emons Spedition ergab dieses Verfahren eine verifizierte Antwortqualität von über 95 Prozent.
Erheben Sie parallel die Werte, an denen Sie Wirkung ablesen können. Dazu gehören das Ticketvolumen und der Anteil wiederkehrender Anfragen, die durchschnittliche Bearbeitungszeit, die Einarbeitungsdauer neuer Mitarbeitender und die Kundenzufriedenheit. Bei BORA war genau das ein zentraler Nachweis. Der NPS von 80 blieb trotz KI im Erstkontakt erhalten.
Klären Sie außerdem früh, wie das System nach dem Start beobachtet wird. Joel Anfuso beschreibt im Webinar den Unterschied zwischen Pilot und Produktion so: Im Pilot schaut jemand aufmerksam zu, in der Produktion schaut niemand. Ohne Feedback-Schleife, ohne Rückverfolgung zur Quelle und ohne klare Zuständigkeiten für Nacharbeit verlieren Sie den Überblick genau dann, wenn das System dauerhaft läuft. Legen Sie deshalb vor dem Start fest, welche Auswertungen Sie brauchen und wer für Anpassungen verantwortlich ist.
Der ehrliche Befund ist der bessere Ausgangspunkt
Man muss nicht perfekt aufgestellt sein, um zu starten. Man muss nur wissen, wo man steht. Ein geschöntes Raster hilft dabei niemandem. Es verschenkt genau die eine Information, für die es gebaut ist: den ehrlichen Blick auf den eigenen Ausgangspunkt.
Der vollständige Self-Check mit allen sechzehn Fragen, den Einordnungen zu jeder Komponente und dem ausführlichen Praxisbericht von BORA steht als eBook zum Download bereit: KI-Readiness Self-Check herunterladen.
Wie octonomy den Kundenservice automatisiert, ohne an Qualität zu verlieren, zeigt die Lösungsseite KI im Kundenservice. Dort identifizieren wir in einem kurzen Gespräch gemeinsam den ersten Use-Case mit klarer ROI-Perspektive.
Häufige Fragen zur KI-Readiness
Veröffentlicht am 7. September 2026 von
Valeriia Levchuk
Bereit zur Transformation? Sprechen Sie mit unseren KI-Experten über Ihr Potenzial!
Bereit zur Transformation? Sprechen Sie mit unseren KI-Experten über Ihr Potenzial!
Tauschen Sie sich unverbindlich mit einem KI-Experten aus und erhalten Sie Einblicke, wie andere Unternehmen Ihre Produktivität mit octonomy steigern konnten.