Amazon Connect und die kleine Mailbox…

Amazon Connect ist als veröffentlichter Service zwar noch relativ jung, aber definitiv nicht mehr in den Kinderschuhen. Das cloudbasierte Contact Center von Amazon etabliert sich zunehmend, was auch wir - nicht zuletzt über steigende Projektzahlen - feststellen können. Dabei besticht es unter anderem durch seine offene Plattform und hohe Integrierbarkeit.

Was fehlt - ist eine Mailbox!

Denn man vermisst gelegentlich das ein oder andere, vermeintlich selbstverständliche Feature. So war z.B. ein Kunde kürzlich ganz erstaunt, dass Amazon Connect über keine native Mailbox Funktion verfügt. Das ist korrekt, aber auch in Zeiten von Automatisierung und Self-Service wird sie noch benötigt, die gute alte Mailbox. Manchmal möchte man dem Kunden eben ganz bewusst einen persönlichen Agenten zuweisen. Und wenn dieser nicht erreichbar und auch ein Rückrufservice nicht ausreichend ist, soll der Kunde sein Anliegen loswerden können. Man kann da doch was bauen…

Der Media-Streaming Block macht es möglich

Hier kommt die angesprochene Stärke der hohen Integrierbarkeit von Amazon Connect zum Tragen. Seit Dezember 2018 kann der Audiostream des Kunden von beliebiger Stelle des Contact Flows in Echtzeit verarbeitet werden, d.h. sogar vor einem, nach einem oder gar ganz ohne ein Gespräch mit einem Agenten. Der Media-Streaming Block im Contact Flow sorgt dafür, dass der Audiostream zu Amazon Kinesis Video Streams gesendet wird und von dort aus verarbeitet werden kann. Es eröffnen sich viele interessante Möglichkeiten einen Mehrwehrt für den Kunden und unser Business zu generieren. So könnte z.B. eine KI gestützte Analyse des Datenstroms in Echtzeit durchgeführt werden. Wir müssten nur die Sprache transkribieren, um strukturierte Daten zu erhalten. Diese könnten wir dann automatisiert verschlagworten und einer Sentiment-Analyse unterziehen. Auch das Übersetzen in andere Sprachen stellt kaum ein Problem dar, AWS Services wie Transcribe, Translate und Comprehend machen es möglich. Natürlich sind ebenso Drittanbieter Lösungen integrierbar…

Je stärker die KI der Services wird, desto höher die Qualität der Ergebnisse. AWS zeigt in diesem YouTube Video (und stellt einen Deployment Guide mit Cloudformation Template zur Verfügung), was bereits heute mit den genannten Services möglich ist. Uns genügt jedoch zunächst die Möglichkeit den Kunden Audiostream zu speichern, wir erinnern uns, wir benötigen eine Mailbox.

Das Szenario, was wollen wir genau?

Unser Kunde wünscht ein individuelles Routing seiner Kunden, jeweils mit persönlichen Agenten. Jeder dieser Agenten soll seine eigene Mailbox besitzen auf die immer dann gesprochen werden kann, wenn dieser nicht erreichbar ist - eben der allgemein bekannte Grund für eine Mailbox. Die aufgezeichnete Sprachnachricht soll dauerhaft gespeichert werden und möglichst einfach durch den Agenten abrufbar sein. Natürlich soll der Agent auch automatisch über den Eingang einer Nachricht informiert werden, hier bietet sich eine E-Mail an. Weiterhin sollen lediglich AWS Services genutzt werden. An dieser Stelle ist anzumerken, dass der Userpool durch die bestehende Amazon Connect Instanz selbst verwaltet wird. Das bedeutet es existiert kein Single-Sign-On durch eine Integration anderer Lösungen, z.B. per AD oder einem CRM System. Darüber hinaus hat der Agent keinen Zugang zu dem AWS Account (kein IAM-Benutzer), in dem die Instanz liegt. Es wird weiterhin auch lediglich das Standard CCP von Amazon Connect genutzt. Wir befinden uns also noch auf der ersten Stufe der Integration. Somit sind diverse Herausforderungen zu bewältigen.

