Agentic

Der Support-Triage-Mitarbeiter: Einstufung, bevor es eskaliert

Wie oft beginnt jemand in Ihrem Team eine Eskalation damit, etwas erneut zu recherchieren, das bereits irgendwo vermerkt ist? Das Kundenkonto, die letzte Rechnung, die beiden vorherigen Tickets, die Sprache, in der der Kunde schreibt.

Wie oft recherchiert Ihr Engineer bei einer Eskalation zuerst, was längst im Stack steht? Plan und Seats, Verlängerungsdatum, die fehlgeschlagene Stripe-Abbuchung, das Jira-Ticket vom letzten Sprint, die Sprache des Admins.

Wie oft sucht Ihr Disponent bei einer Reklamation des Verladers erneut heraus, was längst im TMS steht? Die Auftragsnummer, das gebuchte Zeitfenster, die Tour-ID des Trailers, den CMR von gestern, den Kontraktpreis der Relation.

Wie oft sucht ein Senior-Entwickler bei Ihnen erst zusammen, was längst in Jira steht, bevor er eine Störung angeht? Die SLA-Stufe des Kunden, das Release vom Dienstag, die verbleibenden Retainer-Stunden.

Wie oft sucht Ihr Service bei einer Störmeldung erneut heraus, was längst dokumentiert ist? Die Seriennummer, die As-built-Stückliste, den letzten Servicebericht, den Garantiestatus der Anlage.

Die Frage ist nicht, ob Sie zu viele Fahrkarten erhalten. Die Frage ist, in welchem Zustand eine Fahrkarte ist, wenn eine Person sie in die Hand nimmt.

Ihre Intercom-Queue ist nicht das Thema. Die Frage lautet: In welchem Zustand erreicht ein Ticket den Engineer oder CSM, der es als Erster wirklich übernimmt?

Es geht nicht darum, wie viele Anrufe zu einer Sendung eingehen. Es geht darum, was der Disponent weiß, wenn er die Meldung übernimmt.

Die Zahl der Tickets im Servicedesk ist nicht die Frage. Die Frage ist, was ein Entwickler weiß, wenn er das Ticket öffnet.

Die Frage ist nicht, wie viele Störmeldungen eingehen. Die Frage ist, was Ihr Servicetechniker weiß, wenn er eine Meldung übernimmt.

Ich möchte zwanzig meiner eigenen Tickets nacheinander durchgehen

30 Min. · Senior Consultant · keine Präsentation

Der Mechanismus liegt in der Übertragung

Der Mechanismus liegt in der Weiterleitung, nicht im Umfang. Ein Mitarbeiter der ersten Anlaufstelle liest eine Meldung, vermisst den Kontext, stellt eine Rückfrage und leitet das Ticket mit genau demselben Text weiter, mit dem es eingegangen ist.

Das Leck liegt in der Übergabe. Ein deutscher Kunde meldet, dass der DATEV-Export abbricht. Ihrem Support fehlen Tenant und Integrationsversion, er bittet um einen Screenshot und reicht das Ticket mit denselben zwei Sätzen an Engineering weiter.

Der Mechanismus steckt in der Übergabe vom Kundenservice an die Disposition. Ein Verlader mailt: Wo bleibt meine Ladung für das Lager in Venlo? Der Kundenservice fragt nach der Auftragsnummer und leitet die Mail unverändert weiter.

Das Leck sitzt in der Übergabe. Ihr Servicedesk erhält: Die Schnittstelle zur Buchhaltungssoftware geht seit gestern nicht. Er bittet um einen Screenshot, wartet einen Tag und reicht das Ticket mit genau diesem einen Satz an die Entwicklung weiter.

Das Leck liegt in der Übergabe. Ein Kunde schreibt: Anlage steht, Fehler E-217. Der Innendienst fragt nach der Seriennummer, wartet einen Tag und leitet die Mail mit genau dieser einen Zeile an den Service weiter.

Der Spezialist fängt also bei Null an. Er rekonstruiert das, was die Primärversorgung bereits fast wusste. Diese Rekonstruktion ist in keinem Dashboard sichtbar, da sie als Behandlungszeit und nicht als Verlust gewertet wird.

