Retourenverhinderung durch gezielte Rabatte: Entwicklung eines KI-basierten Prototyps mit Low-Code-Technologie für den Kundendienst

Die effiziente Gestaltung von Kundendienstprozessen ist ein zentrales Anliegen in der modernen Unternehmensführung und stellt besonders im Zeitalter der Digitalisierung und im E‑Commerce eine Herausforderung dar. Der Kundendienst ist die Schnittstelle zwischen Unternehmen und Kundschaft und spielt eine tragende Rolle in der Bindung und Zufriedenheit der kaufenden Personen (vgl. Dombrowski et al. 2020). Um eine lange und vertrauensvolle Geschäftsbeziehung zur Kundschaft aufzubauen, können Unternehmen Rabatte (z. B. Mengenrabatte, Treuerabatte, Zeitrabatte oder individuelle Rabatte) gewähren. Insbesondere der individuelle Rabatt ist ein Instrument, das sowohl zur Pflege der Kundschaft als auch zur Senkung der Retourenkosten und zur strategischen Umsatzsteigerung eingesetzt wird (vgl. Von Lindequist 2022). Sobald eine kaufende Person Produkte retournieren möchte, kann in einer individuellen Verhandlung ein Rabatt für die möglichen Qualitätsdefizite und Leistungseinschränkungen angegeben werden. Durch die Annahme des Rabatts von der kaufenden Person wird dann eine Retoure gänzlich verhindert, was zur Entlastung des komplexen Retourenprozesses führt und unnötige Transporte vermeidet (vgl. Deges 2017).

Die vorliegende Arbeit widmet sich der Retourenverhinderung durch die Vergabe von individuellen Rabatten im Kundendienst, wobei der entwickelte KI-Prototyp darauf ausgerichtet ist, diesen Prozess zu optimieren. Entscheidend bei der Festlegung der Rabatthöhe ist die Expertise der einzelnen Kundendienstmitarbeitenden (nachfolgend als Agenten bezeichnet), die beim Einsatz des Fallbasierten Schließens im entwickelten Prototypen systematisch genutzt wird. Im Fokus der Betrachtung steht ein kooperierender Versandhändler für Möbel und Wohnaccessoires, der durch seinen wirtschaftlichen Erfolg (stetig steigender Nettojahresumsatz) und das Bekenntnis zu Klimaneutralität und Naturschutz hervorsticht. Im Spannungsfeld von wirtschaftlichem Erfolg und nachhaltigem Handeln befindet sich der Kundendienst, welcher das Retourenverhalten der kaufenden Personen direkt beeinflussen kann und dabei eine Vielzahl an Herausforderungen bewältigt (vgl. Dombrowski et al. 2020).

Im Rahmen dieser Fallstudie wird die Entwicklung und Evaluierung eines Prototyps zur Optimierung der Rabattermittlung im Kundendienst behandelt, der das Ziel verfolgt, Retouren zu minimieren und Kosten zu reduzieren, die bei der wiederholenden Festlegung von Rabatten für wiederkehrende Anfragen auftreten. Der Prototyp verwendet Fallbasiertes Schließen (FBS), eine KI-basierte Technologie, um auf im ERP-System gespeicherte Daten zurückzugreifen, die frühere Rabattfälle dokumentieren. Dadurch werden die umfangreichen Erfahrungen der Agenten aus diesen Fällen aktiv genutzt, um individuell passende Rabatte zu bestimmen und strategisch einzusetzen. Zudem ermöglicht der Einsatz von Low-Code-Technologie und Open-Source-Software wie myCBR eine effiziente Integration in die bestehende IT-Infrastruktur mit verhältnismäßig geringem Aufwand (vgl. Stahl and Roth-Berghofer 2008).

Nach der Einführung in die Aufgaben und Prozesse des Kundendienstes des Kooperationspartners in Kap. 2 folgt die Beschreibung des Entwicklungsprozesses des Prototypen in Kap. 3. Die Evaluierung der Anwendung im realen Kundendienstumfeld wird anschließend in Kap. 4 aufgezeigt. Aus den Ergebnissen der Evaluation in Kap. 5 können Schlüsse für die Praxis sowie Ansätze für die Weiterentwicklung gezogen werden.

Der Kundendienst bei dem betrachteten Kooperationspartner setzt sich zum Zeitpunkt der vorliegenden Arbeit aus einem Team von 24 Agenten zusammen. Die Organisationseinheit hat insgesamt die folgenden Aufgaben: Auskünfte über Rechnungen, Preise und Produkte, Unterstützung bei Fragen zur Benutzung der Produkte, Entgegennehmen von Beschwerden, Verschicken von Retourenscheinen und Verhinderung von Retouren durch Gewährung von Rabatten. Alle Aufgaben müssen gleichzeitig schnell, effizient und kostengünstig bearbeitet werden.

Die Rabattvergabe, die lediglich von der individuellen Erfahrung der Agenten abhängt, kann sich in der Rabatthöhe bei gleichen Artikeln unterscheiden. Es existiert kein allgemeingültiges Schema zur Identifizierung der Rabatte. Die Agenten sichten den Auftrag, bewerten die Informationen der kaufenden Person und setzen eine angemessene Rabattierung fest. Vor allem neue Agenten vergeben tendenziell großzügigere Rabatte als Erfahrene. Diese Unterschiede hinsichtlich der Rabatthöhe stellen einen ungleichmäßigen Wissenstransfer dar, der vermieden werden sollte. Es ist eine Standardisierung bei der Ermittlung von Rabatten erforderlich.

Um dem Kundendienst einen geeigneten Prototypen zur Unterstützung anzubieten, sollen die existierenden Prozesse weiterentwickelt und mit einem KI-basierten Ansatz angereichert werden. Die Entwicklung des Prototypen für die Rabattermittlung kann die Entscheidungsfindung im Kundendienst maßgeblich erleichtern und sowohl den Wissenstransfer verbessern als auch die Kosten senken.

