Rozwiązania otwarte a zastrzeżone

Obecnie rozwój obsługi klienta chatbots jest zdominowany przez drogich specjalistów, którzy często używają zastrzeżonych technologii do dostarczania rozwiązań.

Rozwiązania te mają następujące główne wady:

• Przywiązują klientów do zastrzeżonych rozwiązań
• Klienci nie mają dostępu lub mają ograniczony dostęp do własnych danych lub krytycznego kodu źródłowego.
• Klienci nie mogą łatwo rozszerzyć lub dostosować rozwiązań bez pomocy ze strony dostawcy.
• Rozwiązania te są często oparte na technologii "czarnej skrzynki", której debugowanie i kontrolowanie jest trudne nawet dla ekspertów
• Rozwiązania są drogie jak na swoje możliwości

Nie ma powodu, dla którego tak miałoby być, z wyjątkiem faktu, że rynek chatbotów jest stosunkowo nowy (choć nie aż tak nowy) i zarówno twórcy chatbotów, jak i firmy mają mniej informacji na temat alternatywnych rozwiązań.

Jedno jest jednak pewne, koszt tych rozwiązań będzie spadał, ponieważ coraz więcej osób odkrywa, że technologia przetwarzania języka naturalnego(NLP) jest szeroko dostępna, dość łatwa w użyciu dla większości programistów i konkurencyjna cenowo.

Jednak nawet jeśli koszty spadną, pozostałe trzy wady pozostaną. Są to wady, które Botpress chce rozwiązać poprzez demokratyzację rozwoju chatbotów.

Naszym celem na Botpress jest sprawienie, aby tworzenie wysokiej jakości, spersonalizowanych botów było w zasięgu początkujących programistów i twórców treści, a także znalezienie sposobów, w jakie zaawansowani twórcy chatbotów mogą zmaksymalizować wartość swoich umiejętności.

Botpress Szablony są tworzone w oparciu o popularne, dobrze rozumiane technologie (np. przy użyciu frameworkaBotpress ), co oznacza, że dane i kod źródłowy są otwarte, łatwo jest znaleźć programistów do pracy nad projektami, a szablony można dostosowywać i rozszerzać.

Rozszerzalność jest tak ważna, ponieważ gdy firma ma już uruchomionego podstawowego bota do obsługi klienta, nagle zda sobie sprawę ze wszystkich możliwości, jakie otwiera to w zakresie świadczenia innych usług angażujących klientów w zintegrowany sposób.

Jeśli system nie jest otwarty i rozszerzalny, a znalezienie programistów do pracy nad nim nie jest łatwe, nie będą oni w stanie dodać potrzebnych funkcji za rozsądną cenę lub nawet w ogóle.

Na przykład, wyobraźmy sobie firmę, która sprzedaje bilety na koncerty, tworzy bota FAQ, aby odpowiadać na proste, powtarzające się pytania i eskalować trudniejsze pytania do agentów klienta. Następnie zdają sobie sprawę, że niektóre z zadawanych pytań dotyczą dostępności biletów na niektóre koncerty, na które nie można odpowiedzieć za pomocą prostej implementacji FAQ. Postanawiają więc zintegrować bota ze swoim systemem sprzedaży biletów, aby uzyskać odpowiedzi.

Problem polega na tym, że niezależnie od tego, czy są w stanie to zrobić, czy nie, jeśli kupili zastrzeżone rozwiązanie bota, są w dużym stopniu zależni od dostawcy, jeśli w ogóle jest to możliwe. A nawet jeśli jest to możliwe, koszty będą znacznie wyższe niż w przypadku otwartego systemu, biorąc pod uwagę, że są oni klientem zmonopolizowanym.

Inną kwestią jest to, że praca, którą wykonują integrując swój zewnętrzny system z botem, będzie działać tylko z systemem dostawcy. Nie można go łatwo przełączyć do pracy z innym systemem, więc im więcej pracy wykonują z tym dostawcą, tym bardziej stają się zablokowani.

I oczywiście jakość samego rozwiązania jest w dużym stopniu zależna od zastrzeżonego rozwiązania dostawcy, ponieważ nie mają oni dostępu do najlepszych w swojej klasie rozwiązań innych firm, ale są ograniczeni do rozwiązania dostawcy.

Problem ten staje się jeszcze bardziej dotkliwy, gdy firma biletowa zdaje sobie sprawę, że mogłaby sprzedawać bilety bezpośrednio z bota, ponieważ zdaje sobie sprawę, że będzie to wymagało jeszcze większych inwestycji, a rozwiązanie będzie miało wszystkie te same wady omówione wcześniej.

Dlatego decydują się na ponowne wdrożenie bota na otwartym frameworku, co wiąże się z dużymi kosztami i wysiłkiem. Dzieje się tak, ponieważ zdają sobie sprawę, że te zmiany to dopiero początek tego, co jest możliwe dla botów, a ostatecznie centrum kontaktowe i usługi zostaną połączone w doświadczenie onmi-channel, które musi być otwarte i rozszerzalne.