Offene vs. Proprietäre Lösungen

Gegenwärtig wird die Entwicklung des Kundendienstes chatbots von hochpreisigen Spezialisten beherrscht, die häufig proprietäre Technologien zur Bereitstellung von Lösungen verwenden.

Diese Lösungen haben vor allem die folgenden Nachteile:

• Sie binden die Kunden an firmeneigene Lösungen
• Die Kunden haben keinen oder nur einen eingeschränkten Zugang zu ihren eigenen Daten oder kritischem Quellcode
• Die Kunden können die Lösungen ohne Hilfe des Anbieters nicht einfach erweitern oder anpassen.
• Die Lösungen beruhen häufig auf einer Blackbox-Technologie, die selbst für Experten schwer zu debuggen und zu kontrollieren ist.
• Die Lösungen sind teuer für das, was sie sind

Es gibt keinen Grund, warum das so sein sollte, außer der Tatsache, dass der Chatbot-Markt relativ neu ist (wenn auch nicht so neu) und es sowohl für Chatbot-Ersteller als auch für Unternehmen weniger Informationen über alternative Lösungen gibt.

Eines ist jedoch sicher: Die Kosten für diese Lösungen werden sinken, wenn mehr Menschen entdecken, dass die Technologie zur Verarbeitung natürlicher Sprache(NLP) weithin verfügbar, für die meisten Entwickler relativ einfach zu verwenden und preislich konkurrenzfähig ist.

Doch selbst wenn die Kosten sinken, bleiben die drei anderen Nachteile bestehen. Diese Nachteile will Botpress durch die Demokratisierung der Chatbot-Entwicklung beheben.

Unser Ziel bei Botpress ist es, die Erstellung von qualitativ hochwertigen, maßgeschneiderten Bots auch für Einsteiger und Inhaltsersteller zugänglich zu machen und Wege zu finden, wie fortgeschrittene Chatbot-Entwickler den Wert ihrer Fähigkeiten maximieren können.

Botpress Vorlagen werden auf populären, gut verstandenen Technologien aufgebaut (z.B. mit dem Botpress Framework), was bedeutet, dass die Daten und der Quellcode offen sind, es einfach ist, Entwickler zu finden, die an Ihren Projekten arbeiten, und die Vorlagen anpassbar und erweiterbar sind.

Die Erweiterbarkeit ist deshalb so wichtig, weil ein Unternehmen, sobald es einen grundlegenden Kundenservice-Bot in Betrieb genommen hat, plötzlich all die Möglichkeiten erkennt, die sich dadurch für die Bereitstellung anderer integrierter Dienste für Kunden ergeben.

Wenn das System nicht offen und erweiterbar ist und es nicht leicht ist, Entwickler zu finden, die daran arbeiten, werden sie nicht in der Lage sein, die benötigten Funktionen zu einem vernünftigen Preis oder überhaupt hinzuzufügen.

Stellen Sie sich zum Beispiel vor, ein Unternehmen, das Konzertkarten verkauft, erstellt einen FAQ-Bot, um einfache, sich wiederholende Fragen zu beantworten und schwierigere Fragen an Kundenbetreuer weiterzuleiten. Dann stellt das Unternehmen fest, dass sich einige der gestellten Fragen auf die Verfügbarkeit von Tickets für bestimmte Konzerte beziehen, die mit einer einfachen FAQ-Implementierung nicht beantwortet werden können. Daher beschließen sie, den Bot in ihr Ticketverkaufssystem zu integrieren, um die Antworten zu erhalten.

Das Problem ist, dass sie, unabhängig davon, ob sie dazu in der Lage sind oder nicht, wenn sie eine proprietäre Bot-Lösung gekauft haben, in hohem Maße vom Anbieter abhängig sind, um dies zu tun, wenn es überhaupt möglich ist. Und selbst wenn es möglich ist, werden die Kosten dafür viel höher sein als bei einem offenen System, da sie ein gebundener Kunde sind.

Ein weiteres Problem ist, dass die Arbeit, die sie für die Integration ihres externen Systems in den Bot leisten, nur mit dem System des Anbieters funktioniert. Es kann nicht ohne Weiteres auf ein anderes System umgestellt werden. Je mehr sie also mit diesem Anbieter arbeiten, desto mehr sind sie gebunden.

Und natürlich ist die Qualität der Lösung selbst in hohem Maße von der herstellereigenen Lösung abhängig, da sie nicht auf die besten Lösungen von Drittanbietern zugreifen können, sondern auf die Lösung des Anbieters beschränkt sind.

Dieses Problem wird noch akuter, wenn das Ticketunternehmen feststellt, dass es tatsächlich Tickets direkt über den Bot verkaufen könnte, weil es erkennt, dass dies noch mehr Investitionen erfordert und die Lösung unter all den zuvor besprochenen Nachteilen leidet.

Sie beschließen daher, den Bot mit viel Aufwand und Kosten auf ein offenes Framework umzustellen. Das liegt daran, dass sie jetzt erkennen, dass diese Änderungen nur der Anfang dessen sind, was für Bots möglich ist. Letztendlich werden das Contact Center und die Dienste in einem On-Media-Kanal-Erlebnis kombiniert, das offen und erweiterbar sein muss.