Der Einsatz einer KI-basierten Lösung stellt einen entscheidenden Fortschritt im Management von Anfragen der kaufenden Personen dar und ist ein Meilenstein in der verbesserten Rabattermittlung des Kooperationspartners (vgl. Lichtenthaler 2021). Im Vordergrund dieses Kapitels steht die Entwicklung des Prototyps, welcher aus einer fallbasierten Komponente besteht, die über eine Webapplikation zugänglich gemacht wird. Für eine unkomplizierte Verwendung im kooperierenden Unternehmen sowie zum praxisnahen Einsatz wurde eine Client-Server-Infrastruktur implementiert, die es ermöglicht, dass Agenten einfach über eine Webadresse auf den Prototypen zugreifen können. Dieses Vorgehen vermeidet die Notwendigkeit zusätzlicher Installationen oder lokaler Datenspeicherungen und sorgt für einen schnellen und effektiven Zugriff auf den Prototypen. Zusätzlich werden Aufschluss über die konkrete Umsetzung des FBS-Ansatzes sowie über die Bestimmung von ähnlichen Rabattfällen gegeben, die zum Vergleich herangezogen werden können.

3.1 Fallbasiertes Schließen und myCBR

Fallbasiertes Schließen (engl. Case-Based Reasoning, CBR) ist ein Ansatz der Künstlichen Intelligenz (KI), der neue Problemstellungen löst basierend auf der Verarbeitung und dem Verständnis von vergangenen, ähnlichen Problemen und deren Lösungen. Bei der Lösungsfindung wird ein aktuelles Problem bspw. anhand von ausgewählten Attributen mit bereits gelösten Fällen aus einer Fallbasis verglichen. Entscheidend ist dabei die Identifikation und Nutzung der relevanten Ähnlichkeiten zwischen den Attributen der Fälle (vgl. Bergmann et al. 2020, S. 343–344).

Ähnlichkeiten werden im FBS entweder durch boolesche, numerische oder symbolische Werte bzw. durch mengentheoretische Prinzipien ausgedrückt und mathematisch ermittelt (vgl. Pfuhl 2003, S. 53–54). Um die Ähnlichkeitsberechnung im FBS zu verdeutlichen, werden nachfolgend beispielhaft drei Lampen mit numerischen Werten verglichen: Lampe A hat einen roten Lampenschirm und zeichnet sich durch eine hohe Helligkeit aus, Lampe B hat einen grünen Lampenschirm und eine geringe Helligkeit, während Lampe C, für die es die ähnlichste Lampe zu finden gilt, ebenfalls einen roten Lampenschirm hat aber eine mittlere Helligkeit aufweist. Diese Lampen sollen nun anhand von numerischen Werten verglichen werden. In Bezug auf die Helligkeit bekommt Lampe A einen Wert von 8, Lampe B einen Wert von 2 und Lampe C einen Wert von 6. Was die Lampenschirmfarbe betrifft, so haben sowohl Lampe A als auch Lampe C einen Wert von 1, da beide einen roten Schirm haben, während Lampe B mit dem grünen Schirm bspw. einen Wert von 2 besitzt. Die unterschiedlichen Werte basieren auf den unterschiedlichen Farben. Ein direkter Vergleich zwischen den drei Lampen zeigt, dass die Lampen C und A einander ähnlicher sind als die Lampen C und B. Dies liegt daran, dass die Lampenschirme von C und A die gleiche Farbe haben (beide 1) und ihre Helligkeitsstufen näher beieinander liegen (6 und 8) als es bei Lampe C und B der Fall ist (6 und 2).

Das im Rahmen des FBS gewonnene Wissen kann somit operationalisiert werden, indem es gezielt für die Lösung ähnlicher Herausforderungen eingesetzt wird, basierend auf der Annahme, dass ähnliche Probleme oft ähnliche Lösungen erfordern Althoff and Weß (1992, S. 146). Ein Fall ist dabei die dokumentierte Beschreibung einer Problemsituation, die sowohl die Problemstellung als auch die zugehörige Lösung und gegebenenfalls den Lösungsweg umfasst. Des Weiteren können zusätzliche Informationen, Handlungsempfehlungen oder Erklärungen mit dem Fall abgelegt sein. Die Sammlung der gespeicherten Fälle bildet die (Fall‑)Basis, auf die das FBS-System zugreift. Ein neues Problem wird dadurch gelöst, dass ein ähnlicher früherer Fall in der Basis gesucht wird und dessen Lösungsweg sowie die relevanten Informationen und das Wissen in der neuen Problemsituation wiederverwendet werden. Dieser Prozess wird insbesondere durch die Ermittlung von Fällen mit ähnlichen Merkmalen mittels spezieller Ähnlichkeitsmaße umgesetzt (vgl. Aamodt and Plaza 1994).

Den Ablauf eines FBS-Systems beschreiben Aamodt and Plaza (1994) als einen Zyklus bestehend aus vier Phasen, die nacheinander durchlaufen werden (Retrieve, Reuse, Revise und Retain). Der Zyklus spiegelt die Informationsverarbeitung innerhalb des Systems wider. In der Retrieve-Phase wird nach ähnlichen, früher gelösten Fällen in der Fallbasis gesucht, um mögliche Lösungen zu identifizieren. In der Reuse-Phase wird die frühere Lösung auf das neue Problem angewendet, wobei die Lösung auch modifiziert werden kann. Die Revise-Phase beschreibt den Einsatz der angepassten Lösung aus der Reuse-Phase. Schließlich wird in der Retain-Phase der neue Fall mit angepasster Lösung zur späteren Wiederverwendung in der Fallbasis gespeichert, wodurch inkrementelles Lernen genutzt wird und das System sich kontinuierlich weiterentwickelt (vgl. Reuss et al. 2017). Am Beispiel des vorliegenden Prototyps sehen die Phasen folgendermaßen aus: In der Retrieve-Phase geben die Agenten die Daten der vorliegenden Beschwerde ein und erhalten daraufhin die drei ähnlichsten Fälle aus der Fallbasis. Anschließend nutzen die Agenten die präsentierten Informationen z. B. zu den Rabatthöhen als Entscheidungsunterstützung (Reuse), um die vorliegende Beschwerde zu bewerten und einen Rabatt festzulegen und zu übermitteln. Der Einsatz und die Anwendung der Informationen aus der Fallbasis umfasst die Revise-Phase. Schließlich wird im Rahmen der Retain-Phase der neue Rabattfall, der im ERP-System gespeichert wird, für zukünftige Beschwerden als gelöster Fall zugänglich gemacht.

