Erfahrung mit Entwicklung einer Low-Code-Plattform Drag & Drop Development im Contact Center

Anbieter zum Thema

Hyland Software Germany GmbH

Mendix GmbH

Cloudgermany.de GmbH

Low-Code zu programmieren ist das eine, unbescholtene Benutzer ohne Programmiererfahrung in die Position eines Low-Code Users oder Citizen Developer zu versetzen das andere. Genau das versucht das Team von ilogixx.

Mit myContactCenter entwickeln wir eine Software für Contact Center und für den Kundendienst. Da ein solches Kontaktzentrum weit mehr Kommunikationswege anbietet als ein Callcenter, muss die Software Anrufe, Chats, E-Mails und Faxen intelligent verteilen, sich an Datenbanken bedienen und andere Applikationen steuern können.

Die Low-Code-Plattform basiert dabei auf sogenannten Skills und Sprachfähigkeiten der Agenten. Jeder Skill hat eine ACD, eine Automatic Contact Distribution. Die ACD ist per Anruf, Chat, Mail und Fax für Anfragende erreichbar. Jede ACD besitzt ihre eigene Logik und ihren eigenen Ablauf, bei uns Flow genannt.

Bildergalerie

Unser System wollten wir nun so weiterentwickeln, dass Anwender völlig ohne Coding-Kenntnisse per Drag and Drop Fälle und Ereignisse eingeben und damit den Flow ohne externe Hilfe verändern können.

Low-Code für User ohne Coding-Kenntnisse

Als Beispiel dient eine Begrüßungsansage, die bei Anrufen läuft – viele Punkte verfeinern die Begrüßung und legen den Flow fest: Läuft Musik im Hintergrund? Kommen kombiniert Daten aus Datenbanken zum Einsatz? Wenn ja, wie werden diese verarbeitet? Es existieren so viele Flows wie Fälle. Und je differenzierter die Flows, desto zufriedener der Verbraucher.

Wonach wir also suchten, war eine Lösung, die auch Nutzern ohne jegliche Coding-Kenntnisse und Geduld Eigenständigkeit für das Einrichten eigener Flows überlässt. Das bewog uns dazu einen Low-Code-Ansatz zu verfolgen.

Erfahrungswerte

In den vergangenen Jahren sammelten wir viel Erfahrung, wozu Verantwortliche im Kundendienst oder im Contactcenter in der Lage sind und wozu nicht. Wir analysierten, was verschiedene Anbieter von Private-Branch-Exchange-Systemen im Bereich Flow-Design (Programmierung) anbieten, um den Ablauf eines Anrufes festzulegen: So erstellte bei einem Modell ein Art Designer aus der grafischen Darstellung VBScript (im Folgenden: VB Script) oder ähnliches und entsprach somit keiner echten Domänenspezifischen Sprache (Domain Specific Language, DSL).

Jeder Block brachte seinen Quellcode als VB Script selber mit und wurde anschließend weder kompiliert noch syntaktisch geprüft – eine Eignung als No-Code war damit ausgeschlossen. Andere Low-Code Systeme wiederum erschienen uns als viel zu zu komplex, um das gewünschte Ziel einer schnellen, einfachen Erstellung zu erreichen. Ebenso häufig beobachteten wir bei vergleichbaren Systemen das Fehlen einer Ereignissteuerung.

Ereignissteuerung: ja oder nein?

Viele Systeme sehen von Ereignissteuerung ab, was zu einer gewissen Schwerfälligkeit führt. Zusätzlich verbrauchen Polling und Interpreter viel Ressourcen. Der Grund für den Verzicht liegt auf der Hand: Kunden können mit einer Ereignissteuerung häufig nicht umgehen. 90 Prozent nutzt Standardfälle – was in der Telefonie bedeutet: Startblock, Wartefeldblock, Übermittlung an Agenten. Weiterhin beliebt sind Begrüßung und Wartemusik.

Weil Ereignissteuerung jedoch Arbeit erleichtern und Ressourcen schonen kann, wollten wir sie dennoch unbedingt integrieren. Um Kunden nicht zu überfordern, sollten möglichst viele Standardfälle ohne Ereignisse abbildbar sein: Sie sollten wählen können, ob sie Standard oder Premium fahren. Das warf Fragen auf: Welche Ereignisse brauchen wir? Mit wie vielen Ereignissen können Kunden umgehen?

Low-Code-Implementierung: Anforderungen ans Programmieren

Aus dem Wunsch des Low-Code-Ansatzes entsprangen folgende Anforderungen an die zu erstellende Low-Code-Implementierung fürs Flow Design:

