Wie wir einen Microservice auf Camunda für ein Callcenter gemacht und die Conversion verdoppelt haben

Hallo, mein Name ist Alexey, ich bin für den digitalen Vertrieb einer der größten Regionalbanken unseres Landes verantwortlich. Das Besondere an meiner Arbeit ist, dass sowohl Business als auch IT unter meinen Fittichen konzentriert sind. Deshalb werde ich Ihnen heute erzählen, wie wir mit Hilfe technischer Lösungen die Grundbedürfnisse des Geschäfts gelöst haben, oder besser gesagt, wie wir ein System zum Überwachen und Navigieren von Anrufen auf einer kostenlosen Engine entwickelt und gleichzeitig die Konversion erhöht haben reduzierte Kosten.

Alexej Averin

Entwicklungsdirektor für digitale Kanäle bei der Sinara Bank. Gemeinsame Erfahrung mit Netology

Warum brauchen wir ein eigenes System?

Früher nutzte die Bank, in der ich arbeite, nur ein internes Callcenter. Da damals der Anteil der Kunden, die über digitale Kanäle kamen, gering war, reichte ein solches Zentrum aus, um den heutigen Kundenstamm zu bedienen.

Aber im Laufe der Zeit erschienen neue Produkte. Mit dem Wachstum der Zahl der Kreditanträge entschied sich die Bank, das interne Call Center nicht auszubauen, sondern externe Outsourcer (im Folgenden VCC genannt) mit der Bearbeitung von Anträgen zu verbinden. Für seine Zentrale fallen Kosten für Anstellung, Schulung, Arbeitsplatzausstattung, Telefonie und Personal an.

Die Integration mit einem externen Auftragnehmer war 2,5-mal günstiger.

Also verbanden wir zuerst zwei Call Center und dann zwei weitere. Wir haben VCC integriert, indem wir Anrufe über die Avaya-Telefonie ausgetauscht haben, die bereits in der Bank installiert war. Das interne Zentrum arbeitete mit dem alten Kundenstamm, da sie Zugriff auf alle persönlichen Daten hatten. Und VKTS arbeitete mit neuen Kunden.

Der Kunde füllte einen Antrag auf unserer Website oder der Zielseite unseres Partners aus, woraufhin der Antrag in unserem CRM landete. In den meisten Fällen verfügte die Bank nicht über genügend Daten, um sich für eine Zusammenarbeit zu entscheiden, dh der Kundenfragebogen musste ausgefüllt werden. Wenden Sie sich dazu an den Auftraggeber und fordern Sie die fehlenden Informationen bei ihm an. All dies wurde in der Anfangsphase manuell und bereits im Nachhinein überwacht: So viel kam der Antrag, so viel kam das Ergebnis, und Zwischenstände wurden nicht überwacht. Damals gab es noch keine einheitliche Statusbasis für Bewerbungen. Nach ca. 4 Monaten Nutzung des Systems verdreifachte sich die Zahl der Bewerbungen erneut, VCC erhöhte die Zahl der Operatoren.

Anhand von Downloads von Avaya wurde allen klar, dass die Implementierung ineffizient war und alle Indikatoren deutlich verbessert werden konnten.

Die Hauptprobleme, mit denen wir konfrontiert waren:

  • Nur eines von vier Callcentern konnte einen Kreditantrag entgegennehmen. Er unternahm darauf innerhalb von 3–5 Tagen bis zu vier Wählversuche, danach schickte er das Ergebnis an die Bank zurück.

  • Die VCC selbst vermittelte Anrufe innerhalb ihres Systems und ermittelte die Rückrufzeit zum Kunden. Aus diesem Grund kam es zu Ausfällen: Niemand bestimmte die Zeitzone des Kunden, sodass die Operatoren zu einem ungünstigen Zeitpunkt anrufen konnten.

  • In der Regel arbeitete nur ein Operator mit dem Kunden zusammen.

  • Ein bestimmter VKC hat eine Anwendung in Arbeit genommen und damit „von und bis“ gearbeitet. Aus diesem Grund kam es zu Ausfällen. Angenommen, das erste Callcenter nahm die Anfrage entgegen und begann mit dem Ausfüllen der Daten, aber der Anruf schlug fehl. Und da alle Operatoren an diesem VCC beschäftigt sind, stellt sich die Anwendung in die Schlange, der Anruf wird verschoben. In anderen CCs können Operatoren frei sein, aber sie können diese Arbeit nicht annehmen. Oder der Antrag ist vollständig ausgefüllt, der Kredit wird genehmigt, aber der Kunde muss das Einkommen bestätigen, eine Bescheinigung mitbringen. Der Client stellt sich wieder in dieser VCC ein, und der andere kann Ressourcen haben, aber sie sind nicht beteiligt.

  • Manchmal war es nicht notwendig, zusätzlich mit dem Kunden zu kommunizieren – wenn er den Antrag selbst ausfüllte. Aber das VCC wusste nichts davon und rief weiter an.

  • Das VCC nahm einen Kreditantrag in die Arbeit auf und konnte den Kunden 10 Mal anrufen und ihn einmal anrufen. Wir sahen, was im Zentrum passierte, und konnten die Qualität der Arbeit nicht kontrollieren: wie die Telefonisten anrufen, wie viel sie reden und so weiter.

