Kann der Agent die Lieferadresse ändern?

Stellen Sie sich eine Kundin vor, die ihre Lieferadresse ändern möchte, bevor das Paket versandt wird. Gehört die Bestellung wirklich zu ihr? Ist die Änderung noch möglich? Und steht danach die richtige Adresse im Bestellsystem? An diesem kleinen Beispiel lässt sich ein Agent gut prüfen. Am Ende brauchen Sie entweder eine bestätigte Änderung oder einen offenen Fall, den das Serviceteam übernommen hat. Die freundliche Zusage im Chat allein genügt nicht.

Beschreiben Sie diesen Auftrag, bevor der Anbieter die Vorführung vorbereitet. Halten Sie getrennt fest, was der Agent mitteilen, was er ändern und was er nicht tun darf. Die Erlaubnis zur Adresskorrektur umfasst in unserem Beispiel weder Stornierung noch Erstattung. Für die erste Vorführung können Sie freigegebene Testkonten und erfundene Bestellungen verwenden. Echte Kundendaten sind dafür nicht nötig.

Cognigy beschreibt Anschlüsse an bestehende Contact-Center-Plattformen, CRM und Ticketsysteme. Druid nennt außerdem RPA-Brücken für ältere oder proprietäre Anwendungen.^1,2,3

Lassen Sie jeden Anbieter dieselben Schritte zeigen: Bestellung finden, Versandstatus lesen, Änderung anfordern und die gespeicherte Adresse erneut aufrufen. Schreiben Sie dazu, welches System handelt, welches Konto sich anmeldet und welche Arbeit das Angebot abdeckt. So wird aus einer langen Anschlussliste eine konkrete Antwort. Ein Lesezugriff kann den Versandstatus liefern, ohne eine Adressänderung zu erlauben.

Dann wird es interessant: Die Änderungsanfrage läuft in eine Zeitüberschreitung. Vielleicht hat das Bestellsystem die neue Adresse trotzdem gespeichert. Lassen Sie zeigen, wie der Agent das herausfindet, bevor er den Auftrag erneut sendet. „Anfrage abgeschickt“ ist noch kein Erfolg. Entweder ist die Änderung bestätigt, oder der Vorgang bleibt erkennbar offen, bis jemand den tatsächlichen Stand klärt.

Cognigy beschreibt simulierte Gespräche vor dem Start und nach Änderungen. Der Simulator kann auch fehlerhafte Antworten angeschlossener Systeme nachbilden.^4,5

Nehmen Sie Varianten aus dem Servicealltag, aber übernehmen Sie keine echten personenbezogenen Daten. Eine Kundin nennt eine fremde Bestellnummer, korrigiert die Adresse während der Bearbeitung oder möchte zusätzlich eine Kulanzleistung. Entscheiden Sie vor der Vorführung, wann der Agent nachfragen, ablehnen oder einen Menschen hinzuziehen soll. Schauen Sie getrennt auf seine Formulierungen, seine Handlungen und den gespeicherten Datensatz. Eine angenehme Antwort kann einen falschen Eintrag nicht ausgleichen.

Alle Anbieter bekommen dieselben erwarteten Ergebnisse. Lassen Sie Ihr Serviceteam außerdem eine zusätzliche Variante einbringen. Daran können Sie prüfen, ob die Lösung den vereinbarten Auftrag erfüllt oder nur den vorbereiteten Dialog beherrscht. Halten Sie offene Punkte als solche fest, bis ein Beleg vorliegt und die zuständige Person ihn akzeptiert. Eine nicht gezeigte Funktion ist weder bestanden noch erwiesenermaßen unmöglich.

Nexus beschreibt den gemeinsamen Aufbau des ersten Ablaufs mit dem Kundenteam. Wonderful beschreibt den späteren Übergang zur Verantwortung des Kunden.^6,7

Führen Sie je Anbieter ein einfaches Blatt: Fallvariante, erwartetes Ergebnis, gezeigtes Ergebnis, Beleg, offene Frage und zuständige Person. Ergänzen Sie, was Ihr Team beim Aufbau und später im Betrieb tun muss. Eine Beispielzeile könnte lauten: „Schon versandt; Adresse bleibt unverändert; Ticket an Versandservice; Beleg: Ticketkennung und gespeicherte Adresse.“ Das ist eine vorgeschlagene Abnahmeregel, kein Ergebnis eines Tests von Werkbank KI.

Wählen Sie danach aus, welche Bedingungen unbedingt erfüllt sein müssen. Wenn die Bestellung nicht sicher zum Kunden zugeordnet wird, helfen weitere Kanäle nicht weiter. Dasselbe gilt für eine Änderung, deren Ausgang nach einem Fehler ungeklärt bleibt. Behalten Sie einen Gegenkandidaten, der die offene Frage anders angeht, etwa durch einen vorhandenen Contact-Center-Anschluss oder eine andere Aufteilung der Arbeit beim Aufbau.