#16 Tech Talk: Das brauchst du zur KI-Automatisierung

Jonas Wascheroh: einer der größten Fehler oder Probleme, wir sehen, ist einfach, dass man selber keinen guten Überblick über die eigenen Prozesse hat. wie zum Beispiel ein Bestellschatus behandelt werden soll. Aber es ist nirgends wirklich runtergeschrieben, das so einer KI gut verdaulich vorzugeben. Oder auch, dass z.B. jeder Mitarbeiter ein bisschen anderes Vorgehen hat und eine andere Meinung dazu hat, wie so ein Prozess auszusehen hat. Und hier auch wieder mit dem Gedanken rangehen. Da kommt jetzt ein neuer Mitarbeiter. Wie kann dieser Mitarbeiter möglichst schnell und einfach eingearbeitet werden? das fehlt dann oft und dann wird dann eben... mit der Erwartung angegangen. Die KI macht es schon, die ist ja schlau genug, aber wenn die KI eben selber nicht weiß, was sie denn tun soll, kommen wir eben wieder zum Thema Halluzination. also ganz klar No- oder Low-Code-Lösungen wie Zapier und n8n auf jeden Fall zum Start nutzen. Also ich schließe zum Beispiel mein Zen Desk an, sehe schon wie die einlaufenden Tickets und Kundenanfragen da reinlaufen, kann dann im nächsten Schritt, KI nutzen, zum Beispiel die Kundenanfrage zu klassifizieren und dann auch schon an das ERP-System zum Beispiel im nächsten Schritt auch mehr oder weniger No-Code gehen, Daten abzugreifen. Also mit No- und Low-Code-Lösung ist man da sehr schnell. Und wonach wir da immer schauen, dass die Systeme anbindbar sind. Das heißt, sie haben Schnittstellen, also sogenannte APIs. Das können entweder Standard REST APIs sein oder auch neuere Systeme wie Shopify zum Beispiel setzen auf GraphQL Schnittstellen. Und da ist eben ganz, ganz wichtig, dass die anbindbar sind, viele Systeme, auch ältere oder legacy Systeme werden on-premise gehostet, das heißt auf eigenen Servern oder hinter versteckten Türen quasi. Und da ist es eben wichtig, dass die Systeme auch von außen, also aus dem Internet, erreichbar sind, wenn man die quasi anbinden möchte.

Max: Moin und herzlich willkommen zu einer neuen Folge von Service Cells. Heute gehen wir mal richtig tief rein mit einem neuen Format, nämlich mit einem Tech Talk mit unserem CTO Jonas. Jonas, schön, dass du wieder da bist.

Jonas Wascheroh: Freut mich.

Max: Wir schauen uns an, welche ERPs, HepTest und Shops sich besonders gut eignen für Automatisierung und KI. Das habe ich mir in letzten Folge mit Jakob auch schon mal angeschaut, aber da haben wir so bisschen an der Oberfläche erst mal gekratzt. Und heute wollen wir wirklich so tief ins Detail zusammen mit Jonas gehen und vor allem auch darauf eingehen, welche Architektur-Patterns stabil laufen, was man bei Datenstrukturen beachten muss und wie aufwändig am Ende die Implementierung auch wirklich ist. Und Jonas, lass uns direkt reinstarten mit der ersten Frage. Wenn ich heute mit KI im Service automatisieren will, welche Kriterien muss ich dann beachten bei der Einführung von ERP, Shop und Helpdesk?

Jonas Wascheroh: Ja, genau. Also mit der Einführung von Systemen oder Tools fällt uns steht natürlich die ganze Automatisierung mit KI im Kundenservice. Und wonach wir da immer schauen, was ganz wichtig ist, eben, dass die Systeme anbindbar sind. Das heißt, sie haben Schnittstellen, also sogenannte APIs. Das können entweder Standard REST APIs sein oder auch neuere Systeme wie Shopify zum Beispiel setzen auf GraphQL Schnittstellen. Und da ist eben ganz, ganz wichtig, dass die anbindbar sind, also auch erreichbar sind. Also viele Systeme, auch ältere oder legacy Systeme werden on-premise gehostet, das heißt auf eigenen Servern oder hinter versteckten Türen quasi. Und da ist es eben wichtig, dass die Systeme auch von außen, also aus dem Internet, erreichbar sind, wenn man die quasi anbinden möchte. Dann ist natürlich auch ganz wichtig, wie man die anbindet, also wie authentifiziert oder autorisiert man sich. Gibt es da ein klassisch User and Password, wo man einfach Admin Zugriff auf alles hat. Das birgt natürlich dann auch immer Gefahren und Risiken oder kann man da auch gegebenenfalls einzelne Scopes verteilen, je nachdem, was man machen möchte, dass man zum Beispiel nur Bestellungen bearbeiten kann und einem nur Zugriffe darauf geben kann, was wirklich angefasst oder ausgelesen werden soll. Und natürlich auch ganz wichtig, dass diese Schnittstellen stabil sind, also sowohl stabil als auch gut dokumentiert, weil die beste Schnittstelle bringt einem nichts, wenn keiner weiß, wie sie funktioniert. Das heißt, öffentliche Dokumentation, dass man eben auch schon vorab sich mit der Datenstruktur und den Endpunkten vertraut machen kann, eine gute Versionierung und aber auch eine Zukunftsträchtigkeit, also dass die Schnittstellen auch gewartet werden, erweitert werden und nicht eben im nächsten Jahr zum Beispiel abgeschaltet werden. Kleiner Bonus, was wir auch immer gern sehen und was ganz hilfreich ist, ist, wenn es verschiedene Umgebung gibt, in denen man arbeiten kann, also so Sandboxing oder Staging Environments, damit man zum Beispiel gerade bei, sagen wir mal, schreibenden Zugriffen auf so Systeme, also wenn man zum Beispiel eine Bestellung verändern möchte, dass man da nicht auf Produktivdaten direkt zugreift, sondern erstmal in einem Testsystem arbeitet und dann das ganze Thema Observability oder Monitoring. dass man in dem System auch nachvollziehen kann, was denn passiert ist. gerade wenn man dann, da kommen wir auch denke später noch darauf zu, wenn man gerade Daten bearbeitet, also zum Beispiel eine Bestellung bearbeitet, dann ist es ganz wichtig, dass es irgendwo nachvollziehbar ist, wer und was quasi was geändert hat, das Ganze eben auch besser nachvollziehen zu können.