Ihr Engineer beginnt also bei null. Welches Release nutzt der Kunde, welche Feature Flags sind aktiv, welcher API-Key gehört dazu? Diese Suche zählt als Sprintzeit, nicht als Verlust, und taucht daher in keinem Burn Multiple auf.

Der Disponent fängt also bei null an. Er sucht den Trailer in der Telematik, ruft den Fahrer an, prüft, ob das Zeitfenster verschoben wurde. Diese Suche taucht nirgends auf, sie zählt als Dispozeit, nicht als Kosten der Relation.

Ihr Entwickler beginnt also bei null. Er sucht, welche API-Version läuft, auf welcher Umgebung, was der letzte Sprint geändert hat. In der Zeiterfassung heißt das Support, und niemand erkennt darin verlorene Auslastung.

Der Techniker beginnt also bei null. Er klärt, welcher Retrofit 2021 erfolgte und welche SPS-Version läuft. Das zählt als Servicestunden, oft in der Garantie und damit nicht abrechenbar, nie als Verlust.

Die Kosten zweiter Ordnung sind die Bearbeitungszeit bis zum Kunden. Jede Rückfrage kostet einen Kundenzyklus. Bei mehrsprachigen Kommunikationsströmen, in denen Niederländisch, Englisch und Deutsch durcheinanderkommen, und bei Erwartungen hinsichtlich der Nachrichtenbeantwortung, bei denen ein Kunde innerhalb einer Stunde eine Antwort erwartet, summiert sich dies. Sie verlieren keine Minuten, sondern ganze Bearbeitungsrunden.

Teurer ist die Durchlaufzeit zum Kunden. Jede Rückfrage kostet eine Runde. Ihre Kunden schreiben Niederländisch, Englisch und Deutsch, im In-App-Chat und im geteilten Slack-Kanal, und Ihr Enterprise-Vertrag verspricht eine Antwort binnen vier Stunden. Mitten im Trial oder kurz vor der Verlängerung summiert sich das. Sie verlieren keine Minuten, Sie verlieren Runden.

Die Kosten zweiter Ordnung liegen in der Reaktionszeit zum Verlader. Jede Rückfrage kostet eine Runde. Das deutsche Lager mailt auf Deutsch, der polnische Subunternehmer schreibt auf Englisch, der Verlader erwartet binnen einer Stunde eine neue ETA im Portal. Der Lkw steht derweil an der Rampe, und jede Runde kostet einen Slot.

Die zweite Rechnung zahlt Ihr Kunde: Durchlaufzeit. Jede Rückfrage kostet eine Runde. Ein Product Owner in Hamburg schreibt Englisch im gemeinsamen Teams-Kanal, sein IT-Leiter ruft auf Deutsch an, und der Vertrag verspricht eine Reaktion binnen vier Stunden bei P1. Dort zählen keine Minuten. Sie verlieren Runden, und jede davon zählt bei der Vertragsverlängerung.

Die Kosten zweiter Ordnung sind der Stillstand beim Kunden. Ein Instandhaltungsleiter in Bayern schreibt Deutsch, sein Einkauf verlangt eine Bestellnummer für das Verschleißteil, Ihr Engineer denkt auf Englisch. Steht seine Linie, erwartet er binnen einer Stunde einen Rückruf. Jede Rückfrage kostet ihn eine Schicht. Sie verlieren keine Minuten, Sie verlieren Schichten.

Dieses Muster hält sich, weil niemand daran Schuld hat. Die erste Instanz wird anhand der Bearbeitungsgeschwindigkeit bewertet, daher ist es rational, den Fall weiterzuleiten. Die zweite Instanz wird anhand der Lösung bewertet, daher ist es rational, den Fall gründlich zu prüfen. Niemand wird für die Übergabe zwischen den Instanzen zur Rechenschaft gezogen.

Berechnen Sie die Kosten anhand Ihrer eigenen Zahlen

