Was ich wünschte, ich hätte von Anfang an gewusst, wie man entwickelt Chatbots

Erik leitet eine Agentur für Chatbot-Entwicklung. Sie bietet Chatbot-Lösungen für große Unternehmen an, insbesondere im Bereich Kundenservice und Marketing.

Erik erzählte mir, dass das Geschäft einerseits sehr gut läuft, weil die Konversionsrate bei Pitches für chatbots extrem hoch ist. Dies spiegelt vielleicht die Tatsache wider, dass er einer der ersten ist, der in diesem Bereich auf den Markt kommt.

Gleichzeitig hatte er Schwierigkeiten, die richtigen Werkzeuge zu finden, um chatbots effizient und in hoher Qualität zu erstellen.

Als er zum ersten Mal die No-Code-Plattformen wie Chatfuel und Motion.ai entdeckte, war er optimistisch, dass diese Tools sein Problem lösen würden. Er stellte fest, dass sie zwar gut für das Prototyping der Bots funktionierten, er aber schnell auf Probleme stieß.

Viele Bots mussten auf eine Art und Weise angepasst werden, die nur in Code dargestellt werden konnte, und diese Plattformen unterstützten die Codierung nicht. Einige Bots mussten in die Altsysteme des Kunden integriert werden, und auch das war nicht möglich.

Allein diese Probleme waren schon ein Problem, aber selbst wenn sie gelöst werden konnten, war es ihm unangenehm, dass die gesamte Logik und die Daten auf einem System eines Drittanbieters lagen, über das er keine Kontrolle hatte. Seine Kunden bestanden oft darauf, den Bot aus Sicherheitsgründen selbst zu hosten.

Er beschloss daher, die Bots von Grund auf mit Microsoft Bot Framework zu programmieren und nach Möglichkeit Entwickler in Niedriglohnländern einzusetzen. Durch diese Vorhersehbarkeit entstanden weitere Probleme.

Obwohl er nun Eigentümer des Codes und der Daten war und den Bot in dem gewünschten Maße anpassen konnte, waren die Ergebnisse gemischt.

Er erkannte schnell, dass alle Bots viele Funktionen gemeinsam hatten, z. B. rollenbasierte Sicherheit, Abonnements, Broadcasting, Human in the Loop, aber diese Funktionen wurden von den Entwicklern von Grund auf neu kodiert, was die Entwicklungszeit unnötig verlängerte und seine Gewinnspanne schmälerte.

Die Entwicklungsrisiken waren auch deshalb unnötig hoch, weil verschiedene Entwickler die Funktionen auf unterschiedliche Weise kodierten und die Gesamtarchitektur sich ad hoc entwickelte. Einige Entwickler hatten dieses Problem erkannt und begannen, wiederverwendbare Bibliotheken für gemeinsame Funktionen zu erstellen, aber diese Bibliotheken waren kaum die qualitativ hochwertigen Bibliotheken, auf denen er sein Unternehmen aufbauen wollte. Sie waren mit eigenen Risiken und unerwünschten Abhängigkeiten verbunden, vor allem wenn die benötigten Funktionen komplex waren. Es war schwierig für ihn, die Qualität zu überprüfen, ganz zu schweigen davon, seinen Kunden die Gewissheit zu geben, dass alles, was erstellt wurde, einem ausreichend hohen Standard entsprach.

Er zog kurz die Idee in Betracht, eine eigene Plattform zu entwickeln, aber das erschien ihm zu aufwendig. Dies würde unnötige Entwicklungs- und Wartungskosten verursachen und möglicherweise zu Verkaufsproblemen führen, wenn sich auf dem Markt Standard-Frameworks herausbilden, die die Kunden bevorzugen würden, was seiner Meinung nach geschehen würde. Es war nur eine Frage der Zeit.

Seiner Meinung nach ähnelte das Problem dem, mit dem Webentwickler in den Anfängen des Internets konfrontiert waren. Damals gab es keine Content-Management-Tools wie Wordpress, so dass die Websites jedes Mal von Grund auf neu programmiert werden mussten. Dies führte zu den gleichen Problemen wie die erhöhten Entwicklungskosten und die unterschiedliche Qualität des Codes und der Ausgabe, mit denen er jetzt bei der Erstellung von Bots konfrontiert war.

Als Erik Botpress.io online fand, dauerte es nicht lange, bis er erkannte, dass Botpress eine mögliche Lösung für seine Probleme bot. Ihm gefiel die modulare Architektur in der Theorie, und es erschien ihm sinnvoll, ein Äquivalent zu einem CMS für Bots zu bauen. Das war es, was seiner Meinung nach gebraucht wurde. Es könnte das fehlende Puzzlestück sein, aber er musste erst einige Fragen beantworten.

Erstens musste er sicher sein, dass die Lösung robust, sicher und zuverlässig ist.

Zweitens musste er sicherstellen, dass alle gemeinsamen kritischen Funktionen, die er als erforderlich identifiziert hatte, über den Rahmen verfügbar waren

Drittens musste er sich vergewissern, dass die wirtschaftlichen Aspekte für seine Agentur funktionieren würden.

Da er selbst ein praktischer und technischer Mensch ist, beschloss er, die ersten beiden Fragen persönlich zu überprüfen, indem er das System tatsächlich testete. Er trat der Botpress Community bei und arbeitete sich durch einige der Video-Tutorials der Open-Source-Version.

Die Tatsache, dass es bereits eine große und aktive Gemeinschaft von Entwicklern gab, die die Software nutzten, bedeutete, dass sie kampferprobt war, was eine gute Sache war.

