Budowa sklepu internetowego: co projekt naprawdę obejmuje

Budowa sklepu internetowego to nie sam wybór szablonu graficznego. Jak przygotować katalog, rozliczenia, dostawę i proces odstąpienia od umowy oraz co sprawdzić przed uruchomieniem.

Sklep internetowy nie jest gotowy w chwili, gdy da się w nim otworzyć stronę produktu i wrzucić towar do koszyka. Jest gotowy wtedy, gdy kupujący widzi właściwą cenę, wybiera wariant, który naprawdę jest dostępny, płaci i dostaje zrozumiałe potwierdzenie, a sprzedawca potrafi zamówienie zrealizować i w razie potrzeby przyjąć towar z powrotem; oprawa graficzna jest najbardziej widoczną częścią projektu, ale to nie ona rozstrzyga, czy pierwsze zamówienie skończy się dostawą.

Dlatego pytanie o to, jak wygląda budowa sklepu internetowego, trzeba najpierw doprecyzować: jaki proces sprzedaży ma przebiegać bez improwizacji? Odpowiedź zaczyna się od jednego towaru i jednego pełnego zamówienia, w którym jest jasne źródło danych, rezerwacja stanu, wynik płatności, utworzenie przesyłki i postępowanie przy odstąpieniu od umowy. Każde pytanie bez odpowiedzi staje się później zakresem pracy albo ręczną czynnością: trzeba wskazać odpowiedzialnego, czas realizacji i granicę, poza którą ręczne podejście już nie wystarcza. W przeciwnym razie technicznie skończony sklep nadal będzie opierał się na ustnej umowie i pamięci człowieka.

Ten artykuł dotyczy przygotowania projektu i jego odbioru, a nie porównywania cen platform; przed pracami i uruchomieniem trzeba przygotować dane wejściowe, oddzielić funkcje sklepu od procesu firmy i przyjąć pracę na prawdziwym zamówieniu testowym, a nie na zrzucie ekranu. Takie podejście pasuje zarówno wtedy, gdy budują Państwo sklep sami, jak i wtedy, gdy zadanie powierzają Państwo wykonawcy.

Na początek jedno zamówienie, nie nazwa platformy

Zanim wybiorą Państwo technologię, trzeba opisać jedno zwyczajne zamówienie od znalezienia towaru do dostawy, na konkretnym towarze, cenie, sposobie płatności i adresie. Należy zapisać, co na każdym etapie robi kupujący, sklep i Państwa pracownik. Jeśli odpowiedź brzmi „to załatwimy ręcznie”, trzeba też wskazać odpowiedzialną osobę, czas potrzebny na czynność i liczbę zamówień, przy której taki porządek przestanie być praktyczny.

Ten opis szybko pokazuje, czy potrzebują Państwo standardowego sklepu, czy bardziej indywidualnej obsługi zamówień, bo katalog, jedna logika cen, zwykła płatność kartą i paczkomat zwykle nie wymagają złożonego systemu, natomiast ceny według umowy z klientem, dostępność w kilku magazynach albo zatwierdzanie w innym systemie zmieniają zakres jeszcze przed projektem graficznym. Na liście funkcji oba projekty mogą wyglądać podobnie, ale w opisie procesu różnica staje się oczywista i da się ją zamienić w kryterium odbioru, które na końcu projektu można sprawdzić bez zgadywania, co wykonawca miał na myśli.

Platformę trzeba wybrać według tego procesu i spodziewanego wzrostu: WooCommerce może być racjonalnym rozwiązaniem przy ustandaryzowanej sprzedaży, a Laravel daje więcej swobody przy nietypowej logice i integracjach; szersze porównanie jest w artykule o tym, kiedy wybrać WooCommerce, a kiedy Laravel. Na tym etapie ważniejsze jest zrozumienie, że sama nazwa platformy nie mówi, co stanie się z Państwa zamówieniem.

Do opisu procesu trzeba też dodać jeden wyjątek i sprawdzić, co się stanie, jeśli płatność się nie uda, dwóch ludzi jednocześnie spróbuje kupić ostatnią sztukę, paczkomat będzie niedostępny albo klient będzie chciał oddać część zestawu. Nie trzeba wyliczać każdej rzadkiej sytuacji, jednak jeden nieudany scenariusz ujawnia statusy, powiadomienia i obowiązki pracowników znacznie lepiej niż dziesięć zielonych odhaczeń w wycenie.

