Ceny i stany w sklepie z trzech źródeł: Allegro i Apilo

Jeden towar, cztery ceny. W ofercie na Allegro 149 zł, w Apilo 139 zł, w pliku od dostawcy 112 zł netto, a w panelu sklepu 145 zł, bo ktoś poprawiał to ostatnio na wiosnę. Liczby są przykładowe, sytuacja nie. Każda z tych cen kiedyś była prawdziwa. Pytanie brzmi, która jest prawdziwa dziś i kto w firmie ma prawo to rozstrzygnąć.

W ostatnich dwóch tygodniach robiliśmy w jednym projekcie dokładnie trzy takie rzeczy: ceny towarów własnych zaciągane wprost z ofert Allegro przez API, ceny produktów dostawcy liczone z jego pliku według reguły „cena z pliku minus 2 procent” i porządkowanie towarów pobranych z Apilo tak, żeby ten sam model w pięciu rozmiarach był jednym produktem z wariantami, a nie pięcioma osobnymi kartami. Trzy zadania, jeden problem pod spodem: ta sama informacja żyła w kilku miejscach i żadne z nich nie było oznaczone jako obowiązujące.

Ten wpis jest o tym oznaczaniu. Nie o narzędziu, tylko o decyzji, którą trzeba podjąć raz, a potem zapisać w kodzie: skąd bierzemy cenę, skąd stan, skąd nazwę i co robimy, gdy źródła się nie zgadzają.

Skąd w praktyce bierze się cena

W firmie handlowej, która sprzedaje ten sam towar na Allegro i we własnym sklepie, cena mieszka zwykle w czterech miejscach naraz:

• Oferty Allegro. Tu cena jest najbardziej żywa, bo reaguje na konkurencję, prowizje i promocje. W wielu firmach to jedyne miejsce, gdzie ktoś naprawdę pilnuje marży.
• Apilo albo inny OMS. System do obsługi zamówień trzyma własną kartotekę towarów, bo musi: łączy kanały sprzedaży, magazyn i wysyłki. Ceny i nazwy wpadają do niego z marketplace'ów i zostają w takiej formie, w jakiej wpadły.
• Plik od dostawcy. CSV albo XLSX przychodzi mailem raz w tygodniu, raz na miesiąc albo „jak coś się zmieni”. Ma ceny zakupu, czasem sugerowane ceny sprzedaży, czasem stany u dostawcy. Prawie nigdy nie ma tych samych indeksów, co Twój magazyn.
• Panel sklepu. Tu cena jest ustawiana ręcznie i tu najdłużej leży nieaktualna, bo nikt nie dostaje powiadomienia, że się rozjechała.

Zwykle dochodzi piąte miejsce: ERP, u polskich firm najczęściej Subiekt. On wie, po ile towar kupiono i ile go fizycznie jest, ale nie wie nic o prowizji Allegro ani o promocji, która ruszyła w piątek.

Każde z tych miejsc pokazuje inną liczbę i każde ma na to dobry powód: w jednym ceny zmieniały się wczoraj, drugie jest sprzed trzech tygodni, w trzecim ktoś poprawił nazwę ręcznie i przy okazji cenę. Rozjazd nie bierze się z czyjegoś błędu, tylko z liczby miejsc, w których ta sama dana żyje własnym życiem.

Kto wygrywa konflikt: źródło prawdy dla ceny, stanu i nazwy osobno

Najczęstszy błąd na tym etapie to próba wybrania jednego systemu na wszystko. „Od dziś prawdą jest Apilo” brzmi porządkująco i rozsypuje się w pierwszym tygodniu, bo Apilo nie wie o Twojej marży, a Allegro nie wie o towarze, który leży na magazynie i nie jest wystawiony.

Źródło prawdy wybiera się osobno dla każdego pola. Nie „dla produktu”, a dla ceny, stanu, nazwy, wariantów i ceny zakupu oddzielnie. Tak to zwykle rozkładamy:

Przy takim układzie konflikt przestaje być konfliktem. Jeśli cena w panelu sklepu różni się od ceny z oferty Allegro, to nie jest spór do rozstrzygnięcia przez człowieka, tylko błąd do naprawienia w jedną stronę. Integracja wie, którą.

Typowe rozjazdy: rozmiary, nazwy z marketplace, marża od starej ceny

Trzy rozjazdy wracają w prawie każdym projekcie, w którym katalog ma więcej niż jedno źródło. Wszystkie trzy wyglądają na drobiazg, dopóki nie trzeba ich posprzątać przy kilku tysiącach pozycji.