• 1. Alle verschiedenen Abläufe für alle verfügbaren Kommunikationskanäle (Anruf, Chat, Mail, Fax, Social Media, Dokumente, etc.) müssen aus Gründen der Nachvollziehbar- und Wiederholbarkeit mit genau den gleichen Mitteln erstellbar sein.

• 2. 95 Prozent aller Kundenanforderungen müssen in No-Code abbildbar sein

• 3. Aus dem grafischen Ablauf muss ein ausführbares Assembly entstehen, welches auf beliebigen Plattformen ausführbar ist

• 4. Sowohl synchrone als auch asynchrone Operationen müssen laufen

• 5. Jede Operation benötigt ein eigenes graphisches Element

• 6. Ereignisse müssen als Blöcke verfügbar sein

• 7. Linien müssen alle Elemente miteinander verbinden, um flexibel die Reihenfolge festlegen zu können

• 8. Unmittelbare Fehleranzeige unterstützt den Nutzer beim selbstständigen Festlegen von Flows

• 9. Ein in C# darstellbarer Code soll entstehen

• 10. Mit einzelnen Blöcken sollen externe Dienste wie beispielsweise Microsoft Cognitive Services nutzbar sein

• 11. Mit einzelnen Blöcken muss auf Datenbanken/Web Services wie MSSQL zugegriffen werden können

• 12. Daten müssen stark typisiert sein, um Fehler durch implizite Typkonvertierungen zu vermeiden

• 13. Die dynamische Codeerstellung/Kompilierung (via Roslyn) soll mit Standardmitteln ermöglicht werden

Ergebnis: grafische DSL

Aus diesen Anforderungen schufen wir als Ergebnis eine grafische Domain Specific Language. Sie endet in einer direkt in .NET ausführbaren Softwarekomponente, die wir innerhalb eines unserer Dienste ausführen. Die einzelnen Blöcke erzeugen direkt keinen Code, sondern stehen für eine im Funktionsgraphen abgebildete Funktion. Das war es, wonach wir strebten: nach direkt Ausführbarem.

Da wir aus der Microsoft-Dotnet-Welt kommen, wussten wir, dass wir aus der grafischen Oberfläche ein .NET Assembly erstellen wollten. Hier griffen wir auf Roslyn zurück. Mit Roslyn können wir sowohl den dynamischen Code und den Graph erstellen als auch das Assembly oder die C# Darstellung. Das bedeutet: Das gesamte Tooling liegt vollständig vor und die Flows funktionieren auf jeder Plattform. Der Strang lautet:

Grafisches Design -> Roslyn -> Graph der Applikation -> Roslyn -> Assembly oder C#-Darstellung

Nutzen per Drag and Drop

Wir entwarfen das System so, dass User Standardfälle auch ohne Ereignisorientierung bedienen können. Die Design-Blöcke, die Ereignisse darstellen, weisen keinen Eingang auf, lassen sich also nicht mit einer Linie aus einem Ausgang eines anderen Blockes verbinden, sondern bilden einen separaten Startpunkt in der grafischen Darstellung. Das ermöglicht sofortiges Ausführen ohne Wartezeit bei Eintreten des Ereignisses – wie beispielsweise der Statuswechsel einer Konversation von Warten auf Klingeln.

Weitere, eher Contact-Center-spezifische Vereinfachungen wie Medienauswahl oder Auswahl von Textbausteinen reduzieren die Anzahl an Blöcken erheblich. So ist zum Beispiel die Medienverwaltung intelligent genug, um automatisch passende Ansagen/Textbausteine anhand eines definierten Medientyps, der Sprache und dem Skill aus dem Medienpool zu laden.

Begrüßung, Warteansage oder Empfangsbestätigung dienen hier als Beispiel. Nutzer müssen keine Fallunterscheidung nach Skill oder Sprache treffen, sondern lediglich einen grafischen Block „Medienwiedergabe“ für die Begrüßung ins Leben rufen. Für jede Kombination aus Skill und jede Sprache spielt das System dann die korrekte Ansage ab.

Die Blöcke bergen also eine integrierte Logik, was das Programmieren für uns komplex, das Bedienen für Nutzer aber einfach macht. Der eigentliche Flow bleibt übersichtlich, weil die Darstellung auf Fallunterscheidungen verzichtet und das Wesentliche ins Sichtbare hebt.

* Christian Becker ist Gründer, Geschäftsführer und kreativer Kopf von ilogixx. Herzstück des Trierer Technologieunternehmens ist die eigenentwickelte Contact-Center-Software myContactCenter. Seit fünfzehn Jahren sammelt Becker Erfahrung im Bereich Business-Kommunikation.

(ID:46674966)