

BłażejŁukomski
Wyobraź sobie firmę produkującą parapety cięte na wymiar, która postanowiła zbudować w swoim sklepie internetowym konfigurator pozwalający klientowi samodzielnie dobrać długość, materiał i wykończenie produktu. Strukturę takiego konfiguratora, a więc same miejsca wyboru oraz przypisane do nich towary, udało się przygotować w rozmowie z asystentem AI, bez konieczności wchodzenia w panel administracyjny sklepu. Na liście zadań do wykonania ręcznie zostało jednak coś, co z pozoru wydawało się drobnostką, a mianowicie parametry samej długości: od ilu do ilu metrów klient może wybierać, z jakim skokiem, jaka wartość ma być podpowiedziana jako domyślna. Powód był prosty i, jak się później okazało, tymczasowy – nie istniało jeszcze narzędzie, które pozwalałoby ustawić te parametry poprzez rozmowę z AI, więc trzeba było wykonać ten krok tak, jak wykonywano go od lat, czyli ręcznie.
Ta historia jest dobrym punktem wyjścia do drugiego artykułu z naszej serii o MCP w e-commerce, ponieważ pokazuje coś istotnego – wdrażanie MCP w konkretnym systemie nie jest jednorazowym wydarzeniem, lecz procesem, w którym kolejne obszary sklepu stopniowo stają się dostępne dla asystenta AI. To, czego jeszcze wczoraj nie dało się zrobić w rozmowie, dziś już się da – i właśnie ten proces chcemy Ci dzisiaj pokazać na najbardziej wymagającym przykładzie, jakim jest konfigurator produktu.

Zanim przejdziemy do tego, jak wygląda budowa konfiguratora w rozmowie z AI, warto poświęcić chwilę na cztery pojęcia, bez których trudno zrozumieć, co właściwie dzieje się pod maską takiego produktu. Nie są to pojęcia skomplikowane, ale bywają mylone nawet wewnątrz firm zajmujących się e-commerce, a każda taka pomyłka potrafi później kosztować godzinę niepotrzebnej dyskusji na spotkaniu.
Pierwszym pojęciem jest towar konfigurowalny, czyli produkt, który sam w sobie się nie sprzedaje, lecz stanowi ramę, w którą klient wkłada swoje wybory. Można o nim myśleć jak o pustym formularzu zamówienia, który dopiero wypełniony konkretnymi decyzjami klienta staje się gotowym produktem trafiającym do koszyka.
Drugim pojęciem jest pojedyncze miejsce wyboru w takim konfiguratorze, a więc na przykład „długość”, „kolor” czy „dodatkowe wyposażenie”. Każde takie miejsce ma swoją nazwę, swoją kolejność w ścieżce zakupowej oraz zestaw reguł określających, czy klient musi go wypełnić, czy może je pominąć, i czy wybór w tym miejscu wpływa na ostateczną cenę.
Trzecim pojęciem jest sposób, w jaki dane miejsce wyboru jest wypełniane, a tutaj mamy do czynienia z dwiema zasadniczo różnymi sytuacjami. W pierwszej klient wybiera gotowy towar z listy, na przykład konkretny model uchwytu czy zawiasu. W drugiej klient nie wybiera niczego z listy, lecz wpisuje albo wskazuje wartość, na przykład dokładną długość w metrach czy wybrany kolor z palety. Rozróżnienie tych dwóch sytuacji już na etapie planowania produktu jest jedną z decyzji, które później najtrudniej cofnąć, gdyby okazało się, że wybrano niewłaściwe podejście.
Czwartym i ostatnim pojęciem są parametry poszczególnych miejsc wyboru, a więc konkretne liczby i ustawienia, takie jak minimalna i maksymalna długość, skok, czyli najmniejsza jednostka, o jaką można zmienić wartość, czy jednostka miary. Część z tych parametrów ustawia administrator sklepu, definiując reguły gry, a część wypełnia dopiero klient na stronie produktu, dokonując swojego wyboru w ramach tych reguł.
Warto zapamiętać jedną konsekwencję płynącą z tych czterech pojęć, ponieważ ma ona bezpośrednie przełożenie na to, co MCP potrafi dzisiaj zrobić, a czego jeszcze nie – w sytuacji, w której klient wpisuje albo wskazuje wartość zamiast wybierać towar z listy, cała treść danego miejsca wyboru mieści się właśnie w tych parametrach. Samo miejsce wyboru, bez wypełnionych parametrów, jest praktycznie puste, nie niesie żadnej informacji poza samym swoim istnieniem. Dlatego narzędzie, które pozwala jedynie tworzyć takie miejsca wyboru, ale nie pozwala ustawiać ich parametrów przez AI, w praktyce rozwiązuje tylko połowę problemu, z jakim mierzy się firma budująca konfigurator.