Das FBS-System zur Entscheidungsunterstützung für den Kundendienst des Kooperationspartners wird so entwickelt, dass zum einen die Interaktion mit den Nutzenden und zum anderen die Repräsentierbarkeit von Hintergrundwissen effizient abläuft. Für die Entwicklung wird die Open-Source-Software myCBR herangezogen. Die Software zeichnet sich durch eine ausgeprägte Benutzerfreundlichkeit aus und umfasst eine Workbench mit einer intuitiven grafischen Benutzeroberfläche (GUI), die den Entwickelnden eine visuelle Ähnlichkeitsmodellierung ermöglicht, ohne dass tiefgehende Programmierkenntnisse erforderlich sind (vgl. Stahl and Roth-Berghofer 2008). Der Entschluss für myCBR basierte auf einer gründlichen Analyse verschiedener Kriterien. Eine Open-Source-Software, deren Nutzung zugleich mit geringem Programmieraufwand verbunden und in Java realisiert ist, stand dabei im Vordergrund. Es war ebenfalls wichtig, eine breite Unterstützung für diverse Fallrepräsentationen zu gewährleisten, um im Rahmen der Entwicklung möglichst wenig Einschränkungen zu haben. Des Weiteren war es erforderlich, einen etablierten Ansatz zu verfolgen, was sich in der Anzahl der Publikationen zum jeweiligen Framework widerspiegelt. Die Überprüfung der Arbeit von Schultheis et al. (2023), die eine Reihe von FBS-Frameworks einer vergleichenden Betrachtung unterzieht, hat gezeigt, dass sowohl CloodCBR als auch myCBR unseren Anforderungen gerecht werden konnten. Die reichhaltige Publikationslandschaft von myCBR erscheint dabei als Beleg für dessen Reife und Gemeinschaftsakzeptanz, was unsere Wahl für den Branch der Universität Hildesheim weiter untermauert (vgl. Schultheis et al. 2023).

MyCBR lässt sich aufgrund der charakteristischen Merkmale als eine Low-Code-Plattform (LCP) einordnen (vgl. Di Ruscio et al. 2022). LCP sind gekennzeichnet durch ihre visuellen Entwicklungsansätze und eine Minimierung manueller Codierung, was bei myCBR durch die intuitive GUI zur Ähnlichkeitsmodellierung erreicht wird (vgl. Bach and Althoff 2012). Darüber hinaus sorgen LCP (und auch myCBR) dafür, dass die Entwicklung und Wartung von Applikationen erleichtert wird. Zusätzlich verfügt myCBR über einen Software Development Kit, der die Integration in vielfältige Anwendungen als Plugin unterstützt und damit die Integrationsmöglichkeiten und Wiederverwendbarkeiten fördert (vgl. Di Ruscio et al. 2022). Im Prozess der Ähnlichkeitsmodellierung werden relevante Attribute aus den vorhandenen Fällen ausgewählt und in myCBR über die GUI gewichtet und damit priorisiert. Diese Gewichtung erlaubt es dem späteren FBS-System, die Ähnlichkeit neuer Fälle im Vergleich zu den bereits vorhandenen Fällen zu ermitteln. Wenn bspw. eine kaufende Person eine Beschwerde über ein geliefertes Produkt mit einem kleinen Kratzer einreicht, ermöglicht das Ähnlichkeitsmodell des FBS-Systems genau diejenigen Fälle aus der Fallbasis zu extrahieren, die hinsichtlich der gewichteten Attribute als ähnlich bestimmt werden können. Als Attribute könnten z. B. das spezifische Produkt, der Preis oder der Schaden herangezogen werden (vgl. Karmen et al. 2019). Auf die Modellierung und Berechnung der Ähnlichkeiten des Prototyps wird im Abschn. 3.3 eingegangen.

3.2 Generierung der Fallbasis

Ein Fall in einer Fallbasis kann aus vielen unterschiedlichen Attributen bestehen, die als Attribut-Wert-Paare repräsentiert werden können, z. B. Attribut = „ItemPriceSell“ und Wert = „19,95“. Die Attribute werden für die Ähnlichkeitsmodellierung verwendet und die Werte zur Ahnlichkeitsbestimmung miteinander in Relation gesetzt (vgl. Richter 2003). Zur Repräsentation der Attribut-Wert-Paare wurde eine CSV-Datei angelegt, in der die Spalten als Attribute betrachtet werden und die einzelnen Einträge in den Zeilen als Werte. Ein Tupel in der Datei kann als Fall angesehen werden. Die benötigten Daten werden mittels einer SQL-Abfrage aus dem Data Warehouse (DWH) des Kooperationspartners entnommen, das über die Funktion des CSV-Exports aus dem System verfügt. Dabei werden zu Beginn deutlich mehr Attribute in SQL abgefragt und exportiert, als im späteren Verlauf der Entwicklung für die Gewichtung und die Ähnlichkeitsberechnung verwendet werden. Dieser Ansatz verfolgt das Ziel, eine umfangreiche Datenbasis für eine erste Merkmalsselektion zu schaffen, von der aus iterativ die entscheidenden Attribute und Gewichtungen herausgearbeitet und verfeinert werden können, um das FBS-System sukzessive zu entwickeln und dessen Präzision kontinuierlich zu verbessern. Im weiteren Verlauf werden die final genutzten Attribute in Tab. 1 und die daraufhin zusätzlich für die Ähnlichkeit gewichteten Attribute in Tab. 4 präsentiert.

