Co chciałbym wiedzieć o rozwoju od samego początku? Chatbots

Erik prowadzi agencję rozwoju chatbotów. Dostarcza rozwiązania chatbotowe dużym firmom, szczególnie w zakresie obsługi klienta i marketingu.

Erik powiedział mi, że z jednej strony biznes idzie bardzo dobrze, ponieważ współczynnik konwersji na stronie chatbots jest niezwykle wysoki. Być może odzwierciedla to fakt, że jest on jednym z pierwszych na rynku w tej przestrzeni.

Jednocześnie miał trudności ze znalezieniem odpowiednich narzędzi do efektywnego tworzenia wysokiej jakości strony chatbots .

Kiedy po raz pierwszy odkrył platformy no-code, takie jak Chatfuel i Motion.ai, był optymistycznie nastawiony, że narzędzia te rozwiążą jego problem. Choć okazało się, że dobrze sprawdzają się przy prototypowaniu botów, szybko napotkał problemy.

Wiele botów wymagało dostosowania w sposób, który można przedstawić tylko w kodzie, a platformy te nie obsługiwały kodowania. Niektóre boty musiały być zintegrowane ze starszymi systemami klienta, co również nie było możliwe.

Już same te problemy stanowiły przeszkodę, ale nawet gdyby udało się je rozwiązać, nadal nie czuł się komfortowo z całą logiką i danymi znajdującymi się w systemie innej firmy, nad którym nie miał kontroli. Jego klienci często nalegali na samodzielne hostowanie bota ze względów bezpieczeństwa.

W związku z tym zdecydował się na zakodowanie botów od podstaw przy użyciu Microsoft Bot Framework i tam, gdzie to możliwe, skorzystanie z usług programistów w krajach o niskich kosztach. Ta przewidywalność stworzyła jednak inne problemy.

Chociaż miał on teraz prawo własności do kodu i danych i mógł dostosować bota do wymaganego stopnia, wyniki były mieszane.

Szybko zdał sobie sprawę, że wszystkie boty miały wiele wspólnych funkcji, takich jak bezpieczeństwo oparte na rolach, subskrypcje, nadawanie, człowiek w pętli, ale funkcje te były kodowane od podstaw przez programistów, co niepotrzebnie wydłużyło czas rozwoju i zmniejszyło marże zysku.

Ryzyko rozwoju było również niepotrzebnie wysokie, ponieważ różni programiści kodowali funkcje na różne sposoby, a ogólna architektura ewoluowała w sposób ad hoc. Niektórzy programiści dostrzegli ten problem i zaczęli tworzyć biblioteki wielokrotnego użytku dla wspólnych funkcji, ale biblioteki te nie były wysokiej jakości bibliotekami, na których chciałby budować swój biznes. Wiązały się one z własnym ryzykiem i niepożądanymi zależnościami, zwłaszcza gdy wymagana funkcjonalność była złożona. Trudno było mu zweryfikować jakość, nie mówiąc już o zapewnieniu swoim klientom pewności, że wszystko, co zostało zbudowane, było na wystarczająco wysokim poziomie.

Przez chwilę rozważał pomysł zbudowania własnej platformy, ale wydawało mu się to przesadą. Stworzyłoby to niepotrzebne koszty rozwoju i utrzymania, a także potencjalnie problemy ze sprzedażą, gdyby pojawiły się standardowe ramy rynkowe, które klienci woleliby, co jego zdaniem nastąpi. To była tylko kwestia czasu.

Jego zdaniem problem był podobny do tego, z jakim borykali się twórcy stron internetowych u zarania Internetu. W tamtych czasach nie było narzędzi do zarządzania treścią, takich jak Wordpress, więc strony internetowe musiały być kodowane od zera za każdym razem. Stworzyło to te same problemy związane ze zwiększonymi kosztami rozwoju i zmienną jakością kodu i wyników, z którymi borykał się teraz podczas tworzenia botów.

Kiedy Erik znalazł Botpress.io online, nie zajęło mu dużo czasu, aby uznać, że Botpress oferuje potencjalne rozwiązanie jego problemów. Teoretycznie podobała mu się modułowa architektura i zbudowanie odpowiednika CMS dla botów miało dla niego sens. To było to, co uważał za potrzebne. Mógł to być brakujący element układanki, ale najpierw potrzebował odpowiedzi na kilka pytań.

Po pierwsze, musiał mieć pewność, że rozwiązanie będzie solidne, bezpieczne i niezawodne.

Po drugie, musiał upewnić się, że wszystkie wspólne krytyczne funkcje, które zidentyfikował jako wymagane, są dostępne za pośrednictwem frameworka

Po trzecie, musiał upewnić się, że ekonomia sprawdzi się w jego agencji.

Będąc osobą praktyczną i techniczną, postanowił osobiście zweryfikować pierwsze dwa pytania, faktycznie testując system. Dołączył do społeczności Botpress i zapoznał się z niektórymi samouczkami wideo, korzystając z wersji open source.

Fakt, że istniała już duża i aktywna społeczność deweloperów korzystających z oprogramowania oznaczał, że zostało ono przetestowane w boju, co było dobrą rzeczą.