Nicht out of the box

Nun ist zwar der Media-Streaming Block in Amazon Connect verfügbar, allerdings bedeutet dies nicht, dass die Umsetzung trivial wäre – auch das gezeichnete Szenario trägt hierzu bei. Spätestens in der AWS Dokumentation merkt man und dort gibt es sogar einen expliziten Hinweis, dass mindestens grundlegende Entwicklerkenntnisse erforderlich sind. Eine kurze Wegbeschreibung bevor wir in den Genuss der Mailbox kommen:

• Konfigurieren der Amazon Connect Instanz zur Nutzung des Live Media Streamings.
• Erstellen eines Contact Flows welcher als Mailbox fungiert.
• Schreiben einer Lambda Funktion, um die Contact Attributes an den Stream zu übergeben und einen Prozess außerhalb des Contact Flows triggert.
• Einrichtung einer Job-Queue mit AWS SQS zur asynchronen Verarbeitung.
• Herausfiltern des korrekten Kunden Audiostreams aus Kinesis.
• Konvertierung und Speicherung der Sprachdaten auf S3.
• Erzeugung einer presigned URL für den Zugriff auf die Sprachnachricht.
• Benachrichtigung des Agenten via E-Mail mit AWS Simple E-Mail Service.

Konfigurieren der Instanz

Standardmäßig ist das live Media Streaming für eine Amazon Connect Instanz deaktiviert. Daher muss die Instanz entsprechend konfiguriert werden. Dies erfolgt im Bereich „Data storage“ der Instanzeinstellungen.

Per Edit für die Sektion „Live media streaming“ können wir:

1. Das Feature aktivieren.
2. Ein Präfix für den Kinesis Video Stream definieren, um diesen später wieder finden zu können. Der Stream selbst wird dann automatisch erstellt.
3. Natürlich sollen die Daten verschlüsselt werden, dazu nutzen wir den AWS eigenen Service KMS.
4. Für die Aufbewahrungsdauer der Daten im Stream wählen wir eine Stunde, damit diese ausreichend lange für die Verarbeitung erhalten bleiben und nicht unnötige Kosten verursachen.
5. Oben rechts speichern wir unsere Einstellungen für das „Live media streaming“.
6. Und nochmal (unten rechts) für den Bereich „Data storage“.

Der Mailbox Contact Flow und seine Verbündeten

Diverse Gründe sprechen dafür die Mailboxfunktion in einem separaten Contact Flow umzusetzen, an welchen der Anrufer bei Bedarf weitergeleitet wird. Z.B außerhalb der Geschäftszeiten, oder wenn er sich zu lange unbeantwortet in der Warteschleife befindet. Im Folgenden ist ein exemplarischer Flow mit den notwendigen Bausteinen dargestellt. Vorstellbar ist eine initiale Ansage, der Anruf könne aktuell leider nicht entgegen genommen werden und es solle bitte nach dem Piep-Ton auf die Mailbox gesprochen werden. Die Ansage kann über TTS mit Polly erfolgen, oder wie im Beispiel eine aufgezeichnete Ansage als Wav-Datei sein.

1. Nach der Ansage wird mit dem entsprechenden Block das Streaming gestartet und der angesprochene Piep-Ton abgespielt.
2. Aufruf einer Lambda Funktion. Sie ist essenziell und wird weiter unten erklärt.
3. Durch das Abspielen von zwei Minuten Stille als prompt, wird die Aufzeichnungsdauer der Mailbox bestimmt. Diese Variante ist nicht unbedingt elegant, mangels dynamischer Alternativen aber aktuell nicht vermeidbar. Im weiteren Verlauf wird dies noch ausführlicher kommentiert.
4. Nach zwei Minuten wird das Streaming und anschließend das Gespräch beendet (sofern der Anrufer nicht schon vorzeitig selbst aufgelegt hat).

In diesem Kundenszenario haben wir aufgrund der überschaubaren Anzahl für jeden Agenten einen eigenen Mailbox Flow erstellt. Steigt die Zahl der Agenten, so empfiehlt es sich einen zentralen Flow mit variablen Komponenten zu nutzen.