Max: gibt jetzt schon einige Kriterien, die die Systeme erfüllen müssen. nehme jetzt mal mit, dass eine vollständige Schnittstelle und eine saubere Dokumation vor allem sehr wichtig sind. Kannst uns da vielleicht paar Beispiele geben? Welche Systeme sind in der Praxis wirklich automatisierungsfreundlich?

Jonas Wascheroh: Wir teilen ja die Systeme in drei Kategorien ein, die man im E-Commerce benutzt. Also einmal das Shop-System, also das Storefront, was die Kunden benutzen. Da sehen wir am häufigsten oder am einfachsten anzubinden Shopify ganz klar. Also die haben ein super Schnittstellenangebot, super Dokumentation, erweitern die auch stetig. und sind da auch stark in dieser sogenannten Developer Experience. Also schauen wirklich aus Sicht eines Entwicklers oder einer Person, die quasi die Schnittstellen integrieren kann, wie man diese Experience verbessern kann. Also da ganz klar Shopify. Shopify hat auch gute Dokumentationen. Jetzt gerade ein System aus Deutschland auch. Ja, die nächste Kategorie ist dann das ERP-System, also vor allem essentiell für Unternehmen, die auch auf Marktplätzen verkaufen. Da geht es ja dann nicht mehr über das Shop-System nur, sondern geht direkt ins ERP-System. Da auch aus Deutschland ein System ist Xcentral. Die haben auch sehr gute Schildstellen-Dokumentationen. Die haben verschiedene Versionen, weil die sich auch mit der Zeit eben weiterentwickeln und auch nach und nach modernisieren. Und da haben wir Ja, viele gute Erfahrungen gemacht, was alles möglich ist. Aber auch so was wie Microsoft Dynamics ist sehr flexibel und sehr gut dokumentiert. Und auch etwas ältere Systeme wie JL, Vavi zum Beispiel hat jetzt zum Beispiel auch aktuell eine Schnittstelle, ein Beta-Programm und damit kann man auch einige Prozesse abbilden. Und dann zu guter Letzt. braucht man natürlich ein System, wo man die ganzen Kundenanfragen auch herausziehen kann. Das sind die Helpdesk oder Ticketsysteme. Und hier ist ganz klar Zendesk am besten zu integrieren, weil die auch eine gute Develop Experience haben, also sehr gute Dokumentationen und auch sowas wie Webhook Events mitbringen, wo wir oder wo man quasi benachrichtigt werden kann, dass es zum Beispiel neue Tickets, neue Kundenanfragen gibt.

Max: Du hast ja jetzt vorhin auch schon mal gesagt, dass man bei dieser Tool-Auswahl auch wirklich darauf achten sollte, dass es zukunftsträchtig ist, also dass man da auch lange mit arbeiten kann. Und das ist ja auch was, was wir sehen oder ich glaube, was viele Teams auch vernachlässigen, ist, dass sie gar nicht daran denken, bei der Tool-Auswahl, wie kann ich da später mal mit automatisieren? Weil vor allem bei kleinen Teams ist natürlich erst mal nicht so viel Automatisierung notwendig. Aber worauf sollte ich denn da jetzt wirklich bei der, wenn ich mir jetzt ein neues Shop-System einführe oder neue RP, worauf sollte ich dann da noch achten, damit das auch wirklich später mit der Automatisierung mit KI auch wirklich gut funktioniert.

Jonas Wascheroh: Genau, also wir haben schon das Thema Erreichbarkeit angesprochen. Also das ist quasi essentiell. Wenn das System eine Schnittstelle auch mitbringt, dann muss auch sichergestellt werden, dass die auch von außen erreichbar ist. Es sei denn, macht die ganze Automatisierung zum Beispiel auch inhouse, dann geht das natürlich auch. Und ganz klar, gute Dokumentation, also im besten Fall öffentliche Dokumentation, ⁓ eben die ganzen Endpunkte nachzuvollziehen. und quasi das gesamte Angebot an Endpunkten und Schnittstellen, die verfügbar sind, zu prüfen, ob alle meine Prozesse auch durch diese Funktionalitäten abgedeckt werden können. Weil das haben wir auch schon öfter gesehen. Gerade Systeme, die zwar eine vermeintlich starke Dokumentation und Schnittstelle mitbringen, sind dann sehr limitiert in dem, was sie können oder sehr komplex. Weil man vielleicht genau im umkehrschluss alles machen kann aber dadurch ist sehr komplex wird und dann aber auch ganz wichtig was wir auch immer sehen ist sicherstellen wo liegen denn wirklich die daten also gerade in einem tool umfeld wo es verschiedene tools gibt liegen daten gegebenenfalls an mehreren stellen und da eben sicherstellen wo liegt denn so die single source of truth also gerade dieses zusammenspiel von shop und erp system muss man oft schauen ob man an das Shop-System geht oder an das ERP-System, in welchen Prozessen muss man gegebenenfalls an beide Systeme gehen. Im Idealfall sollte da ein System eben geben, was so die Datenhoheit sicherstellt. Und das ist eben wichtig sicherzustellen. Und dann auch ganz klar aus Security-Sicht und Compliance-Sicht, dieses ganze Thema Rollen und Rechte ist extrem wichtig, dass so ein System da auch flexibel ist. so Rollen und Rechte einzustellen. Dadurch eben gerade bei Einsatz von KI, auch wenn man das Ganze mehr oder weniger autonom gestalten will, dass dann auch die KI wirklich nur auf das zugreifen kann, was sie auch wirklich darf. Weil wenn es quasi so ein Admin-Access gibt, dann hat man eben quasi ein Risiko mehr, dass gegebenenfalls Sachen bearbeitet werden, die man gar nicht bearbeiten lassen möchte. Dann eben noch aus technischer Sicht, gerade die Schnittstellen noch zu nutzen, dass entsprechende SLAs eingehalten und gegeben sind. Das heißt, die Schnittstelle muss auch verfügbar sein, also nicht nur erreichbar, sondern auch dauerhaft verfügbar sein und nicht zu viele Downtimes haben und entsprechende großzügige Limits zur Verfügung stehen. Also wenn man zum Beispiel nur einen eine Abfrage pro Sekunde an so System machen kann, dann ist das ein krasses Bottleneck in der Automatisierung bei vielen Hunderten oder Tausenden Anfragen, wenn man sehr lange warten muss, bis man wieder an das System gehen kann.