Jedną z bardziej użytecznych obserwacji, jakie można wynieść z pracy nad wieloma różnymi konfiguratorami w wielu różnych branżach, jest to, że niemal wszystkie realne przypadki dają się sprowadzić do sześciu powtarzających się wzorców. Rozpoznanie, z którym wzorcem ma się do czynienia już na pierwszym spotkaniu z klientem, potrafi skrócić wycenę projektu z tygodnia analizy do jednej rozmowy telefonicznej, ponieważ znajomość wzorca od razu podpowiada, ile pracy i jakiego rodzaju będzie wymagało wdrożenie.
Pierwszy wzorzec to cięcie na wymiar, znane doskonale z branży produkującej parapety, blaty, płyty czy tkaniny sprzedawane na metry. Klient podaje wymiar mieszczący się w dopuszczalnym zakresie, a cena wylicza się z metra bieżącego lub kwadratowego.
Drugi wzorzec to zestaw modułowy, typowy dla mebli, regałów, szaf czy zestawów narzędziowych. Produkt składa się z korpusu oraz wymiennych modułów, przy czym każdy moduł oferuje własną listę dopuszczalnych opcji, a część z nich jest opcjonalna. Cena sumuje się z poszczególnych wybranych elementów, a kolejność, w jakiej klient podejmuje decyzje, bywa równie ważna jak same opcje, ponieważ decyduje o tym, jak naturalnie przebiega rozmowa sprzedażowa na stronie produktu.
Trzeci wzorzec to personalizacja i nadruk, obecne w sprzedaży kubków, koszulek, grawerowanych przedmiotów, opakowań czy zaproszeń. Klient wpisuje własny tekst, wybiera czcionkę i kolor, a niekiedy wgrywa własne zdjęcie. W tym wzorcu szczególnie istotne stają się ograniczenia techniczne, takie jak maksymalna liczba znaków czy dopuszczalny rozmiar przesyłanego pliku, ponieważ ich brak prowadzi prosto do reklamacji.
Czwarty wzorzec to kreator wieloetapowy, spotykany tam, gdzie klient potrzebuje raczej doradztwa niż prostego wyboru z listy, na przykład przy konfiguracji instalacji technicznej czy dobieraniu zestawu produktów pod konkretne pomieszczenie. Klient przechodzi przez kolejne kroki pytań, a odpowiedź udzielona na jednym etapie zawęża opcje dostępne na kolejnym, aż do finalnego podsumowania i wyceny. Warto wiedzieć, że jest to zarazem najkosztowniejszy w utrzymaniu z sześciu wzorców, ponieważ każda zmiana oferty potrafi dotknąć jednocześnie kilku kroków naraz.
Piąty wzorzec to konfigurator z podglądem wizualnym, obecny przy sprzedaży mebli tapicerowanych, drzwi, stolarki czy innych produktów, w których wybór klienta wpływa na widoczny na ekranie render. W tym wzorcu parametry opisują nie tylko cechy produktu, ale również jego geometrię – pozycję, skalę i obrót elementu widocznego na wizualizacji.
Szósty i ostatni wzorzec to zestaw promocyjny, a więc pakiety, komplety czy oferty typu „kup razem taniej”. Jest to najprostszy z sześciu wzorców, ponieważ sprowadza się do kilku gotowych opcji z ustaloną z góry regułą cenową na całości, dzięki czemu klient rozumie go niemal natychmiast, bez żadnego dodatkowego wyjaśnienia.
Praktyczna wartość tego podziału ujawnia się najpełniej w rozmowie handlowej. Zamiast pytać klienta o listę technicznych funkcji, wystarczy zapytać, czy klient podaje wymiar, składa produkt z modułów, personalizuje go, przechodzi ścieżkę pytań, czy ogląda podgląd wizualny. Odpowiedź od razu wskazuje właściwy wzorzec, wzorzec wskazuje niezbędne miejsca wyboru, a te z kolei przekładają się na realną pracochłonność wdrożenia.