Um die Datenmasse sowohl für die Entwicklung als auch Evaluierung zu verkleinern, wurden nur Fälle von Speditionssendungen extrahiert, die für die Agenten aufgrund der hohen Preise und Lieferkosten schwieriger einzuschätzen sind als Paketsendungen. Hierdurch wurde zum einen die zu verarbeitende Datenmenge für den Prototyp verringert und zum anderen fokussierten sich die Rahmenbedingungen der Fallstudie auf die Fälle, bei denen laut Kundendienst am meisten Unterstützung nötig ist. Insbesondere wurden ausschließlich Bestellungen in Betracht gezogen, deren Lieferland Deutschland war, die vollständig bearbeitet wurden und die keine Ersatzlieferungen beinhalteten.

Nach dem Ausführen der entsprechenden SQL-Abfrage ergab sich eine Fallbasis bestehend aus insgesamt 560 Fällen, die sich aus 339 unterschiedlichen Artikelnummern zusammensetzen. Für die Nutzung der Daten in myCBR mussten auch Anpassungen von Zeichenformaten berücksichtigt werden wie bspw. die Entfernung von Umlauten und mögliche Kommata in Artikelbezeichnungen. Hierdurch konnten Kompatibilitätsprobleme vermieden werden. Eine Übersicht über die extrahierten Attribute und dazugehörige Beispiel-Werte wird in Tab. 1 ersichtlich, wobei die fettgedruckten Attribute für die Berechnung der Ähnlichkeit zwischen den Fällen verwendet wurden. Einige Attribute erhielten bei der Ermittlung der Ähnlichkeit ein höheres Gewicht, während andere lediglich den Agenten zusätzliche Informationen bereitstellten, um die Entscheidungsfindung zu unterstützen. Jene Attribute, die nicht in die Ähnlichkeitsberechnung eingeflossen sind, sind bspw. die Gutschrift oder das Verkaufsdatum zur schnelleren Nachvollziehbarkeit der Fälle und deren Unterschiede. Dies kann insbesondere hilfreich sein, wenn Mitarbeitende unsicher sind, welchen Rabatt sie der kaufenden Person anbieten sollen, oder wenn bei zwei ähnlich gelagerten Fällen zusätzliche Informationen für eine besser fundierte Entscheidung herangezogen werden müssen. Die gewichteten Attribute sind in Tab. 4 ersichtlich.

Durch die Fallbasis in der Applikation können die Agenten in Echtzeit auf systematisch aufbereitete und historische Daten zugreifen, was eine zuverlässige Entscheidungsfindung bezüglich der Rabattermittlung bedeutend erleichtert. Die zielgerichtete und datengetriebene Unterstützung, welche die Webapplikation bietet, ist aufgrund der intuitiven Handhabung und der browserbasierten Zugänglichkeit ausgesprochen nutzerfreundlich.

3.3 Ähnlichkeitsmodellierung und Gewichtung der Attribute

Im Rahmen der Ähnlichkeitsmodellierung in myCBR spielen zwei unterschiedliche Ähnlichkeitsmaße eine zentrale Rolle, um Werte bzw. Fälle miteinander zu vergleichen und entsprechend den Ähnlichkeiten zu bewerten. Diese sind die lokalen Ähnlichkeitsmaße und das globale Ähnlichkeitsmaß. Die lokalen Ähnlichkeitsmaße definieren, wie ähnlich sich zwei Werte eines bestimmten Attributes sind. Sobald mithilfe der Ähnlichkeitsmaße die Ähnlichkeiten zwischen den Werten der unterschiedlichen Fälle ermittelt wurden, werden die lokalen Ähnlichkeiten zu einem globalen Ähnlichkeitswert aggregiert. Dies dient dazu, die einzelnen lokalen Ähnlichkeiten zu einem Gesamturteil zusammenzuführen. Dabei werden verschiedene Methoden angewendet, die abhängig von der jeweiligen Ausprägung der Werte ist. Die Werte können bspw. numerisch oder symbolisch sein. Je nachdem welche Ausprägung ein Wert hat, werden die Ähnlichkeiten in myCBR auf unterschiedliche Weise modelliert, z. B. können numerische Werte zur Berechnung genutzt oder, bei symbolischen Werten, in einer Matrix über das myCBR-Interface eingestellt werden. Im Falle der gewichteten Summe wird der Einfluss jedes einzelnen Attributes über ein entsprechendes Gewicht gesteuert. Im Gegensatz hierzu werden die Einstellungen für die symbolischen Werte ausgelesen und miteinander verglichen.

Wird das Beispiel der Lampenschirme aus dem Abschn. 3.1 erneut aufgegriffen, können wir zwischen den drei Lampen mit myCBR auch die Preise und entstandenen Retourengründe, die in den Fällen in der Fallbasis hinterlegt sind, vergleichen. Angenommen uns liegt eine Beschwerde einer kaufenden Person für Lampe C vor, die noch nicht in unserer Fallbasis existiert. So benötigen wir hierfür einen ähnlichen Fall, deren Informationen wir zur Lösung der Beschwerde nutzen können. Die Attribute, anhand derer die Lampen verglichen werden sollen, sind: (1) Lampenschirmfarbe, (2) Helligkeit, (3) Verkaufspreis und (4) Retourengrund. Die Ausprägung der Attribute (1), (2), (3) sind numerisch und des Attributs (4) symbolisch. Da im vorherigen Beispiel bereits festgestellt wurde, dass Lampe A am ähnlichsten zu Lampe C ist, ausgehend von den Attributen (1) und (2), konzentrieren wir uns nachfolgend auf die Attribute (3) und (4). Lampe A (roter Lampenschirm und hohe Helligkeit von 8) hat einen Verkaufspreis von 20 € und, im vorliegendem Fall, als Retourengrund „Produktschaden“. Lampe B (grüner Lampenschirm und geringe Helligkeit von 2) hat einen Verkaufspreis von 10 € und, im vorliegenden Fall, als Retourengrund „Nichtgefallen“. Die Lampe C, für die es einen ähnlichen Fall zu finden gilt, hat einen roten Lampenschirm, eine mittlere Helligkeit von 6, einen Verkaufspreis von 16 € und als Retourengrund einen „Transportschaden“. Da die numerischen Werte mathematisch bereits miteinander verglichen werden können, wird zuerst auf die Modellierung der symbolischen Attribute eingegangen. Um dies zu realisieren, besteht die Möglichkeit in myCBR die Werte (in diesem Beispiel Retourengründe) miteinander vergleichbar zu machen. Hierzu können in einer Matrix die Ähnlichkeiten zwischen den einzelnen Werten (in diesem Fall die drei vorhandenen Retourengründe) hinterlegt werden. Als Beispiel sind sich „Produktschaden“ und „Nichtgefallen“ nur zu 20 % ähnlich, während „Produktschaden“ und „Transportschaden“ sich zu 80 % ähnlich sind. In myCBR würde das in Form einer Matrix hinterlegt werden können, wie in Tab. 2 visualisiert. Hierdurch können die Ähnlichkeiten herausgelesen werden, ausgehend vom Retourengrund des zu vergleichenden Falls (im vorliegenden Beispiel „Transportschaden“; in der Tabelle fettgedruckt).