Max: Ich glaube, man sieht, wie viel man dann doch beachten muss bei der Tool-Auswahl. vorsichtig zu sein und vor allem, wenn man plant, hinten raus wirklich viel zur Automatisierung oder KI einzusetzen, sollte man wirklich auf diese ganzen Kriterien achten. Das ist wichtig. In der letzten Folge haben Jakob und ich auch schon über das Thema Middleware geredet und wie die da jetzt so reinspielt in das ganze Thema und wie die auch hilfreich sein kann. Da gibt es ja Tools wie Zappier, Make oder N8N. Was würdest du denn sagen, Jonas, welche Rolle spielt sie auch so in dieser ganzen KI-Automatisierung?

Jonas Wascheroh: Genau, also spielt eine essentielle und wichtige Rolle. Also wenn man sich diese ganzen Tools eben so als kleine Bausteine oder Lego-Blöcke vorstellt, dann ist eben so eine Middleware wie zum Beispiel N8N oder eine eigengeschriebene Lösung eben so das ganze Feld, auf dem man diese Bausteine zusammenbauen kann, weil die Bausteine selber, die sind zwar nützlich, aber die müssen irgendwo zusammenlaufen und benutzbar sein. Und genau das macht eben so eine Middleware. Also am konkreten Beispiel von n8n lassen sich dann sogenannte Workflows aufsetzen, die so Prozesse durchlaufen können. Das heißt, da hätten wir so diesen ganzen gesamten Ablauf von Kundenanfrage kommt rein. Also kann abgefragt werden zu diesen ganzen KI-Layer, also wie und was macht die KI und dann auch an die einzelnen Systeme gehen, ⁓ Daten wirklich abzurufen oder gegebenenfalls auch zu verändern. Also zum Beispiel das ERP-System in diesen Workflows auch zu nutzen und dann entsprechend auch wieder als letzten Schritt, diese ganze Automatisierung auch vollständig zu haben, auch wieder die Anfrage zurück an den Kunden zu stellen.

Max: Genau, und bei diesem Middleware, gibt es ja auch Unterschiede, wie komplex die auch teilweise sind. Also da gibt es jetzt ganz klar so No-Code-Lösungen. Das ist bei Zapier zum Beispiel auch viel so. Oder auch eben Custom, wo man auch wirklich Custom-Code eingeben kann, was ja zum Beispiel bei n8n auch möglich ist. Was würdest du sagen, wann benutze ich am besten was?

Jonas Wascheroh: Ja, also ganz klar No- oder Low-Code-Lösungen wie Zapier und n8n auf jeden Fall zum Start nutzen. Also damit kann man sehr, schnell die ersten Ergebnisse sehen. Also ich schließe zum Beispiel mein Zen Desk an, sehe schon wie die einlaufenden Tickets und Kundenanfragen da reinlaufen, kann dann im nächsten Schritt, also im nächsten Knoten von so einem Workflow KI nutzen, zum Beispiel die Kundenanfrage zu klassifizieren und dann auch schon an das ERP-System zum Beispiel im nächsten Schritt auch mehr oder weniger No-Code gehen, Daten abzugreifen. Also mit No- und Low-Code-Lösung ist man da sehr schnell. Aber man kennt das ja auch dann im Praxisalltag im Kundenservice. Nicht jeder, nicht jede Kundenanfrage ist gleich. Es gibt auch mal mehr oder weniger komplexe Anforderungen und Anfragen. Und da wird es dann auch in solchen No- and Low-Code-Lösungen sehr komplex. Gerade wenn man verschiedene Textblöcke oder Blöcke allgemein wiederverwendbar machen möchte, da wird es dann sehr komplex oder auch gerade bei einer großen Anzahl an Prozessen, die man automatisieren will. Und da verliert man auch häufig den Überblick. Und dann ist aber auch das ganze Thema Verfügbarkeit, Erreichbarkeit und Performance enorm wichtig, weil gerade im Kundenservice spricht und verarbeitet man dann eben auch sehr viele Anfragen und da stoßen dann solche Lösungen auch an ihre Grenzen. Da muss man dann immer schauen, wie aufwendig diese Prozesse dann auch wirklich sind.

