Od projektu NFT do produktu turystycznego
Produkt powstał przed erą ChatGPT jako spin-off jednego z projektów opartych na NFT. Zbudowaliśmy go dla klienta rozwijającego pomysł związany z turystyką kulinarną w Polsce. Prace zakończyły się działającym proof of concept, a nie wydaniem produkcyjnym.
Nasz zakres obejmował wstępne badania rynku, analizę konkurencji, doradztwo produktowe i realizację techniczną. Klient prowadził większą część prac go-to-market i badań z użytkownikami przy naszym wsparciu. Taki podział pozostawiał odkrywanie rynku po stronie klienta, a jednocześnie pozwalał dostosowywać produkt i rekomendacje do wniosków z badań.
Proof of concept działał na AWS i wykorzystywał własny system rekomendacji. Obejmował też pozyskiwanie danych potrzebnych do zebrania miejsc oraz informacji turystycznych przed uruchomieniem logiki rankingu.
Problem układania planu
Planowanie podróży kulinarnej jest trudniejsze niż przygotowanie listy restauracji lub atrakcji. Użyteczny harmonogram dnia musi uwzględniać dopasowanie preferencji, położenie, kolejność, czas i praktyczną dostępność. Wysoko oceniane miejsce nie pomaga, jeśli nie pasuje do trasy lub priorytetów grupy.
Rozdzieliliśmy rekomendowanie od konstrukcji planu. Pierwsza warstwa wskazywała potencjalnie odpowiednie doświadczenia kulinarne. Druga musiała układać wybrane propozycje z uwzględnieniem ograniczeń harmonogramu. Dzięki temu atrakcyjna lista miejsc nie była automatycznie traktowana jako wykonalny plan podróży.
Produkt powstał, zanim ogólne modele konwersacyjne stały się standardowym interfejsem. Zaprojektowaliśmy więc logikę rekomendacji i pozyskiwanie danych bezpośrednio dla problemu turystycznego, zamiast polegać na modelu językowym tworzącym wiarygodnie brzmiący plan z luźnego opisu.
Badania zmieniły obraz biznesowy
Badania wykazały strukturalny problem ówczesnej turystyki kulinarnej w Polsce. Wiele płatności i ustaleń z mniejszymi oraz średnimi dostawcami nie było zapisanych w spójnych systemach cyfrowych. Dane transakcyjne pozostawały więc niepełne albo trudne do połączenia ze standardowym procesem platformy.
Nie oznaczało to braku rzeczywistych firm lub popytu. Produkt oparty na całkowicie udokumentowanych transakcjach mógł jednak kolidować ze sposobem działania części rynku. Wymaganie nowego procesu płatności lub raportowania mogło działać przeciw potrzebom mniejszych firm, które platforma miała uwzględniać.
Ten wniosek wpływał na model biznesowy równie mocno jak na oprogramowanie. System rekomendacji może wskazać odpowiednie miejsce, lecz finalizacja transakcji wymaga zgodnych praktyk rezerwacji, płatności i rozliczeń. Przy rozproszonych procesach platforma musiałaby przejąć dodatkową obsługę albo ograniczyć bazę dostawców.
Rekomendacje i pozyskiwanie danych
Własny system rekomendacji łączył preferencje użytkownika lub grupy z pozyskanymi informacjami o dostępnych doświadczeniach. Jego zadaniem było uporządkowanie kandydatów i wsparcie trasy, a nie generowanie opisowej narracji podróżniczej.
Pozyskiwanie danych było potrzebne, ponieważ informacje źródłowe nie występowały w jednym formacie. PoC zamieniał dostępne materiały w porównywalne dane wejściowe dla algorytmu. AWS zapewniał środowisko działania rozwiązania.
Projekt nie osiągnął etapu, na którym bieżąca dostępność, finalizacja płatności lub wszystkie ograniczenia planu mogły być uznane za zweryfikowane funkcje produkcyjne. Trafność rekomendacji i wykonalność operacyjna są osobnymi pytaniami.
Logika rekomendacji porządkowała kandydatów, natomiast ograniczenia harmonogramu określały wykonalność proponowanej trasy.
Co potwierdził PoC
PoC potwierdził możliwość połączenia pozyskanych danych z dedykowanym podejściem rekomendacyjnym dla turystyki kulinarnej. Dostarczył też ważniejszego wniosku komercyjnego: otoczenie transakcyjne mogło ograniczać wartość aplikacji dla mniejszych i średnich dostawców.
Decyzja nie zależała więc wyłącznie od jakości algorytmu. Klient musiał ocenić, czy model go-to-market obejmie dostawców, których operacje nie są w pełni reprezentowane w ustandaryzowanych systemach cyfrowych. Nasze badania i realizacja ujawniły to ograniczenie przed większym wdrożeniem.
Potwierdzony rezultat i granice
Potwierdzonym rezultatem jest ukończony PoC dla klienta, obejmujący badania, analizę konkurencji, pozyskiwanie danych, własny system rekomendacji i AWS. Klient prowadził go-to-market oraz badania z użytkownikami przy naszym wsparciu.
Opis nie deklaruje wdrożenia produkcyjnego, ukończonych rezerwacji, wolumenu płatności, aktywnych użytkowników, wzrostu przychodów dostawców ani potwierdzonej wykonalności tras. Nie określa też nieudokumentowanych transakcji jako nielegalnych. Wniosek dotyczy braku ustandaryzowanych danych potrzebnych proponowanej platformie.
W podobnym produkcie trzeba sprawdzić logikę rekomendacji razem z danymi dostawców, rezerwacjami, ograniczeniami płatności i reprezentatywnymi trasami. Strona o dedykowanych algorytmach pokazuje, jak oceniać dopasowanie i ograniczenia przed skalowaniem.