Da wir mit gewichteten Summen im Rahmen eines Scorings zur Bestimmung der globalen Ähnlichkeit arbeiten wollen, benötigen wir Gewichte für die lokalen Ähnlichkeiten. Wir berücksichtigen dabei, dass Preis und Retourengrund für das vorliegende Beispiel am bedeutsamsten sind und erhalten damit die Gewichte: Lampenschirmfarbe = 0,5; Helligkeit = 0,6; Verkaufspreis = 0,9 und Retourengrund = 0,8. Das einflussreichste Attribut ist somit der Verkaufspreis. Es sei angemerkt, dass sich die Gewichte bei der Eingabe in myCBR nicht zu 1 addieren müssen. Der Score jeder Lampe wird ermittelt, indem die Attribute einer Lampe jeweils mit dem zugeordneten Gewicht multipliziert und anschließend die resultierenden gewichteten Werte für jede Lampe aufsummiert werden. Aufgrund der anschließenden Berechnung: \(\min_{i=\text{Lampe A},\text{ Lampe B}}{|\text{Score}_{\text{Lampe C}}-\text{Score}_{ \textit{i}}|}\) ergibt sich das Ergebnis, dass Lampe A am ähnlichsten zu Lampe C ist.

Die Herausforderung bei der Ähnlichkeitsmodellierung liegt darin, die Gewichte und Ähnlichkeitswerte so einzustellen, dass die Ergebnisse aus dem FBS-System die reale Welt auf sinnvolle und nützliche Weise abbilden. Dies erfordert Verständnis sowohl für die Domäne, bzw. das Fachgebiet als auch Wissen darin, wie ähnlich zwei spezifische Ausprägungen eines Attributs einander sind. Es sei an dieser Stelle hervorgehoben, dass kein Modell universell ist und stets die Einsichten und Annahmen reflektiert werden müssen, die im Laufe der Entwicklung eingeflossen sind.

Im weiteren Verlauf wird auf die Ähnlichkeitsmodellierung im Rahmen der Entwicklung und im Bereich der Möbel und Wohnaccessoires eingegangen. Um die Ergebnisse für die Agenten besser nachvollziehbar zu machen, verwenden wir Ähnlichkeitsmaße für numerische Werte, die keine Unterschiede in den Distanzen aufzeigen. Die Gewichte wurden so verteilt, dass die wesentlichen Attribute für die Rabattermittlung besonders hervorgehoben wurden, vor allem hinsichtlich der Kosten. Die gewichteten Attribute, die \(> 1\),0 sind (Standardwert), können der Tab. 4 entnommen werden. Zur Feinjustierung der Gewichte besteht die Möglichkeit, diese im Dezimalbereich anzupassen. Im Rahmen des Prototyps wurde hierauf nicht zurückgegriffen, weshalb alle Gewichte auf 0 enden.

Bei der großzügigen Gewichtung von 9,0 für den Artikelpreis (ItemPriceSell) liegt der Fokus darauf, dass der Preis unmittelbar die Profitabilität von Rabattaktionen beeinflusst. Es ist ein klares Signal für die Wertigkeit eines Produkts und damit essentiell für die Kalkulation von Rabatten. Gleichzeitig ist die Artikelnummer (ItemId) entscheidend, da sie die Identifikation exakter Produkt- und Fallübereinstimmungen ermöglicht und somit zur Genauigkeit der Produktempfehlungen im Rahmen des FBS beiträgt. Weitere Attribute, wie der Grund der Gutschrift, z. B. Transportschaden (CreditNoteReason), bieten zusätzlich wichtige Einblicke in die Gründe für Retouren oder Beschwerden, was wiederum die Entscheidungsfindung im Kundendienst hinsichtlich der Gewährung von Rabatten beeinflusst. Auch die Warengruppe des Produkts, z. B. Gartenliege (CommodityGroupId), kann für die Rabattermittlung von Bedeutung sein, da sich bspw. die interne Retourenverarbeitung von Liegen und Vasen unterscheidet. Es kann daher sinnvoll sein, manche Warengruppen stärker zu rabattieren und dessen Retoure zu verhindern (vgl. Asdecker 2014). Da die Artikelbezeichnung nicht unmittelbar Aufschluss über die zugehörige Warengruppe geben muss und es praktikabler ist, sich an der überschaubaren Anzahl an Warengruppen anstatt den zahlreichen individuellen Produkten zu orientieren, werden die Warengruppen genutzt. Transportdienstleister (Logistic) und Vertriebskanäle (SalesChannel) beeinflussen direkt das Verhalten der kaufenden Personen und das Serviceerlebnis seitens des Unternehmens. Einkaufspreis (ItemPriceBuy), UVP (RRP) und Prozentsatz der Gutschrift, z. B. 15 % (Percent), stellen wiederum wichtige historische Merkmale dar, die Aufschluss über die üblichen Rabattierungspraktiken der Agenten geben und somit als Referenzpunkte für neue Fälle dienen. Insgesamt ermöglicht diese differenzierte und gezielte Gewichtung eine präzisere Rabattermittlung, die auf entscheidende wirtschaftliche und operative Aspekte aus Kundschafts- und Unternehmenssicht abgestimmt ist.