Max: Also ich würde sagen, egal ob No Code, Low Code oder Custom, es lohnt sich auf jeden Fall in der Middleware einzuführen oder sich das auch mal anzuschauen, weil da einfach super viele Möglichkeiten sind, wie man eben automatisieren kann. Wir wollen uns jetzt aber im nächsten Schritt einmal auch das ganze Thema Architektur anschauen und wie denn eine saubere Architektur aussieht, wenn man vor allem jetzt so ja Prozesse wie Bestellstatus, Stornos oder Rechnungen automatisieren will. Wie sieht es genau aus oder wie kann da die KI das auch wirklich selbstständig handeln?

Jonas Wascheroh: Ja, also da würde ich immer versuchen, ranzugehen, zu überlegen, wie sieht quasi so ein Prozess gerade aus, also in der manuellen Bearbeitung. Und dann geht man von vorne bis hinten einmal durch und versucht diese Schritte dann auch in so einem KI-Agenten abzubilden. Das heißt, wir schauen uns erstmal an, über welchen Kanal sprechen wir eigentlich, also wo kommen die Kundenanfragen rein? Ist es eben Zum Beispiel ein Chatbot, es WhatsApp, ist es Telefon oder eben per E-Mail. Im Beispiel von E-Mail laufen die Anfrage dann in häufigerweise in Helpdesk-Systemen wie Zendesk oder kann auch zum Beispiel in Outlook reinlaufen. Und wenn wir bei Zendesk sind, können wir da eben dann auch benachrichtigt werden, wenn es Kundenanfragen gibt. Und da ist quasi der Einstiegspunkt. Das heißt, erst mal diese ganze Channel Engine. Wir sagen hier gibt es eine neue Kundenanfrage und die fangen wir an zu verarbeiten und zu automatisieren. Das heißt, haben im ersten Schritt diese ganze Kundenanfrage vorliegen und dann geht es schon mit KI weiter. Und die KI entscheidet dann erstmal, worum geht es überhaupt. Also die ganze Orchestrator-Layer kann man das nennen. Also zu entscheiden, wo geht es hin, wo geht es weiter. kann zum Beispiel sein, dass die Nachricht eine Systemnachricht ist, Newsletter, eine Spam-Anfrage, das heißt, hier muss erstmal gecheckt werden, was geht es überhaupt, welches Thema ist es, wollen wir das überhaupt automatisieren und es richtet sich auch stark nach der ganzen Business-Logik und was man quasi im Vorfeld auch definiert hat. Also zum Beispiel hat man eine große Blacklist an Newsletter-Mails oder eben Spam-Mails, die man direkt blockieren möchte, dass man da auch keine Gefahr läuft, falsche Informationen rauszusenden oder auch Kosten zu sparen. Und dann geht es quasi weiter, wenn wir Orchestrator-Layer quasi entscheiden, okay, hier haben wir zum Beispiel eine Anfrage zum Bestellstatus, dann geht es weiter in die, ja, man kann sich vorstellen, wie so Sub-Workflows oder Sub-AI-Agents, die sich nur diesen Prozess von einem Bestellstatus kümmern, das heißt, die sind dann für diesen Workflow, für diesen Prozess und die fangen dann an mit der Verarbeitung. Also die schauen, was hat der Kunde zum Beispiel eine Bestellnummer angegeben. Wenn nicht, ist die E-Mail bekannt. E-Mails haben wir direkt die E-Mail-Adresse des Kunden. heißt, hier haben wir erstmal dann alle Informationen zur Extraktion parat. Und sobald wir die dann haben, kann es dann eigentlich an die jeweiligen Shop oder ERP-Systeme gehen. Das heißt, wir prüfen, haben wir eine Bestellnummer oder haben wir eine E-Mail-Adresse. Und dann, je nachdem, was gegeben ist, bedienen wir gegebenenfalls auch verschiedene Endpunkte. gerade in ERP-Systemen gibt es zum Beispiel eine Suche nach einer Bestellung. Das ist ein häufiger Endpunkt. Und da lässt sich dann angeben, ob man die Bestellnummer oder die E-Mail-Adresse als Such-Filter oder Suchkriterium übergeben möchte. Und das wird dann da übergeben. Dann wird die Anfrage gemacht an das ERP-System und mit der Rückgabe wird dann weiter gemacht. Und da geht dann auch wieder diese Business-Logik los. Grundsätzlich lässt sich immer sagen, an den Stellen, wo wir quasi feste Überprüfung machen, empfehlen wir auch keine KI einzusetzen, damit wir einfach das Risiko an Halluzinationen und quasi Fehlschritten vermeiden können. Und hier können wir eben genau das machen. Das heißt, schauen, wurde eine Bestellung gefunden oder nicht. Wenn nicht, dann können wir einen anderen Fahrt weitergehen oder wieder zurück an den Orchestrator gehen. Oder wenn eben eine Bestellung gefunden wurde, können wir hier auch nochmal konkret prüfen, ist es auch wirklich die Bestellung von dem Kunden. Das heißt, match die Bestellnummer. oder match die E-Mail-Adresse und können dann die Informationen aus dieser Bestellung auslesen. Also was wir im Case von Bestellstatus häufig machen, ist dann genau den Status auszulesen und den Tracking-Link oder die Tracking-ID, dann zum Beispiel an Versanddienstleister zu gehen, wirklich die exakte Location oder den exakten Status der Lieferungen nachzuvollziehen. Und das Ganze wird dann quasi angereichert, wird der KI wieder zur Verfügung gestellt, dann die finale Antwort zu bilden. Da ist eben durch KI dieser Vorteil, dass dann die Antwort keine Standardantwort ist mit, hier ist der Status Doppelpunkt XY, kommt dann genau, je nachdem, was der Kunde geschrieben hat, bekommt der Kunde dann auch eine passende Antwort in dem Tonfall, in der Art und Weise, wie man es auch definiert hat. Dann ist aber auch ganz wichtig, das Thema, das wird häufig dann auch vergessen in der Architektur, das ganze Thema Logging oder Monitoring, das heißt nachzuvollziehen, was die KI gemacht hat, an welchen Stellen und warum. Also ein sogenanntes Reasing mit dabei und das Monitoring auch vor allem ⁓ die genauen Prompts nachzuvollziehen. gemacht wurden an die Large Language Model. weil wenn das nicht gegeben ist, besteht im Nachhinein auch keine Möglichkeit mehr, den gesamten Ablauf nachzuvollziehen und auch den Ablauf zu verbessern.