Berechnen Sie es anhand Ihrer eigenen Zahlen. Nehmen Sie die Anzahl der Tickets, die pro Monat an den Second-Level-Support weitergeleitet werden. Multiplizieren Sie diese mit der Anzahl der Minuten, die eine Person dafür aufwendet, den Kontext neu zu erfassen. Teilen Sie das Ergebnis durch 60, da der Divisor die Anzahl der Minuten in einer Stunde ist. Multiplizieren Sie anschließend Ihren eigenen vollen Stundensatz damit.

Zur Veranschaulichung, mit Zahlen, die Sie selbst einsetzen müssen: 180 übertragene Fahrkarten mal 12 Minuten ergibt 2160 Minuten. Geteilt durch 60 ergibt das 36 Stunden pro Monat – rein rechnerisch. Dieser Betrag entspricht den Kosten für die Übertragung, nicht für die Fahrkarten.

Unsere Einschätzung, kein gemessener Wert.

Breites Schachbrett mit Figuren in der Mitte einer Partie, aus Augenhöhe betrachtet
[ Vier Fragen ]

Vier Fragen an Ihr eigenes Ticket-System

  1. Welcher Anteil Ihrer weitergeleiteten Tickets gelangt ohne Kontogeschichte an die zweite Instanz, und können Sie diese Daten aus Ihrem Ticketsystem abrufen oder müssen Sie sie schätzen?

    Welcher Anteil Ihrer eskalierten Tickets erreicht Engineering oder Ihr CSM ohne ARR, Plan und Verlängerungsdatum, und lässt sich das aus Zendesk und HubSpot ziehen oder müssen Sie schätzen?

    Welcher Anteil Ihrer weitergeleiteten Meldungen erreicht die Disposition ohne Auftragsnummer, Tour-ID oder CMR-Status, und holen Sie das aus dem TMS oder müssen Sie schätzen?

    Welcher Anteil Ihrer eskalierten Tickets erreicht die Entwicklung ohne SLA-Stufe, letztes Deployment und Vertragsstunden, und liefert Jira das oder müssen Sie schätzen?

    Welcher Anteil Ihrer weitergeleiteten Störmeldungen erreicht den Service ohne Seriennummer oder Maschinenkonfiguration, und liefert Ihr ERP diese Zahl oder müssen Sie schätzen?

  2. Wie oft wird dasselbe Ticket innerhalb einer Woche von mehr als zwei Personen bearbeitet, und spiegelt sich dies in Ihrer Bearbeitungszeit pro Ticket wider?

  3. Wie viele Ihrer eingehenden Meldungen sind eigentlich dieselbe Frage in einer anderen Sprache – Niederländisch, Englisch oder Deutsch?

  4. Wenn Sie heute die fünf letzten Eskalationen aufrufen, wie viele davon enthalten eine Zwischenfrage, die sich anhand der Daten aus Ihren eigenen Systemen beantworten ließ?

Zwei Teile: ein Routing-Agent und ein Spezialistenpfad

Der Agent besteht aus zwei Teilen. Ein Router-Agent liest die eingehende Meldung, ermittelt die Sprache, klassifiziert die Anfrage und wählt einen Pfad aus: Rechnungsstellung, Technik oder Kündigungsrisiko. Erkennt er eine bekannte Anfrage mit einer hinterlegten Antwort, beantwortet er diese selbst. Ist dies nicht der Fall, wird die Meldung an einen Spezialisten weitergeleitet.

Der Agent hat zwei Teile. Ein Routing-Agent liest das Ticket, erkennt die Sprache und wählt einen Pfad: Billing, etwa eine Rechnung mit USt oder eine abgelehnte Karte, Technik, etwa SSO oder ein API-Limit, oder Churn-Risiko, etwa eine Downgrade-Anfrage. Fragt ein Admin, wie er Seats hinzufügt, antwortet der Agent selbst. Erkennt er die Frage nicht, geht das Ticket in den Spezialistenpfad.

Der Agent hat zwei Teile. Ein Routing-Agent liest die eingehende Meldung, erkennt die Sprache, ordnet die Auftragsnummer zu und wählt einen Pfad: Status und ETA, Schaden und POD oder ein Rechnungsstreit um Diesel- oder Mautzuschlag. Fragt ein Verlader nach einem unterschriebenen POD, der schon im System liegt, schickt er ihn selbst. Sonst geht die Meldung an den Disponenten.