Lambda macht das schon

Die notwendigen Entwicklerkenntnisse wurden angedroht, hier werden sie nun das erste Mal benötigt. Bei dieser Lösungsvariante ergeben sich drei Herausforderungen:

1. Der Audiostream des Kunden wird an einen Kinesis Video Stream gesendet, für jeden Call wird automatisch ein eigener Stream generiert. Wir müssen also den Kundenanruf und seine Kontaktdaten (ContactData) eindeutig mit dem korrekten Stream verknüpfen, damit die Daten nicht unauffindbar im Kinesis Stream-Meer versinken.
2. Die Funktion einer Mailbox birgt in sich, dass der Anrufer seine Nachricht hinterlässt und anschließend auflegt. Unglücklicherweise wird damit auch der Contact Flow beendet und aus Amazon Connect heraus ist keine weitere Aktion mehr möglich.
3. Wer soll später die E-Mail über den Eingang einer Sprachnachricht erhalten?

Diesen Problemen begegnen wir mit der Lambda Funktion. Letzteres ist die einfachste Herausforderung – da unser Contact Flow einem bestimmten Agenten zugewiesen ist, kennen wir auch dessen E-Mail-Adresse. Wir übergeben der Lambda Funktion also beim Aufruf (ganz ungeniert hartcodiert) diese Information als Variable in den ContactData im Event:

Auch unser erstes Problem können wir über die ContactData an Lambda auslagern. Sie werden im Event standardmäßig beim Aufruf einer Funktion übergeben. Erfreulicherweise hat auch der Start-Media-Streaming-Block hier relevante Informationen hinterlegt.

Über das Event stehen uns in Lambda folgende Informationen zur Verfügung:

Verwertung im Code

Im Code müssen wir diese jetzt nur noch geschickt verwerten. Bleibt noch das zweite Problem. Wir haben den Stream konfiguriert die Daten für eine Stunde vorzuhalten und müssen diese zu einer Audiodatei konvertieren und speichern, sowie den Besitzer der Mailbox über den Eingang der Nachricht informieren. Da wir nicht wissen wann der Anrufer aufgelegt und damit ebenfalls unseren Contact Flow in Amazon Connect beendet hat, müssen wir den Verarbeitungsprozess auslagern. Sicherlich gibt es auch hier mehrere Lösungsvarianten, jedoch bietet sich unsere Lambda Funktion geradezu an. Ebenso kommt einem beim Thema der asynchronen Verarbeitung recht schnell der Service AWS SQS in den Sinn. Den letzten Dienst kann uns unsere Lambda Funktion also erweisen, indem sie die relevanten Daten als Message in eine SQS Queue sendet. Dabei geben wir der Message aber eine Verzögerung von etwas mehr als zwei Minuten mit, damit SQS den Auftrag erst nach Ablauf dieser bearbeitet (wir erinnern uns, dass Lambda zu Beginn des Streamings gestartet wird, der Anrufer aber bis zu zwei Minuten Sprechzeit haben kann).

Der Job ist noch nicht beendet

Die Konfiguration einer SQS Queue ist nahezu intuitiv. Wir bedienen uns der Standard-Variante mit einer ausreichenden Zeit für die „Visibility Timeout“. Hierdurch wird garantiert, dass die Message mindestens einmal – idealerweise aber auch nicht öfter – verarbeitet wird. Der SQS Service speichert sie bis dahin mehrfach redundant.

Nur wer übernimmt nun die Aufgabe der Verarbeitung? Wie wäre es mit Lambda als Consumer?

In der bereits angesprochenen AWS Dokumentation zum Media Streaming aus Amazon Connect wird ein guter Einstieg mit Code-Beispielen zur Audioverarbeitung geliefert. Siehe dazu: How to Access Kinesis Video Stream Data

Sobald konvertiert, muss die Audiodatei nun noch persistiert werden, dazu prädestiniert ist dann S3. Im Account unseres Kunden haben wir einen separaten Bucket erstellt. Der Zugriff ist nach Best Practice natürlich nicht öffentlich und die Daten im Bucket sind per AES-256 verschlüsselt. Die relevanten Informationen (siehe oben) des Anrufs, wie ContactId, Telefonnummer, oder auch die E-Mail-Adresse des Agenten wurden mit Lambda an das erstellte S3 Objekt als Metadaten übergeben.

