Wdrożenie WooCommerce w firmie z Krasnobrodu i okolic to zwykle projekt na 40–80 roboczogodzin po stronie technicznej — a nie „kilka kliknięć w panelu”. Ten tekst porządkuje stronę organizacyjną: co wchodzi w zakres prac, czego w nim nie ma, ile to trwa i jakie decyzje musisz podjąć po swojej stronie, zanim wykonawca zacznie. Punkt odniesienia dla procesu i wyceny znajdziesz też w materiale o wdrożeniach i optymalizacji WooCommerce dla firm w Zamościu — sama sekwencja etapów jest identyczna, zmienia się głównie otoczenie logistyczne i podatkowe. Dalej znajdziesz listę typowych błędów, checklistę do rozmowy z wykonawcą i odpowiedzi na pytania, które najczęściej padają w pierwszej godzinie ustaleń.
Wdrożenie WooCommerce to projekt, nie instalacja wtyczki. Poniżej sześć bloków — każdy ma osobny zakres i osobny czas realizacji.
Sklep do 300 SKU to najczęściej 40–80 roboczogodzin po stronie technicznej. Do 100 SKU z jedną strefą wysyłki realne jest 40–50 h; 300 SKU z wariantami, kilkoma strefami i dwiema bramkami — bliżej 80 h.
Czego wdrożenie zwykle NIE obejmuje: pisania opisów produktów, sesji zdjęciowych, obsługi księgowej, feedu do Google Merchant Center, kampanii Ads. To osobne projekty i osobne wyceny — jeśli wykonawca wrzuca je „w cenę”, warto sprawdzić, ile godzin realnie na nie przeznacza.
Wdrożenie a opieka techniczna. Wdrożenie to jednorazowy projekt z odbiorem i przekazaniem. Opieka to stały abonament godzinowy z SLA — np. reakcja w 4 h w dni robocze, aktualizacje WordPressa i wtyczek, kopie, monitoring uptime, drobne poprawki. Jedno nie zastępuje drugiego.
Kolejność etapów i sposób rozliczenia opisujemy szerzej przy organizacji wdrożenia WooCommerce dla firm z Zamościa.
| Blok | Zakres | Orientacyjny czas (sklep do 300 SKU) |
|---|---|---|
| Środowisko i hosting | serwer, PHP 8.2+, SSL, cron, staging | 3–6 h |
| Instalacja WordPress + WooCommerce | czysta instalacja, role, konfiguracja bazowa | 2–4 h |
| Produkty i kategorie | struktura, atrybuty, warianty, import CSV | 8–20 h |
| Szablon i UX | szablon potomny, karta produktu, ścieżka zakupowa | 10–20 h |
| Płatności i wysyłka | bramki, strefy, metody dostawy, progi | 6–12 h |
| Testy i start | scenariusze zamówień, dokumentacja, przekazanie | 6–12 h |
Wybór platformy to decyzja na 3–5 lat, nie na jedno wdrożenie. Pięć kryteriów, które realnie różnicują WooCommerce i PrestaShop:
wp_postmeta puchnie, zapytania o atrybuty robią się cięższe, a filtrowanie po wariantach wymaga dodatkowej wtyczki i pamięci podręcznej obiektów (Redis). Przy 10 tys. SKU i więcej PrestaShop jest zwykle szybszy „z pudełka”.Jeśli szukasz punktu odniesienia kosztowego, analiza kosztów wdrożenia WooCommerce dla firm z Zamościa rozbija wycenę na te same elementy.
| Kryterium | WooCommerce | PrestaShop |
|---|---|---|
| Liczba SKU | komfort do ok. 1–5 tys.; wyżej wp_postmeta i cache obiektowy | lepsza wydajność przy dużych katalogach „z pudełka” |
| B2B i grupy cenowe | wtyczka lub moduł własny, koszt utrzymania | natywne grupy klientów i reguły cenowe |
| Wielojęzyczność | WPML / Polylang + wtyczka walutowa (licencje roczne) | wielojęzyczność w rdzeniu |
| Koszt utrzymania (3 lata) | więcej deweloperów, niższe stawki, więcej wtyczek | mniej deweloperów w PL, wyższe stawki |
| Kto prowadzi sklep | gdy obsługa zna WordPressa | gdy obsługa zna PrestaShop |
Siedem etapów, w tej kolejności. Czasy dotyczą sklepu do 300 SKU.
/%postname%/), strefy wysyłki, klasy podatkowe, waluty, jednostki miary, ustawienia e-maili transakcyjnych.upload_max_filesize, post_max_size, max_execution_time — przy 2000 wierszy import potrafi się urwać w połowie.Przy sklepie sezonowym (np. sprzedaż wiosenna) start zaplanuj z 3–4-tygodniowym zapasem — testy zawsze wychwytują coś, czego nie było w założeniach. Wdrożenie WooCommerce dla firm ze Szczebrzeszyna prowadzimy według tej samej sekwencji.
Kolejność ma znaczenie: pomiar → baza → serwer → frontend. Odwrotna kolejność (najpierw wtyczka do cache, potem diagnoza) to najczęstszy sposób na przepalone 20 godzin bez efektu.
Diagnoza (2–4 h). Query Monitor pokaże zapytania na karcie produktu i w kategorii — szukaj tych powyżej 50 ms; ponad 100 zapytań na stronę to sygnał ostrzegawczy. Slow Query Log w MySQL/MariaDB wskaże zapytania bez indeksów, PageSpeed Insights da dane laboratoryjne i polowe (CrUX), a WebPageTest pozwoli wymusić lokalizację testu w Polsce.
Progi na mobile: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — zgodnie z definicją metryk opisanych w materiałach Web Vitals.
wp_options sprawdź wiersze z autoload = yes — kilka opcji po 1–2 MB spowalnia każdy request; w wp_postmeta usuń osierocone wiersze bez odpowiadającego wpisu; wyczyść wygasłe transienty i wpisy w wp_actionscheduler_actions ze statusem failed.pm.max_children (RAM podzielony przez realny rozmiar procesu, zwykle 60–90 MB).fetchpriority="high", liczba wtyczek ograniczona do kilkunastu, skrypty WooCommerce ładowane warunkowo — tylko na koszyku i karcie produktu. Szerszy kontekst porządkowania prac znajdziesz w materiale o organizacji wdrożenia WooCommerce.Pułapka: cache stron z podglądem koszyka. Zcache'owana strona plus skrypt cart fragments pobierający koszyk z sesji równa się klient widzący niepusty koszyk po wejściu na stronę. Rozwiązanie: wyklucz koszyk i zamówienie z cache, wyłącz cart fragments poza tymi stronami i za każdym razem sprawdź efekt w trybie incognito.
| Metryka | Próg (mobile) | Najczęstsza przyczyna w WooCommerce |
|---|---|---|
| LCP | poniżej 2,5 s | niezoptymalizowany obraz główny, brak OPcache, wolne zapytania do bazy |
| INP | poniżej 200 ms | JavaScript ładowany globalnie, zbyt wiele aktywnych wtyczek |
| CLS | poniżej 0,1 | obrazy i banery bez zarezerwowanego miejsca, fonty bez font-display |
Integracje to najczęstsze źródło przekroczenia budżetu — nie dlatego, że są trudne, ale dlatego, że ich zakres bywa niedoszacowany już na etapie oferty. Poniżej to, co realnie decyduje o liczbie godzin.
Bramki płatności. Przelewy24, PayU, Tpay i Stripe różnią się nie samym podłączeniem, a obsługą brzegów: zwroty przez API, webhooki potwierdzające, zachowanie przy porzuconej płatności, płatności odroczone (PayPo, Klarna) z innym cyklem statusów zamówienia. 6–12 h na bramkę to realna wartość, jeśli ma działać automatyczna zmiana statusu po zaksięgowaniu.
Wysyłka. InPost Paczkomaty przez ShipX API to generowanie etykiet, mapa punktów odbioru i statusy przesyłek; DPD, DHL i Poczta mają własne API i własne limity zapytań.
ERP to inny poziom. Punkty zapalne: mapowanie statusów (sklepowe „w realizacji” kontra ERP-owe „przyjęte”), stany magazynowe w czasie rzeczywistym, wystawianie faktur, kolejność i idempotencja komunikatów — bez idempotencji jedna zmiana statusu potrafi wygenerować dwie faktury.
Kanał wymiany danych decyduje o koszcie: REST API producenta ERP (najlepszy, o ile istnieje dokumentacja), pliki XML/CSV po SFTP (tańsze, ale opóźnione i podatne na konflikty), pośrednik typu BaseLinker (abonament w zamian za mniej godzin wdrożeniowych). Analogiczny układ prac opisujemy przy wdrożeniach i optymalizacji WooCommerce dla firm z Zamościa.
Przed wyceną zadaj cztery pytania: kto po stronie firmy odpowiada za ERP, czy istnieje dokumentacja API, jaki jest limit zapytań i kto testuje na środowisku przedprodukcyjnym. Brak odpowiedzi na którekolwiek z nich to ryzyko przeniesione na Ciebie.
| Zakres integracji | Realne godziny | Co podnosi koszt |
|---|---|---|
| Wysyłka (InPost ShipX, DPD, DHL, Poczta) | 8–20 h | mapa punktów odbioru, etykiety PDF, statusy zwrotne |
| ERP w jedną stronę (stany, zamówienia) | 30–50 h | brak dokumentacji API, nietypowe mapowanie statusów |
| ERP dwukierunkowo z fakturowaniem | 50–80 h | idempotencja komunikatów, kolejność zdarzeń, faktury |
Migracja boli w jednym dniu — w dniu przełączenia. Prace przed nim mają sens tylko wtedy, gdy da się je wycofać w kilka minut.
Kolejność: (1) pełna kopia na subdomenę testową z włączonym noindex i test wszystkich ścieżek — produkt, koszyk, płatność, mail; (2) zamrożenie starego sklepu na czas eksportu i importu (realnie 2–6 h, najlepiej w nocy), żeby nie zgubić zamówień złożonych w trakcie; (3) zmiana DNS; (4) weryfikacja po starcie: przekierowania, formularz, płatność testowa, sitemapa.
Mapa przekierowań 301: jeden stary URL = jeden nowy URL. Bez łańcuchów (A → B → C) i bez zbiorczego przekierowania wszystkich produktów na stronę główną — to najszybszy sposób na wyzerowanie ruchu organicznego.
Na 24 h przed migracją obniż TTL rekordu DNS do 300 s. Jeśli coś pójdzie nie tak, powrót zajmie minuty, a nie godziny. W Google Search Console zgłoś zmianę adresu — ma to sens przy zmianie domeny; przy przejściu na nowe ścieżki w tej samej domenie wystarczy mapa 301 i nowa sitemapa. Przez 30 dni po starcie sprawdzaj raport 404. Ta sama sekwencja działa niezależnie od miejscowości — patrz też wdrożenia i optymalizacja WooCommerce w Szczebrzeszynie.
Zapominane elementy: linki wewnętrzne w treściach wpisów i opisach kategorii, obrazy podlinkowane w kategoriach, linki w stopce oraz w kampaniach e-mail wysłanych wcześniej. Każdy z nich trzeba przejść ręcznie.
Dane, które nie mogą przepaść: historia zamówień i konta klientów. Haseł przenieść się nie da — hashe z PrestaShop mają inny format niż WordPress, więc przygotuj reset hasła i uprzedź klientów mailem przed startem. Wtyczki i szablon odtwarzasz w nowym środowisku, nie kopiujesz. Przy okazji przepisz opisy kategorii, zamiast wklejać je 1:1 — zasady tworzenia treści dla ludzi działają tu tak samo jak przed migracją.
| Krok | Kiedy | Kontrola po wykonaniu |
|---|---|---|
| Kopia na subdomenę testową | 3–5 dni przed startem | noindex włączony, płatność i mail testowe, test koszyka |
| Obniżenie TTL do 300 s | 24 h przed zmianą DNS | sprawdzenie rekordów w dig lub narzędziu DNS-checker |
| Zamrożenie starego sklepu | dzień migracji, 2–6 h | eksport zamówień do ostatniej minuty |
| Zmiana DNS i mapa 301 | dzień migracji | jeden URL = jeden cel, brak łańcuchów przekierowań |
| Monitoring po starcie | 30 dni | Search Console: raport 404, ponowne zgłoszenie sitemapy |
Strukturę adresów ustaw przed startem, nie po. W WooCommerce robisz to w Ustawienia → Bezpośrednie linki → Baza kategorii produktu oraz Baza tagu produktu. Jeśli chcesz wyciąć z URL-a segment product-category, wpisz w to pole kropkę. Slug produktu trzymaj krótki i zgodny z nazwą — kurtka-puchowa-czarna-m, nie kurtka-puchowa-czarna-rozmiar-m-kopia. Import z CSV dosypuje końcówki -2, a te po pół roku generują kilkadziesiąt przekierowań do posprzątania. Zmianę bazy zrób raz, przed indeksacją: przy 1500 SKU przebudowa adresów po starcie to tygodnie przepisywania i chwilowy spadek widoczności. Jak te ustawienia wpisują się w całą kolejność prac, rozpisaliśmy w materiale o organizacji wdrożenia WooCommerce.
Dane strukturalne: WooCommerce natywnie wypuszcza Product i Offer w JSON-LD. BreadcrumbList zależy od motywu i często trzeba go dołożyć ręcznie. AggregateRating sam się nie pojawi — WooCommerce nie wstawia średniej ocen do schematu, więc potrzebny jest moduł albo kilka linijek kodu. Katalog typów, które Google faktycznie obsługuje, znajdziesz w dokumentacji Google Search Central o danych strukturalnych.
Z indeksu wyklucz koszyk, zamówienie, moje konto, podziękowanie za zamówienie oraz wyniki filtrowania i sortowania. Paginacji kategorii nie wykluczaj — zostaw self-canonical na każdej stronie, a noindex, follow dodaj tylko widokom z parametrami. Inaczej wypadasz z listy produktów z dalszych stron.
Meta title i description w kategoriach ustaw szablonem (Yoast, Rank Math): title 50–60 znaków, description 140–160. Liczba produktów na stronę kategorii: 12–24. Poniżej 12 rośnie liczba stron paginacji i głębokość indeksacji, powyżej 48 wydłuża się generowanie strony i LCP. Pomiar: Search Console, GA4, Consent Mode v2 oraz polityka prywatności podpięta w miejscu zbierania danych. Wydajność traktuj jako element UX — LCP, INP i CLS przekładają się wprost na porzucenia koszyka.
| Element | Ustawienie |
|---|---|
| Koszyk, zamówienie, moje konto | noindex + Disallow w robots.txt |
| Podziękowanie za zamówienie (/order-received/) | noindex, brak w sitemap |
| Filtry i sortowanie (?filter_, ?orderby=) | noindex, follow |
| Paginacja kategorii (/page/2/) | self-canonical, bez noindex |
| Sitemap | tylko produkty, kategorie, wpisy — bez stron technicznych |
Stawka godzinowa na polskim rynku za prace WooCommerce to najczęściej 120–200 zł netto za godzinę dewelopera. Wszystko poniżej 100 zł zwykle oznacza wdrożenie na gotowym szablonie bez testów płatności i wysyłki — czyli pracę, którą zapłacisz drugi raz przy pierwszej awarii.
Model rozliczenia wybierz świadomie. Rozliczenie godzinowe z limitem (np. 60 h na wdrożenie, nadwyżka tylko po Twojej akceptacji) opłaca się, gdy zakres jest płynny: nie wiesz jeszcze, czy wchodzisz w B2B, czy zostajesz przy B2C. Fixed price z zakresem na piśmie opłaca się, gdy wiesz dokładnie, co chcesz — jesteś wtedy chroniony przed rozjazdem kosztów, ale każda zmiana w trakcie to aneks. Ryzyko siedzi w obu: przy godzinowym — w braku limitu, przy fixed — w niedopisanym zakresie.
Na cenę wpływa liczba szablonów do przygotowania, wielojęzyczność, logika B2B (ceny netto, grupy klientów, limity kredytowe), nietypowa wysyłka (kilku kurierów, palety, progi darmowej dostawy per region) oraz integracja z ERP lub systemem magazynowym. Sam modul niestandardowy to zwykle 15–40 h. Porównanie widełek z drugim rynkiem lokalnym znajdziesz w tekście o koszcie wdrożenia i optymalizacji WooCommerce, a rozbicie stawki na etapy — w opisie cennika i zakresu prac WooCommerce.
Po starcie dolicz opiekę techniczną: 2–5 h miesięcznie na aktualizacje, kopie zapasowe i monitoring. Czytając ofertę, pytaj o trzy rzeczy: ile godzin obejmuje kwota, czy w środku jest środowisko testowe i kto realnie pisze kod — bezpośredni deweloper czy podwykonawca, którego nie poznasz.
| Zakres prac | Czas | Uwagi |
|---|---|---|
| Sklep do 300 SKU, standardowy motyw | 40–80 h | konfiguracja, testy płatności i wysyłki |
| 300–2000 SKU, import i atrybuty | 80–160 h | import CSV, kategorie, warianty, filtry |
| Migracja z innej platformy | 20–60 h | mapowanie danych, przekierowania 301 |
| Moduł niestandardowy | 15–40 h | konfigurator, indywidualna logika wysyłki |
| Wielojęzyczność (WPML/Polylang) | +20–40 h | tłumaczenia, adresy, sitemap per język |
Umowa SLA powinna mieć cztery liczby: czas reakcji, czas naprawy, zakres godzin w abonamencie i dostępność. Czas reakcji to moment, w którym ktoś potwierdzi zgłoszenie — nie czas naprawy. Jeśli wykonawca podaje tylko pierwszą wartość, resztę ustal pisemnie.
Rutynowe prace po starcie są nudne i to jest ich zaleta: aktualizacje rdzenia i wtyczek wgrywane najpierw na staging, kopie zapasowe z testem odtworzenia raz na kwartał, monitoring uptime i błędów PHP (logi z wp-content/debug.log), przegląd Core Web Vitals po każdej większej zmianie. Kolejność etapów przy tego typu pracach opiszemy na przykładzie organizacji wdrożenia WooCommerce w Chełmie.
Sygnały ostrzegawcze u wykonawcy bez zaplecza: brak środowiska testowego (prace idą wprost na produkcji), brak dostępu do kodu i repozytorium, wymijająca odpowiedź na pytanie o plan awaryjny, jedna osoba robiąca wszystko i brak drugiej pary rąk do przeglądu.
| Parametr SLA | Typowe wartości |
|---|---|
| Czas reakcji | 4 h / 8 h / następny dzień roboczy |
| Czas naprawy błędu krytycznego | 4–8 h od potwierdzenia |
| Zakres w abonamencie | 2–5 h miesięcznie, nadwyżka wg stawki godzinowej |
| Monitoring | uptime 24/7, alerty e-mail |
| Kopie zapasowe | codziennie, retencja 14–30 dni, test odtworzenia raz na kwartał |
Zamawianie wdrożenia bez środowiska stagingowego — wszystko testowane od razu na produkcji
Jak wykryć: Zapytaj wykonawcę, na jakim adresie będziesz mógł kliknąć sklep przed startem. Jeśli odpowie „przetestujemy po uruchomieniu”, to znak ostrzegawczy.
Jak naprawić: Wpisz do umowy oddzielne środowisko testowe (subdomena lub osobny hosting) z kopią bazy i co najmniej jednym pełnym cyklem zamówienia: gość, zalogowany, kod rabatowy, zwrot.
Wybór szablonu po wyglądzie, a nie po wydajności i liczbie dołączonych wtyczek
Jak wykryć: Przed zakupem sprawdź w PageSpeed Insights demo szablonu na mobile i policz, ile wtyczek producent dołącza jako obowiązkowe.
Jak naprawić: Szablon kupuj pod szybkość: lekkie motywy bez wbudowanego buildera. Jeśli potrzebujesz modyfikacji, rób je w szablonie potomnym albo w jednej dedykowanej wtyczce — nie przez dopisywanie kodu do plików rodzica, bo zniknie przy aktualizacji.
Import produktów bez wcześniejszego mapowania atrybutów i wariantów
Jak wykryć: Po pierwszym imporcie CSV sprawdź, czy liczba wariantów zgadza się z plikiem, czy nie powstały duplikaty i czy atrybuty nie utworzyły się jako nowe, puste taksonomie.
Jak naprawić: Najpierw zaimportuj 10–20 produktów testowych, ustal nazwy atrybutów używanych globalnie, dopiero potem wrzucaj całość. Przy dużych plikach podziel import na partie i sprawdź limit czasu wykonania oraz rozmiar uploadu na serwerze.
Konfiguracja płatności i wysyłki wgrywana od razu na produkcję bez trybu sandbox
Jak wykryć: Sprawdź, czy bramka płatnicza ma w panelu przełącznik trybu testowego i czy wykonawca przesłał Ci zrzuty transakcji testowych.
Jak naprawić: Każdą bramkę uruchom najpierw w sandboxie i przejdź nią pełną ścieżkę: koszyk, płatność, powrót do sklepu, mail, faktura. Metody dostawy mapuj do stref wysyłki i progów darmowej dostawy dopiero po zatwierdzeniu cennika przez firmę.
Traktowanie wdrożenia jako stałej opieki technicznej
Jak wykryć: Porównaj ofertę z pytaniem: „co się dzieje w miesiącu 4 po starcie?”. Jeśli w ofercie nie ma pozycji abonamentowej z SLA, to nie jest opieka.
Jak naprawić: Rozdziel umowę na jednorazowe wdrożenie i abonament opieki z określonym czasem reakcji, liczbą godzin w miesiącu i zakresem (aktualizacje, kopie, monitoring, poprawki).
Brak higieny bazy od pierwszego dnia — tabela wp_options rośnie razem z każdą wtyczką
Jak wykryć: Zainstaluj Query Monitor i sprawdź liczbę zapytań oraz czas generowania strony w panelu. W bazie sprawdź wp_options pod kątem wierszy z autoload = yes.
Jak naprawić: Po wdrożeniu przejrzyj opcje z autoload i wyłącz te, które nie muszą ładować się na każdym żądaniu, usuń osierocone transienty i wtyczki, których nikt nie używa. Zmiany rób na kopii, nie na produkcji.
Strona organizacyjna wdrożenia WooCommerce to przede wszystkim ustalenie zakresu i podziału odpowiedzialności. Wdrożenie to jednorazowy projekt techniczny na 40–80 roboczogodzin przy sklepie do 300 SKU, a nie stała opieka nad sklepem. Treści, zdjęcia, feed produktowy i kampanie reklamowe niemal zawsze są poza tym zakresem, więc zaplanuj je osobno. Jeśli chcesz porównać proces i kolejność etapów dla innej lokalizacji, zobacz materiał o wdrożeniach i optymalizacji WooCommerce dla firm w Szczebrzeszynie.
Dla sklepu do 300 SKU sama praca techniczna to zwykle 40–80 roboczogodzin. Kalendarzowo najczęściej wychodzi 3–6 tygodni, bo duża część czasu to oczekiwanie na treści, zdjęcia i decyzje biznesowe po stronie firmy. Realistyczny plan uruchomienia względem sezonu układaj od tyłu: start minus dwa tygodnie na testy i poprawki.
Zwykle nie. Wdrożenie obejmuje techniczne przygotowanie importu i konfigurację katalogu, ale treści opisów, tłumaczenia i sesje zdjęciowe to osobne prace. Ustal to na piśmie w pierwszej rozmowie, bo brak opisów to najczęstszy powód przesunięcia startu.
Tak, przy każdym sklepie, który ma działać dłużej niż kilka miesięcy. Bez osobnego środowiska każda aktualizacja wtyczki i każda zmiana w szablonie to ryzyko dla sprzedaży. Testy na produkcji zdarzają się tylko wtedy, gdy ktoś akceptuje przerwę w przyjmowaniu zamówień.
Granica nie jest ostra, ale praktycznie: przy 1–5 tys. SKU WooCommerce pracuje komfortowo, powyżej zaczynają się problemy z tabelami wp_postmeta i wp_options oraz czasem zapytań. Drugi sygnał to rozbudowane B2B z grupami cenowymi i indywidualnymi cennikami — tam PrestaShop ma więcej natywnych rozwiązań, a w WooCommerce trzeba dopisać moduł własny.
Trzeba policzyć trzy pozycje: licencje płatnych wtyczek i szablonu, hosting oraz abonament opieki technicznej. Liczba płatnych wtyczek rośnie z każdą funkcją, więc warto przejrzeć listę po pierwszym roku i usunąć to, czego nikt nie używa. Do tego dochodzą koszty pracy osoby, która prowadzi sklep.
Nie, to osobne usługi. Wdrożenie kończy się na sklepie, który poprawnie działa i ma poprawne dane produktów. Feed, dane strukturalne i kampanie planuj jako kolejny etap po starcie, gdy katalog jest już stabilny i ceny się nie zmieniają codziennie.
Osoba, która realnie zna asortyment i ma czas reagować na zamówienia. Kryterium praktyczne przy wyborze platformy brzmi: na czym ta osoba już pracowała. Jeśli w firmie nikt nie czuje się swobodnie w panelu WordPressa, warto wliczyć w projekt godzinę lub dwie szkolenia i krótką instrukcję obsługi.
Jeśli chcesz przejść przez te ustalenia z kimś, kto robi to na co dzień, opisz krótko swój asortyment i plan startu — w DropDigital odpowiemy, co jest realne w Twoim terminie i co warto przesunąć na później.