Der Agent hat zwei Teile. Ein Routing-Agent liest das eingehende Ticket, erkennt die Sprache und wählt einen Pfad: Incident unter SLA, Bug in der Gewährleistung, Change Request, den Sie separat abrechnen, oder Risiko bei einem Schlüsselkunden. Eine bekannte Frage, etwa einen Nutzer im CMS anlegen oder ein DNS-Eintrag nach einem Umzug, beantwortet er selbst. Alles andere geht in den Spezialistenpfad.

Der Agent hat zwei Teile. Ein Routing-Agent liest die Meldung, erkennt die Sprache, ordnet die Seriennummer der Anlage zu und wählt einen Pfad: Ersatzteilbestellung, technische Störung oder Garantiefall. Fragt ein Kunde die Lieferzeit eines Standard-Verschleißteils oder eine Kopie der CE-Erklärung an, antwortet er selbst. Alles andere geht in den Spezialistenpfad.

Dieser Spezialistenpfad übernimmt die Aufgaben, die derzeit wegfallen. Er ruft die Kundenhistorie, offene Posten und frühere Tickets ab, erstellt einen Lösungsentwurf und bereitet diesen zur Überprüfung vor. Was nicht gelöst werden kann, wird eskaliert. Dabei wird jedoch die Akte bereits mitgeliefert: wer der Kunde ist, was zuvor geschehen ist und was der Mitarbeiter versucht hat. Der Mitarbeiter beginnt bereits informiert und nicht bei Null.

Alter Messingschlüssel in Nahaufnahme auf dunklem Hintergrund

Die PRAL-Schleife in ihrer einfachsten Form

Dies ist PRAL in seiner einfachsten Form. „Perceive“ umfasst die Meldung sowie den Systemkontext. „Reason“ umfasst die Klassifizierung und die Wahl des weiteren Vorgehens. „Act“ bedeutet, zu reagieren, zu ergänzen oder zu eskalieren. „Learn“ ist die Korrektur des Konzepts durch Ihren Spezialisten.

Ehrlichkeit hinsichtlich des Autonomiegrads

Ehrlichkeit hinsichtlich des Autonomiestufens. Dieser Workflow läuft auf Stufe L2, KI-unterstützt: Der Agent unterbreitet einen Vorschlag, ein Mensch validiert diesen. Nur der schmale Bereich bekannter Fragen mit festgelegter Antwort erreicht Stufe L3. Capgemini schätzte für das Jahr 2025, dass etwa 15 Prozent der Prozesse auf Stufe L3 oder höher ablaufen, wobei dieser Anteil bis 2028 auf ein Viertel ansteigen wird. Wer Ihnen einen vollautonomen Support-Agenten verkauft, verkauft Ihnen „Agentic Washing“.

Die Polarität des Sicherheitswerts, einmal explizit dargelegt: „Hoch“ bedeutet sicher, „Niedrig“ bedeutet unsicher. Die Regel lautet daher: Nur bei einem hohen Sicherheitswert antwortet der Bot selbst, bei mittlerem oder niedrigem Wert wird die Anfrage an einen Menschen weitergeleitet.

Darüber hinaus gilt eine strenge Regel, unabhängig vom Grad der Sicherheit: Alles, was eine Zahlung, eine Gutschrift, eine Kündigung oder eine Beschwerde mit rechtlicher Tragweite betrifft, wird stets an einen Mitarbeiter weitergeleitet.

Was Sie in Woche eins tun

Was Sie in Woche eins tun: Nehmen Sie hundert abgeschlossene Tickets aus dem vergangenen Monat und lassen Sie den Mitarbeiter diese klassifizieren, ohne dass er darauf antwortet. Vergleichen Sie seine Zuordnung mit dem, was damals tatsächlich geschehen ist. Sie messen, wie oft er eine falsche Zuordnung vornimmt und wie oft seine Unterlagen vollständig genug waren, um damit zu beginnen. Diese zweite Zahl ist entscheidend.