Max: du hast das Thema Halluzination eben auch schon mal angesprochen und da auch schon eigentlich gesagt, was man so bisschen dagegen machen kann. Aber ich glaube, das ist immer noch ein wichtiges Thema, was viele auch beschäftigt, weil man will ja vor allem bei kritischen Anfragen keine falschen Informationen rausgeben. Was sind denn da noch so für Maßnahmen, die man ergreifen kann, ⁓ zu verhindern, dass die KI halluziniert?

Jonas Wascheroh: Mhm. Ja, beim Prozess angefangen ist es erstmal ganz wichtig, erstmal zu definieren, wie der Prozess genau aussieht. es ist zum Scheitern verurteilt, wenn man einfach nur bei Bestellschattos sagt, hier ist der Use Case und die KI soll schauen, wie sie antwortet, weil der vermeintlich einfache Case von Bestellschattos hat dann doch sehr, sehr viele Unterschiede und Feinheiten, je nachdem was eine Kombination aus der Bestellung und dem Versandstatus ist, wo das Paket liegt, ob es gegebenenfalls schon zurückgeschickt wurde. Da gibt es sehr, viele Feinheiten. Und genau diese Feinheiten sind wichtig, in der Definition festzuhalten. Also genauestens zu dokumentieren und der KI anzuweisen, was wann gemacht werden soll. Und da auch wirklich zu prüfen. bei diesem Thema, was wann gemacht werden soll, zu entscheiden, brauchen wir hier KI. Also sogenannte deterministische Checks, also Sachen, die bei jeder Eingabe auch die gleiche Ausgabe haben sollen, die sollen möglichst ohne KI gemacht werden, hier einfach das Risiko von Halluzinationen zu senken. Also gerade eine Prüfung auf die Bestellnummer. ob die zusammen, ob die match zu dem, was wir gefunden haben, oder eben Name oder Adresse zu matchen. Dafür braucht man keine KI. Das sind einfache Vergleiche. Und genau solche Entscheidungen sollten sich durch den gesamten Prozess ziehen, hier die Gefahr von Halluzination zu vermeiden. Also grundsätzlich einfach KI nicht einfach überall einzusetzen, sondern wirklich an den Stellen, wo es notwendig ist. Und dann aber auch ganz wichtig direkt an das Human Handover denken. Also zu überlegen, an welchen Stellen soll und darf die KI gegebenenfalls gar nicht weitermachen, sondern soll an einen Menschen übergeben. Da gibt es verschiedene Ansätze. Man kann mit so Confidence Thresholds arbeiten. Das heißt, man lässt immer die KI noch zusätzlich so einen Wahrscheinlichkeitswert definieren. Zu wie viel Prozent ist die KI sich zum Beispiel sicher? Und ab einem bestimmten Wert kann man auch sagen, okay. Hier sind wir uns nicht mehr sicher. Hier gehen wir an Agenden, an Menschen über. Dann aber auch ein weiteres Thema, was enorm wichtig ist, ist einfach die Datenbasis und die Datenqualität sicherzustellen. wenn nur sehr, sehr wenig oder sehr, sehr vage Informationen als Basis für eine Antwort zur Verfügung stehen, dann erhöht uns eben massiv die Wahrscheinlichkeit von Halluzinationen. Wenn jetzt bei einem Bestell- Versandstatus zum Beispiel sehr genau zurückkommt, wo ist die Bestellung und warum wurde die zum Beispiel zurückgeschickt, zum Beispiel die wurde an, es konnte kein, es hat keiner die Tür aufgemacht zum Beispiel, dann kann die KI damit klar arbeiten. Wenn eben wenig drinsteht, sondern nur nicht zugestellt, dann erhöht das einfach die Wahrscheinlichkeit, dass die KI da was dazudichtet. weil sie denkt, wir müssen dem Kunden jetzt eine möglichst gute Antwort geben.

Max: uns mal zum Thema Implementierung kommen. Da stellt sich hier häufig auch die Frage, wie aufwendig ist das Ganze. Vor allem wenn wir jetzt darüber nachdenken, was wir jetzt schon alles besprochen haben und worauf man alles achten muss, haben da glaube ich immer viele Angst vor dem Aufwand, der da auf einen zukommt. Wirklich von Kickoff bis Live-Gang. Gib uns mal eine ehrliche Roadmap, Jonas. Wie sieht das Ganze aus?