Was wir haben wollten

Basierend auf den Ergebnissen der identifizierten Probleme entschieden wir uns, einen Microservice zu implementieren, der es uns ermöglichen würde, alle Anrufe zwischen Call Centern zu verwalten: Führen Sie das richtige Routing durch, erhalten Sie vollständige Analysen und verwalten Sie die Warteschlange.

Die zweite Aufgabe des Microservice ist die vollständige Integration mit API-Callcentern. Wir wollten vollständige Statistiken sehen, Anrufergebnisse online erhalten und die Arbeit jedes Operators und Call Centers analysieren.

Wie wir einen Microservice erstellt und implementiert haben

Alle VCCs verwenden Naumen in ihrer Arbeit. Für den Microservice haben wir ein Team aus Analysten und Business-Analysten, Java-Entwicklern, Python-Entwicklern und Testern zusammengestellt – insgesamt 14 Personen.

Der Microservice wurde in Java mit Spring Boot entwickelt. Camunda wurde als Engine für die Verarbeitung von Geschäftsprozessen verwendet, die auf bpmn entwickelt wurden. Integrationen wurden durch Implementierung der REST-API durchgeführt. Die Dokumentation wurde mit Swagger erstellt.

Durch die Verwendung von Camunda konnten wir den Zeitaufwand für Änderungen am Geschäftsprozess erheblich reduzieren – wir beschleunigten dreimal.

Bisher wurde all dies in Code implementiert und durchlief alle drei Phasen: Analyse, Entwicklung, Test. Jetzt haben die Analysten selbst ein Toolkit zum Bearbeiten erhalten – Camunda Modeler. Mit seiner Hilfe ist für die meisten Aufgaben, wenn auch nicht für alle, die Notwendigkeit verschwunden, Entwickler anzuziehen.

Warum Camunda:

  • Es ist kostenlos.

  • Es hat eine große und entwickelte Community, sodass es einfach ist, Antworten auf Fragen zu erhalten oder zu finden.

  • Das Vorhandensein einer GUI, in der Sie sehen können, wie der Prozess Schritt für Schritt verlief.

  • Unterstützung für Postgre als Datenbank.

Darüber hinaus verzeichneten wir insgesamt einen Rückgang der Anzahl von Fehlern im System. Fehler traten in der Phase auf, die mit der Übertragung eines Geschäftsprozesses in Code verbunden war. Diese Phase verschwand einfach und der Prozess selbst wurde in der von Camunda durchgeführten bpmn-Notation implementiert. Wir haben Business Analysten Wissen über Variablen im Rahmen der Ausführung der Camund-Engine vermittelt, damit sie bedingt verstehen, welche Variablen welche Werte speichern. Infolgedessen konnten wir den gesamten Prozess für Geschäftsanalysten schließen, Systemanalysten und Entwickler daraus entfernen und letztere nur in Fällen einbeziehen, in denen es erforderlich ist, fehlende Werte zum Kontext hinzuzufügen.

Was wir tatsächlich als Ergebnis getan haben: Wir haben begonnen, DMN innerhalb bestehender bpmn-Prozesse zu verwenden, die von Camunda ausgeführt werden, und camunda-engine-dmn-Inside-Services, für die das Aufrufen des gesamten Camunda überflüssig wäre.

Als netter Bonus einer solchen Lösung ist es möglich, Änderungen am Prozess vorzunehmen, ohne dass Anwendungen neu erstellt und angehalten werden müssen. Sie können mit der Rest-API Camunda neue Schemata direkt online hochladen.

