Przeniesienie sklepu z WooCommerce na Payload
Nie dlatego, że strona wolno działała. Dlatego, że specyficznej funkcjonalności było coraz więcej, a każda nowa możliwość wymagała obchodzenia ograniczeń cudzej platformy. Przenieśliśmy się na własny system, w którym sklep i CRM to jedna całość.
Powodem przeprowadzki nie była szybkość. Strona działała i można ją było dalej przyspieszać. Problem był inny: w sklepie nagromadziło się bardzo dużo specyficznej funkcjonalności — własnej, nie „jak u wszystkich”. A im więcej jej było, tym częściej każda nowa możliwość wymagała nie zrobienia, lecz obejścia: kolejna wtyczka, kolejne pole z boku, kolejna proteza na cudzej logice.
Ponadto sklep działał w układzie „strona osobno, CRM osobno”. Zamówienia, klienci, statusy, wysyłki — wszystko to trzeba było utrzymywać zsynchronizowane między dwoma systemami, które nic o sobie nie wiedzą.
W pewnym momencie rachunek stał się oczywisty: taniej zbudować system pod te procesy, niż dalej płacić za obchodzenie cudzych ograniczeń. Tak sklep i CRM stały się jedną całością.
Czego potrzebowano
Sklep z dużą ilością własnej logiki, kilkoma dostawcami o różnych warunkach — i menedżerami pracującymi w systemie przez cały dzień.
- Przenieść katalog 10 000+ produktów, nie tracąc pozycji w wyszukiwarce
- Połączyć stronę i CRM w jeden system zamiast dwóch, które trzeba synchronizować
- Podłączać dostawców i aktualizować ich cenniki bez pracy ręcznej
- Uwzględnić, że każdy dostawca ma własne dni wysyłki i własne sposoby dostawy
- Pracować zarówno z własnym towarem, jak i dropshippingiem w jednym katalogu
- Zachować możliwość dalszej rozbudowy własnej funkcjonalności — bez obejść
Co zrobiliśmy
Własny system na Payload CMS i Next.js: logika sklepu opisana kodem pod konkretne procesy, a nie złożona z cudzych wtyczek.
- Katalog 10 000+ produktów z wariantami kolorystycznymi w jednej karcie zamiast osobnych produktów na każdy kolor
- Ponad 13 tysięcy starych adresów przekierowywanych jest na nowe automatycznie — pozycje zachowane
- CRM wewnątrz strony: zamówienia, klienci, statusy i wysyłki w tym samym systemie co sklep
- Podłączenie dostawcy to konfiguracja, a nie rozwój: format feedu, adres, interwał aktualizacji i mapowanie kolumn
- Cenniki aktualizują się same według harmonogramu: cena, cena promocyjna i dostępność; produkty, których nie ma już w feedzie, system zdejmuje ze sprzedaży
- Każdy dostawca ma własne sposoby dostawy i własny harmonogram wysyłek — karta produktu sama liczy, kiedy paczka wyjedzie
- Płatność kartą, kryptowalutą i za pobraniem; dostawa Nova Poshta i Meest
- Listy przewozowe tworzone są automatycznie, statusy paczek pobierają się same, klient dostaje SMS
- Program bonusowy, logowanie numerem telefonu, opinie, sprawdzanie IMEI, eksport do Google Merchant
Osobno o przeprowadzce. Sklepu z taką historią nie da się po prostu „przenieść”: przez lata nagromadziły się adresy stron, po których jest znajdowany w Google. Dlatego każdy stary adres prowadzi na swój nowy — takich przekierowań jest ponad trzynaście tysięcy.
Przy okazji naprawiliśmy to, co przez lata przeszkadzało: wcześniej każdy kolor produktu był osobną kartą i konkurowały ze sobą w wyszukiwarce. Teraz kolory to warianty jednej karty, a kupujący przełącza je na miejscu.
Najciekawiej wyszło z dostawcami. Wcześniej aktualizacja cen i dostępności była pracą ręczną: pobrać cennik, zweryfikować, zaktualizować. Teraz dostawca w systemie to po prostu karta z ustawieniami: format pliku (CSV lub XML), adres cennika, jak często go pobierać i która kolumna co oznacza.
Dalej system robi wszystko sam według harmonogramu: pobiera cennik, aktualizuje ceny, ceny promocyjne i dostępność, a produkty, których dostawca już nie ma, zdejmuje ze sprzedaży. Każde uruchomienie zapisuje się w dzienniku — widać, ile pozycji zaktualizowano i co dokładnie się stało.
Ważne, że dostawcy są różni. Każdy ma własne dni wysyłki i godzinę, do której trzeba zdążyć z zamówieniem, a także własne dostępne sposoby dostawy. Wszystko to ustawia się w jego karcie, a kupujący na stronie produktu widzi nie ogólne zdanie, lecz konkret: kiedy dokładnie ten produkt zostanie wysłany. Dzięki temu sklep równie spokojnie pracuje zarówno z własnym magazynem, jak i z dostawcami dropshippingu — w jednym katalogu, bez osobnych stron i tabel.
Panel zrobiono pod pracę menedżera, a nie pod to, na co pozwala platforma. Na głównym ekranie — wykres sprzedaży i szybkie przejścia do tego, czego potrzeba codziennie. W nagłówku — saldo SMS, aby wysyłka nie zatrzymała się w środku dnia, i powiadomienia o nowych zamówieniach.
W zamówieniu menedżer widzi wszystko od razu: skład zamówienia, status płatności, przycisk tworzenia listu przewozowego i status SMS-a do klienta. Cennik dostawcy można wgrać ręcznie, wskazując, która kolumna za co odpowiada — i od razu zobaczyć dziennik, co dokładnie zostało zaktualizowane.
Najważniejsze jest jednak to, że system jest otwarty na rozwój. Kolejne specyficzne wymaganie biznesu to zadanie programistyczne wewnątrz własnego systemu, a nie szukanie i tworzenie wtyczki, która „mniej więcej” potrafi to, co potrzeba.