Osobny produkt na każdy rozmiar. Kurtka w pięciu rozmiarach trafia z marketplace'u albo z OMS-a jako pięć niezależnych towarów, bo tam każdy wariant jest osobną ofertą. W sklepie powinna być jednym produktem z listą rozmiarów. Różnica jest widoczna dla kupującego: pięć kart zamiast jednej psuje listingi, wyszukiwanie i karuzele powiązanych produktów. Scalanie po nazwie nie działa, bo nazwy są niespójne. Działa mapowanie po kodzie wariantu albo po EAN, z regułą, co zrobić z pozycją, dla której kodu nie ma.

Nazwy wprost z marketplace'u. Tytuł oferty na Allegro jest optymalizowany pod wyszukiwarkę Allegro: ma słowa kluczowe, parametry i skróty. W sklepie czyta go człowiek i Google. Jeśli nazwa ze źródła operacyjnego nadpisuje nazwę w sklepie, każda synchronizacja cofa pracę nad opisem. Nazwa i cena mogą płynąć z różnych źródeł i to jest w porządku.

Marża liczona od starej ceny. Reguła w stylu „cena z pliku dostawcy minus 2 procent” jest prosta, dopóki wiadomo, od czego liczymy te 2 procent. Od ceny z nowego pliku czy od tej, która jest w sklepie? Od ceny netto czy brutto? Co z pozycją, której w nowym pliku nie ma: zostaje, czy znika z oferty? Pytania brzmią trywialnie, a odpowiedzi różnią się o kilka procent marży na całym katalogu. Dlatego regułę zapisuje się jako kod z testem, nie jako notatkę w mailu.

Jak często odświeżać i co zrobić, gdy źródło milczy

Częstotliwość wybiera się per źródło, nie dla całej integracji. Plik dostawcy przychodzi raz w tygodniu, więc częstsze zaglądanie do niego nic nie wnosi. Stany schodzą w ciągu godzin, więc raz na dobę to za rzadko. U nas to zwykle wygląda tak: stany co kilka minut, ceny co godzinę, plik dostawcy po jego otrzymaniu, katalog i opisy wtedy, gdy ktoś je zmieni.

Druga połowa roboty to zachowanie, gdy źródło nie odpowiada albo odpowiada czymś dziwnym. Tu jest różnica między integracją a skryptem, który raz zadziałał:

1. 01Cisza nie znaczy zero. Puste API, plik z zerowym rozmiarem, timeout: to brak danych, nie zerowy stan. Automat, który w takiej sytuacji wyzeruje stany, w kwadrans wyłącza cały sklep ze sprzedaży.
2. 02Walidacja przed zapisem. Cena 0, cena dziesięć razy wyższa niż poprzednia, 90 procent katalogu zmienione w jednym przebiegu: to sygnały, że źródło przysłało śmieci albo zmieniło format. Taki przebieg odkładamy do akceptacji, nie wpuszczamy na produkcję.
3. 03Kwarantanna pozycji. Jedna pozycja bez kodu wariantu nie może zatrzymać importu pozostałych. Idzie na listę do ręcznej decyzji, reszta wchodzi normalnie.
4. 04Idempotencja. Ten sam plik wczytany dwa razy musi dać ten sam efekt, a nie dwa razy tę samą obniżkę. Przy cenach liczonych regułą to pierwsza rzecz, która boli, gdy jej brakuje.
5. 05Historia zmian. Kto, kiedy i na jakiej podstawie zmienił cenę. Bez tego nie odtworzysz, skąd wzięła się dziwna liczba, ani nie pokażesz historii ceny przy promocji.
6. 06Alert do człowieka. Nie „log w pliku”, a wiadomość tam, gdzie ktoś patrzy, z konkretem: to źródło, ten przebieg, tyle pozycji wstrzymanych.

W hurtowni AGD, dla której budowaliśmy hub integracji z Subiektem nexo, dokładnie ta część okazała się najważniejsza: zamówienie wysłane ponownie po utracie sygnału jest rozpoznawane jako duplikat, więc do Subiekta wchodzi jeden dokument. Opis całego wdrożenia jest w realizacji hurtowni B2B.

Rachunek czasu: 500 i 5000 SKU

Teraz liczby. Nie z Twojej firmy, tylko z modelu, który zbudowałem na czterech założeniach. Wszystkie są do podmiany i wszystkie są celowo ostrożne:

• 12 procent katalogu zmienia w miesiącu cenę albo stan w którymś ze źródeł,
• każde kolejne źródło dokłada 50 procent zmian do pogodzenia, bo tę samą pozycję trzeba sprawdzić w kilku miejscach,
• 2 minuty na znalezienie i poprawienie jednej pozycji ręcznie,
• 15 procent nieaktualnych pozycji kończy się sprawą do obsługi (pytanie kupującego, anulacja, korekta), po 5 minut każda.