Die Fertigstellung dauerte drei Monate. Der Microservice berücksichtigte schließlich die folgenden Parameter:

  • die Anzahl freier Betreiber auf der VCC-Seite,

  • die Anzahl der Anrufe in der Warteschleife und die Auslastung des VCC,

  • Zeitzone des Kunden,

  • Online-Statusaustausch zwischen der Bank und allen VCCs.

Welches Ergebnis haben wir bekommen und was wollten wir später

Wir haben alle großen anfänglichen Schmerzen abgedeckt. Folgendes ist passiert:

  • Auf Wunsch eines Kunden generiert die Bank die erforderliche Anzahl von Anrufen und stellt sie in die allgemeine Warteschlange. Verschiedene VCCs nehmen Arbeitsanrufe entgegen und senden ein Ergebnis für jeden getätigten Anruf zurück.

  • Die Bank disponiert Anrufe zum richtigen Zeitpunkt, bestimmt die Zeitzone des Kunden eindeutig und schließt Fälle von Anrufen aus, die zeitlich nicht akzeptabel sind.

  • Der Anruf fällt in die Arbeit verschiedener Operatoren, eine lange Warteschlange wird nicht erstellt.

  • Jetzt ist es möglich, die Arten von Anrufen zu einem bestimmten VCC zu regulieren. Manchmal müssen Sie einen Fragebogen von Grund auf neu ausfüllen, manchmal müssen Sie einige Informationen klären, und manchmal müssen Sie überhaupt nichts ausfüllen, es ist nur eine Bestätigung erforderlich.

  • Wenn Sie die Notwendigkeit des Weiterwählens aufheben, verschwinden bereits unnötige Anrufe aus der Warteschlange, niemand stört die Kunden.

  • Die Bank schreibt für jeden Anruf vier Zeitparameter: die Zeit, zu der der Anruf in Arbeit genommen wurde, den Beginn des Anrufs, das Ende des Anrufs, die Ausgabe des Ergebnisses des Anrufs an die Bank.

Aber bei der Arbeit an all diesen Daten haben wir festgestellt, dass wir zur Steigerung der Effizienz mit einer viel größeren Anzahl von Parametern arbeiten können. Basierend auf der Analyse von Retrodaten nach sechs Monaten Arbeit haben wir festgestellt, dass nicht alle VCCs auf die gleiche Weise mit dem Datenverkehr umgehen. Wir haben mehr als 30 verschiedene Quellen für Anfragen und 4 Kontaktzentren, die diese bearbeiten. Alle diese 30 Verkehrsquellen führen zu einem ungleichmäßigen Fluss von Anwendungen: Einige sind komplexer, andere weniger produktiv und konvertieren schlechter.

Daher haben wir uns entschlossen, unseren Microservice zu verbessern und der Anrufverteilung weitere Variablen hinzuzufügen.

Wir haben Abhängigkeiten von der Art des Verkehrspartners, den soziodemografischen Merkmalen des Kunden, seinem Wohnort usw. aufgebaut. Insgesamt wurden mehr als 30 Parameter verwendet. Basierend auf diesen Daten wurden Anrufe bereits an bestimmte Betreiber verteilt, die diese Art von Anrufen am effektivsten bearbeiten.

Dafür wurde ein Python-Modul implementiert, das im Moment all diese Daten berechnet und die Aufrufe des Microservices verteilt. Für den Rollout des Modells wurde unser MLOps-Server verwendet. Das Hauptproblem, mit dem wir konfrontiert waren, war die Aufrechterhaltung der Genauigkeit des Modells, wenn die Anwendung online ausgeführt wird. Für jeden Betreiber wurde ein Cluster mit bestimmten Parametern identifiziert, die die größte Effizienz bieten. Weiterhin wurden einfache Clustering-Modelle entwickelt, die im Betrieb keinen großen Ressourcenaufwand erfordern.

So haben wir nicht nur die anfänglichen Probleme, für die das Projekt konzipiert wurde, geschlossen, sondern es auch erheblich verbessert.

Was hat es uns in Zahlen gegeben:

  • Die Call-Erfolgsraten lagen bei 49 %, die Post-Projekt-Erfolgsraten bei 82 %.

  • Die Umwandlung in die fertige Anwendung stieg um das 2-fache.

  • Senkung der Kosten für VCC-Dienste um 21 %.

Similar Posts

Leave a Reply

Your email address will not be published.