TL;DR
- L1-Auto-Resolution-Pitches versprechen 50–70 % Deflection; real sind 15–25 % (Password-Reset, Lizenz-Reaktivierung, Standard-FAQ).
- Der echte Hebel sitzt in L2-Routing + Kontext-Bundle: Asset-Lookup, Ticket-Match und Lösungs-Vorschlag reduzieren die Mean-Time-to-Engineer um 60–70 %.
- Bei mittlerer MSP-Last sind die 8–12 Min/Ticket × Volume der größere ROI-Block als jede Auto-Resolution.
Warum L1-Auto-Resolution falsch verkauft wird
Der Pitch fast aller KI-Vendor-Plugins für ServiceNow, Jira Service Management, OTRS und Zammad lautet: „Wir schließen 50 % Ihrer L1-Tickets autonom." In der Mittelstands-MSP-Realität liegt die nachweisbare Deflection bei 15–25 % — gut für Password-Reset, Lizenz-Reaktivierung, MFA-Resync und Standard-FAQ. Alles darüber kollidiert mit Asset-Spezifika, Lizenz-Konstellationen und Ausnahmen.
Das Problem ist die Pitch-Mechanik: Auto-Resolution ist als Wirkung sichtbar (Ticket geschlossen), Routing-Beschleunigung verschwindet in der Bearbeitungs-Statistik.
| Use Case | Deflection | Voraussetzung |
|---|---|---|
| Password-Reset (AD/Entra) | 60–80 % | SSO, Self-Service-Portal |
| Lizenz-Reaktivierung (M365, Adobe) | 40–60 % | API-Zugriff auf Tenant |
| MFA-Resync | 30–50 % | Identity-Provider angebunden |
| Standard-FAQ (Drucker, VPN) | 20–35 % | Knowledge-Base aktuell |
| Komplexe Incidents (≥ L2) | < 5 % | — |
| Gewichteter Schnitt | 15–25 % | reale Mischung |
Wer 50 % verspricht, rechnet eine reine L1-Sub-Population oder schließt Tickets, die nie hätten geöffnet werden sollen — „Self-Service-Hygiene", kein KI-Effekt.
Der echte Hebel: Routing + Kontext-Bundle
Das durchschnittliche MSP-Ticket verbrennt 8–12 Minuten Engineer-Zeit, bevor die eigentliche Arbeit anfängt: Kunde identifizieren, Asset zuordnen, Lizenz-Status prüfen, Verlauf scannen, ähnliche Fälle suchen, Engineer routen. Diese Minuten sind automatisierbar — ohne dass die KI eine Entscheidung trifft. Sie bundlet nur Kontext, den der Mensch sonst manuell zusammensucht:
- Asset-CMDB-Lookup. Aus Absender-Mail oder Subject zieht der Assistent Device, OS, Software, Lizenz-Status, Garantie und Wartungsstand. In IT-Glue, Hudu oder ServiceNow-CMDB liegt das strukturiert vor — wird aber nicht aufgerufen, weil der Lookup vier Klicks kostet.
- Vergangenheits-Ticket-Match. Vektorsuche über 12–24 Monate gelöster Tickets liefert die drei ähnlichsten Fälle inklusive Lösungsweg — bei 100 k+ Tickets die größte ungehobene Wissens-Reserve im Haus.
- Lösungs-Vorschlag mit Konfidenz. Bei klaren Patterns (gleiches Asset, Symptom, Fix) liefert der Assistent einen Vorschlag mit Konfidenz-Score. Der Engineer akzeptiert, lehnt ab oder modifiziert — die Recherche entfällt.
In MSP-Pilots zeigt sich: Die KI muss nicht die Tickets lösen. Sie muss die Lücke zwischen Ticket-Eingang und der ersten produktiven Engineer-Minute schließen — und das ist der Großteil der heutigen Bearbeitungszeit.
Wie der Assistent arbeitet
Der Workflow ist deterministisch — die KI sitzt nur an den drei Stellen, an denen Semantik-Verständnis nötig ist:
- Klassifikation (LLM, Haiku-Klasse): Ticket-Typ, Kunde, Asset-Hinweis aus dem Mail-Body.
- CMDB-Lookup (deterministisch, API): Asset, Lizenzen, Garantie, Wartungsstand.
- Historien-Match (Vektorsuche + LLM): drei ähnlichste gelöste Tickets, Relevanz-Ranking.
- Routing-Vorschlag (Regel-Engine): L1/L2/L3-Gruppe und spezifischer Engineer.
- Kontext-Bundle (Template): strukturierte Ticket-Notiz im PSA-Tool, die der Engineer übernimmt.
Gesamtzeit: 8–12 Sekunden vom Eingang bis zum vollständig kontextualisierten Ticket auf dem Schreibtisch des richtigen Engineers. Heute verbrennt derselbe Schritt 8–12 Minuten — ein Faktor 60–80.
MSP-Pilot: 280 MA, 14.000 Tickets/Monat
Pilot-Implementierung Q1/2026 bei einem süddeutschen MSP mit 280 Mitarbeitenden und 14.000 Tickets/Monat. Toolchain: ServiceNow, IT-Glue als CMDB, Pinecone-Vektor-Store, LLM-Calls über Nexus Router.
| Kennzahl | Vor Pilot | Nach 90 Tagen | Delta |
|---|---|---|---|
| Mean-Time-to-Engineer | 11,4 Min | 3,8 Min | –67 % |
| First-Touch-Resolution-Rate | 38 % | 51 % | +13 pp |
| Tickets/Engineer/Tag | 18 | 26 | +44 % |
| L1-Auto-Resolution-Quote | 12 % | 21 % | +9 pp |
| Engineer-NPS (intern) | +12 | +41 | +29 |
| Engineer-Kapazität (annualisiert) | — | +9 FTE | freigesetzt |
Der größte Effekt ist nicht die Auto-Resolution (+9 pp), sondern die Mean-Time-to-Engineer (–67 %) — 9 FTE Kapazitäts-Gewinn aus 280, ohne Hire, ohne Outsourcing. Die NPS-Bewegung von +12 auf +41 ist der unterschätzte Nebeneffekt: bei 18–25 % Engineer-Fluktuation rechnerisch der zweite ROI-Block.
Was bleibt menschlich
- Eskalations-Entscheidung. Wann ein Ticket an L3 oder zum Vendor eskaliert, bleibt Engineer-Urteil. Der Assistent liefert Daten, nicht die Entscheidung.
- Kundenkommunikation bei Eskalation. Sobald ein Incident die SLA-Grenze touchiert oder sensibel wird, übernimmt der Service-Manager. Templates ja — Versand niemals autonom.
- Knowledge-Base-Pflege. Erkennt der Assistent systematisch dieselben Patterns nicht, ist das ein Hinweis auf eine Wissens-Lücke und bleibt Senior-Arbeit.
Einordnung
Der Hebel ist nicht die KI-Magie, sondern die kalte Mathematik: 14.000 Tickets × 8 Minuten gesparte Vorbereitung ergeben rund 1.870 Engineer-Stunden pro Monat. An dieser Zahl misst jeder MSP-Geschäftsführer das Projekt. Das Routing-Bundle baut sich aus den Bestandsdaten des Hauses — CMDB, Historie, Lizenz-Stamm. Wer die Daten nicht bundlet, kauft Vendor-Magie und bekommt 15 % Deflection.
Stand Mai 2026.
Nächster Schritt
Passt das auf Ihren Fall?
30-Min-Erstgespräch, kostenfrei und unverbindlich. Wir gehen Ihren konkreten Fall durch — und sagen ehrlich, wenn nichts passt.