Katalog zaczyna się od definicji jednostki sprzedaży

Plik Excel z produktami to jeszcze nie katalog, bo najpierw trzeba się umówić, czym w systemie jest jedna jednostka sprzedaży: dla zwykłej książki może to być jeden towar z jedną ceną i stanem, ale przy odzieży każda kombinacja rozmiaru i koloru może mieć własny SKU, zdjęcie, kod kreskowy i stan. Przy zestawie z kolei trzeba wiedzieć, czy jest samodzielnym produktem, czy zbiorem kilku jednostek magazynowych.

Trzeba przygotować jeden w pełni wypełniony towar wzorcowy, zanim zespół zacznie masowy import, i zawrzeć w nim nazwę, krótki i pełny opis, cenę, sposób naliczania podatku, kategorię, wariant, SKU, stan, wagę lub wymiary istotne dla dostawy, zdjęcia oraz inne informacje ważne dla kupującego. Wzorzec pozwala zauważyć brakujące pole, gdy trzeba poprawić jeden wiersz, i jednocześnie daje projektantowi prawdziwą treść, a nie idealną kartę demonstracyjną.

Nieograniczona liczba SKU w rozwiązaniu technicznym nie oznacza, że przygotowanie czterdziestu i czterech tysięcy towarów to ta sama praca, bo cena funkcji sklepu może się nie zmienić, ale w większym katalogu rośnie czyszczenie danych, powiązanie zdjęć, sprawdzanie wariantów, tłumaczenie i import. Dlatego w wycenie trzeba osobno wskazać zdolność platformy do przechowywania katalogu i pracę, którą trzeba włożyć, żeby Państwa dane nadawały się do użycia; w tę pracę może wchodzić mapowanie pól, obsługa błędnych wierszy, sprawdzenie zdjęć i porównanie końcowego importu z plikiem źródłowym.

Odzież: rozmiar i kolor to nie tylko filtr

W sklepie odzieżowym rozmiar i kolor często są wariantami z własną dostępnością, a nie tylko wartościami filtra, dlatego kupujący musi widzieć, że niebieski rozmiar M się skończył, nawet jeśli czarny M jeszcze jest, zdjęcie ma się zmieniać wraz z wybranym kolorem, a do zamówienia ma trafić dokładna kombinacja. Zanim wprowadzą Państwo cały katalog, trzeba sprawdzić jeden produkt z co najmniej dwoma rozmiarami, dwoma kolorami i jednym niedostępnym wariantem.

Katalog potrzebuje właściciela także po uruchomieniu, dlatego należy ustalić, kto zmienia cenę, dodaje wariant, poprawia opis i wycofuje towar ze sprzedaży, a jeśli informacje przychodzą od dostawcy albo z systemu ERP, trzeba określić główne źródło danych i kierunek synchronizacji. Dwa miejsca, w których pracownicy mogą poprawiać jedną cenę, nie dają elastyczności, tylko przesłankę do rozjazdu danych. Dlatego trzeba się umówić co do historii zmian, uprawnień do zatwierdzania i postępowania przy błędnym imporcie; zespół musi umieć ustalić, w którym źródle powstała zła wartość i czego już zdążyła dotknąć.

Proces płatności trzeba opisać statusami i działaniami

Integracja płatności nie jest skończona wraz z otwarciem okna płatności, bo w projekcie trzeba ustalić, co sklep robi po każdym wyniku: udana płatność może zmienić status zamówienia, wysłać potwierdzenie, zmniejszyć dostępną ilość i przekazać zadanie do kompletacji. Nieudana albo przerwana płatność nie może wyglądać jak opłacone zamówienie, ale nie powinna też rezerwować towaru bez końca.

W codziennym języku „płatność się udała” może znaczyć, że bank potwierdził transakcję, operator płatności ją zarejestrował albo pieniądze są już na koncie firmy, a proces realizacji nie może opierać się na tak niejasnym sformułowaniu, dlatego należy ustalić, który status systemu pozwala zacząć kompletację i jak pracownik widzi zamówienie wymagające sprawdzenia. Zamówienia za pobraniem i przelewem trzeba obsługiwać osobno, a nie jako kopię procesu płatności kartą.