Was Sie in Woche eins tun. Exportieren Sie hundert geschlossene Tickets aus dem letzten Quartal, samt der Woche nach Ihrem letzten großen Release, und lassen Sie den Agenten sie klassifizieren, ohne zu antworten. Vergleichen Sie sein Routing mit dem, was damals geschah. Sie messen Fehlrouten und wie oft sein Dossier für Ihren Engineer reichte. Die zweite Zahl zählt.

Was Sie in Woche eins tun. Nehmen Sie hundert abgeschlossene Meldungen aus dem Kundenservice-Postfach des Vormonats und lassen Sie den Agenten sie routen, ohne zu antworten. Legen Sie seine Wahl neben das, was die Disposition damals tat. Sie messen die Fehlroutings und wie oft seine Akte mit Tour und CMR vollständig genug war. Die zweite Zahl zählt.

Was Sie in Woche eins tun. Exportieren Sie hundert geschlossene Servicedesk-Tickets des Vormonats und lassen Sie den Agenten sie routen, ohne zu antworten. Legen Sie seine Wahl neben das, was damals geschah, und achten Sie gesondert auf Change Requests, die Sie gratis als Bug gelöst haben. Sie messen, wie oft er falsch routet und wie oft sein Dossier für den Start reichte. Die zweite Zahl zählt.

Was Sie in Woche eins tun. Nehmen Sie hundert abgeschlossene Servicemeldungen des letzten Quartals und lassen Sie den Agenten sie sortieren, ohne zu antworten. Vergleichen Sie sein Routing mit dem damaligen Vorgehen. Sie messen, wie oft er falsch routet und wie oft sein Dossier mit Seriennummer, As-built und letztem Einsatz für den Techniker vollständig genug war. Die zweite Zahl zählt.

Governance

Was die DSGVO konkret von Ihnen verlangt

Dieser Prozess betrifft Kundendaten und häufig auch Zahlungs- und Vertragsdaten. Dies stellt das größte Risiko der vier Arbeitsabläufe in diesem Bereich dar. Aus diesem Grund wird das Thema Governance hier als eigener Abschnitt und nicht nur als einzelner Satz behandelt.

Für ein niederländisches Unternehmen mit 10 bis 100 Mitarbeitern bedeutet dies fünf konkrete Maßnahmen: einen Auftragsverarbeitungsvertrag mit dem Modellanbieter – welche Daten, wofür, wie lange, wer Zugriff hat; ein Geschäftskonto anstelle eines Privatkundenkontos. Wissen, in welcher Region die Verarbeitung stattfindet, und dies nachweisen können. Eine Aufbewahrungsregel pro Datenart, festgeschrieben und durchsetzbar. Und ein dokumentierter Eskalationsweg zu einer verantwortlichen Person, einschließlich der Angabe, wer unterschreibt.

Hinzu kommt ein Prüfpfad: Für jede Entscheidung werden der Beschluss, die verwendeten Daten, der Sicherheitswert sowie die Angabe, ob eine Person die Entscheidung überprüft hat, erfasst. Das dient nicht nur der Compliance. Es ist Ihre einzige Möglichkeit, einen Fehler rückgängig zu machen und den Kunden zu informieren. Deloitte stellte im Jahr 2026 bei 3.235 Führungskräften in 24 Ländern fest, dass 74 Prozent agentische KI einsetzen möchten, während 21 Prozent über ausgereifte Governance-Strukturen verfügen.

Ein Punkt, den Sie nicht unter den Teppich kehren sollten. Der Mitarbeiter erfasst, wie oft er seinen Entwurf überschreibt. Dabei handelt es sich um personenbezogene Daten, auch wenn sie den Mitarbeiter selbst betreffen. Unsere Regel lautet: Diese Überschreibungsquote ist Teamdaten, Eigentum des Teams, und dient dazu, den Mitarbeiter anzuleiten und die Arbeitsbelastung zu verringern. Sollten Sie diese Daten jemals für individuelle Beurteilungen verwenden, handelt es sich um einen anderen Zweck, und der Betriebsrat muss im Vorfeld mitentscheiden. Teilen Sie dies Ihrem Team mit, bevor Sie beginnen.