Wir stehen kurz vor dem Ziel, jetzt muss nur noch der Agent benachrichtigt werden. Dazu bedienen wir uns erneut einer Lambda Funktion. Diese erhält als Trigger das S3 Event ObjectCreatedByPut. Somit wird diese Lambda Funktion immer dann ausgeführt, wenn im entsprechenden Bucket, bzw. Unterordner ein S3 Objekt erstellt wird, also immer dann, wenn eine neue Sprachnachricht fertig abgespeichert wurde. Mit den Informationen aus diesem Event und den Metadaten des Objekts genügen ein paar Zeilen Code um automatisiert via AWS SES (Simple-E-Mail-Service) eine E-Mail an den Agenten zu versenden. Damit dieser bequem auf die Sprachnachricht zugreifen kann, erzeugt die Lambda Funktion zuvor noch eine PreSigned-URL für das Objekt und fügt sie in den E-Mail Text mit ein.

Die PreSigned-URL ist notwendig, da weder der Agent Zugriff auf den AWS Account besitzt noch der S3 Bucket und die enthaltenen Objekte frei zugänglich sind. Nun kann der Agent mit einem Klick auf den Link in der E-Mail die Sprachnachricht abhören bzw. herunterladen. Damit die PreSigned-URL ihre maximale Gültigkeit von sieben Tagen bekommt, müssen beim Erzeugen die Credentials eines programmatischen IAM-Users verwendet werden.

Fazit

Am Ziel angekommen blicken wir zurück und stellen fest, dass wir auf unserem Weg den ein oder anderen Kompromiss eingegangen sind. So ist die vordefinierte Aufzeichnungsdauer natürlich nicht optimal, insgesamt aber zu verkraften, zumal die spätere Sprachnachricht bei der Konvertierung auf die korrekte Länge gekürzt wird. Dem Kundenszenario, bzw. der bislang noch niedrigen Integrationsstufe ist geschuldet, dass wir uns einer PreSigned-URL für den Zugriff auf S3 bedient haben. Diese ist per programmatischen User (was uns ebenfalls nicht überaus glücklich macht) erzeugt, maximal sieben Tage gültig. Ist der Agent länger abwesend, z.B. bei Urlaub ist die Nachricht zwar nicht weg, aber es müsste entweder eine neue PreSigned-URL erzeugt, oder das Objekt manuell (mit Zugriff auf den AWS Account) aus dem S3 Bucket gesucht werden. Bei einer höheren Integrationsstufe der Kundenumgebung mit AWS könnte man z.B. ein Single-Sign-On Szenario realisieren. Damit können dem Agenten Zugriffsberechtigungen im AWS Account erteilt werden und die PreSigned-URL wäre überflüssig. Zusätzlich bräuchte sich der Agent wie gewohnt, dann auch nur noch einmalig in seiner Kundenumgebung anmelden. Mit einem individuell angepasstem CCP könnte man dem Agenten die Sprachnachrichten auf seiner Mailbox sogar ganz komfortabel bereitstellen.

Denkbar ist auch eine automatisierte Verarbeitung der Sprachnachrichten auf S3. Wie wäre es per Batch-Job die Sprache zu transkribieren, auf Schlagworte und Sentiment zu analysieren und damit vielleicht das Abhören ganz überflüssig zu machen? Man könnte sogar bereits beim Anrufer ansetzen und dessen Anliegen mit gut ausgefeilten Sprach-Bots automatisiert – quasi als Selfservice – bedienen.

Aber hey, wir wollten ja eine persönliche Mailbox! Schade dass diese bisher nicht zum Standardrepertoire gehört, aber dank der hohen Integrierbarkeit von Amazon Connect, haben wir für unser Kundenszenario nun eine gute, verlässliche und automatisierte Mailbox.

Credits

Photo by Mikaela Wiedenhoff on Unsplash