Call Center Service “Amazon Connect” mit Lambda Integration - Alles möglich?

This content is more than 4 years old and the cloud moves fast so some information may be slightly out of date.

Call Center Service “Amazon Connect” mit Lambda Integration

Connect ist der neue Service von AWS, in dem man einfach in der Cloud ein Call Center mit eigener Rufnummer erstellen kann. Mit einer grafischen Oberfläche kann man dann mit wenig Programmierkenntnissen eigene telefonische Abläufe erstellen, Anrufe auf S3 aufzeichnen, Statistik über Cloudwatch machen usw..

Alle telefonischen Agenten können vollständig mit einem Browser und Rechner ohne Telefonanschluss arbeiten. Hier stellen wir im Beispiel, vor wie Connect mit eigenen Lambda Funktionen zusammenarbeitet.

Dabei kann komplett dynamische Abläufe in der Anrufbehandlung erstellen. In Kürze wird dies mit Amazon lex auch mit tatsächlicher natürlicher Sprachsteuerung, also gesprochene Wörter möglich sein. Im Moment muss man immer noch auf Tastendrücke zurückgreifen.

In kurzer Zeit kann man Call Funktionen wie folgende in der Cloud realisieren: Ein Anrufer mit Basis Support im Beispiel:

Contact Flows in Connect

Innerhalb von Connect wird der Anrufen durch Contact Flows geführt. Diese ermöglichen z.B. Zuweisung von Anrufern zu Agenten nach bestimmten Eingaben. Für komplexe Abläufe kann man Eingaben, die der Anrufen über das Telefon macht an Lambda Funktionen weiterleiten. Hier können dann komplexe Abfragen durchgeführt werden.

Anwendungsfall

Im Beispiel gibt der Kunde seine Kontonummer ein. In der Simulation ermittelt lambda aus der Kontonummer den Supportlevel. Der Rückgabewert steuert dann die weiteren Ansagen. In einem echten Szenario könnte man dann den Kunden je nach Support an verschiedene Bearbeiter weiterleiten.

Realisierung in der Übersicht

 

  1. Callcenter mit Connect aufbauen
  2. Deutsche Einwahlnummer claimen
  3. Eigenen Contact Flow erstellen
  4. Lambda Funktion erstellen
  5. Test

Voraussetzung

 

  1. AWS Account - eine Anleitung zu Erstellung eines AWS Account kann man hier finden.
  2. Installiertes node, Node kann über die Node Webseite runtergeladen werden.
  3. Installiertes serverless Framework, siehe Serverless Webseite
  4. AWS Credentials für Serverless einrichten, siehe Serverless Dokumentation

Callcenter mit Connect aufbauen

Connect versteckt sich in der AWS Console unter dem Punkt “Call Center:

Unter der Funktion “Claim a Number” kann man für DID “Direct Inward Dailing” einfach eine deusche Einwahlnummer bekommen. Für diese Einwahlnummer kann man nun Contact Flow verbinden. Wir bauen hier im Beispiel einen eigenen Contact Flow. Zuerst sollte man die Sprache mit Set Voice auf Deutsch stellen.

Beide deutschen Stimmen von Amazon Polly stehen zur Verfügung. Auch eine Sprachweiche könnte man dazu erstellen. Groß Danach kann man eine Ansage in der gewählten Sprache mit Play prompt ausgeben.

Jetzt könnte man schon eine Lambda Funktion bauen, die mit der Einwahlrufnummer Berechnungen durchführt. In unserem Beispiel wird zuerst eine vierstellige Kontonummer mit “Store Customer Input” eingegeben: groß

Der Input wird auf 4 Ziffern begrenzt, die der Kunde mit der Telefontasten eingibt.Bild.

Aufruf der Lambda Funktion

Die Eingabe wird dann in eine Lambda Funktion übergeben. Dazu stellt man unter key ein, wie der Parameter heißt, den Lambda dann als Input bekommt. Im Beispiel wird account innerhalb der Lambda Eingangsdatenstruktur als Parameter übergeben:

     "Parameters": {
                "account": "5678"
            }

In der Funktion ARN wird die ARN der Lambda Funktion eingetragen. Lambda gibt dann als servicelevel einen “berechneten String zurück:

      if( account == "5678"){
        level = "premium";
      };

      callback(null, { servicelevel : level });

In dem Contact Flow kann dann eine Weiche entsprechend dem Lambda Rückgabewert eingebaut werden:

Im einfachsten Fall verweist man auf verschiedene Ansagen.