3.4 Webapplikation

Die Webapplikation ist so konzipiert, dass sie den Agenten dabei unterstützt, eine optimale Rabattierung anzubieten. Diese soll nicht nur von der Kundschaft akzeptiert werden, sondern auch die Wirtschaftlichkeit im Zusammenhang mit potenziellen Retouren maximieren. Hierfür werden aus der Vergangenheit gewährte Rabatte von Agenten genutzt und systematisch wiedergegeben. Die Architektur der Applikation verfügt dabei über drei Hauptkomponenten: eine CSV-Datei (Fallbasis), aus myCBR exportierte Dateien (FBS-System) sowie den Seiten der Webapplikation. Die Applikation ist für die Nutzenden so aufgebaut, dass nach Eingabe der Daten einer vorliegenden Anfrage, eine von zwei Oberflächen erscheint: Entweder für Rabattfälle oder für Nicht-Rabattfälle. Die Funktionen der Letzteren wurden insbesondere zu Demonstrationszwecken eingebunden, um das Potenzial der Applikation im praktischen Einsatz aufzuzeigen. Beispielsweise wird durch das Bereitstellen spezifischer Handlungsanweisungen bei Nicht-Rabattfällen die Einarbeitung neuer Agenten erleichtert und es trägt zur Standardisierung der Prozesse sowie zum Transfer von Wissen bei. Im Weiteren liegt der Fokus auf der Nutzung der Applikation für Rabattfälle, für die das mithilfe von myCBR entwickelte FBS-System zum Einsatz kommt.

Eine Darstellung der Applikationen im Rabattfall wird durch Abb. 1 ersichtlich, in dem sowohl Eingabemaske (Seite 1) als auch Ausgabemaske (Seite 2) präsentiert werden. Auf der ersten Seite werden die Daten zu der vorliegenden Beschwerde der kaufenden Person eingegeben, auf der zweiten Seite werden die Ergebnisse des FBS-Systems präsentiert. Durch einen Knopf auf der zweiten Seite gelangen die Agenten zurück zur ersten Seite und können die Daten einer neuen Beschwerde einer kaufenden Person eingeben und suchen. Die Applikation erfordert somit keine zusätzlichen Systeme und kann als eigenständiges Tool zur Rabattermittlung verwendet werden, wobei der vorgeschlagene Rabatt eines Falls das Attribut „Prozent“ auf der zweiten Seite darstellt.

Die Eingabemöglichkeiten auf der ersten Seite sind Artikelnummer, Artikelpreis, UVP, Verkaufskanal, Transportdienstleister, Beschwerdegrund und ob eine Ersatzlieferung seitens der kaufenden Person gewünscht ist. Die Eingabefelder wurden sorgfältig ausgewählt, um selbst bei sehr ähnlichen Fällen den mit der höchsten Übereinstimmung zu finden und dessen Ähnlichkeit in Prozent zu zeigen. Obwohl für die Berechnung der Ähnlichkeiten weitere Attribute einbezogen wurden (siehe Tab. 4), wurden nicht alle in den Eingabefeldern genutzt, um die Benutzerfreundlichkeit zu erhöhen und die Komplexität des Systems für die Nutzenden zu reduzieren. Werden diese Daten in korrekter Art und Weise eingegeben, so werden sie vom FBS-System weiterverarbeitet und die drei ähnlichsten Fälle aus der Fallbasis den Agenten auf der zweiten Seite präsentiert.

Ergebnisse der Webapplikation Quelle: Eigene Darstellung

Full size image

Die Entscheidung für die Anzeige von drei ähnlichen Fällen auf der zweiten Seite beruht darauf, dass die Präsentation lediglich eines einzigen Falles im Prototyp als zu begrenzt erachtet wurde, während mehr als drei Fälle die Übersichtlichkeit beeinträchtigen würden. Die ähnlichen Fälle, die durch das FBS-System automatisch ermittelt und durch die Webapplikation wiedergegeben wurden, umfassten alle relevanten Informationen des Falls für die Unterstützung der Rabattermittlung durch den Agenten. Auf der zweiten Seite des Prototyps wurden die Ähnlichkeiten der Fälle zur eingegeben Beschwerde der kaufenden Person aufgeführt, die Artikelnummer, um die es sich im jeweiligen Fall handelte, der Verkaufspreis des Artikels, der Verkaufskanal, der Transportdienstleister, Beschwerdegrund, der prozentuale und monetäre Nachlass (angegeben als Prozent und Gutschrift) und abschließend das Verkaufsdatum.

In diesem Kapitel wird das Vorgehen und die Evaluation des Prototyps zur Rabattermittlung im Kundendienst vorgestellt. Der Fokus liegt auf dem Aufbau und Ablauf der Evaluierung sowie auf der Auswertung und Interpretation der daraus gewonnenen Ergebnisse. Aus der vorliegenden Arbeit geht hervor, welche Auswirkungen die Integration des Prototyps auf die Rabattermittlung und die resultierende Kosteneinsparung haben kann. Für die Durchführung der Evaluation wurde die Webapplikation auf dem DWH-Server des Kooperationspartners dem Kundendienst bereitgestellt, wodurch nicht nur ein firmeninterner oder gesicherter VPN-Zugriff auf die Applikation sichergestellt werden konnte, sondern auch eine hohe Systemverfügbarkeit und Performance durch die dedizierten Serverkapazitäten gewährleistet war. Zusätzlich ermöglichte diese Vorgehensweise eine strukturierte Datensicherung und verbesserte Wartungsmöglichkeiten, sodass im Falle technischer Schwierigkeiten schnell und effizient reagiert werden konnte.

4.1 Datengrundlage und Vorgehen im Kundendienst