Trzeba też rozstrzygnąć, jak długo nieopłacone zamówienie trzyma towar w rezerwacji, bo zbyt krótki okres może zwolnić towar, gdy kupujący jeszcze kończy płatność, a zbyt długi sztucznie zmniejsza dostępny stan. Podstawowe ustawienia stanów WooCommerce’a pozwalają zarządzać ilością i ustawić czas rezerwacji dla nieopłaconych zamówień, więc standardowy sklep może kontrolować swój wewnętrzny stan bez zewnętrznej integracji magazynowej.

Przed uruchomieniem trzeba wykonać co najmniej jedną udaną płatność, jedną przerwaną i jeden zwrot, w trybie testowym albo na niewielką realną kwotę, i sprawdzić ekran kupującego, status zamówienia w administracji, e-maile, zmianę stanu i zapis u operatora płatności. Jeśli zespół widział tylko scenariusz sukcesu, duża część procesu płatności nadal nie jest sprawdzona, bo w realnej pracy trzeba odróżnić opóźnione powiadomienie banku, płatność przerwaną przez kupującego i błąd systemu, a po każdym przypadku w administracji ma zostać zrozumiały zapis.

Dostawa i realizacja zamówienia to nie jedno odhaczenie

Integracja dostawy może policzyć cenę, pokazać paczkomaty, utworzyć przesyłkę i zwrócić numer śledzenia, ale nie każde rozwiązanie robi to wszystko, dlatego sformułowanie „podłączyć kuriera” trzeba zastąpić konkretnymi pytaniami: czy kupujący wybiera paczkomat, czy cena zależy od wagi, kwoty koszyka albo kraju, czy etykieta powstaje w sklepie i czy link śledzenia sam trafia do e-maila?

Realizacja zamówienia zaczyna się po jego przyjęciu, a pracownik musi jasno widzieć opłacone i do skompletowania zamówienia oraz sposób postępowania przy błędach. Należy ustalić, kto może zmieniać status, czy kupujący dostaje powiadomienie i jak jest zapisywany numer śledzenia; w małym sklepie może to robić jedna osoba, ale w większym zespole bez podziału odpowiedzialności jedno zamówienie można przygotować dwa razy, podczas gdy inne zostanie pominięte.

Ceny dostawy trzeba sprawdzić na skrajnych przykładach, nie tylko na jednym przeciętnym koszyku, i wypróbować najtańszy i najdroższy towar, próg darmowej dostawy, adres poza dozwolonym obszarem oraz towar, którego nie da się włożyć do paczkomatu. Jeśli w obliczeniu jest waga, jeden towar bez wagi może rozbić cały wynik. Przy cenie stałej trzeba wiedzieć, kto pokrywa różnicę przy niestandardowej przesyłce; trzeba też sprawdzić dostawę w kilku paczkach i to, czy metoda zostaje dostępna dla koszyka z towarami o różnych rozmiarach.

Odbiór w biurze albo w sklepie stacjonarnym też jest metodą dostawy z własnymi zasadami, dlatego kupujący musi znać adres, godziny i moment, w którym zamówienie jest gotowe do odbioru, a pracownik magazynu ma się o tym wyborze dowiedzieć na czas. Dobry test nie kończy się napisem „zamówienie przyjęte”, tylko paczką albo towarem przygotowanym do wydania i dokładnym powiadomieniem wysłanym do kupującego.

Wymagania wobec zamówienia i odstąpienia trzeba zamienić w konkretne działania

Umowę na odległość można zawrzeć na stronie internetowej, e-mailem, w komunikatorze albo inną zdalną drogą, dlatego obowiązki sprzedawcy nie znikają, jeśli zamówienie przyjmą Państwo w sieci społecznościowej, a fakturę wyślą później; w elektronicznym procesie zamawiania przycisk albo równoważna czynność musi jednoznacznie wskazywać, że zamówienie tworzy obowiązek zapłaty. Wymagania dotyczą samej kolejności zamawiania, a nie tylko strony regulaminu w stopce witryny.