Lambda Funktion mit Serverless einfach erstellen

Jetzt muss man noch eine Lambda Funktion erstellen, die die eigentliche Berechnung macht. Mit den beiden Dateien im Anhang kann die Lambda Funktion mit einer Kommandozeile erzeugt werden:

    sls deploy

Dabei ist sls die Abkürzung für Serverless. Die ARN der erzeugten Funktion wird wie oben beschrieben im Connect eingetragen.

    'use strict';
    module.exports.hello = (event, context, callback) => {
      var account = event.Details.Parameters.account;
      var level = 'none';
      if( account == "1234"){
        level = 'basis';
      };
      if( account == "5678"){
        level = "premium";
      };

      callback(null, { servicelevel : level });

    };

Die Lambda Funktion besteht aus wenigen Zeilen: Aus der Eingabe in _event _wird die Nummer aus account ausgelesen. Ein “berechneter” Wert wird dann als servicelevel zurückgegeben. Durch den ersten Parameterwert null im Callback wird die fehlerfreie Ausführung angezeigt. Um zu wissen, welche Struktur die Eingabe Json hat, empfiehlt es sich, zuerst ein _console.log(JSON.stringify(event))  _einzubauen. Mit der im cloudwatch log ausgegebenen Struktur kann man dann weiter entwickeln.

Serverless Konfiguration

Bei der serverless Konfiguration haben wir ein kleines Henne Ei Problem: Zuerst muss die Lambda Funktion “_connect-supportlevel-dev-hello” _erzeugt werden, damit die LambdaInvokePermission keinen Fehler wirft.

Diese lambda function policy ist notwendig, damit der connect service mit dem principal connect.amazonaws.com diese Lambda Funktion aufrufen darf.

Daher muss man die Zeilen 16-24 vor dem ersten _sls deploy a_uskommentieren (mit “#”) , dann wieder einkommentieren und sls deploy erneut ausführen. Das geht natürlich auch noch eleganter.  

Weitere Einsatzmöglichkeiten

Durch Lambda hat man Zugriff auf alle möglichen Szenarien, auch im Backend. Denkbar sind unter anderem:

  • Sprachausgabe eines Status, z.B. von Bestellungen
  • Ermitteln der Kundendokumente, während der Kunde sich noch ein paar Sätze anhört
  • Runterfahren von EC2 Instanzen sprachbasiert (gesehen auf einem chinesischem Blog!)

Was sind Ihre Ideen für die Einsatzgebiete?

Anhang:

Dateien:

Die Node Funktion: handler Serverless Konfiguration:

    service: connect-supportlevel 

    provider:
      name: aws
      runtime: nodejs4.3
      stage: dev
      region: us-east-1
      ## Hier Account ID einsetzen
      account: 12345678

    functions:
      hello:
        handler: handler.hello

    resources:  
      Resources:
        LambdaInvokePermission: 
          Type: "AWS::Lambda::Permission"
          Properties: 
            FunctionName: "connect-supportlevel-dev-hello"
            Action: "lambda:InvokeFunction"
            Principal: "connect.amazonaws.com"
            SourceAccount: 
              Ref: "AWS::AccountId"

Lambda Funktion Policy:

    {
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": \[
    {
    "Sid": "connect-supportlevel-dev-LambdaInvokePermission-xxxxxxx",
    "Effect": "Allow",
    "Principal": {
    "Service": "connect.amazonaws.com"
    },
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:us-east-1:xxxx:function:connect-supportlevel-dev-hello",
    "Condition": {
    "StringEquals": {
    "AWS:SourceAccount": "xxxxxxx"
    }
    }
    }
    \]
    }

Similar Posts You Might Enjoy

Dissecting Serverless Stacks (IV)

Dissecting Serverless Stacks (IV) After we figured out how to implement a sls command line option to switch between the usual behaviour and a way to conditionally omit IAM in our deployments, we will get deeper into it and build a small hack on how we could hand over all artefacts of our project to somebody who does not even know SLS at all. - by Thomas Heinen

Dissecting Serverless Stacks (III)

Dissecting Serverless Stacks (III) The third post of this series showed how to make IAM statements an external file, so we can deploy that one but still work with the sls command. It still involved commenting out things in the configuration, so this post will show how to solve that issue. - by Thomas Heinen

Dissecting Serverless Stacks (II)

Dissecting Serverless Stacks (II) With the output of the last post of this series, we established the base to be able to deliver a Serverless application independent of its needed IAM privileges. So let’s see how this will work out. - by Thomas Heinen