Jonas Wascheroh: Ja, also wenn man das wirklich so from scratch alles selber aufbauen will, dann gibt es ja verschiedene Phasen, die man durchlaufen kann. Also erstmal so die Discovery-Phase, wo man erstmal checkt, was für Tools haben wir alles, welche Zugänge sind möglich zu den Tools, wie sehen die Zugänge aus, welche Prozesse haben wir, also genauestens erstmal definieren. ohne irgendwas schon technisch zu implementieren. Da kann man so von, sagen wir, 1 bis 2 Wochen, wenn man sich damit wirklich intensiv auseinandersetzt, reden. Das heißt, erst mal einen groben Plan aufstellen, was man machen will und auch die Risiken abschätzen. Und dann kann man eigentlich schon in so eine Prototypphase gehen, also einen MVP anfangen. Hier empfehle ich z.B. N8N. als Tool, das Ganze schnell und einfach aufzusetzen. Da aber auch auf wenige Use Cases fokussieren. Also wenn man merkt, das Thema Bestellstatus macht eben den Großteil meines Service-Volumes aus, dann macht es Sinn auch, sich erstmal auf den zu fokussieren. Wie gesagt, da gibt es viele, viele Feinheiten, deswegen das nicht unterschätzen, dass so ein Use Case auch aufwendig werden kann. Da empfehle ich so drei bis sechs Wochen einzuplanen, auch mit dem ganzen Thema. Testing und Monitoring, weil den ersten Prompt, den man schreibt, der wird nicht bleiben, sondern wird es über die Zeit noch verändern. Man wird viele verschiedene Szenarien auch begegnen, wenn man auch viele verschiedene Kundenanfragen bearbeiten lässt. Also hier drei bis sechs Wochen circa. Und dann das Ganze eben mit weiteren Use Cases aufbauen und eben versuchen, skalierbar zu machen. Da ist natürlich umso mehr Use-Cases, umso mehr Kundenanfragen reinkommen, umso schwerer wird es auch, das Ganze auch stabil zu halten, den Überblick zu behalten, das ganze Thema Monitoring auch gut zu lösen und auch einen Überblick zu haben, wie kann ich das ganze System verbessern. Da geht dann eigentlich die Hauptarbeitenzeit drauf und es sind auch mal so sechs bis zwölf Wochen, bis man das alles drin hat und dann über die Zeit, wenn es System steht, das ganze Thema Wartung, also zu schauen, dass es läuft, wie kann man es verbessern, reviewen und gegebenenfalls neue Use Cases auch implementieren. Das ist natürlich aber auch noch stark variabel oder kommt darauf an, wie komplex wirklich die Prozesse sind, man hat. Deswegen kann sich quasi jeder dieser Phasen auch nochmal den Faktor verlängern.

Max: und es kommt auch letztendlich darauf an, welche Tools benutzt du jetzt auch wirklich und wie einfach sind die anbindbar. Da hast du ja auch schon mal einige Kriterien angesprochen.

Jonas Wascheroh: Genau, richtig. wenn man z.B. Shopify Sender Central nimmt, dann ist es sehr einfach. Da gibt es gegebenenfalls auch schon vorgefertigte Templates, die man nutzen kann. Aber mit jedem weiteren System oder komplexen System schaukelt sich das dann natürlich weiter hoch.

Max: Genau und an der Stelle vielleicht auch noch mal ein klein bisschen Werbung für uns, ⁓ darauf hinzuweisen, dass wir das in der Implementierung auch also vieles davon übernehmen mit unseren Kunden und da auch schon einige Tools tief integriert sind. Aber natürlich so Sachen wie die Datenzugänge zu klären oder auch zu wissen, wo die Daten liegen oder wie die Tools funktionieren, das ist natürlich dann auch ein Stück weit unseren Kunden überlassen. Aber da sind wir dann immer da, ⁓ Support anzubieten und unterstützen da eben auch wirklich bei der ganzen Implementierung. Kommen wir aber mal zum ganzen Thema Datenstruktur. Welche Art von Datenstruktur brauchst du denn, damit Automatisierung wirklich stabil ist und am Ende auch skalierbar läuft?

Jonas Wascheroh: Ja, also da natürlich darauf achten, dass die, dass dieses Thema auch die Daten hergeben, wie sie auch quasi logisch angeordnet sind. Das heißt, gerade im E-Commerce, im Kundenservice ist die Grundlage ja immer eine Bestellung, also die Order. Zu einer Order, zu der Bestellung gehörten Kunde. Der Kunde kann auch mehrere Bestellungen haben und dann hat natürlich jede Bestellung auch Bestellpositionen, also je nach System, manche nennen es Items, manche Positions, hat man dann eben die Übersicht, was wurde bestellt, das ist eben enorm wichtig, dass man die Information hat, auch gerade in Use Cases, wo Kunde mehrere Pakete oder mehrere Artikel bestellt hat und es wird nur nach einem von diesen Artikeln eine Rückfrage gestellt oder der Status abgefragt, da ist es natürlich wichtig, dass man auch die Information hat, welche Artikel gibt es überhaupt in der Bestellung. Und dann ganz wichtig sind auch das Thema Fulfillment und Payment. einmal zu wissen, wo liegt es, wurde es bereits versandt, mit wem wurde es versandt, wie ist da die Tracking ID oder der Tracking Link. Einfaches Beispiel ist zu sagen, es wurde mit DRL verschickt, das ist die Tracking ID von DRL. Dann kann man zum Beispiel bei DHL auch weitermachen, den genauen Status abzufragen. Und dann auch das Thema der Zahlungsinformationen, also wurde bereits bezahlt, ist vielleicht noch ein Betrag offen. sehen wir auch häufig in Rückfragen zu Zahlungen, wenn vielleicht noch ein Restbetrag offen ist und der Kunde beschwert sich, dass er eine Mahnum bekommen hat. Da kann man eben ganz transparent aufzeigen, hier du hast noch x Euro offen und dass es dann eben damit steht und fallen dann auch einzelne Use Cases. Ganz wichtiger Punkt beim Thema Datenstruktur ist auch, wie man auch solche Datensätze identifizieren kann, also so eindeutige Schlüssel zu finden, weil was wir häufig in der Praxis sehen, ist, dass manche Systeme verschiedene Arten von solchen Schlüsseln Verfügung stellen. Das heißt einmal zum Beispiel eine interne ID, wie das System selber so einen Datensatz, also zum Beispiel eine Bestellung identifiziert und dann noch eine externe ID, also was der Kunde wirklich am Ende bekommt, also die klassische Bestellnummer. Und da ist es eben wichtig zu wissen und zu definieren, was brauchen wir wann. Also der Kunde, der Endkunde kennt zum Beispiel selten die interne ID, die Shop oder ERP-System. intern braucht, damit das funktioniert, sondern kennt nur eben die Bestellnummer. Wenn jetzt so ein System aber nur mit diesen internen Schlüsseln zum Beispiel umgehen kann, dann haben wir ein Problem, weil dann bedeutet das am Ende, wir haben keine Möglichkeit, nach dieser externen Bestellnummer zu suchen und finden die Bestellung nicht und können dann den Kundenservice nicht automatisieren. Also das ist enorm wichtig, da immer den Überblick zu haben, welche Nummern sind für was und das auch immer aus Kundensicht zu betrachten. Genau. Und dann auch wichtig, das ganze Thema der Nachvollziehbarkeit, also dass die Daten entsprechend mit Zeitstampeln angereichert sind, dass wir nachvollziehen können, wann die erstellt wurde, wann sie bearbeitet wurde. Eventuell gibt es Versionshistorien, wo man auf bestimmte Versionen zurückblicken kann. Und dann aber auch das ganze Thema der Business Logik, also wann zum Beispiel eine Bestellung storniert werden kann, hängt von verschiedenen Faktoren ab, ob zum Beispiel die Bestellung bereits verschickt wurde oder nicht, ob die bereits bezahlt wurde oder nicht. Aber da gibt es viele, viele Abhängigkeiten, das System sicherstellen muss, dass die abgedeckt werden. Und hier auch nochmal mein Hinweis oder meine Empfehlung, auch bei einer Auswahl von Tools zu schauen. dass das die Systeme auch direkt mitbringen, also diese diese Checks, weil wenn quasi man selber als Anwender oder jemand, der so ein System integrieren möchte, sicherstellen muss, dass so eine Bestellung zum Beispiel wirklich storniert werden kann, da läuft man halt immer Gefahr, dass man gebenfalls Sachen macht oder Sachen bearbeitet, die so gar nicht vorgesehen waren. Hat man auch schon mal in der Praxis gesehen, dass So Systeme das einfach zur Verfügung stellen, gerade auch wenn die sehr flexibel sind. Und dann fängt man an, die interne Business Logik nachzubauen. Und deswegen soll man versuchen zu schauen, dass die Systeme das auch direkt mitbringen und entsprechende Fehlercodes zum Beispiel zurückschicken, falls man sowas versuchen möchte.