[ Nach Sektoren ]

Derselbe Arbeitsablauf, drei Fachbereiche, drei unterschiedliche Diagnosen

Derselbe Arbeitsablauf, drei Bereiche, drei unterschiedliche Diagnosen. Die Maßeinheit ändert sich, das Messinstrument ändert sich, und der Zeitpunkt, zu dem Sie messen, ändert sich ebenfalls.

SaaS-Scale-up

Die Einheit sind Tickets pro aktivem Konto und Monat. Das Instrument ist die Verknüpfung zwischen Ticket-Labels und Ihrem Release-Protokoll. Der Zeitrahmen ist der Release-Zyklus.

  1. Ziehen Sie aus den letzten beiden Veröffentlichungen alle Tickets heraus und kennzeichnen Sie diese nach Funktionsbereich.
  2. Legen Sie die Beschriftungen neben die Versionshinweise und markieren Sie, welche Spitzen auf eine Änderung folgen.
  3. Lassen Sie den Router-Agenten zunächst nur die Labels vorhersagen – noch ohne Antwort – und messen Sie die Fehlweiterleitungen pro Funktionsbereich.
  4. Fügen Sie die bekannten Fragen, die nach jeder Veröffentlichung immer wieder auftauchen, in den festgelegten Antwortsatz ein.
  5. Wiederholen Sie die Messung nach der nächsten Version und prüfen Sie, ob sich die Fehlleitung entsprechend der Änderung mitverändert.

Logistik

Die Einheit sind Anfragen pro Sendung. Das Instrument ist die Verknüpfung von Meldungen mit dem Sendungsstatus im TMS. Der Zeitrahmen ist das Lieferfenster, nicht der Monat.

  1. Wählen Sie eine Woche mit Sendungen aus und zählen Sie pro Sendung, wie viele Kundenkontakte dadurch entstanden sind.
  2. Tragen Sie jeden Kontakt in die Zeitleiste der Sendung ein und kennzeichnen Sie, ob er vor, während oder nach dem Lieferzeitfenster stattfand.
  3. Lassen Sie den Sachbearbeiter lediglich die Statusabfragen von den Ausnahmen wie Schäden und Fehlmengen trennen.
  4. Prüfen Sie, ob die Akte in Ausnahmefällen bereits den Frachtbrief und den letzten Scan enthielt.

Maschinenbau

Die Einheit sind Meldungen pro Maschine im Einsatz. Die Kennung umfasst die Seriennummer, die Wartungshistorie und den Garantiestatus. Die Zählung bezieht sich auf die Stillstandstunden.

  1. Ordnen Sie jede Meldung einer Seriennummer und der letzten Wartung zu.
  2. Legen Sie für jede Meldung fest, ob sie unter die Garantie fiel oder nicht und ob dies bei der Entgegennahme bekannt war.
  3. Lassen Sie den Sachbearbeiter ausschließlich den Garantiestatus und die Wartungshistorie abfragen, ohne eine Beurteilung der Beschwerde vorzunehmen.
  4. Ermitteln Sie, wie viele Ausfallstunden eingespart werden, da der Servicekoordinator diese beiden Angaben nicht mehr selbst recherchieren muss.
  5. Kennzeichnen Sie alle Meldungen mit sicherheitsrelevanten Auswirkungen als „immer vom Menschen verursacht“, unabhängig vom Grad der Gewissheit.
Zwei Menschen in Anzügen geben sich die Hand; im Hintergrund ist ein Feld aus Lichtpunkten zu sehen
Bitte bringen Sie mit

Wählen Sie zunächst Ihre eigenen zwanzig Lose aus, bevor Sie etwas kaufen

Bitte lesen Sie dies, bevor Sie etwas aufkleben