Ustawa o prawach konsumenta przewiduje, że bezpośrednio przed elektronicznym zamówieniem kupujący ma zobaczyć między innymi określone istotne informacje, cenę końcową i koszty dodatkowe, natomiast sposoby płatności i ograniczenia dostawy trzeba podać nie później niż na początku składania zamówienia. Ponieważ skład wymagań może się zmieniać, przed uruchomieniem trzeba sprawdzić redakcję obowiązującą tego dnia i porównać ekrany sklepu z konkretnymi przepisami.

W potwierdzeniu zamówienia musi znaleźć się kopia samych warunków umowy albo inny dokument na trwałym nośniku, który kupujący może zachować w niezmienionej postaci; sam link do strony, którą sprzedawca może jednostronnie zmieniać, nie wystarcza, dlatego trzeba sprawdzić, czy w potwierdzeniu są zamówione towary, cena, dostawa, dane sprzedawcy i wymagane informacje przedumowne. Dokładny zestaw dokumentów i sformułowań należy uzgodnić z prawnikiem stosownie do Państwa modelu sprzedaży. Użytą wersję trzeba zachować razem z datą zamówienia, żeby w sporze dało się pokazać nie tylko aktualną stronę regulaminu, ale też informacje faktycznie przekazane kupującemu.

UOKiK wyjaśnia, że konsumentowi przy towarach zwykle przysługuje czternastodniowe prawo odstąpienia od umowy, liczone od otrzymania towaru, a w przepisach wymienione są konkretne wyjątki. W projekcie trzeba przewidzieć nie tylko tekst o odstąpieniu, ale też formularz albo kontakt, rejestrację daty oświadczenia, sprawdzenie towaru, zwrot pieniędzy i przywrócenie stanu; jeśli te czynności żyją w pamięci jednego pracownika, sklep działa tylko tak długo, jak długo ten człowiek jest dostępny.

Sklep bez własnego magazynu nadal jest procesem sprzedawcy

Sklep można prowadzić bez własnego fizycznego magazynu, na przykład wysyłając towar od dystrybutora albo producenta, i w ten sposób zmniejszyć potrzebę trzymania zapasów, ale to nie znosi odpowiedzialności sprzedawcy wobec kupującego. Jeśli umowa jest zawarta z Państwa firmą, za jej wykonanie wobec kupującego nadal odpowiada Państwa firma, a nie dostawca.

W takim modelu krytyczna jest informacja o dostępności, a jeśli dostawca zapewnia strumień danych albo interfejs programistyczny, trzeba ustalić częstotliwość odświeżania, obsługę błędów i postępowanie przy zerwaniu połączenia. Pięciominutowe opóźnienie przy szybko sprzedawanej ostatniej sztuce może być istotne, ale dla katalogu o wolnym obrocie stanów może być akceptowalne. Częstotliwość synchronizacji trzeba ustalić według ruchu stanów i ryzyka firmy, i umówić się też, czy w czasie błędu połączenia towar jest ukrywany, zostaje w sprzedaży, czy idzie do ręcznego sprawdzenia.

Ważne jest rozróżnienie wewnętrznej ewidencji stanów sklepu od modułu magazynowego albo zewnętrznej integracji: podstawowe możliwości WooCommerce’a mogą przechowywać ilość dla każdego towaru i wariantu, zmniejszać ją po zamówieniu i nie pozwalać zamówić towaru bez stanu, i tego może wystarczyć jednemu katalogowi utrzymywanemu w samym sklepie. Moduł magazynowy staje się potrzebny, gdy główny stan żyje w innym systemie, jest kilka miejsc składowania albo trzeba zsynchronizować kilka kanałów sprzedaży.

Przed uruchomieniem trzeba przećwiczyć sytuację, w której dostawca nie może zrealizować zamówienia, choć towar na ekranie sklepu nadal jest dostępny, i ustalić, kto dostaje powiadomienie, jak szybko kontaktuje się z kupującym, czy oferuje alternatywę i jak robi zwrot pieniędzy. Ten scenariusz nie czyni modelu złym, ale zamienia nieoczekiwane utrudnienie w ryzyko, którym da się zarządzać.

Czy można zbudować sklep internetowy za darmo?

