Zapis zamówienia
WooCommerce miał zapisać wybrane produkty i dane kupującego. Zamówienie pozostawałoby w sklepie jako podstawa dalszej obsługi.
SERWIS Z OPONAMI / DOKUMENTACJA
Specyfikacja techniczna sklepu z oponami
Specyfikacja techniczna sklepu zaleznego od hurtowni (API)
Zaprojektowaliśmy w dokumentacji zależności między doborem opon, ceną sklepu i realizacją zamówienia przez hurtownię, wraz z obsługą wyjątków i zakresem prototypowania.
Strony i e-commerce
00 / Sytuacja wyjściowa
Planowany sklep internetowy miał sprzedawać opony z oferty hurtowni i przekazywać jej zamówienia do realizacji. Właściciel potrzebował określić, jak połączyć dane dostawcy z własnymi regułami cenowymi, płatnościami i obsługą kupujących. Przygotowaliśmy specyfikację techniczną tego serwisu.
01 / ZAKRES OPRACOWANIA
Jak sklep ma sprzedawać z magazynu partnera
Opracowaliśmy specyfikację sklepu na WordPressie i WooCommerce, obejmującą drogę od wyszukania opon do przekazania opłaconego zamówienia hurtowni. Opisaliśmy funkcje dla kupujących i administratorów, podział danych między systemami oraz wymagania wobec integracji.
Kluczowe było powiązanie tego, co klient zobaczy i kupi w sklepie, z informacją o tym, co partner może dostarczyć. Ceny hurtowe i dostępność pochodziłyby z zewnętrznego systemu, a zamówienie i płatność byłyby obsługiwane w sklepie. Dokument określał zależności między tymi częściami sprzedaży.
02 / DOBÓR PRODUKTU
Od danych samochodu do konkretnej opony
Rozpisaliśmy dwie drogi wyszukiwania. Kupujący znający rozmiar miał podawać szerokość, profil i średnicę opony. W drugim wariancie wybierałby parametry samochodu — między innymi markę, model i rocznik.
Ta druga ścieżka wymagała lokalnej bazy przypisującej rozmiary opon do pojazdów. Dopiero ustalony rozmiar miał służyć do wyszukania pasujących produktów w ofercie hurtowni. Specyfikacja rozdzielała więc dobór rozmiaru od pobrania dostępnych opon.
03 / PODZIAŁ ODPOWIEDZIALNOŚCI
Oferta hurtowni, dane zamówień w sklepie
Przyjęliśmy, że hurtownia będzie nadrzędnym źródłem cen bazowych i stanów magazynowych. Produkty miały być pobierane przez API, z możliwością czasowego buforowania odpowiedzi, bez utrzymywania pełnego katalogu na stałe w sklepie. Po stronie WooCommerce pozostawałyby zamówienia i konta klientów, a po stronie sklepu również reguły cenowe. Określiliśmy źródło danych dla każdej z tych części systemu.
04 / REGUŁY CENOWE
Własna cena na podstawie ceny hurtowej
Opisaliśmy mechanizm narzutu stosowanego przy pobieraniu produktu. Administrator miał ustalać i zmieniać reguły w panelu, przypisując je do kategorii, marek lub parametrów opon. Cena dostawcy stanowiłaby podstawę obliczenia ceny widocznej dla kupującego.
W ten sposób dokument wskazywał zarówno miejsce zarządzania polityką cenową sklepu, jak i moment jej zastosowania do danych otrzymanych z hurtowni.
05 / Proces
Projektowany przebieg: od zakupu do przyjęcia przez hurtownię
Potwierdzenie płatności
Potwierdzenie od operatora płatności miało uruchamiać przekazanie zamówienia do hurtowni. Samo opłacenie zakupu nie oznaczałoby jeszcze przyjęcia go przez partnera.
Odpowiedź hurtowni
Integracja miała odebrać potwierdzenie przyjęcia zamówienia albo informację o problemie. Od tej odpowiedzi zależałby kolejny krok obsługi.
06 / SCENARIUSZ DO OBSŁUŻENIA
Co, jeśli po płatności zabraknie towaru?
Uwzględniliśmy scenariusz, w którym kupujący opłaca zamówienie, lecz hurtownia nie może już go zrealizować z powodu braku produktu. Specyfikacja przewidywała odebranie informacji o niedostępności i powiadomienie klienta.
Osobno opisaliśmy błędy komunikacji z API: ich rejestrowanie oraz ponowienie zapytania lub powiadomienie administratora. Dzięki temu wymagania obejmowały także sytuacje, w których płatność została przyjęta, ale przekazanie zamówienia do realizacji wymaga dalszej obsługi.
TWÓJ PROJEKT E-COMMERCE
Ustal zasady działania sklepu przed rozpoczęciem budowy
Przekładamy model sprzedaży na wymagania wobec sklepu, integracji i codziennej obsługi. Pomagamy określić, jakie dane i decyzje mają łączyć te obszary.
08 / OBSŁUGA I UTRZYMANIE
Zadania zespołu obsługującego sklep
Zakres panelu objął zamówienia, ustawienia integracji, reguły cenowe i zarządzanie treścią. Opisaliśmy także wymagania dotyczące bazy wiedzy, newslettera oraz raportów sprzedaży i statusów zamówień.
Uzupełniliśmy je o wymagania dotyczące uprawnień użytkowników, kopii zapasowych i wydajności serwisu. Były to założenia dla przyszłego wykonania i sprawdzenia systemu, określające obok funkcji sprzedażowych również warunki jego utrzymania.
09 / PLAN WERYFIKACJI
Zależności od API wskazane przed implementacją
Rozróżniliśmy wymagany przepływ zamówienia od funkcji zależnych od możliwości partnera. Aktualizacja informacji o wysyłce miała być opcjonalna, możliwa wtedy, gdy API hurtowni udostępni odpowiednie dane lub powiadomienia.
W planie prototypowania wskazaliśmy między innymi pobieranie produktów, wyszukiwanie opon, płatność i przekazanie zamówienia. Dokument wyznaczał zakres weryfikacji tych połączeń przed pełną implementacją.
S.09 / KontaktZapytanie / podobne wyzwanie
Co w tej realizacji przypomina Twoją sytuację?
Opisz podobieństwo i wynik, którego potrzebujesz. Nie założymy, że ten sam zakres będzie właściwą odpowiedzią.
- 1Zakres rozmowyAktywny krok
- 2Kontekst
- 3Budżet i termin
- 4Kontakt
Wracamy z konkretną rekomendacją najpóźniej w następnym dniu roboczym.
Krok 1 / 4