Support-Triage ist der beste erste Agent, den die meisten Teams nie aufbauen

Eine Support-Warteschlange besteht aus zwei Jobs mit demselben Namen. Eine davon besteht darin, herauszufinden, um welchen Kunden es sich handelt, was er betreibt, was sich in letzter Zeit geändert hat und ob dies etwas ähnelt, was man zuvor gesehen hat. Der andere ist das Lösen.

Der erste Job ist die meiste verstrichene Zeit und fast kein Fachwissen. Diese Asymmetrie macht die Triage zu einem guten Ersthelfer.

Was der Agent tun sollte

Lesen Sie das eingehende Problem und stellen Sie den Kontext zusammen, den ein Techniker sonst von Hand erfassen würde: die Konfiguration des Kunden, die Region, aktuelle Änderungen an seinem Konto, ähnliche frühere Tickets und den relevanten Runbook-Abschnitt.

Entwerfen Sie einen Klassifikationsvorschlag und eine Ausgangshypothese mit den beigefügten Quellen.

Halten Sie dann an und geben Sie einer Person ein ausgefülltes Ticket.

Was es nicht tun sollte

Schließen Sie ein Ticket. Entscheiden Sie, dass ein Problem kein Problem ist. Kontaktieren Sie den Kunden ohne eine Person dazwischen. Handeln Sie auf den Systemen des Kunden.

Dabei handelt es sich nicht um Leistungsgrenzen. Hier muss die Verantwortung sitzen, und ein Agent, der sie überschreitet, führt zu einem Fehler, den der Kunde direkt erfährt, und nicht zu einem Fehler, den ein Techniker erkennt.

Warum die Grenze Bestand hat

Der messbare Vorteil besteht darin, dass ein Techniker mit einem ausgefüllten Ticket beginnt und nicht mit einem leeren. Das spart echte Minuten bei jedem Problem und verlangsamt die Bearbeitung einer Warteschlange.

Sobald ein Agent mit der Lösung statt mit der Vorbereitung beginnt, muss jede Ausgabe sorgfältig überprüft werden, da niemand vorhersagen kann, welche Lösung die falsche ist. An diesem Punkt ist die Zeit eher verstrichen als verschwunden, und das Programm hört stillschweigend auf, sich zu amortisieren.

Was zu instrumentieren ist

Zeit von der Ankunft bis zur ersten Aktion des Ingenieurs. Dies ist die Zahl, die der Agent tatsächlich bewegt.

Nacharbeitsrate: Wie oft verwirft ein Ingenieur den zusammengestellten Kontext, anstatt darauf aufzubauen? Wenn dieser hoch ist, ist der Abruf falsch, nicht das Modell.

Kosten pro Ticket, die dem Agenten und nicht einer allgemeinen KI-Leitung zugeschrieben werden, daher ist der Wert in einer Planungsbesprechung fraglich.

Wiederholungsversuche getrennt von Erfolgen, da ein Triage-Agent, der auf halbem Weg fehlschlägt und neu startet, ein Ticket doppelt in Rechnung stellt.

Der Misserfolg, den es zu planen lohnt

Sicherlich falscher Kontext. Der Agent fügt ein veraltetes Konfigurationsdetail hinzu, ein Techniker vertraut ihm einigermaßen und die Diagnose verläuft schief.

Bei der Schadensbegrenzung handelt es sich um die Herkunft aller Angaben des Agenten sowie um Kriterien zur Bewertung, ob die von ihm zitierten Quellen tatsächlich seine Behauptung stützen. Ein Agent, der Unsicherheit markiert, ist in einer Demo weniger beeindruckend und in einer Warteschlange deutlich nützlicher.

Ein realistischer Rollout

Ein Produktbereich, nicht die ganze Warteschlange. Ein benannter Eigentümer auf der Support-Seite und nicht in der IT. Bewertungskriterien, die anhand der echten Tickets des letzten Quartals erstellt wurden. Ein Budget, das blockiert. Erweitern Sie, wenn die Ergebnisse nicht mehr interessant sind, was normalerweise länger dauert, als irgendjemand geplant hat, und der Teil ist, der dafür sorgt, dass es hängen bleibt.

Als nächstes

Auf den Seiten des Agent Orchestration System werden Eigentum, Zuordnung, Richtlinien und Bewertung behandelt. Buchen Sie eine Demo, um die Diskussion anhand Ihrer eigenen Warteschlange statt einer generischen Warteschlange zu besprechen.