Przed uruchomieniem sklepu internetowego sprawdź pełną ścieżkę zamówienia: produkt, wariant, koszyk, checkout, płatność, dostawę, potwierdzenie, mail transakcyjny i widok zamówienia w panelu. Sklep jest gotowy do publikacji dopiero wtedy, gdy klient może złożyć zamówienie bez zgadywania, a obsługa widzi w panelu komplet danych potrzebnych do jego realizacji.
Nie oceniaj sklepu tylko po wyglądzie strony głównej. Przy odbiorze ważniejsze jest to, czy działa zakup na telefonie, czy koszt dostawy liczy się poprawnie, czy płatność zmienia status zamówienia, czy mail dochodzi do klienta i czy błąd formularza mówi, co trzeba poprawić. Jeśli test pokazuje, że brakuje podstawowej funkcji sprzedażowej, wróć do zakresu i porównaj go z tym, jakie funkcje sklepu na start powinny być gotowe przed pierwszymi klientami.
W praktyce odbiór sklepu powinien mieć formę krótkiego protokołu: test, wynik, decyzja i osoba odpowiedzialna za poprawkę. To pomaga oddzielić błędy blokujące start od drobnych zadań rozwojowych. Przy tworzeniu sklepów internetowych największe ryzyko pojawia się zwykle nie w grafice, ale w niedotestowanym checkoutcie, płatnościach, dostawach, mailach i panelu zamówień.
Co sprawdzić przed uruchomieniem sklepu w 30 sekund
Najpierw wykonaj jedno pełne zamówienie testowe tak, jak zrobiłby to klient. Wejdź na kartę produktu, wybierz wariant, dodaj produkt do koszyka, przejdź checkout, wybierz dostawę, wybierz płatność, zaakceptuj wymagane zgody, kliknij przycisk finalizacji i sprawdź, co dzieje się po zakupie. Potem przejdź do panelu sklepu i zobacz, czy zamówienie da się obsłużyć.
| Obszar | Co ma działać | Decyzja |
|---|---|---|
| Karta produktu | Wariant, cena, dostępność, zdjęcia, opis i przycisk dodania do koszyka są jasne | Popraw przed startem, jeśli klient nie wie, co kupuje |
| Koszyk | Ilość, wariant, rabat, dostawa i suma zamówienia są poprawne | Wstrzymaj start, jeśli suma lub wariant są błędne |
| Checkout | Pola, zgody, dostawa, płatność i przycisk finalizacji działają na mobile i desktopie | Wstrzymaj start, jeśli klient nie może dokończyć zakupu |
| Płatność | Sukces, błąd i anulowanie płatności mają czytelny status | Wstrzymaj start, jeśli sklep nie wie, czy zamówienie jest opłacone |
| Dostawa | Metoda, koszt, termin, ograniczenia i dane do wysyłki są jasne | Wstrzymaj start, jeśli koszt dostawy jest losowy lub niezgodny z zasadami |
| Maile | Klient dostaje potwierdzenie i wie, co dalej | Wstrzymaj start, jeśli po zakupie nie ma żadnej informacji |
| Panel | Zamówienie, dane klienta, wariant, płatność i status są widoczne | Wstrzymaj odbiór, jeśli obsługa musi zgadywać, co zrealizować |
Werdykt w 30 sekund: możesz publikować sklep, jeśli pełna ścieżka zamówienia przechodzi na telefonie i komputerze, płatność oraz dostawa ustawiają właściwe statusy, maile dochodzą, a panel pozwala obsłużyć zamówienie bez ręcznego wyjaśniania podstawowych danych. Jeśli którykolwiek z tych punktów nie działa, nie podpisuj pełnego odbioru.
Czerwona flaga: wykonawca pokazuje tylko stronę główną, katalog i koszyk, ale nie przechodzi z Tobą płatności, maili, błędów formularza i widoku zamówienia w panelu. To nie jest pełny odbiór sklepu, tylko prezentacja frontu.
Zamówienie testowe od produktu do potwierdzenia
Zamówienie testowe jest najważniejszym scenariuszem odbioru. Nie chodzi o kliknięcie "dodaj do koszyka", tylko o przejście całej drogi klienta od wyboru produktu do potwierdzenia zamówienia. Dopiero wtedy widać, czy sklep rzeczywiście sprzedaje, czy tylko wygląda jak sklep.
Zacznij od produktu, który ma realny wariant: rozmiar, kolor, pojemność, konfigurację, pakiet albo inną cechę wpływającą na zamówienie. Jeśli sklep ma produkty proste i produkty wariantowe, przetestuj przynajmniej scenariusz z wariantem, bo tam częściej pojawiają się błędy w koszyku, panelu i mailach.
| Krok testu | Co sprawdzić | Co oznacza problem |
|---|---|---|
| Karta produktu | Czy cena, wariant, dostępność i dostawa są zrozumiałe przed dodaniem do koszyka | Klient może kupić zły wariant albo zrezygnować przez brak informacji |
| Dodanie do koszyka | Czy po kliknięciu widać komunikat i produkt trafia do koszyka z właściwą ilością | Klient nie wie, czy akcja się udała |
| Koszyk | Czy da się zmienić ilość, usunąć produkt, zobaczyć wariant, rabat i sumę | Klient nie może poprawić zamówienia bez cofania się |
| Checkout | Czy formularz zbiera tylko potrzebne dane i pokazuje błędy przy polach | Zbyt długi lub nieczytelny checkout blokuje zakup |
| Zgody i przycisk | Czy wymagane zgody są widoczne, a finalizacja jasno wskazuje zamówienie z obowiązkiem zapłaty | Proces może być nieczytelny dla klienta i ryzykowny formalnie |
| Potwierdzenie | Czy po zakupie jest numer zamówienia, podsumowanie i dalsze kroki | Klient nie ma dowodu, że proces się zakończył |
W zamówieniu testowym użyj danych, które pozwalają sprawdzić realne pola: imię i nazwisko, e-mail, telefon, adres dostawy, ewentualne dane do faktury i komentarz do zamówienia, jeśli sklep ma takie pole. Nie wpisuj samych znaków testowych, bo wtedy nie zobaczysz, czy formularz dobrze waliduje telefon, kod pocztowy, adres e-mail albo NIP.
Jeśli sklep ma kody rabatowe, sprawdź przynajmniej jeden poprawny i jeden błędny kod. Poprawny powinien zmienić sumę w przewidywalny sposób. Błędny powinien dać jasny komunikat, a nie cicho zniknąć albo zepsuć koszyk. Jeśli sklep ma próg darmowej dostawy, sprawdź zamówienie poniżej i powyżej progu.
Decyzja praktyczna: jedno zamówienie testowe jest minimum, ale nie zawsze wystarczy do odbioru. Jeśli sklep ma kilka głównych metod płatności, kilka typów dostawy, produkty wariantowe i faktury, trzeba przejść najważniejsze scenariusze osobno. Nie musisz testować każdej możliwej kombinacji, ale sprawdź te ścieżki, które będą używane od pierwszego dnia.
Płatności i dostawy bez zgadywania
Płatności i dostawy są krytyczne, bo wpływają jednocześnie na decyzję klienta i pracę obsługi. Klient musi wiedzieć, ile zapłaci, kiedy dostanie paczkę i co stało się z płatnością. Obsługa musi wiedzieć, czy zamówienie można realizować, jaką metodę dostawy wybrał klient i czy dane do wysyłki są kompletne.
Nie wystarczy informacja, że "płatności są podłączone". Trzeba sprawdzić, co dzieje się przy udanej płatności, płatności anulowanej, błędzie operatora i statusie oczekującym. Jeżeli sklep obsługuje przelew tradycyjny, pobranie albo płatność odroczoną, każdy z tych scenariuszy powinien mieć jasny status zamówienia.
| Scenariusz | Co widzi klient | Co widzi obsługa | Co blokuje start |
|---|---|---|---|
| Płatność udana | Potwierdzenie zamówienia i jasny status płatności | Zamówienie oznaczone jako opłacone albo gotowe do dalszej obsługi | Brak zmiany statusu po poprawnej płatności |
| Płatność anulowana | Informację, że płatność nie została zakończona i co może zrobić dalej | Zamówienie oczekujące, anulowane albo oznaczone do wyjaśnienia zgodnie z procesem | Zamówienie wygląda jak opłacone mimo anulowania |
| Błąd płatności | Komunikat bez straszenia i możliwość ponowienia lub wyboru innej metody | Status pozwalający odróżnić błąd od sukcesu | Brak informacji, czy zamówienie istnieje |
| Przelew tradycyjny lub pobranie | Warunki płatności i dalszy krok | Status zgodny z ręczną lub automatyczną obsługą | Obsługa nie wie, czy realizować zamówienie |
| Dostawa kurierska lub punkt odbioru | Koszt, metoda, adres albo wybrany punkt | Dane do nadania przesyłki, metoda i ewentualny tracking | Brak pełnych danych wysyłki |
| Odbiór osobisty | Miejsce, warunki i informacja, kiedy zamówienie będzie gotowe | Status gotowe do odbioru i dane kontaktowe klienta | Odbiór osobisty istnieje w sklepie, ale firma go realnie nie obsługuje |
Przy dostawach sprawdź nie tylko listę metod. Ważne są reguły: koszt przy różnych wartościach koszyka, darmowa dostawa, gabaryty, kraje wysyłki, produkty wysyłane osobno, dostawa do punktu i sytuacja, w której klient wpisze błędny adres. Jeśli sklep sprzedaje produkty ciężkie, duże, robione pod zamówienie albo wysyłane z różnych magazynów, reguły dostawy muszą być nazwane przed publikacją.
Osobnym testem jest etykieta i tracking, jeśli mają działać od startu. Sprawdź, czy obsługa może wygenerować etykietę, czy numer nadania wraca do zamówienia i czy klient dostaje informację o wysyłce. Jeśli etykieta ma być generowana ręcznie poza sklepem, to też powinno być opisane. Najgorszy wariant to półautomatyzacja, w której wszyscy zakładają, że ktoś inny zmieni status.
Jeżeli płatności, dostawy, magazyn, faktury i statusy mają wymieniać dane automatycznie, potraktuj integracje w sklepie internetowym jako osobny punkt odbioru. Wtedy test nie kończy się na tym, że klient widzi metodę płatności lub dostawy. Trzeba jeszcze sprawdzić, gdzie trafia zamówienie, który system zmienia status i kto widzi błąd synchronizacji.
Czerwona flaga: koszt dostawy pojawia się dopiero na końcu, zmienia się bez wyjaśnienia albo nie zgadza się z zasadami firmy. Dla klienta to wygląda jak ukryty koszt, a dla obsługi oznacza ręczne prostowanie zamówień.
Maile transakcyjne, statusy i komunikaty błędów
Maile transakcyjne są częścią działania sklepu, nie dodatkiem do grafiki. Po zakupie klient powinien dostać podsumowanie zamówienia, numer zamówienia, informacje o płatności, dostawie, danych sprzedawcy i dalszych krokach. Jeśli tego nie ma, klient zaczyna pisać do obsługi albo ponawia zakup, bo nie wie, czy proces się udał.
Sprawdź skrzynkę klienta i panel sklepu po każdym ważnym scenariuszu: zamówienie opłacone, płatność nieudana, zmiana statusu, wysyłka, anulowanie i ewentualny zwrot, jeśli ten proces ma być obsługiwany od startu. Nie zakładaj, że skoro pierwszy mail doszedł, wszystkie kolejne też są poprawne.
| Komunikat | Co powinien zawierać | Co sprawdzić |
|---|---|---|
| Potwierdzenie zamówienia | Numer, produkty, warianty, suma, dostawa, adres, dane kontaktowe | Czy dane zgadzają się z koszykiem i panelem |
| Status płatności | Informację o sukcesie, oczekiwaniu, błędzie albo anulowaniu | Czy klient nie dostaje sprzecznych informacji |
| Zmiana statusu | Prosty opis, co stało się z zamówieniem | Czy status w mailu odpowiada statusowi w panelu |
| Wysyłka | Metoda, numer nadania lub informacja o odbiorze, jeśli dotyczy | Czy tracking nie jest pusty albo błędny |
| Błąd formularza | Wskazanie konkretnego pola i problemu | Czy klient wie, co ma poprawić |
| Brak metody dostawy | Jasny powód i możliwy kolejny krok | Czy komunikat nie kończy się ogólnym "spróbuj ponownie" |
Błędy formularzy testuj celowo. Zostaw puste wymagane pole, wpisz niepoprawny e-mail, błędny kod pocztowy, za krótki numer telefonu, niepełny adres i dane do faktury, jeśli są dostępne. Komunikat powinien pojawić się przy właściwym polu i pozwolić poprawić błąd bez utraty danych z całego formularza.
Zwróć uwagę na treść przycisku finalizacji zamówienia. W sklepie internetowym klient musi jasno rozumieć, że kliknięcie kończy się zamówieniem z obowiązkiem zapłaty. To punkt do weryfikacji w aktualnym kontekście prawnym, podobnie jak regulamin, polityka prywatności, cookies, informacje o zwrotach i dokumenty związane z odstąpieniem od umowy. Artykuł nie zastępuje konsultacji prawnej, ale przy odbiorze sklepu nie warto odkładać tych elementów na "po starcie".
Czerwona flaga: komunikat "coś poszło nie tak" bez wskazania problemu. Taki komunikat nie pomaga klientowi poprawić adresu, płatności, telefonu ani danych do faktury. W praktyce zamienia błąd techniczny w zgłoszenie do obsługi.
RWD, checkout mobilny i formularze
RWD w sklepie nie oznacza tylko tego, że strona mieści się na ekranie telefonu. Klient ma być w stanie znaleźć produkt, wybrać wariant, dodać go do koszyka, przejść checkout, zapłacić i wrócić do potwierdzenia bez przybliżania ekranu, cofania się po kilka razy i zgadywania, gdzie jest przycisk.
Test mobilny wykonaj na realnym telefonie, nie tylko w podglądzie przeglądarki. Podgląd jest przydatny, ale nie pokaże wszystkich problemów z klawiaturą, sticky paskiem, wyborem punktu odbioru, przewijaniem koszyka czy widocznością komunikatu błędu.
| Miejsce | Co sprawdzić na telefonie | Czerwona flaga |
|---|---|---|
| Menu i wyszukiwanie | Czy da się wejść do kategorii, produktu i koszyka | Menu zasłania treść albo nie da się go zamknąć |
| Karta produktu | Czy zdjęcia, warianty, cena i CTA są czytelne | Przycisk zakupu znika pod sticky elementem |
| Koszyk | Czy widać wariant, ilość, sumę i koszt dostawy | Klient musi przewijać w kółko, żeby znaleźć przejście dalej |
| Checkout | Czy pola są czytelne, a klawiatura nie zasłania przycisku | Nie widać błędu albo finalizacji zamówienia |
| Płatność | Czy przekierowanie działa i wraca do sklepu | Klient wraca na pustą stronę albo nie wie, co stało się z płatnością |
| Formularze | Czy etykiety, zgody i błędy są widoczne | Placeholder znika, a użytkownik nie wie, co wpisać |
Na desktopie sprawdź z kolei szerokie i mniejsze ekrany. Sklep może wyglądać dobrze na dużym monitorze, ale na laptopie koszyk, pasek cookies, chat i sticky header mogą zasłonić finalizację. Jeżeli sklep ma formularze w modalu, rozwijane wybory dostawy albo mapę punktów odbioru, trzeba zobaczyć, czy te elementy nie blokują przewijania i wyboru.
Przy formularzach ważne są etykiety pól, kolejność przechodzenia, walidacja i zachowanie po błędzie. Użytkownik nie powinien tracić uzupełnionych danych tylko dlatego, że pomylił kod pocztowy. Błąd powinien być widoczny, zrozumiały i powiązany z konkretnym polem.
Decyzja praktyczna: mobile blokuje start, jeśli klient nie może samodzielnie dokończyć zakupu. Drobne przesunięcie tekstu w mniej ważnej sekcji można wpisać do poprawek, ale ukryty przycisk finalizacji, niedziałający wybór dostawy albo niewidoczny błąd formularza to blokery odbioru.
Panel sklepu i gotowość obsługi
Sklep musi działać także po stronie panelu. Publiczna ścieżka zakupu może wyglądać dobrze, ale jeśli obsługa nie widzi statusu płatności, wariantu produktu, adresu dostawy albo danych do faktury, zamówienie zaczyna wymagać ręcznego wyjaśniania.
Po zamówieniu testowym zaloguj się do panelu i sprawdź, czy zamówienie da się obsłużyć bez wiedzy programisty. To jest szczególnie ważne, gdy sklep ma wiele wariantów, kody rabatowe, dostawę do punktu, faktury, integracje z magazynem albo sprzedaż w kilku kanałach.
| Element w panelu | Co powinno być widoczne | Dlaczego to ważne |
|---|---|---|
| Zamówienie | Numer, data, produkty, warianty, ilości, suma | Obsługa wie, co klient kupił |
| Dane klienta | E-mail, telefon, adres dostawy, dane do faktury, jeśli dotyczy | Da się zrealizować i skontaktować z klientem |
| Status płatności | Opłacone, oczekujące, anulowane, nieudane lub inny jasny status | Obsługa wie, czy kompletować paczkę |
| Dostawa | Metoda, koszt, adres, punkt odbioru, numer nadania | Da się nadać przesyłkę bez przepisywania danych |
| Stany i warianty | SKU, wariant, dostępność, rezerwacja, jeśli jest używana | Sklep nie sprzedaje czegoś innego niż klient wybrał |
| Dokumenty | Faktura, paragon, dane do dokumentu albo informacja, gdzie dokument powstaje | Księgowość i obsługa nie działają na domysłach |
| Historia zmian | Statusy, notatki, maile lub logi, jeśli są dostępne | Da się odtworzyć, co stało się z zamówieniem |
Panel nie musi od razu mieć rozbudowanej automatyzacji zwrotów, zaawansowanego helpdesku i pełnego OMS. Na start musi jednak pozwalać obsłużyć zamówienie, zmienić status, sprawdzić płatność, przygotować wysyłkę i skontaktować się z klientem. Jeśli któraś z tych rzeczy wymaga ręcznego szukania danych w kilku miejscach, trzeba opisać to jako ryzyko.
Sprawdź też role użytkowników. Konto właściciela lub administratora powinno mieć uprawnienia do podstawowej obsługi sklepu, a osoby operacyjne nie powinny pracować na przypadkowym wspólnym loginie. To nie musi być rozbudowany system uprawnień, ale po starcie powinno być jasne, kto może zmieniać produkty, ceny, statusy, treści i ustawienia płatności.
Jeśli odbiór obejmuje analitykę, nie poprzestawaj na informacji, że kod śledzący jest wklejony. Osobno sprawdź mierzenie sprzedaży w sklepie internetowym od startu: zdarzenie zakupu, wartość zamówienia, produkty, źródła sprzedaży i zgodność danych z panelem sklepu. Błędny pomiar nie zawsze blokuje samą publikację, ale blokuje sensowną ocenę pierwszych kampanii i zmian w checkoutcie.
Praktyczny wniosek: odbiór sklepu nie kończy się na poprawnym froncie. Kończy się dopiero wtedy, gdy zamówienie złożone przez klienta jest kompletne, zrozumiałe i obsługiwalne w panelu.
Blokery startu i poprawki po odbiorze
Nie każda uwaga musi zatrzymać publikację, ale błędów krytycznych nie wolno przepychać na "po starcie". Najlepiej podzielić listę uwag na trzy grupy: blokuje start, popraw przed kampanią, monitoruj po publikacji. Dzięki temu nie blokujesz projektu przez drobiazg, ale też nie wypuszczasz sklepu, który nie potrafi przyjąć zamówienia.
| Priorytet | Przykłady | Decyzja |
|---|---|---|
| Blokuje start | Zamówienie nie zapisuje się w panelu, płatność nie działa, koszt dostawy jest błędny, checkout nie działa na mobile, klient nie dostaje potwierdzenia | Nie podpisuj pełnego odbioru |
| Popraw przed kampanią | Wolniejsze ładowanie części widoków, mniej czytelny komunikat, brak części treści pomocniczych, słabszy opis warunków dostawy | Można publikować ostrożnie tylko wtedy, gdy zakup działa |
| Monitoruj po publikacji | Drobne usprawnienia treści, dodatkowe raporty, rozwój automatyzacji, kolejne szablony maili | Nie blokuje startu, jeśli ma właściciela i termin |
Blokery odbioru to zwykle problemy, które uniemożliwiają zakup, płatność, dostawę, komunikację albo obsługę zamówienia. Do tej grupy należą: brak zamówienia w panelu, błędny status płatności, brak maila transakcyjnego, niedziałający formularz checkoutu, brak kosztu dostawy, niepoprawny wariant produktu, błąd na telefonie i brak podstawowych informacji prawnych przy zakupie.
Poprawki po odbiorze mogą dotyczyć rzeczy, które nie blokują zamówienia: dopracowania części tekstów, uporządkowania dodatkowych komunikatów, poprawy zdjęć, rozwinięcia instrukcji dla obsługi albo szerszego raportowania. Warunek jest jeden: poprawka musi mieć właściciela, termin i opis. Bez tego "po starcie" często znaczy "nigdy nie wróciliśmy do tematu".
Ważne jest też rozróżnienie błędu od nowego zakresu. Jeśli w ustalonym zakresie miała działać płatność online i nie działa, to jest błąd odbiorowy. Jeśli po testach chcesz dodać nowego operatora płatności, kolejną metodę dostawy, automatyczne zwroty albo rozbudowaną integrację z magazynem, to zwykle jest nowy zakres lub etap rozwoju.
Czerwona flaga: wykonawca mówi, że brak maili, statusów, widoku płatności albo obsługi błędu "dopnie się po uruchomieniu", mimo że są częścią podstawowej ścieżki sprzedaży. To nie jest kosmetyka. To ryzyko dla pierwszych klientów.
Kiedy zaakceptować prace nad sklepem
Akceptacja prac powinna nastąpić dopiero po sprawdzeniu publicznej ścieżki zakupu i zaplecza obsługi. Nie musi oznaczać, że sklep jest idealny i ma wszystkie funkcje rozwojowe. Ma oznaczać, że pierwsze zamówienia można przyjąć, oznaczyć właściwym statusem płatności, wysłać, potwierdzić i obsłużyć bez chaosu.
Przy zamknięciu projektu warto też rozdzielić testy sklepu od formalnego przekazania projektu. Test mówi, czy klient może kupić, a przekazanie mówi, czy firma ma dostęp, instrukcję, kopie, zasady poprawek i kontrolę nad usługami. Ten drugi obszar dobrze porównać z tym, co powinien przekazać wykonawca po wdrożeniu strony, nawet jeśli odbierany projekt jest sklepem, a nie prostą stroną firmową.
Najprostszy protokół odbioru może mieć cztery kolumny: test, wynik, decyzja i odpowiedzialny. Wpisuj tam konkretne obserwacje, a nie ogólne oceny. Zamiast "koszyk do poprawy" lepiej napisać: "po zmianie ilości suma zamówienia nie aktualizuje się do momentu odświeżenia strony". Zamiast "problem z mailem" lepiej napisać: "po płatności nieudanej klient dostaje mail taki sam jak po płatności udanej".
Końcowa checklista odbioru:
| Test | Wynik, którego szukasz | Decyzja |
|---|---|---|
| Zamówienie testowe | Produkt, wariant, koszyk, checkout i potwierdzenie działają | Odbierz, jeśli zamówienie powstaje poprawnie |
| Płatność | Sukces, błąd i anulowanie mają jasne statusy | Wstrzymaj, jeśli sklep myli statusy |
| Dostawa | Koszt, metoda, adres, punkt odbioru i ograniczenia są poprawne | Wstrzymaj, jeśli klient może wybrać niemożliwą dostawę |
| Maile | Klient dostaje właściwe informacje po zakupie i zmianach statusu | Wstrzymaj, jeśli po zakupie nie ma potwierdzenia |
| RWD | Zakup działa na telefonie i desktopie | Wstrzymaj, jeśli mobile blokuje checkout |
| Panel | Obsługa widzi komplet danych i może zmienić status | Wstrzymaj, jeśli zamówienie trzeba wyjaśniać ręcznie |
| Formularze | Walidacja wskazuje konkretne błędy i nie kasuje danych | Popraw przed startem, jeśli klient nie wie, co zrobić |
| Dokumenty i zgody | Regulamin, prywatność, cookies, zwroty i przycisk finalizacji są aktualnie zweryfikowane | Nie odkładaj elementów formalnych na po publikacji |
| Lista poprawek | Blokery są zamknięte, a drobne poprawki mają właściciela i termin | Podpisz odbiór tylko przy jasnym zakresie dalszych prac |
Możesz zaakceptować sklep, gdy główna ścieżka klienta działa, panel obsługuje zamówienie, a lista pozostałych uwag nie dotyczy elementów blokujących sprzedaż. Nie akceptuj prac jako zakończonych, jeśli zamówienie testowe nie przechodzi, płatność ma niejasny status, klient nie dostaje maila albo obsługa nie widzi w panelu danych potrzebnych do realizacji.
Ostateczna decyzja jest prosta: uruchamiaj sklep wtedy, gdy potrafi bezpiecznie przyjąć i obsłużyć pierwsze zamówienia. Jeśli sklep tylko wygląda na gotowy, ale nie przechodzi testu zakupu, płatności, dostawy, maili, RWD i panelu, wróć z konkretną listą braków zamiast podpisywać odbiór na podstawie prezentacji.