Przy trzech źródłach i dwóch typowych rytmach ręcznej aktualizacji wychodzi z tego taka tabela:

Dwie rzeczy warto z tego wyciągnąć. Pierwsza: przy 5000 SKU samo zgrywanie cen to co najmniej jedna czwarta etatu, jeszcze przed obsługą skutków. Druga: rzadsze zgrywanie nie oszczędza czasu, tylko zamienia godziny przeklejania na nieaktualne ceny w sklepie. Przy 500 SKU różnica między tygodniem i miesiącem to jedna godzina pracy, ale czterokrotnie więcej błędnych cen.

Poniżej ten sam model z Twoimi liczbami. Ustaw liczbę SKU, zaznacz swoje źródła i rytm, a na końcu wypełnij tabelę źródeł prawdy: to ona jest tu najcenniejsza.

Symulator nie zna Twojej firmy i nie udaje, że zna. Pokazuje, jak zachowuje się rozjazd przy zmianie trzech rzeczy: skali katalogu, liczby źródeł i rytmu aktualizacji. Jeśli chcesz zrobić podobny rachunek dla ręcznego przepisywania zamówień, mamy go w osobnym wpisie o koszcie ręcznej obsługi Allegro.

źródła tej samej ceny w typowym sklepie

3

miesięcznie przy 5000 SKU (założenia)

ok. 42 h

pól, dla których trzeba wskazać źródło prawdy

6

Co z tego robimy u klientów

Zakres takiego wdrożenia jest dość powtarzalny, niezależnie od tego, czy źródłem jest Allegro, Apilo, plik dostawcy czy wszystkie trzy naraz:

1. 01Spis źródeł: co gdzie żyje, kto to zmienia i jak często. Zwykle na tym etapie wychodzi jedno źródło, o którym nikt nie pamiętał.
2. 02Tabela źródeł prawdy per pole, zatwierdzona przez osobę, która odpowiada za ceny. To decyzja biznesowa, nie techniczna.
3. 03Mapowanie towarów: EAN, kod producenta, kod wariantu, a dla pozycji bez żadnego z nich jawna reguła i lista do ręcznej decyzji.
4. 04Reguły cenowe w kodzie, z testami: narzut, zaokrąglenia, ceny netto i brutto, wyjątki na konkretne grupy towarowe.
5. 05Scalanie wariantów: jeden produkt z rozmiarami w sklepie, nawet jeśli źródło przysyła płaską listę ofert.
6. 06Walidacje, kwarantanna, historia zmian i alerty, czyli to wszystko, co opisałem wyżej w sekcji o milczących źródłach.
7. 07Podgląd dla człowieka: co się zmieni w tym przebiegu, zanim zmiana pójdzie na sklep.

Typowe wdrożenie to 2-3 tygodnie od startu do produkcji, a większy projekt dzielimy na etapy po 2-3 tygodnie, każdy z działającym fragmentem na końcu. Tak zrobiliśmy w hurtowni AGD z czterema cennikami i 1293 produktami, gdzie aplikacja na tablet, portal B2B i Subiekt nexo pracują dziś na jednych danych. W sklepie z odzieżą roboczą aplikacja wystawia oferty wprost przez Allegro REST API i liczy marżę po prowizji i dostawie jeszcze przed publikacją; droga do produkcji zajęła 3 tygodnie.

Czego nie obiecujemy. Automat nie zastąpi decyzji cenowej: wykonuje regułę, którą ktoś w firmie ustalił, i jest tylko tak dobry jak ta reguła. Nie obiecujemy też porządku w katalogu, jeśli ten sam towar ma w trzech systemach trzy różne indeksy i nic ich nie łączy; wtedy pierwszym etapem jest mapowanie, a w tej pracy musi wziąć udział ktoś od Was. I nie udajemy, że własna integracja zawsze bije gotowe narzędzie: przy jednym koncie, jednym cenniku i standardowych regułach wystarczy integrator z abonamentem i powiemy to wprost. Więcej o tym, jak podchodzimy do takich wdrożeń, jest na stronie automatyzacji procesów.

Jeśli warto, kolejnym krokiem jest audyt za 699 zł netto: kilka dni naszej pracy i dokument wdrożeniowy z tabelą źródeł prawdy, mapowaniem, zakresem, ryzykami, stałą ceną i terminem. Całą kwotę audytu odliczamy od ceny wdrożenia.