Lesen Sie dies, bevor Sie etwas hochladen, denn dieser Schritt ist nicht optional. Entfernen Sie Namen, E-Mail-Adressen, Telefonnummern, Kundennummern und Rechnungsnummern aus den Tickets. Ersetzen Sie diese durch „Kunde A“, „Kunde B“. Verwenden Sie ein Geschäftskonto Ihres LLM-Anbieters, kein Privatkundenkonto. Vergewissern Sie sich, dass eine Auftragsverarbeitungsvereinbarung vorliegt, bevor Sie auch nur anonymisierte Kundentexte hochladen. Prüfen Sie, wo die Verarbeitung stattfindet. Bewahren Sie die Ergebnisse nicht länger auf, als Ihr Test dauert, und löschen Sie sie anschließend. Dieser Test dauert eine Stunde und gibt Ihnen mehr Aufschluss als drei Demos.

Der Auftrag 
Je bent triage-analist voor mijn klantenservice. Ik plak hieronder twintig echte,
geanonimiseerde tickets. Doe precies dit, in deze volgorde, en verzin niets bij.

1. Bepaal per ticket: de taal, het pad (facturatie, technisch, opzeggingsrisico,
   overig), en een zekerheidsscore hoog, midden of laag. Polariteit: hoog betekent
   zeker, laag betekent onzeker.
2. Pas deze regel toe: alleen bij zekerheid hoog antwoordt de agent zelf, bij
   midden of laag gaat het naar een mens.
3. Harde stopregel, ongeacht de zekerheid: alles wat een betaling, een creditering,
   een opzegging of een klacht met juridische lading raakt, gaat altijd naar een mens.
4. Noem per ticket welke drie gegevens uit mijn eigen systemen een specialist nodig
   heeft om dit af te maken. Vraag ze niet op, benoem ze alleen.
5. Schrijf voor de drie tickets die volgens jou het duurst zijn in behandeltijd een
   overdrachtsdossier van maximaal acht regels: wat er speelt, wat al geprobeerd is,
   wat de specialist als eerste moet controleren.
6. Sluit af met de vijf vragen die zo vaak terugkomen dat ze een vastgelegd antwoord
   verdienen, en zeg er per vraag bij waarom je dat denkt.

Zeg expliciet welke tickets je niet kon classificeren en waarom.

Schauen Sie sich anschließend Punkt 5 an, nicht Punkt 1. Wenn diese Unterlagen verwertbar sind, ist der Workflow sinnvoll. Sind sie es nicht, liegt das an Ihrer Erfassung und nicht am Modell, und dann ist RENEW Ihr erster Schritt.

Wo dies endet

Dieser Agent ist nicht das Richtige für Sie, wenn Ihr Vertriebskanal der Support ist und jedes Gespräch ein Kundenkontakt ist. Dann verlieren Sie mehr, als Sie gewinnen. Er ist auch nicht das Richtige, wenn Ihr Ticketvolumen gering ist und Ihre Fragen jedes Mal anders ausfallen, da es dann kein Muster für die Weiterleitung gibt. Und er ist auch nicht geeignet, wenn Sie ihn kaufen, um Personal zu sparen. Gartner geht davon aus, dass bis 2027 mehr als 40 Prozent der Agentic-Projekte aufgrund eines unklaren geschäftlichen Nutzens scheitern werden. Die Umleitung von Anfragen als Ziel ist genau ein solcher unklarer Nutzen. Wir richten das System nicht ohne menschliche Intervention bei Ausnahmen ein, auch nicht, wenn Sie darum bitten.

Dieser Agent passt nicht, wenn Ihre zwanzig größten Accounts je einen eigenen CSM haben und jedes Supportgespräch ein Expansionsgespräch ist. Dann verlieren Sie mehr, als Sie gewinnen. Er passt auch nicht bei vierzig Kunden, deren Tickets eigentlich Produktfeedback sind, denn dann fehlt das Muster zum Routen. Und er passt nicht, wenn Sie ihn kaufen, um Supportstellen zu streichen, damit Ihr Burn vor der nächsten Runde besser aussieht. Gartner erwartet, dass über 40 Prozent der Agentic-Projekte bis 2027 an unklarem Geschäftswert scheitern. Deflection als Ziel ist genau so ein unklarer Wert. Ohne Menschen für die Ausnahmen bauen wir ihn nicht, auch nicht auf Wunsch.