Bezpłatna budowa sklepu internetowego może znaczyć kilka różnych rzeczy, na przykład darmowy szablon graficzny, oprogramowanie open source, plan próbny albo wystawę w mediach społecznościowych. Te narzędzia mogą obniżyć początkową opłatę licencyjną i pomóc sprawdzić, czy oferta kogoś interesuje, ale nie znoszą pracy przy danych towarów, płatnościach, dostawie, regulaminie, bezpieczeństwie i codziennej administracji.

Jeśli budują Państwo sklep sami, trzeba zacząć od najmniejszego procesu, który da się poprawnie wykonać, bo jeden język, niewielki katalog, jeden sposób płatności i jedna metoda dostawy pozwalają sprawdzić popyt bez utrzymywania złożonych integracji. Także w takiej wersji kupujący musi widzieć właściwą cenę i warunki dostawy, zamówienie musi trafić do administracji, a Państwo muszą umieć wysłać towar i obsłużyć odstąpienie od umowy.

Koszty zwykle pojawiają się tam, gdzie kończy się darmowe narzędzie: na domenie i hostingu, prowizjach od płatności, płatnych wtyczkach, imporcie danych, dopasowaniu szaty graficznej, utrzymaniu i Państwa własnym czasie, dlatego należy porównywać nie tylko miesięczną subskrypcję, ale też godziny, które pójdą na katalog, usuwanie błędów i aktualizacje. Już na etapie próbnym trzeba zapisywać powtarzalne czynności, bo darmowe narzędzie może być oszczędne tylko tak długo, jak długo ręczna obsługa nie pożera zaoszczędzonej opłaty licencyjnej. Jeśli jedną ręczną czynność wykonują Państwo przy pięciu zamówieniach, może być uzasadniona; przy pięciuset zamówieniach jest już mierzalną pozycją kosztową.

Profesjonalna pomoc staje się racjonalna wtedy, gdy błąd kosztuje więcej niż wdrożenie albo proces już nie mieści się w dniu pracy jednej osoby, a o takiej granicy mogą świadczyć rozjeżdżające się stany, kilka języków i grup cenowych, powtarzane ręczne sprawdzanie danych albo integracje z księgowością i dostawcami. Sklep zbudowany własnymi siłami nie jest porażką, a zatrudnienie wykonawcy nie jest obowiązkowym następnym krokiem; decyzję wyznacza złożoność procesu i zdolność firmy do jego utrzymania. W zespole potrzebny jest ktoś, kto regularnie sprawdza aktualizacje, kopie zapasowe, komunikaty bezpieczeństwa i dzienniki błędów, a także trzeba umieć odtworzyć proces zakupu po aktualizacji wtyczek i opisać rozwiązanie tak, żeby sklep nie zależał od wolnego czasu jednego pracownika.

Niezależnie od tego, kto wykonuje pracę, konta domeny, hostingu, operatora płatności i dostawy mają być pod kontrolą firmy, a nie powiązane z prywatnym adresem jednego pracownika albo zewnętrznego specjalisty; trzeba zapisać, gdzie trzyma się dostępy, kto może zatwierdzać płatności i jak odzyskuje się dostęp, gdy odpowiedzialna osoba jest nieobecna. W projekcie robionym własnymi siłami ten porządek jest równie ważny jak przy zleceniu na zewnątrz, bo uprawnienia administracyjne w platformie jeszcze nie oznaczają kontroli nad domeną, serwerem i umowami z usługami zewnętrznymi.

Treści i migrację trzeba przygotować przed końcem prac

Projekt sklepu często opóźnia nie kod, tylko brakujące dane towarów, zdjęcia i decyzje, dlatego należy ustalić, kto w firmie dostarcza treści, kto je zatwierdza i które pola są obowiązkowe, a każdy etap pośredni potrzebuje daty. Wykonawca może utworzyć pole na opis, ale nie może za firmę zdecydować, co wolno obiecać o towarze.

Zdjęcia potrzebują jednolitej proporcji, wystarczającej rozdzielczości i prawa do użycia; trzeba sprawdzić nazwy plików, teksty alternatywne i to, które zdjęcie należy do konkretnego wariantu. Jeśli dostawca zmienia adresy zdjęć bez ostrzeżenia, zewnętrzny odnośnik może zniknąć, dlatego bezpieczniejszy proces zwykle polega na kontrolowanym imporcie i optymalizacji zdjęć w środowisku sklepu, z zachowaniem powiązania z identyfikatorem produktu.