Zum Testen der Applikation wurden drei erfahrene Agenten, inklusive einer Führungskraft für komplexe Fälle, aus dem Unternehmen zur Verfügung gestellt. Diese Agenten bearbeiteten innerhalb von sechs Wochen insgesamt 47 „schwierige“ Anfragen von kaufenden Personen mit dem Prototyp. Die Aufgabe der Agenten bestand darin, die vom Prototyp generierten Rabattvorschläge mit ihrem erfahrenen ersten Eindruck zu vergleichen und entweder anzunehmen oder den kaufenden Personen ihren eigenen Vorschlag zu unterbreiten und dies zu dokumentieren, wobei dieses Procedere gewissermaßen die Revise-Phase im CBR-Zyklus widerspiegelt. Das Vorgehen diente dazu, einerseits die Praxistauglichkeit der Applikation unter realen Bedingungen zu bewerten und andererseits sicherzustellen, dass durch die Technologie keine unwirtschaftlichen Rabatte gewährt wurden.

Den Agenten wurde für die Dokumentation eine Evaluierungsdatei bereitgestellt, in der alle relevanten Erkenntnisse festgehalten wurden. Dazu gehören ausgewählte Parameter der bearbeiteten Beschwerde einer kaufenden Person, z. B. Artikelnummer aus der Bestellung für die Produktzuordnung, Verkaufspreis und Beschwerdegrund des Produkts, der erste Rabattvorschlag der Agenten in %, der Rabattvorschlag der Applikation und ob der, von der Applikation vorgeschlagene, Rabatt angenommen wurde sowie die Höhe des Rabatts in % und €. Zudem erfolgte die Speicherung der vom FBS-System ermittelten drei ähnlichsten Fälle. Alle erhobenen Daten wurden im CSV-Format abgelegt, was sowohl eine einfache Datenhandhabung als auch eine spätere Auswertung ermöglichte.

Die Auswertung der Evaluierungsdaten ergab, dass die Applikation überwiegend adäquate und im Vergleich zu den bisherigen Ersteindrücken der Agenten geringere Rabatthöhen vorschlug. Die Haupterkenntnis hierzu ist die, dass die Agenten häufig im 5 %-Intervall Rabatte vergeben, wohingegen das FBS-System auf frühere Rabatte zurückgreift, die ähnlich sind, und auch mal mit weniger Prozent (z. B. 12 % anstatt 15 %) rabattiert wurden. Auch der Durchschnitt von mehreren früheren Rabatten führt häufig zu einem Prozentsatz, der nicht durch 5 teilbar ist. Diese durch die Kundschaft angenommenen Vorschläge ermöglichen es, dass die Agenten ihre Zielsetzung der Kostensenkung effektiv verfolgen können.

4.2 Ergebnisse der Evaluierung

Die Evaluierung umfasste 47 Beschwerden von kaufenden Personen, darunter 14 als „Härtefälle“ klassifizierte Anfragen. Die Kategorisierung als „Härtefäll“ stammt vom Kundendienst und soll einen schwer zu bearbeitenden Fall vermerken, den im besten Fall erfahrenere Agenten übernehmen. Die Gründe für einen solchen „Härtefälle“ sind nicht standardisiert und individuell zu betrachten. Insgesamt beläuft sich der Verkaufswert aller rabattierten Artikel auf \(> 30.000\),00 €, mit einem durchschnittlichen Rabatt pro Anfrage von 17 % vom Verkaufswert, wobei die Höhe aller gewährten Rabatte der 47 Anfragen aufsummiert 5.108,00 € ergab. Von allen getesteten Anfragen wurden die Vorschläge der Webapplikation bei 37 Fällen genutzt. Das ist eine Akzeptanzrate von \(> 78\) %. Die Nichtakzeptanz in 10 Fällen ist auf unpassende Vorschläge der Applikation zurückzuführen, weil die vom System vorgeschlagenen Rabatte entweder zu niedrig oder zu hoch waren. Die Beurteilung basiert dabei auf den Erfahrungen der Agenten, die an der Evaluation teilgenommen haben. Ein neuer Fall mit entsprechendem Rabatt wurde der Fallbasis an dieser Stelle nicht hinzugefügt, da der Schwerpunkt der Evaluation vordergründig auf der Bestätigung der Wirksamkeit des Prototyps und nicht auf der Erweiterung des Systems lag. Um diese Nichtakzeptanz zu verbessern, könnten bspw. die Ähnlichkeitsmodellierung im weiteren Verlauf feinjustiert und Gewichtungen angepasst werden, wie es bspw. im Rahmen der Retain-Phase passieren würde.

Die Reaktionen auf die von der Webapplikation vorgeschlagenen Rabatte waren insgesamt positiv. Diese fielen im Durchschnitt geringer aus als die Rabatte der Agenten ohne den Einsatz des Prototyps. Diese Informationen haben die kaufenden Personen allerdings nicht bekommen, da lediglich ein Rabatt angeboten und akzeptiert wurde. Besonders bemerkenswert ist, dass alle auf Vorschläge der Webapplikation basierenden Rabatte für „Härtefälle“ von den kaufenden Personen positiv aufgenommen wurden. Dies hebt den Nutzen des Prototyps für Härtefälle nochmal deutlich hervor.

Die Applikation zeigte den Agenten die drei ähnlichsten Fälle für jede neue Anfrage. Die Qualität der Ähnlichkeitsmodellierung wurde durch die hohe Akzeptanz der Vorschläge bestätigt, wobei meist der vorgeschlagene Fall mit der höchsten Ähnlichkeit angewandt wurde, was eine genaue und relevante Modellierung der Ähnlichkeitsmaße impliziert.

Die quantitative Auswertung der Ersparnisse ergab, dass durch die 37 Anwendungen der insgesamt 47 Beschwerden der kaufenden Personen während der Evaluierungsphase, zusammengefasst 329,28 € gegenüber der ansonsten ohne Prototyp gewährten Rabatte eingespart wurden. Wird diese Ersparnis durch die Anzahl der 37 Anwendungen geteilt, so entspricht dies einer durchschnittlichen Ersparnis pro Nutzung des Prototyps von 8,90 € gegenüber der Nicht-Nutzung.