Dieser Agent passt nicht, wenn der Schlüsselkunde Ihrer Kühltransporte bei jeder Abweichung den Geschäftsführer direkt anruft. Dieses Gespräch gehört zur Beziehung, und ein Agent dazwischen kostet mehr, als er bringt. Er passt auch nicht, wenn Sie wenige Meldungen haben und jede Sendung ein Projekt ist, etwa im Schwertransport, denn dann gibt es kein Muster. Und er passt nicht, wenn Sie ihn kaufen, um einen Disponenten einzusparen. Gartner erwartet, dass bis 2027 mehr als 40 Prozent der Agentic-Projekte an unklarem Geschäftswert scheitern. Weniger Disponenten als Ziel ist genau solch ein unklarer Wert. Wir bauen ihn nicht ohne Menschen für die Ausnahmen, auch nicht auf Wunsch.

Dieser Agent passt nicht zu Ihnen, wenn Ihre zwei oder drei größten Kunden den Support direkt über Ihren Account Manager regeln und daraus das nächste Projekt entsteht. Dann verlieren Sie mehr, als Sie gewinnen. Er passt auch nicht bei dreißig Tickets im Monat, die jeweils Individualentwicklung betreffen, die nur ein Entwickler kennt, denn dann gibt es kein Muster zum Routen. Und er passt nicht, wenn Sie ihn kaufen, um eine Stelle im Servicedesk zu streichen. Gartner erwartet, dass bis 2027 mehr als 40 Prozent der Agentic-Projekte an unklarem Geschäftswert scheitern. Deflection als Ziel ist genau so ein unklarer Wert. Wir bauen ihn nicht ohne Menschen für die Ausnahmen, auch nicht auf Ihren Wunsch.

Dieser Agent passt nicht zu Ihnen, wenn Sie fünf Großkunden haben, die Sie selbst anrufen, sobald etwas steht. Dort ist jedes Servicegespräch ein Beziehungsgespräch, und Sie verlieren mehr, als Sie gewinnen. Er passt auch nicht, wenn Sie acht Sondermaschinen im Jahr ausliefern und jede Störung einzigartig ist, denn dann gibt es kein Muster zum Routen. Und er passt nicht, wenn Sie ihn kaufen, um eine Stelle im Innendienst zu streichen. Gartner erwartet, dass bis 2027 über 40 Prozent der Agentic-Projekte an unklarem Geschäftswert scheitern. Deflection als Ziel ist genau so ein unklarer Wert. Garantiefälle und Sicherheitsmeldungen gehen immer an einen Menschen; anders bauen wir ihn nicht, auch nicht auf Wunsch.

Wo Sie im Folgenden weiterlesen können

Zwanzig Ihrer eigenen Tickets, gemeinsam durchgegangen.

Ich würde mir lieber zunächst zwanzig Ihrer eigenen Tickets ansehen, anstatt Ihnen eine Demo zu zeigen: Gerne vereinbare ich einen Termin, bei dem wir diese zwanzig gemeinsam durchgehen.

Statt einer Demo sehe ich mir lieber zwanzig Ihrer eigenen Tickets an, etwa aus dem Monat vor Ihrer letzten Verlängerungsrunde. Gern plane ich ein Gespräch, um diese zwanzig gemeinsam durchzugehen.

Ich sehe mir lieber zwanzig Meldungen aus Ihrem eigenen Kundenservice-Postfach an, als Ihnen eine Demo zu zeigen: Gern plane ich ein Gespräch, in dem wir diese zwanzig gemeinsam durchgehen.

Ich sehe mir lieber zwanzig Tickets eines Ihrer Managed-Services-Kunden an, als Ihnen eine Demo zu zeigen. Vereinbaren Sie ein Gespräch, dann gehen wir diese zwanzig gemeinsam durch.

Ich sehe mir lieber zwanzig Ihrer eigenen Störmeldungen an, als Ihnen eine Demo zu zeigen: Vereinbaren Sie ein Gespräch, wir gehen diese zwanzig gemeinsam durch, von der Mail bis zum Servicebericht.

Ich möchte zwanzig meiner eigenen Tickets nacheinander durchgehen

30 Min. · Senior Consultant · keine Präsentation