Najlepszym sposobem na zrozumienie, jak MCP realnie zmienia pracę nad konfiguratorem, jest pokazanie, jak wygląda pojedyncze polecenie wypowiedziane do asystenta AI i co dzieje się w tle, zanim asystent odpowie, że zadanie zostało wykonane.
Załóżmy, że administrator sklepu chce ustawić parametry długości w komponencie parapetu. Zamiast otwierać panel administracyjny, wchodzić w edycję produktu, odnajdywać właściwe pole i wypełniać je ręcznie, wystarczy jedno zdanie wypowiedziane w naturalnym języku: ustaw zakres długości od 0,1 do 6 metrów, ze skokiem co 0,1 metra i domyślną wartością 6 metrów. Pod tym jednym zdaniem kryją się w rzeczywistości cztery osobne operacje wykonane przez asystenta tzn. ustawienie wartości minimalnej, wartości maksymalnej, skoku oraz wartości domyślnej, a każda z nich kończy się informacją, jaka wartość obowiązywała wcześniej i jaka obowiązuje teraz.
Ten detal, czyli pokazywanie wartości sprzed zmiany obok wartości po zmianie, ma znaczenie większe, niż mogłoby się wydawać na pierwszy rzut oka. To właśnie on sprawia, że administrator nie musi się zastanawiać, czy AI zrozumiało polecenie poprawnie, ponieważ odpowiedź sama, bez dodatkowego pytania, potwierdza dokładny zakres wprowadzonej zmiany. Co więcej, dobrze zaprojektowane narzędzie tego typu radzi sobie także z drobnymi różnicami językowymi, takimi jak zapis liczby z przecinkiem zamiast z kropką dziesiętną, co ma znaczenie w polskojęzycznym środowisku biznesowym, gdzie taki zapis jest naturalny dla człowieka, choć niekoniecznie oczywisty dla systemu informatycznego.
Po wprowadzeniu zmian dobrą praktyką jest poproszenie asystenta o ponowny odczyt całej konfiguracji danego miejsca wyboru, aby na własne oczy zobaczyć, że wszystkie wartości rzeczywiście znalazły się tam, gdzie miały się znaleźć. Każda z tych zmian trafia jednocześnie do historii obiektu w systemie, dzięki czemu w każdej chwili można sprawdzić, kto i kiedy dokonał konkretnej modyfikacji, a to jest temat, do którego wrócimy szerzej w trzecim artykule tej serii, poświęconym bezpieczeństwu i kontroli.

Rzetelność wymaga, aby obok tego, co już działa, równie wyraźnie powiedzieć, czego dany mechanizm jeszcze nie potrafi, a w rozmowach o sztucznej inteligencji ten drugi element bywa pomijany znacznie częściej, niż powinien, co prowadzi później do rozczarowań.
Pierwszym ograniczeniem jest sytuacja, w której miejsce wyboru ma dobierać towary automatycznie na podstawie ich cech, takich jak kategoria czy producent, zamiast z gotowej, wcześniej ustalonej listy. Takie dobieranie towarów po cechach wciąż wymaga dziś ręcznej konfiguracji w panelu administracyjnym, ponieważ mechanizm odpowiedzialny za ten sposób wypełniania konfiguratora nie jest jeszcze dostępny dla asystenta AI.
Drugim ograniczeniem jest sytuacja, w której jedno miejsce wyboru ma odwoływać się do innego i dziedziczyć po nim listę dostępnych opcji, zamiast mieć własną, niezależną listę. System potrafi poprawnie obsłużyć takie odwołanie, gdy klient przegląda sklep, natomiast asystent AI na razie tego mechanizmu nie rozpoznaje, co oznacza, że tego typu powiązania trzeba na razie ustawiać bezpośrednio w panelu, pracując na tym miejscu wyboru, do którego prowadzi odwołanie.
Trzecim, znacznie mniej istotnym ograniczeniem jest obsługa właściwości, które mogą przyjmować jednocześnie wiele wartości. Odczyt takich właściwości działa bez zastrzeżeń, natomiast ich zapis i usuwanie są świadomie zablokowane, ponieważ zapisanie jednej wartości mogłoby przypadkiem skasować wszystkie pozostałe, a to jest przykład sytuacji, w której lepsza jest jasna odmowa wykonania operacji niż ryzyko cichej utraty danych.
Warto też pamiętać o ograniczeniach dotyczących całej tej klasy rozwiązań, niezależnie od konkretnego systemu. Asystent AI nie zna intencji biznesowej stojącej za danym produktem; potrafi zbudować konfigurator zgodnie z opisem, ale nie oceni, czy tak zaprojektowany produkt rzeczywiście sprzeda się lepiej niż poprzednia wersja. Decyzja o tym, jaki zakres długości zaproponować klientom albo które warianty pokazać na pierwszym miejscu, zawsze pozostaje po stronie człowieka znającego rynek i klientów. Warto również wiedzieć, że jakość pracy asystenta zależy bezpośrednio od jakości danych już zgromadzonych w systemie. Sklep z niespójnie nazwanymi produktami i pustymi kategoriami dostanie od AI dokładnie to samo, co dostałby od nowego pracownika pierwszego dnia pracy, czyli serię pytań i sygnałów o brakujących informacjach.

