Kundenübersicht
Branche: Finanzen
Unternehmensgröße: 50-100 Mitarbeiter
Hauptangebot/Produkt: Finanzberatungsdienstleistungen
Ausgangssituation & Herausforderungen
Ausgangspunkt: Die Berater führten nach Bedarf Gespräche mit ihren Kunden. Im Anschluss an diese Anrufe mussten sie die Besprechungen im ausgewählten CRM-System dokumentieren. Dieser Dokumentationsprozess nahm für die Berater sehr viel Zeit in Anspruch und erwies sich als Hindernis bei der Erreichung ihrer Produktivitätsziele. Erschwerend kam hinzu, dass das Unternehmen zusätzliches Personal einstellte, um ROAs (Record of Advice / Beratungsprotokolle) und SOAs (Statement of Advice / Beratungsdokumentationen) zu entwerfen, mit dem Ziel, die Arbeitsbelastung der Berater bei solchen Aufgaben zu senken.
Zentrale Problempunkte (Key Pain Points):
Um die Arbeitslast der Berater zu verringern, musste das Unternehmen Prozesse für Rekrutierung, Einarbeitung und Management von Mitarbeitern durchlaufen, die für die Erstellung von ROAs und SOAs eingestellt wurden. Dies führte zu zusätzlichen Kosten und erhöhte die Arbeitsbelastung der Führungskräfte / der für die Schulung verantwortlichen Mitarbeiter.
Die Dokumentation der Besprechungen kostete zusätzliche Zeit und musste äußerst gründlich sein, damit das Zusatzpersonal, das an den ROAs und SOAs arbeitete, über alle notwendigen Informationen verfügte. Dies resultierte in einer zusätzlichen Arbeitsbelastung für die Berater und in Mehrkosten für das Unternehmen.
Unser Ansatz & Ergriffene Maßnahmen
Analyse & Einblicke:
Wir baten darum, uns beispielhafte Aktennotizen (interne Dokumentationsdateien), ROAs und SOAs sowie die Vorlagen für diese Dokumente zur Verfügung zu stellen (darunter mehr als 10 verschiedene ROA-Vorlagen).
Nachdem wir uns mit dem Material und der Komplexität dieser Dokumente vertraut gemacht hatten, baten wir darum, an einer Schulungssitzung für die neuen Mitarbeiter teilzunehmen, die für die Erstellung von ROAs und SOAs zuständig sein würden. So wollten wir vollständig verstehen, welche relevanten Informationen bei der Erstellung von ROAs und SOAs berücksichtigt werden müssen. Unser Partner stellte uns Aufzeichnungen von Schulungen früherer Teammitglieder zur Verfügung, die alle von uns gewünschten Punkte abdeckten.
Schließlich forderten wir die Aufzeichnungen von Beratungsgesprächen sowie die dazugehörigen Aktennotizen und ROAs an, um die Beziehung zwischen dem Input aus dem Meeting und dem von unserem Partner erwarteten Output vollständig zu erfassen.
Anforderungen und Erwartungen:
Nach Beratungen wurde beschlossen, diesen Prozess vollständig zu automatisieren, wobei der Workflow direkt nach Beendigung des Beratungsgesprächs beginnen sollte.
Bevor der Prozess vollständig automatisiert wurde, schlug das Braynex-Team vor, eine UI-App (Benutzeroberfläche) zu entwickeln. Diese sollte es den Mitarbeitern ermöglichen, das Tool über einen längeren Zeitraum produktiv zu nutzen, um mögliche Randfälle (Edge Cases) aufzudecken, die auftreten könnten.
Der Prozess sollte den automatischen E-Mail-Versand des ROA an den Kunden beinhalten. Diese Anforderung sollte hinzugefügt werden, nachdem die Lösung die UI-Integrationsphase abgeschlossen hatte.
Wie sind wir diese Lösung angegangen (Architektur & Erkenntnisse):
Aus der Schulungssitzung wurde deutlich, dass der erste Schritt vor dem Entwurf eines ROA (Record of Advice) oder SOA (Statement of Advice) immer darin bestand, die Aktennotiz (File Note) fertigzustellen (die vom Berater ausgefüllt würde). Daher entschieden wir uns ebenfalls, die Erstellung von ROA/SOA auf die Aktennotiz selbst zu stützen, anstatt auf das Transkript des Meetings. Somit war klar, dass unser Ausgangspunkt darin bestand, eine Aktennotiz aus dem Transkript des Anrufs zu erstellen und diese Aktennotiz anschließend zur Erstellung des ROA/SOA zu verwenden.
- 1. Erstellung einer Aktennotiz aus dem Transkript
Die wichtigsten Punkte, die hier berücksichtigt werden mussten, waren sicherzustellen, dass keine Informationen übersehen werden, die generierten Dokumente konsistent und zuverlässig sind und dass keine Halluzinationen auftreten. Um diese Probleme anzugehen, entschieden wir uns, Extraktionsaufgaben zu vermeiden (bei denen wir einen Agenten auffordern, Informationen aus einem Textabschnitt zu extrahieren) und stattdessen eine Zusammenfassungslogik (Summarize Logic) zu wählen.
Nachdem das Transkript in kleinere Textabschnitte (Chunks) unterteilt wurde, auf die eine Überlagerungslogik (Overlay Logic) angewendet wurde, setzten wir den "Klassifizierungs-Agenten" ein (dies war eigentlich ein Wrapper/eine Instanz, aber wir nannten sie Agenten, um sie als KI-Objekte besser erkennbar zu machen).
Aber was sollte der Klassifizierungs-Agent klassifizieren? – Wir wollten die KI-Systemarchitektur um die Aktennotiz-Vorlage herum aufbauen. Der Grund dafür war, dass die Aktennotiz nur eine Standardvorlage hatte. Da wir uns an den geschäftlichen Anforderungen orientieren mussten, entschieden wir uns, dies als Ausgangspunkt zu nehmen, indem wir jeden Abschnitt dieser Aktennotiz als eine Eigenschaft in unserem KI-System behandelten und für jeden Abschnitt relevante Agenten erstellten.
Der Klassifizierungs-Agent geht also einen Textabschnitt aus dem Transkript durch und entscheidet, welcher Abschnitt der Aktennotiz am besten zu dieser Diskussion passt, aus einem Pool von 14 Optionen (standardmäßig wurde fast jeder der Abschnitte in einem Beratungsgespräch besprochen).
Nachdem die gesamten Abschnitte des Transkripts klassifiziert und dem richtigen Abschnitts-Agenten zugeordnet waren, wurde jeder Abschnitts-Agent mit einer Zusammenfassungsaufgabe ausgelöst. Dabei nahm er alle für diesen Abschnitt klassifizierten Textteile als Input und gab eine detaillierte Zusammenfassung dieser Teile aus.
Am Ende wurde die Aktennotiz erstellt, indem alle nicht-leeren Abschnitte per Code zusammengesetzt wurden (hier wurde keine KI eingesetzt, um eine höhere Konsistenz und Zuverlässigkeit zu gewährleisten).
Wir fügten einen zusätzlichen "Abschnitts-Agenten" namens "GeneralPurposeAgent" hinzu, der in der eigentlichen Aktennotiz-Vorlage nicht existierte. Wir fügten diesen Agenten hinzu, um alle Randfälle abzufangen, die vielleicht nicht genau in einen Abschnitt passen, obwohl diese Fälle recht selten waren.
2. Erstellung von ROAs/SOAs aus der Aktennotiz
Diese Funktion war einfach zu implementieren, nachdem wir konsistente, zuverlässige Aktennotizen aus dem Transkript erhalten hatten, da die ROAs und SOAs von einem Agenten generiert wurden, der die Aktennotiz selbst als Input nahm und nicht das Transkript. Es gab über 7 Vorlagen für diese Dokumente, und das Ergebnis dieser Implementierung waren ebenfalls konsistente, zuverlässige Dokumente.
Lösungsdetails:
Verwendete Tools/Technologien:
- Azure OpenAI Service
- LangChain
- Python, SQL, React + Vite
- Azure Graph API
Einzigartige Anpassungen für den Kunden:
- Hinzufügen einer einfachen CRM-Funktion innerhalb der App für die Testphase
Wichtigste Erkenntnisse (Key Takeaways):
Die Arbeit mit dem Azure OpenAI Service und der Einsatz von mehr als 14 Agenten ermöglichten eine sehr schnelle Verarbeitung der Transkripte. Durch die Nutzung von Parallelisierung konnten wir alle Agenten gleichzeitig auslösen und schnelle Ergebnisse erzielen.
Was wirklich gut funktionierte, war die Gestaltung der Architektur der Zusammenfassungs-/Abschnitts-Agenten basierend auf der Aktennotiz-Vorlage. Dieser Teil der Architektur trägt die Verantwortung dafür, alle erforderlichen Informationen aus dem Transkript in die Dokumente zu übertragen. Wenn die Ergebnisse hier unzureichend gewesen wären, hätte dies den gesamten Prozess beeinträchtigt. Wir müssen jedoch hinzufügen, dass diese Architektur aufgrund der klar definierten Abschnitte der Aktennotiz-Vorlage möglich war, die sich sehr deutlich voneinander unterschieden.