Max: Dann lassen wir uns direkt rüber gehen zum nächsten Punkt. Ganzes Thema Security und Compliance ist ja auch ein super wichtiges Thema. Was sind da deiner Meinung nach die Must-Haves bei Sicherheit und Monitoring, wenn es vor allem um KI geht und die Einführung von KI?

Jonas Wascheroh: Genau, also gerade mit KI finde ich immer, das hatte ich schon mehrfach erwähnt, ganz wichtig, das Thema Rollenrechte, also wirklich der KI nur die notwendigen Rechte zu geben, vom Thema Least Privilege zu denken. Man kann sich das auch vorstellen, answird jetzt ein neuer Mitarbeiter anfangen, der eben nur für bestimmte Use Cases oder Prozesse zuständig ist. Dem will man ja auch nicht einfach alle Rechte geben, keinen Admin Zugriff und eben hier auch wirklich nur so viel Rechte geben, wie notwendig ist. Und ganz wichtig ist eben das Thema Nachvollziehbarkeit. Also Auditing, Logging, Monitoring zu schauen, kann ich nachvollziehen, was die KI gemacht hat. Weil gerade eben wenn man mit so Low oder No-Code-Tools anfängt, wie Zapier und N8N, kommt man sehr schnell sehr weit, aber man verliert da schnell den Überblick, was wirklich gemacht wurde und warum manche Sachen gemacht wurden. gerade eben das Thema Auditing ist dann eben ganz wichtig, auch aus Compliance Sicht sicherzustellen, was gemacht wurde. Dann eben aus Security Sicht auch, ⁓ gerade auch keine oder gegebenenfalls Strafen bei Systemen zu bekommen, sicherstellen, dass man diese Rate-Limits von so Systemen entweder umgeht oder bisschen abfedern kann, indem man bestimmte Anfragen zeitversetzt machen kann, da eben nicht an Bottle-Legs von den Systemen zu kommen. Zum Thema Datenschutz auch hier versuchen, wirklich die notwendigen Informationen zu benutzen, gerade wenn es beim Thema KI da umgeht, Prompts zu erstellen und zu versenden, wirklich nur die notwendigen Informationen, also personenbezogenen zu nutzen, die für so einen Use-Case, für so einen Prozess wirklich notwendig sind, also nicht konkret die gesamte Bestellung dampen, sondern vielleicht nur den Status oder gegebenenfalls die Artikel nutzen. eine Antwort zu generieren.

Max: Lass uns am Ende noch ein bisschen in die Praxis reingehen. Du warst ja jetzt auch schon bei vielen Projekten mit Kunden mit dabei. Was sind so Fehler, die du da immer siehst und was würdest du sagen, wie kann man die am besten vermeiden? Jetzt auch mal für alle Zuhörer, damit die nicht dieselben Fehler begehen.

