Agenten fürs Backoffice
KI-Agenten, die Ihre Warteschlangen leeren, live in 14 Tagen
Jemand bei Ihnen liest ein Ticket, öffnet drei Systeme, kopiert Felder hin und her und schreibt eine Notiz. Das ist Arbeit, die ein Agent gut macht, und wir bauen sie: typisierte Werkzeugaufrufe nach Salesforce, SAP, Jira, auf Ihre AS/400 oder in Ihre eigene API, ein Freigabeschritt vor jeder schreibenden Aktion und ein Log je Entscheidung, das zeigt, was er gelesen hat und warum er gehandelt hat. Der erste Ablauf braucht vierzehn Tage, der zweite geht schneller, weil die Adapter schon stehen.
14 Tage für den ersten Ablauf; der zweite geht schneller, weil die Adapter stehen
Das RPA-Skript ist durchgestrichen, weil es an dem Tag bricht, an dem ein Anbieter einen Knopf verschiebt. Adapter gehen über APIs, und wo es keine gibt, bauen wir eine.
Manuelle Warteschlange
Menschen sichten Tickets, kopieren zwischen Systemen und folgen einem Runbook, das als PDF existiert.
- ticket queuehumans triage
- copy-paste between systemsmanual
- runbook.pdftribal knowledge
- RPA scriptbreaks on redesign
Agent mit Freigabe
Ein Agent, typisierte Adapter, ein ausdrücklicher Freigabeschritt, eine Audit-Zeile je Entscheidung.
- agentGo · tool calls
- system adapterstyped
- human approvalexplicit gate
- audit trailper decision
14 Tage für den ersten Ablauf; der zweite geht schneller, weil die Adapter stehen
Wie die Arbeit läuft
- 01Tag 1–2
Den Ablauf über eine Rechnung auswählen
Volumen mal Minuten je Fall, minus die Fälle, die weiterhin einen Menschen brauchen. Diese Multiplikation machen wir am ersten Tag mit Ihnen und fangen mit der Warteschlange an, die sich am schnellsten zurückzahlt.
- 02Tag 2–5
Die Adapter schreiben
Typisierte Aufrufe in Ihre Systeme, mit den Fehlerfällen: Rate Limits, halb geschriebene Sätze, der Endpunkt, der 200 zurückgibt und den Fehler in den Body schreibt.
- 03Tag 5–10
Im Schattenbetrieb fahren
Der Agent schlägt vor, ein Mensch entscheidet, und jede Abweichung geht zurück ins Eval-Set. Niemandes Job ändert sich, und Sie bekommen eine echte Trefferquote auf Ihren eigenen Fällen.
- 04Tag 9–14
Die Freigabe Aktion für Aktion öffnen
Aktionen mit sauberer Bilanz und kleinem Schadensradius gehen zuerst auf automatisch. Der Rest bleibt so lange freigabepflichtig, wie Sie wollen, auch dauerhaft.
Was die Plattform macht, was ein Mensch macht
| Was die Plattform macht, was ein Mensch macht | Wer macht was | Anmerkungen |
|---|---|---|
| Runbook und Ticket-Historie lesen | Plattform | Auch die Fälle, die entgegen dem Runbook bearbeitet wurden, und die sind die interessanten. |
| Festlegen, was der Agent ohne Rückfrage darf | Entwickler | Wir empfehlen je Aktionstyp. Sie unterschreiben schriftlich, bevor er läuft. |
| Die Adapter bauen | Gemeinsam | Aus dem API-Vertrag erzeugt, dann von einem Menschen gegen das korrigiert, was die API wirklich tut. |
| Abweichungen aus dem Schattenbetrieb beurteilen | Gemeinsam | Automatisch, wo die Historie das Ergebnis zeigt, menschlich, wo zwei Ihrer Fachleute darüber streiten würden. |
| Die Nachvollziehbarkeit | Plattform | Eingaben, aufgerufene Werkzeuge, Entscheidung, Freigebender. Eine durchsuchbare Zeile je Fall, aufbewahrt, egal ob die Antwort richtig war. |
| Eskalationswege | Entwickler | Was der Agent tut, wenn er unsicher ist, und wer den Fall Freitag um 18 Uhr aufnimmt. |
Die Leute hinter den Agenten
Dutzende Migrationen und über zehn Jahre damit verbracht, Systeme zu verbinden, die nie miteinander reden sollten: SAP, Salesforce, Jira, Dynamics, eine AS/400, ein SOAP-Endpunkt von 2006, eine CSV, die jede Nacht auf einem FTP-Server landet. Agenten sind das Neueste, was wir bauen. Die Anbindung darunter ist das Älteste, und an ihr entscheidet sich, ob das Ganze trägt.
Der Schattenbetrieb ist der Beweis, und er kommt vor der Bindung. Der Agent läuft gegen Ihre echte Warteschlange, schlägt vor, ein Mensch entscheidet. Am Ende halten Sie eine Trefferquote, die an Ihren eigenen Fällen gemessen wurde.
Fragen, die Entwickler uns stellen
- Wie unterscheidet sich das von der RPA, die wir schon gekauft haben?
- RPA bedient die Oberfläche, bricht also bei einem Redesign und versteht nichts vom Fall. Ein Agent ruft APIs auf und kommt mit dem Ticket zurecht, das nicht ins Skript passt, und genau daran sitzen Ihre Leute den ganzen Tag. Der Handel dabei: RPA ist deterministisch, ein Agent nicht, und deshalb gibt es die Freigabe und das Eval-Set.
- Was hindert ihn daran, etwas Teures zu tun?
- Er kann kein Werkzeug aufrufen, das er nicht bekommen hat, und die schreibenden Werkzeuge sind standardmäßig freigabepflichtig. Der Schadensradius wird je Aktionstyp entworfen, bevor irgendetwas läuft, und er steht in dem Dokument, das Sie unterschrieben haben.
- Woher wissen wir, dass er richtig liegt?
- Tage im Schattenbetrieb an Ihrer Warteschlange, ein Eval-Set aus den Abweichungen und ein Log je Entscheidung, das Sie öffnen können, wenn sich jemand über einen bestimmten Fall beschwert.
- Brauchen Sie unsere Daten fürs Training?
- Standardmäßig kein Fine-Tuning. Der Agent liest im Moment des Falls, was er braucht, und was er gelesen hat, steht im Log. Wenn Sie später ein Modell auf Ihrer Historie trainieren wollen, ist das eine eigene Entscheidung mit eigenem Papierkram.
- Was passiert, wenn wir ein angebundenes System ändern?
- Der Adapter ist typisiert, also bricht eine Vertragsänderung den Build, statt beim Monatsabschluss still im Produktivbetrieb zu scheitern. Das ist der Hauptgrund, warum wir Adapter schreiben, statt ein Modell HTTP-Aufrufe erfinden zu lassen.
Schicken Sie uns eine Warteschlange
Beschreiben Sie die Arbeit so, wie ein Mensch sie heute macht, samt dem Schritt, in dem er etwas nachprüft. Wie viele Fälle im Monat und wie lange einer dauert. Diese beiden Zahlen und ein Tag reichen uns, um Ihnen zu sagen, was es spart.
Das Formular fragt nach Fallvolumen und Bearbeitungszeit. Diese beiden Zahlen entscheiden das meiste.