Die Fallstudie verdeutlicht, dass der Einsatz des Prototyps zur Rabattermittlung einen signifikanten Beitrag zur Effizienzsteigerung innerhalb des Kundendienstes leistet. Besonders hervorzuheben sind die Einsparungen bei den Rabatthöhen in Kombination mit der kurzen Entwicklungszeit und den geringen Investitionen, die durch die Nutzung von myCBR möglich waren. Zudem unterstreicht die durchschnittliche Einsparung von 8,90 € pro Anwendung das wirtschaftliche Potenzial des Prototyps. Diese Vorteile werden vor allem bei der Betrachtung einer Hochrechnung über ein ganzes Geschäftsjahr deutlich. Ferner trägt der Prototyp zu einer Verbesserung der Arbeitsprozesse bei, da die Agenten von den Vorschlägen und Schrittanleitungen profitieren können.

Bei der Entwicklung von Prototypen, wie der Webapplikation zur Rabattermittlung im Kundendienst, ist die Auswahl der richtigen Entwicklungsumgebung von zentraler Bedeutung. Low-Code-Technologien, die sich vordergründig durch eine vereinfachte Programmierumgebung auszeichnen, haben dabei das Potential, die Entwicklungsprozesse zu beschleunigen und gleichzeitig die Kosten gering zu halten (vgl. Ostroukh et al. 2022). Die Nutzung von myCBR als Low-Code-Plattform in der betrachteten Anwendung hat primär zu einer deutlichen Kostensenkung beigetragen, da die Software in der hier betrachteten Anwendung kostenlos verfügbar ist. Dank der hohen Anpassungsfähigkeit konnten die Anforderungen im Bereich der Ähnlichkeitsmodellierung effektiv implementiert werden, was es ermöglichte einen exakt auf den Kundendienst und die unternehmensinternen Prozesse zugeschnittenen Prototyp zu entwickeln. Die GUI von myCBR erleichterte zudem die Erstellung und Verwaltung der Fallbasis, da keine vertieften Programmierkenntnisse notwendig waren und die Daten einfach importiert werden konnten. Diese Benutzerfreundlichkeit trägt maßgeblich zu einer beschleunigten Einarbeitungszeit und Entwicklungsarbeit bei.

Neben diesen Vorteilen brachte die Entscheidung für eine Low-Code-Plattform auch Herausforderungen mit sich. Der Mangel an professionellem Support, z. B. durch einen eigenen myCBR-Kundendienst, könnte im Falle auftretender Softwareprobleme oder benötigter Anpassungen zu Schwierigkeiten führen. Auch die Dokumentation von Open-Source-Software weist Lücken auf, was ohne aktuelle und vollständige Anleitungen den Entwicklungsprozess behindern kann. Ferner besteht bei der Software grundsätzlich keine Garantie für Funktionalität oder regelmäßige Updates. Dieser Umstand stellt ein gewisses operationelles Risiko dar. Zusätzlich können Integrationsprobleme mit anderen (insbesondere kommerziellen) Systemen entstehen, die einen erhöhten Entwicklungsaufwand nach sich ziehen. Schließlich ist es möglich, dass die Software trotz ihrer Flexibilität bei besonders komplexen oder spezifischen Anforderungen an die Leistungsgrenzen stößt.

Zusammenfassend hat die Nutzung von myCBR als Low-Code-Plattform den Entwicklungsverlauf des Prototyps entscheidend geprägt und beschleunigt. Die positiven Aspekte wie Kostenersparnis, Benutzerfreundlichkeit und Unterstützung durch eine Community standen Herausforderungen wie dem Fehlen von professionellem Support und potenziellen Performance-Grenzen gegenüber. Die Erfahrungen zeigen, dass sorgfältige Abwägungen erforderlich sind, um zu bestimmen, ob und in welchem Ausmaß Low-Code-Plattformen wie myCBR den spezifischen Gegebenheiten eines Projekts entsprechen. Abschließend wird die Bedeutung des entwickelten Prototyps zur Rabattermittlung im Kundendienst sowie die sich daraus ergebenden Potenziale und Perspektiven zusammengefasst. Diese Arbeit verdeutlicht, wie die methodische Einbindung eines KI-basierten Prototyps zur Verbesserung von Kundendienstprozessen führen und signifikante wirtschaftliche Vorteile bieten kann. Ausgehend von den gewonnenen Erkenntnissen ergeben sich die folgenden Ansätze für weitere Forschungstätigkeiten: (1) Die Untersuchung der Skalierbarkeit des Prototyps im Hinblick auf unterschiedliche Märkte, was eine umfassendere Validierung der Applikation ermöglicht. (2) Umfangreiche Simulationen hinsichtlich der unterschiedlichen Kombinationsmöglichkeiten bei der Vergabe von Gewichtungen in myCBR und der Nutzung anderer Attribute, um die Genauigkeit und Effizienz der Rabattvorschläge zu verbessern. (3) Die Implementierung des Prototyps in unterschiedlichen Unternehmensumgebungen und die Anbindung an bestehende technische Systeme mit dem Ziel einen reibungslosen und automatisierten Datenaustausch zu gewährleisten. (4) Zusätzlich könnte die Einbindung von Typen von kaufenden Personen im Prototyp eine wertvolle Erweiterung darstellen, wobei spezifische Rabattstrukturen von kaufenden Personen auf Basis des Umsatzvolumens implementiert würden: Kaufende Personen mit signifikantem Umsatz könnten attraktivere Rabatte erhalten, während kaufende Personen mit weniger Umsatz zunächst mit moderateren Rabatten angesprochen werden.

Im Interesse einer transparenten und objektiven Forschungspraxis sei an dieser Stelle explizit darauf hingewiesen, dass im Kontext dieser Arbeit keine Interessenkonflikte bestehen. Sowohl die methodische Herangehensweise als auch die Analyse und Interpretation der Daten erfolgten unabhängig und unvoreingenommen.