Jonas Wascheroh: Ja, also einer der größten Fehler oder Probleme, wir sehen, ist einfach, dass man selber keinen guten Überblick über die eigenen Prozesse hat. Also man hat die vielleicht immer so gemacht oder man hat die im Kopf, wie zum Beispiel ein Bestellschatus behandelt werden soll. Aber es ist nirgends wirklich runtergeschrieben, das so einer KI gut verdaulich vorzugeben. Oder auch, dass z.B. jeder Mitarbeiter ein bisschen anderes Vorgehen hat und eine andere Meinung dazu hat, wie so ein Prozess auszusehen hat. Also hier einfach fehlt ein klarer Standard, wie dieser Prozess aussehen muss. Und hier auch wieder mit dem Gedanken rangehen. Da kommt jetzt ein neuer Mitarbeiter. Wie kann dieser Mitarbeiter möglichst schnell und einfach eingearbeitet werden? Mit allen Informationen, die er hat, die er braucht. Und das fehlt dann oft und dann wird dann eben... erwartet oder mit der Erwartung angegangen. Die KI macht es schon, die ist ja schlau genug, aber wenn die KI eben selber nicht weiß, was sie denn tun soll, kommen wir eben wieder zum Thema Halluzination. Das klingt erst mal vielleicht ganz gut, was die KI sagt, aber am Ende ist da viel Halluzination dabei. Also das ist eben extrem wichtig. Dann eben auch, was wir bereits vorher angesprochen haben. noch mal zu entscheiden und unterscheiden, an welchen Stellen KI konkret eingesetzt werden soll. Also nicht einfach nur KI auf alles drauf lassen und draufsetzen, sondern entscheiden, welchen Stellen, zum Beispiel für das Holen der Bestellnummer, also die Extraktion von Informationen für Generierung von Antworten, Entscheidung von bestimmten Themen, also der Themenklassifizierung. Also wirklich einzelne Punkte, wo man KI einstreuen möchte, macht den Unterschied, anstatt einfach KI auf alles drauf zu lassen, weil sonst auch wieder Halititationen zustande kommen. Dann ein großer Punkt, den wir auch bei uns MeLiVo dann quasi auch mit anbieten und lösen, ist eben das Thema Observability und Monitoring. Also hatten wir auch schon erwähnt. dass solche Tools, No-Code-Tools etc., oder gerade wenn man es selber baut, keine Möglichkeit bieten, wirklich nachzuvollziehen, was in der Unterhaltung passiert ist und warum es passiert ist mit KI. Und hier bieten wir zum Beispiel direkt eine Möglichkeit bei uns auf der Plattform an, wirklich jede Unterhaltung nachzuvollziehen, zu sehen, wo kam die Antwort her. Und vor allem ganz wichtig, auch eine Möglichkeit bieten, Kundenanfragen direkt nachzutrainieren, also die KI stetig zu verbessern, weil das ist dann auch bei so No Code Tools oder Custom Lösungen nur quasi sehr mühsamig möglich, indem man wieder den Code oder die ganzen Prompts nochmal händisch anpassen muss. Und dann natürlich großer Fehler, den wir sehen, ist das Thema Datenhygiene. Also wenn selber die Systeme nicht genug Daten hergeben oder unzureichend gemapped werden oder unzureichend dokumentiert werden, vielleicht missverständlich Felder ausgegeben werden. Das führt dann auch dazu, dass einfach bestimmte Use Cases rein vom Datengehalt gar nicht automatisiert werden können. Also das gilt dann auch im Vorfeld schon zu klären. Und dann, gerade wenn es schreibende Zugriffe geht, also wenn es das Thema Bestellungen ändern zum Beispiel geht, dass wir da keine extra Staging oder Testumgebung haben, ⁓ auch Änderungen vorab zu testen. Weil sobald es dann wirklich an Live-Daten geht, kann man sich da keine Fehler mehr erlauben.

Max: Super, danke dir Jonas. Ich würde mal so bisschen zusammenfassen. Es waren jetzt viele Infos heute. Es war ein richtiger Deep Dive, richtig tief auch technisch reingegangen. Aber ich würde einfach mal sagen, also wirklich für eine erfolgreiche Automatisierung mit KI im Kundenservice, also die steht und fällt wirklich mit einer starken API, mit guter Dokumentation, mit einer soliden Mittelware, die man auch benutzen kann, egal ob jetzt No Code, Low Code oder... Custom und einer klaren Datenstruktur. Und da hast du ja wirklich schon viele Kriterien genannt. Kannst du vielleicht nochmal so uns drei konkrete Steps geben, jetzt vor allem für unsere ZuhörerInnen, wie sie da jetzt so vorgehen könnten.

Jonas Wascheroh: Ja, also, erster Punkt, jeden Fall erst mal alle Systeme und Tools checken und prüfen, die man im Einsatz hat, ob da Systeme in Frage kommen, also haben die öffentliche Schnittstellen zur Verfügung, sind die gut dokumentiert, kann ich da vielleicht auch mal einen Test machen, also erst mal das Tooling sicherstellen. Wenn ich da auch grad schon mal Testabfragen mache und die Dokumentation durchgehe, zu schauen, habe ich alle Daten, die ich brauche, ⁓ die Prozesse im Kundenservice zu automatisieren. sind die Bestelldaten vollständig, habe ich eine Verknüpfung zum Beispiel zum Versanddienstleister, habe ich den Namen des Kunden etc. Also ist die Datenhygiene gegeben und dann wirklich so iterativ vorzugehen. Also nicht gleich an Tag 1 100 % versuchen, sondern nach und nach mit den häufigsten Use Cases starten, klein starten, bis man erste Folgen sehen kann und dann nach und nach das Ganze ausbauen.

Max: Super, dank dir. Das war es dann auch heute mit unserem Tech Talk. Ich hoffe, es euch gefallen hat und lasst uns gerne mal Feedback da. Folgt uns auf LinkedIn, da posten wir auch regelmäßig zu all diesen Themen. Dank dir, Jonas, nochmal, dass du dabei warst heute mit allem Wissen.

Jonas Wascheroh: Seigann

Max: Und folgt gerne auch Jonas auf LinkedIn, ist da auch aktiv und teilt den Podcast gerne. Lasst ein Like da oder abonniert es auf Spotify. Wir hören uns bei der nächsten Folge Service Sales.