W migracji trzeba osobno spisać produkty, kategorie, klientów, historię zamówień, kupony, treści i pliki, bo nie wszystko wolno albo trzeba przenosić, a historyczne dane klientów trzeba ocenić także z punktu widzenia ochrony danych i okresów przechowywania. Przed pełną migracją należy zrobić próbę na niewielkim zbiorze, porównać liczby rekordów i pól i dopiero wtedy wyznaczyć moment, od którego w starym systemie nic się już nie zmienia; po końcowym imporcie trzeba przygotować zestawienie braków, duplikatów i wartości, które nowy system zinterpretował inaczej.

Przy zmianie witryny trzeba przygotować mapę starych i nowych adresów, bo adres bez przekierowania prowadzi użytkownika i wyszukiwarkę na nieistniejącą stronę, a samo przekierowanie nie gwarantuje poprzednich pozycji w wynikach wyszukiwania, pomaga jednak zachować logiczną ścieżkę i przekazać sygnały właściwej nowej stronie. Po uruchomieniu należy sprawdzić najważniejsze adresy produktów i kategorii, a nie tylko stronę główną.

Przed uruchomieniem trzeba wykonać pełny test odbioru

W teście odbioru trzeba użyć realistycznego scenariusza kupującego z konkretnym towarem: otworzyć sklep w telefonie, znaleźć towar wyszukiwaniem albo kategorią, wybrać wariant, wrzucić go do koszyka i zmienić ilość, a potem sprawdzić cenę z podatkami, przewidzianą zniżkę i dostawę. Dalej idzie się aż do złożenia zamówienia, zapłaty i przeczytania wszystkich ekranów oraz e-maili.

Test trzeba kontynuować w administracji: sprawdzić status zamówienia, spadek stanu dokładnie na wybranym wariancie, adres, paczkomat i uwagę kupującego, utworzyć przesyłkę, wysłać informację o śledzeniu i zakończyć zamówienie. Na końcu należy obsłużyć odstąpienie od umowy i zwrot pieniędzy, bo pełny cykl często pokazuje, że każda funkcja osobno działa, ale informacja nie przechodzi z jednej funkcji do drugiej.

Krótszy test trzeba powtórzyć z błędami: nieważnym kuponem, niedostępnym wariantem, przerwaną płatnością, adresem poza strefą dostawy i ostatnią sztuką towaru, a komunikat błędu ma wyjaśniać następny krok i system nie może zostawić błędnej rezerwacji. Wynikiem testu ma być nie tylko lista błędów, ale też decyzja, które z nich blokują uruchomienie. Przy każdej poprawce trzeba wskazać odpowiedzialnego, datę ponownego sprawdzenia i dowód odbioru, a potem upewnić się, że błąd już się nie powtarza ani w telefonie, ani w przeglądarce na komputerze.

Trzeba też sprawdzić ustawienia prywatności i analityki, bo opcjonalne skrypty analityki, reklamy albo innego śledzenia, których działanie wymaga zgody, nie mogą ruszyć przed odpowiednim wyborem, a sprawdzenie trzeba zrobić także po odmowie i po wycofaniu zgody. Czynności techniczne potrzebne do zamówienia nie mogą z kolei przestać działać, jeśli kupujący odmówi analityki.

W chwili uruchomienia trzeba wyznaczyć odpowiedzialnych i przygotować plan działania na wypadek awarii, ustalając, kto sprawdza płatności, dostawę i treści, komu zgłaszać krytyczny błąd i jak postąpić, gdy nie da się przyjmować płatności albo ceny są złe. Czasem bezpieczniejszą decyzją jest na jakiś czas wstrzymać zamawianie, zamiast zbierać zamówienia, których nie da się zrealizować. W kontroli uruchomienia należy porównać konfigurację środowiska testowego i publicznego, klucze płatności, konta dostawy, ustawienia podatków i nadawcę e-maila, bo udany test w innym środowisku jeszcze nie dowodzi, że te same warunki działają w sklepie dostępnym dla kupującego.

Administracja i utrzymanie zaczynają się przed uruchomieniem