W pracy nad każdym nowym mechanizmem prędzej czy później pojawia się moment, w którym coś nie działa tak, jak powinno, i to właśnie ten moment najlepiej pokazuje, czy dany dostawca technologii jest gotowy na współpracę z wymagającym klientem biznesowym.
Podczas wdrażania jednego z konfiguratorów zdarzyła się sytuacja, w której odczyt parametrów danego miejsca wyboru zwracał informację, że żadna wartość nie została jeszcze ustawiona, mimo że w rzeczywistości baza danych zawierała już poprawnie zapisane wartości. Przyczyna okazała się dość subtelna – mechanizm odpowiedzialny za odczyt w pewnym momencie pytał o dane przypisane do niewłaściwego elementu struktury, co samo w sobie nie powinno wywołać żadnego widocznego błędu, a jednak przez zbieg kilku okoliczności technicznych doprowadziło do sytuacji, w której system zamiast zgłosić problem, po cichu zwracał pustą odpowiedź.
Dlaczego warto opowiadać tę historię otwarcie, zamiast ją przemilczeć? Ponieważ pokazuje ona coś znacznie ważniejszego niż sam fakt wystąpienia usterki, a mianowicie sposób, w jaki dojrzały proces radzi sobie z takimi sytuacjami. Rozbieżność została wykryta w ramach standardowego testowania, opisana wraz z dowodem na to, na czym dokładnie polegał problem, a poprawka trafiła do systemu razem z dodatkowym testem, który od tej pory pilnuje, aby ten sam błąd nie powrócił niezauważony.
Klient biznesowy, który rozważa wdrożenie technologii na wiele lat, nie pyta zwykle o to, czy dostawca gwarantuje całkowity brak błędów, ponieważ taka gwarancja nigdy nie byłaby wiarygodna – pyta raczej o to, co dzieje się w momencie, gdy błąd faktycznie się pojawi. Ta historia jest właśnie odpowiedzią na to drugie, znacznie trudniejsze pytanie, i jest to odpowiedź lepsza niż jakiekolwiek zapewnienie, że problemów nie ma.
Jeśli prowadzisz firmę sprzedającą produkty, które klient musi dopasować do własnych potrzeb, czy to poprzez podanie wymiaru, wybór modułów, personalizację, przejście ścieżki pytań, czy obejrzenie podglądu wizualnego, ten artykuł miał pokazać Ci, że budowa takiego konfiguratora przestaje być tygodniowym projektem informatycznym angażującym webmastera na każdym etapie. Staje się rozmową, w której administrator opisuje swoim naturalnym językiem to, co chce uzyskać, a asystent AI wykonuje techniczną część tej pracy, zostawiając człowiekowi to, co w tej pracy najważniejsze, czyli decyzje biznesowe dotyczące zakresu oferty i doświadczenia klienta.
Warto jednocześnie pamiętać, że nie jest to mechanizm bezwarunkowy – ma dziś jasno określone granice, a jego jakość zależy od jakości danych już zgromadzonych w systemie. Świadomość tych granic, zamiast osłabiać wartość rozwiązania, czyni rozmowę o nim znacznie bardziej wiarygodną, ponieważ pokazuje, że stoi za nim realne doświadczenie wdrożeniowe, a nie wyłącznie materiał marketingowy.
W trzecim, ostatnim artykule tej serii przejdziemy do pytań, które prędzej czy później zada każdy odpowiedzialny decydent: ile to wszystko realnie kosztuje, jakie ryzyko się z tym wiąże i jakie mechanizmy kontroli powinny być standardem, zanim jakikolwiek asystent AI otrzyma prawo do wprowadzania zmian w produkcyjnym sklepie internetowym.

BłażejŁukomski
