Kluczowe wnioski
- AI nie naprawi bałaganu w danych, tylko go rozmnoży. Jakość katalogu ustawia sufit jakości każdego workflow: żaden prompt nie doda atrybutu, którego nie ma w źródle.
- Przed startem sprawdzasz sześć obszarów na realnym eksporcie, nie w panelu sklepu: pola wymagane, identyfikatory, warianty, jednostki, duplikaty, kategorie. Sprzątasz w kolejności: wymagane i identyfikatory, potem spójność, wzbogacanie na końcu.
- Parametr, który ma trafić do filtra, feedu albo odpowiedzi modelu, musi mieszkać w osobnym polu ze słownikiem wartości. A każde pole ma dokładnie jeden system, który jest jego właścicielem.
- Poza katalogiem firma ma drugą warstwę danych: ton marki, zasady rabatów, procedury, decyzje. Zebrane w jedno centrum wiedzy czytane przez agentów AI kumulują się: każda poprawka człowieka zostaje w systemie na zawsze.
Masz za sobą audyt i kolejkę wdrożeń. Zanim uruchomisz pierwszy automat, zrób jedną rzecz: wyeksportuj katalog do pliku i naprawdę go otwórz. Typowy widok wygląda tak: eksport z Subiekta, sześć tysięcy wierszy, kolumna „kolor” pełna wpisów „czarny”, „black” i „BLK”. Rozmiar raz jako „M”, raz jako „38”. EAN produktu nadrzędnego skopiowany na wszystkie warianty. Nikt tego nie planował. Tak po prostu wygląda katalog, który przez pięć lat prowadziło kilka osób w trzech systemach.
Problem w tym, że prawie każde zastosowanie AI w sklepie czyta ten właśnie plik: opisy, tłumaczenia, feedy, odpowiedzi na pytania klientów o parametry. Stąd niewygodna teza tego rozdziału: AI nie naprawi bałaganu w danych, tylko go rozmnoży. Jest też dobra wiadomość. Nie potrzebujesz idealnego katalogu, bo taki nie istnieje. Wystarczy porządek w polach, których dotknie pierwsze workflow.
Automat powiela błąd w każdym wierszu naraz
Kiedy opisy pisze człowiek, dane poprawiają się mimochodem. Redaktor patrzy na zdjęcie, widzi w kolumnie „czarny”, a produkt jest grafitowy, więc poprawia. Automat tego nie zrobi. Wykona dokładnie to, co dostał. W trzystu produktach. Tak samo cierpliwie i tak samo błędnie.
Na tym polega różnica: praca ręczna produkuje błędy pojedyncze i losowe, automatyzacja produkuje błędy systemowe. Błąd systemowy ma jedną zaletę, bo naprawiasz go jedną poprawką reguły. I jedną poważną wadę: do momentu naprawy widzi go każdy klient w każdym kanale.
Sufit jakości, którego nie przebije żadne narzędzie
Drugą rzecz łatwo przeoczyć: dane ustawiają sufit jakości każdego workflow. Jeśli w katalogu nie ma pojemności, materiału ani wymiarów, opis wygenerowany z takich danych będzie kwiecisty i pusty, bo nie ma z czego zbudować konkretu.
Wersja gorsza: model uzupełni lukę czymś, co brzmi prawdopodobnie. Dostajesz wtedy parametr, którego nikt nie sprawdził, w kanale, który za niego odpowiada. Koszt takiego błędu nie kończy się na poprawce w pliku. Wychodzi na zwrotach, reklamacjach i odrzuconych ofertach.
Sześć kontroli, zanim cokolwiek uruchomisz
Ten przegląd robisz raz, na eksporcie z realnego źródła. Nie musisz sprawdzać całego katalogu: wystarczy kilkadziesiąt losowych pozycji plus kilka celowo trudnych (warianty, zestawy, produkty z wieloma jednostkami). Szukasz odpowiedzi na jedno pytanie: czy błędy są pojedyncze, czy systemowe.
| Obszar | Pytanie kontrolne | Sygnał, że masz problem |
|---|---|---|
| Pola wymagane | Czy każdy produkt ma komplet pól wymaganych przez Twoje kanały, a nie tylko przez sklep? | Lista braków przy publikacji nigdy się nie kończy |
| Identyfikatory | Czy SKU i GTIN są unikalne, poprawne i przypisane do właściwego wariantu? | Ten sam SKU w dwóch wierszach, GTIN rodzica skopiowany na warianty |
| Spójność wariantów | Czy każdy wariant ma ten sam zestaw atrybutów i powiązanie z rodzicem? | Warianty upchnięte w jednej komórce, rozmiar raz „M”, raz „38” |
| Jednostki i formaty | Czy jednostki, wymiary, daty i ceny mają jeden format? | „42 cm”, „42cm” i „0,42 m” w tej samej kolumnie |
| Duplikaty | Czy ten sam produkt występuje w katalogu dokładnie raz? | Dwa rekordy z różnym opisem, ceną i stanem |
| Kategorie i atrybuty | Czy kategoria wewnętrzna ma jednoznaczne przełożenie na taksonomię kanału? | Węzeł „Pozostałe” jest jedną z największych kategorii |
Przegląd robisz na eksporcie, nie w panelu. Panel pokazuje dane tak, jak chce je widzieć człowiek. Workflow czyta plik.
Nie rób tego ręcznie, bo wyszukiwanie duplikatów i niespójnych jednostek to samo w sobie praca powtarzalna, czyli dobre zadanie dla narzędzia. Techniczną stronę takiego przeglądu, z zasadą pracy na kopii i przeglądem różnic przed zapisem, opisaliśmy krok po kroku w tekście o czyszczeniu katalogu CSV. Tutaj zostaje warstwa decyzji: co musi być prawdą o danych, żeby automat miał na czym pracować.
„Opisane po ludzku” to nie to samo co „czytelne maszynowo”
To rozróżnienie odpowiada za połowę nieudanych wdrożeń. Zdanie „wodoodporny, spokojnie wytrzyma prysznic” jest jasne dla klienta i bezużyteczne dla systemu. Każdy maszynowy odbiorca chce czegoś innego:
- Kanał sprzedaży: atrybut o ustalonej nazwie i wartość z zamkniętej listy.
- Filtr w sklepie: liczba.
- Model odpowiadający na pytanie klienta: pole, w którym ta wartość po prostu jest.
Stąd reguła: jeżeli parametr ma trafić do filtra, feedu, porównywarki albo odpowiedzi, musi mieszkać w osobnym polu, z przewidywalną nazwą i wartością ze słownika, a nie w środku zdania.
Dwa testy: dane czy tekst
Model potrafi wyciągnąć parametry z opisu i czasem to sensowny skrót, ale nazwijmy go po imieniu: to zgadywanie o wysokiej trafności. Nadaje się do ratowania zastanych danych, nie do bycia źródłem prawdy.
Dwa szybkie testy pokazują, po której stronie jest Twój katalog:
- Test filtrowania: czy dane da się posortować i przefiltrować bez czytania opisów?
- Test dwóch osób: czy dwie różne osoby wpisałyby w to pole dokładnie tę samą wartość?
Jedno „nie” oznacza, że pole jest tekstem, a nie danymi. Workflow zbudowany na takim polu będzie się sypał w miejscach, których nie przewidzisz.
Jedno źródło prawdy: każde pole ma właściciela
W praktyce prawie nikt nie ma jednego systemu. Ceny i stany żyją w ERP, opisy w sklepie albo PIM, marketplace trzyma własne atrybuty, a obok funkcjonuje arkusz marketingu. Jedno źródło prawdy nie oznacza wielkiej migracji do jednego narzędzia, bo taka migracja bywa droższa niż problem, który rozwiązuje.
Oznacza coś prostszego: dla każdego pola wskazujesz jeden system, który jest jego właścicielem, a pozostałe to pole czytają, zamiast je nadpisywać. Konflikt rozstrzyga właściciel pola, nie ostatni zapis.
Bez tego workflow działa poprawnie i mimo to jest bezużyteczny: automat poprawia opisy w sklepie, nocna synchronizacja z ERP nadpisuje je starą wersją, a Ty odkrywasz to po dwóch tygodniach. Spisanie właścicieli pól to jedno popołudnie: bierzesz pola, których dotknie pierwsze workflow, i przy każdym notujesz system źródłowy oraz kierunek przepływu.
Zanim uruchomisz workflow, odpowiedz na jedno pytanie: gdzie ląduje wynik? Automat, który zapisuje efekt pracy poza źródłem prawdy (wprost do kanału albo do osobnego arkusza), nie porządkuje danych, tylko tworzy ich kolejną wersję. Po trzech miesiącach masz cztery wersje opisu tego samego produktu i nikt nie wie, która jest aktualna. Wynik wraca do systemu, który jest właścicielem pola, i stamtąd rozchodzi się do kanałów.
Centrum wiedzy: to samo zrób z wiedzą firmy
Katalog to tylko połowa źródła prawdy. Druga połowa to wiedza, która w większości firm nie leży w żadnym systemie: ton marki, zasady rabatów, procedura zwrotów, powody decyzji („nie wysyłamy za pobraniem, bo…”), najczęstsze pytania klientów i wypracowane na nie odpowiedzi.
Ta wiedza mieszka w głowach, na Slacku i w starych mailach. Każdy nowy pracownik zbiera ją miesiącami. I każdy workflow AI zaczyna bez niej od zera.
Cztery pliki na start
Rozwiązanie brzmi mniej poważnie, niż działa: folder z plikami tekstowymi, który czytają agenci AI przed każdym zadaniem. Nie potrzebujesz żadnej platformy, na start wystarczą cztery pliki:
- Ton marki: z przykładem dobrego i złego opisu.
- Ceny: zasady rabatów i komunikacji cen.
- Zwroty i reklamacje.
- Decyzje: co ustalono i dlaczego.
Magia jest w kumulacji: gdy poprawiasz szkic automatu i dopisujesz powód poprawki do właściwego pliku, ta poprawka zostaje w systemie na zawsze. Człowiek uczy raz, korzysta każdy kolejny workflow.
Po pół roku różnica między firmą, która to robi, a firmą, która za każdym razem tłumaczy wszystko od nowa, jest trudna do nadrobienia. Sami tak pracujemy przy wdrożeniach: nasze własne centrum wiedzy o firmie i klientach czytają agenci przy każdym projekcie i to ono, a nie sprytne prompty, robi największą różnicę w jakości.
Dwie granice od pierwszego dnia
Do centrum wiedzy nie trafiają sekrety (hasła, klucze API, dane dostępowe) ani dane osobowe klientów, bo te pliki będą czytane przez narzędzia i ludzi, a rotacja dostępu do nich musi być prosta. Trafia wiedza o tym, jak firma działa i dlaczego. Jak takie centrum zbudować krok po kroku, od pierwszego pliku po strukturę, którą utrzymuje cały zespół, pokazujemy w rozdziale 7.
Sprzątanie w trzech przejściach
Kolejność ma znaczenie finansowe, bo każde przejście wykonane na złym etapie trzeba powtórzyć. Robisz je po kolei i po każdym sprawdzasz próbkę, zamiast puszczać wszystko naraz.
Przejście pierwsze: pola wymagane i identyfikatory
Zaczynasz od tego, bez czego produkt nie istnieje w kanale, i od kluczy łączących systemy. Braki w polach wymaganych blokują publikację, a zduplikowany identyfikator rozjeżdża wszystko, co potem próbuje połączyć dane z dwóch źródeł. Jedna twarda granica: braków w identyfikatorach się nie generuje. Poprawny GTIN pochodzi z GS1 albo od producenta. Narzędzie ma brak rzetelnie oznaczyć, nie wymyślić.
Przejście drugie: spójność
Teraz ujednolicasz warianty, jednostki, kolory i kategorie oraz rozstrzygasz duplikaty. Efektem nie jest tylko czystszy plik, ale słowniki wartości: lista dopuszczalnych kolorów, format jednostek, mapowanie kategorii na taksonomię kanału. Te słowniki to pierwsi lokatorzy Twojego centrum wiedzy i wejście dla wszystkiego, co uruchomisz w następnym rozdziale.
Przejście trzecie: wzbogacanie
Uzupełnianie atrybutów, opisy, tłumaczenia i dane pod wyszukiwanie robisz na końcu, na uporządkowanym katalogu. Odwrócenie kolejności to najdroższy błąd tego etapu: wzbogacasz rekordy, które okażą się duplikatami, albo piszesz opisy dla wariantów, które trzeba będzie rozbić inaczej. Płacisz dwa razy za tę samą pracę, drugi raz zwykle drożej.
Kryterium wyjścia jest praktyczne, nie doskonałe. Wystarczą trzy rzeczy:
- Czysta próbka: kilkadziesiąt losowych produktów bez braków w polach wymaganych, z unikalnymi identyfikatorami, spójnymi wariantami i jednym formatem jednostek.
- Spisani właściciele pól: wiadomo, który system jest właścicielem których pól.
- Założone centrum wiedzy: folder istnieje, choćby z dwoma plikami.
To wystarczy, żeby uruchomić pierwsze workflow. O tym jest następny rozdział.
Pytania
Czy trzeba mieć PIM, żeby zacząć z AI w eCommerce?
Nie. Warunkiem startu jest ustalenie, który system jest właścicielem których pól i w którą stronę płyną dane, a to da się spisać na jednej kartce. PIM rozwiązuje problem skali: wiele kanałów, języków i osób edytujących ten sam katalog. Jeżeli masz jeden rynek i jeden kanał, wdrażanie PIM przed pierwszym workflow zwykle odsuwa efekt zamiast go przyspieszać.
Czy AI nie posprząta katalogu za mnie?
W dużej części tak i warto z tego skorzystać: wykrywanie duplikatów, przeliczanie sum kontrolnych kodów, ujednolicanie jednostek i kolorów to praca powtarzalna, którą narzędzie wykonuje szybciej i cierpliwiej niż człowiek. Granica jest jedna: wartości, których nie ma w źródle (GTIN, parametr techniczny, materiał), narzędzie ma oznaczyć jako brak, a nie uzupełnić prawdopodobnie brzmiącą wartością.
Od czego zacząć centrum wiedzy, jeśli nic nie jest spisane?
Od tego, co najczęściej poprawiasz albo tłumaczysz nowym osobom. Zwykle są to trzy pliki: ton marki z przykładem dobrego i złego opisu, zasady cen i rabatów oraz procedura zwrotów. Zwykły folder z plikami tekstowymi wystarczy na start. Nie wkładaj do niego haseł, kluczy ani danych osobowych klientów. Pełny framework budowy takiego centrum opisujemy w rozdziale 7.