Administrator sklepu to nie abstrakcyjna rola przyznawana po przekazaniu projektu, dlatego przed uruchomieniem trzeba ustalić, kto ma prawo zmieniać ceny, publikować produkty, robić zwroty i widzieć dane klientów, bo nie każdy człowiek potrzebuje wszystkich uprawnień. Redaktor treści zwykle nie musi zmieniać ustawień płatności, a pracownik magazynu nie musi widzieć więcej informacji o kliencie, niż potrzeba do przygotowania przesyłki.

Należy ustalić, jak instaluje się aktualizacje systemu, wtyczek i integracji, które nie powinny po raz pierwszy trafić do publicznie dostępnego sklepu w piątkowe popołudnie tylko dlatego, że w panelu administracyjnym pojawił się komunikat. Potrzebna jest kopia zapasowa, środowisko testowe i człowiek, który po zmianie wykona krótki test zakupu, bo aktualizacja może dotknąć nie tylko wyglądu, ale też integracji płatności, dostawy i e-maila.

Trzeba ustalić, kto zauważa, że powiadomienia o płatnościach przestają dochodzić do sklepu, interfejs przesyłek zwraca błąd albo gwałtownie rośnie liczba nieudanych zamówień. Telefon od kupującego nie może być pierwszym sygnałem o błędzie. Przynajmniej przy krytycznych integracjach potrzebny jest dziennik błędów i powiadomienie dla odpowiedzialnego, a zespołowi — tryb obsługi incydentów, w którym trzeba wskazać, gdzie trzyma się decyzję o rozwiązaniu tymczasowym i według jakiego kryterium sprawdza się przywrócenie usługi.

W pierwszych tygodniach pomiary mają odpowiadać na pytania o proces, a nie tylko liczyć odwiedziny, dlatego należy porównywać rozpoczęte i dokończone zakupy, błędy płatności, wybory dostawy i powody zgłoszeń do obsługi. Jeśli wielu ludzi zatrzymuje się na jednym etapie, najpierw trzeba sprawdzić przeszkodę techniczną albo treściową, zanim wyciągną Państwo wniosek, że na rynku nie ma popytu.

Co przygotować przed rozmową z wykonawcą

Żeby pierwsza rozmowa była produktywna, trzeba przygotować jeden towar wzorcowy, jeden pełny scenariusz zamówienia i jedną sytuację wyjątkową oraz dopisać przybliżoną liczbę towarów i wariantów, języki, kraje, sposoby płatności i dostawy. Jeśli jest już istniejąca strona, należy wskazać, co chcą Państwo przenieść i z jakimi systemami sklep ma wymieniać dane; nie muszą Państwo znać rozwiązania technicznego, ale muszą Państwo umieć pokazać pracę firmy.

Osobno trzeba nazwać wymagania, które mają być w pierwszym uruchomieniu, i pomysły, które wolno odłożyć: podstawowy proces płatności i dostawy zwykle jest wymaganiem startu, natomiast złożony program lojalnościowy może być następnym etapem, jeśli bez niego da się poprawnie przyjąć i zrealizować zamówienie. Ten podział chroni budżet lepiej niż dowolne skreślanie funkcji, bo każda odłożona praca zostaje z nazwanym powodem, zależnością i momentem, w którym do decyzji trzeba wrócić po prawdziwych danych z zamówień.

Towar wzorcowy, scenariusz zamówienia i sytuacja wyjątkowa wystarczą, żeby w analizie projektu sklepu internetowego ustalić jasny i sprawdzalny zakres pracy, a także termin i cenę. W wycenie należy żądać nie tylko nazw funkcji, ale też granic: kto przygotowuje dane, kto konfiguruje usługę zewnętrzną i po jakim teście praca jest przyjęta.

Jeśli mają Państwo już katalog albo szkic procesu, następnym krokiem jest przejrzeć go z kimś, kto potrafi ocenić zależności techniczne, a jeśli szkicu jeszcze nie ma, możemy zacząć od jego sporządzenia i powiedzieć, czego w pierwszej wersji nie trzeba budować. Zamówić analizę projektu sklepu internetowego warto przed wyborem platformy, bo wtedy cenę wyznacza jasno określony zakres pracy, a nie założenia co do tego, co powinno się mieścić w słowie „sklep”. Obie strony już przed pracami muszą tak samo rozumieć, jaki sprawdzalny wynik potwierdzi, że projekt jest skończony.