Er war zunächst besorgt, dass Botpress quelloffen ist, was seine Kunden (in vielen Fällen zu Recht) als Sicherheitsrisiko ansehen könnten. Er fand jedoch heraus, dass Botpress eine kuratierte Unternehmensversion hatte, die getrennt von der Open-Source-Version gepflegt wurde, um speziell die Sicherheitsprobleme zu lösen.

Natürlich bot die Open-Source-Version einige Vorteile, denn sie war kostenlos und in vielen Fällen ideal für die Entwicklung von Bots außerhalb des Unternehmensbereichs. Dies bedeutete, dass die Komponenten und der Ansatz von vielen verschiedenen Entwicklern intensiv genutzt und validiert wurden.

Viele seiner Kunden verlangten, dass sie den Chatbot vor Ort hosten und aus Sicherheits- und kommerziellen Gründen die Kontrolle über die Daten haben, und Botpress unterstützte dies. Darüber hinaus ermöglichte Botpress die vollständige Anpassung des Codes und die Integration mit internen Systemen, was das ursprüngliche Problem war, das er mit den "no-code" Plattformen hatte.

Die meisten der von ihm gewünschten Funktionen waren verfügbar. Dazu gehörten rollenbasierte Sicherheit, Mehrbenutzerverwaltung und Benutzeroberflächen für die Verwaltung der Bots nach der Bereitstellung. Was noch fehlte, konnte er leicht als Modul hinzufügen.

Die modulare Architektur und die grafischen Schnittstellen zum System machten es sehr einfach zu verstehen, wo alles hingehört. Das bedeutete, dass es selbst dann, wenn er nach der Hälfte eines Projekts zu neuen Entwicklern wechselte oder jemand den Code nach einer längeren Pause wieder aufnehmen musste, nicht lange dauerte, bis die betreffende Person sich einarbeiten konnte. So weit, so gut.

Die wirtschaftliche Frage war natürlich auch wichtig. Würde die Verwendung von Botpress seine Gesamtentwicklungskosten senken? Die Gewinnspannen waren knapp. Er erwartete, dass die Verwendung eines Frameworks wie Botpress die Entwicklungskosten senken und gleichzeitig die Qualität und die Funktionen verbessern würde.

Es stellte sich heraus, dass seine Erwartungen richtig waren. Die Kosten für den Betrieb von Botpress betrugen nur einen Bruchteil der Kosten, die bei der Eigenentwicklung einiger Funktionen entstanden wären, und die Qualität war besser als bei einer proprietären Lösung.

Der versteckte Vorteil des Framework-Ansatzes bestand darin, dass er mehr Zeit auf die Chatbot-Benutzeroberfläche und -Funktionalität verwenden konnte und dadurch das Kundenerlebnis deutlich verbessern konnte.

Er hatte beobachtet, dass viele der chatbots auf dem Markt nicht besonders gut waren. Man könnte sogar sagen, dass die Chatbot-Hersteller als Branche ihre Kunden im Stich lassen.

Es könnte argumentiert werden, dass dies darauf zurückzuführen ist, dass die Unternehmen nicht bereit waren, angemessene Mittel für die Entwicklung von chatbots bereitzustellen, weil sie sich der Ergebnisse nicht sicher waren.

Ein weiteres Argument ist, dass der Entwicklungsprozess für chatbots bisher sehr ineffizient war, weil die Chatbot-Macher nicht über effiziente Tools für die Entwicklung von chatbots verfügten und sich daher ein Großteil der Entwicklungskosten auf das konzentrierte, was im Wesentlichen Infrastruktur ist.

Das Aufkommen von Frameworks wie Botpress hatte das Potenzial, die Qualität von chatbots massiv zu verbessern, da mehr Entwicklungsbudget für die Benutzererfahrung ausgegeben wird.

Fürs Protokoll: Erik ist keine reale Person, sondern eine Zusammenstellung einiger Agenturinhaber, die uns mit ihren Problemen, Anforderungen und ihrem Interesse an den Möglichkeiten von chatbots kontaktiert haben. Auf unterschiedliche Weise teilten sie ihre Version von "Was ich am Anfang gerne über die Entwicklung von chatbots für meine Kunden gewusst hätte".

Wenn wir die wichtigsten Themen zusammenfassen könnten, wären das folgende:

• Die Erstellung von chatbots erfordert den Zugang zu Code und Daten.
• Die Entwickler müssen die Geschäftslogik anpassen und mit internen Systemen integrieren. Es ist nicht möglich, eine großartige chatbots ohne Entwickler zu erstellen.
• Viele Unternehmenskunden haben Sicherheitsbedenken und möchten daher ihren Chatbot vor Ort betreiben. Sie wollen auch die gleiche rollenbasierte Sicherheit und Benutzerverwaltung, die sie von jeder Software, die sie verwenden, erwarten würden.
• Der von einer Agentur gewählte Rahmen sollte eine breite Palette gemeinsamer Funktionen bieten, die sofort einsatzbereit sind.
• Für eine Agentur (oder einen Entwicklungsladen) ist es genauso wenig sinnvoll, ein eigenes Chatbot-Framework für den internen Gebrauch zu entwickeln, wie es für sie sinnvoll ist, ihre eigenen Datenbanken von Grund auf neu aufzubauen. Das wäre nicht nur unwirtschaftlich und würde hohe Wartungskosten verursachen, sondern ihre Kunden würden es wahrscheinlich vorziehen, etablierte, gut verstandene Infrastrukturprodukte zu verwenden, die für einen bestimmten Zweck gebaut wurden, anstatt zu versuchen, eine nicht zum Kerngeschäft gehörende Infrastruktur selbst aufzubauen.
• Die Branche braucht Frameworks, damit mehr Entwicklungsgelder in die Benutzererfahrung und nicht in die Infrastruktur fließen können.