Początkowo obawiał się, że Botpress jest open source, co jego klienci mogą postrzegać (w wielu przypadkach słusznie) jako zagrożenie dla bezpieczeństwa. Dowiedział się jednak, że strona Botpress ma wyselekcjonowaną wersję korporacyjną, która jest utrzymywana oddzielnie od wersji open source, specjalnie w celu rozwiązania kwestii bezpieczeństwa.

Oczywiście wersja open source oferowała pewne korzyści, ponieważ była darmowa i w wielu przypadkach idealna do tworzenia botów poza przypadkiem użycia w przedsiębiorstwie. Oznaczało to, że komponenty i podejście były intensywnie wykorzystywane i weryfikowane przez wielu różnych programistów.

Wielu z jego klientów wymagało hostowania chatbota lokalnie i kontrolowania danych ze względów bezpieczeństwa i komercyjnych, a Botpress to wspierał. Ponadto, Botpress pozwalał na pełne dostosowanie kodu i integrację z wewnętrznymi systemami, co było pierwotnym problemem z platformami "bez kodu".

Większość potrzebnych funkcji była dostępna. Obejmowały one zabezpieczenia oparte na rolach, zarządzanie wieloma użytkownikami i interfejsy użytkownika do zarządzania botami po wdrożeniu. To, czego brakowało, można było łatwo dodać jako moduł.

W rzeczywistości modułowa architektura i graficzne interfejsy systemu sprawiały, że bardzo łatwo było zrozumieć, gdzie wszystko się znajduje. Oznaczało to, że nawet jeśli zmienił programistów w połowie projektu lub ktoś musiał zająć się kodem po długiej przerwie, nie zajęłoby to dużo czasu, aby odpowiednia osoba mogła przyspieszyć. Jak na razie dobrze.

Kwestia ekonomiczna była oczywiście również ważna. Czy korzystanie z Botpress zmniejszyłoby jego ogólne koszty rozwoju? Marże zysku były napięte. Oczekiwał, że korzystanie z frameworka takiego jak Botpress zmniejszy koszty rozwoju, a jednocześnie zwiększy jakość i funkcjonalność.

Okazało się, że jego oczekiwania były słuszne. Koszt uruchomienia Botpress był niewielkim ułamkiem kosztu samodzielnego zbudowania nawet niektórych funkcji, a jakość była lepsza niż w przypadku rozwiązania własnościowego.

Ukrytą korzyścią podejścia ramowego było to, że mógł poświęcić więcej czasu na interfejs użytkownika chatbota i jego funkcjonalność, a tym samym mógł znacznie poprawić wrażenia klienta końcowego.

Zauważył, że wiele z chatbots na rynku nie było tak dobrych. Można nawet powiedzieć, że jako branża twórcy chatbotów zawodzili swoich klientów.

Można argumentować, że wynika to z faktu, że firmy nie były gotowe przeznaczać rozsądnych funduszy na rozwój chatbots , ponieważ nie były pewne wyników.

Innym argumentem jest to, że proces rozwoju chatbots był do tej pory bardzo nieefektywny, ponieważ twórcy chatbotów nie mieli skutecznych narzędzi do rozwoju chatbots , a zatem znaczna część kosztów rozwoju koncentrowała się na tym, co zasadniczo jest infrastrukturą.

Pojawienie się frameworków takich jak Botpress miało potencjał, aby znacznie poprawić jakość chatbots , ponieważ więcej budżetu na rozwój przeznacza się na doświadczenie użytkownika.

Dla przypomnienia, Erik nie jest rzeczywistą osobą, ale zbiorem niektórych właścicieli agencji, którzy skontaktowali się z nami w sprawie swoich problemów, wymagań i zainteresowania tym, co może zrobić chatbots . Na różne sposoby podzielili się oni swoją wersją "Tego, co chciałbym wiedzieć na początku o rozwijaniu chatbots dla moich klientów".

Gdybyśmy mogli podsumować główne kwestie, byłyby one następujące:

• Tworzenie świetnej strony chatbots wymaga dostępu do kodu i danych.
• Programiści muszą dostosować logikę biznesową i zintegrować ją z systemami wewnętrznymi. Nie jest możliwe stworzenie świetnego chatbots bez deweloperów.
• Wielu klientów korporacyjnych ma obawy związane z bezpieczeństwem i dlatego chce uruchomić swojego chatbota w siedzibie firmy. Chcą również takich samych zabezpieczeń opartych na rolach i zarządzaniu użytkownikami, jakich oczekują od każdego używanego przez siebie oprogramowania.
• Struktura wybrana przez agencję powinna zapewniać szeroki zakres wspólnych funkcji po wyjęciu z pudełka.
• Nie ma sensu, aby jakakolwiek agencja (lub sklep deweloperski) budowała własny framework chatbota do użytku wewnętrznego, tak samo jak nie ma sensu, aby budowała własne bazy danych od podstaw. Nie tylko byłoby to nieopłacalne i generowałoby duże koszty utrzymania, ale ich klienci prawdopodobnie woleliby, aby korzystali z uznanych, dobrze rozumianych produktów infrastrukturalnych, które są zbudowane zgodnie z przeznaczeniem, zamiast próbować samodzielnie budować infrastrukturę niezwiązaną z podstawową działalnością.
• Branża potrzebuje frameworków, dzięki którym więcej środków na rozwój będzie można przeznaczyć na doświadczenia użytkowników, a nie na infrastrukturę.