Projektowanie marketplace nie kończy się na przygotowaniu katalogu ofert i mechanizmu zakupowego. Platforma powinna również pozyskiwać, weryfikować i prezentować informacje o sprzedawcach, producentach, produktach oraz ich bezpieczeństwie. To oznacza, że architektura informacji, formularze, statusy ofert i komunikacja z kupującymi muszą tworzyć spójny proces, a nie zbiór niezależnych funkcji.
Dla zarządu, właściciela firmy i zespołu odpowiedzialnego za produkt oznacza to konieczność uwzględnienia podejścia compliance by design już na etapie projektowania. Wymagania wynikające z DSA i GPSR wyznaczają kategorie obowiązków, natomiast szczegółowy układ interfejsu pozostaje decyzją projektową i operacyjną organizacji. Poniżej opisano, jak zaplanować kartę produktu, onboarding sprzedawcy, blokowanie niekompletnych ofert oraz komunikaty o wycofaniu lub zagrożeniu produktu. Obecność danych lub ostrzeżeń nie jest przy tym potwierdzeniem bezpieczeństwa produktu.
Marketplace jako system informacji, nie tylko katalog ofert
Od katalogu ofert do kontrolowanego procesu informacji
Oferta marketplace jest połączeniem kilku warstw informacji: danych sprzedawcy, danych producenta, identyfikacji produktu oraz ostrzeżeń i informacji bezpieczeństwa. Każda z tych warstw może mieć inne źródło, zakres dostępności i znaczenie operacyjne. Dlatego projektowanie marketplace powinno obejmować nie tylko widok dla kupującego, lecz także formularz sprzedawcy, mechanizmy weryfikacji, statusy kontroli i historię decyzji.
W praktyce przejrzystość wymaga rozdzielenia ról marketplace, sprzedawcy, producenta oraz odpowiedzialnego podmiotu w UE, gdy producent nie ma siedziby w Unii Europejskiej. Interfejs powinien wspierać przekazywanie informacji wymaganych przed zawarciem umowy, dotyczących zgodności i bezpieczeństwa produktu. Nie istnieje jeden obowiązkowy układ graficzny karty produktu, dlatego forma komponentów powinna wynikać z logiki oferty, potrzeb użytkowników i przyjętego procesu kontroli.
Jakie dane sprzedawcy należy pozyskać i które pokazać klientowi
Onboarding, weryfikacja i publiczny moduł sprzedawcy
Przed dopuszczeniem sprzedawcy do oferowania produktów konsumentom platforma powinna pozyskać, gdy mają zastosowanie, jego nazwę, adres, numer telefonu, adres e-mail, dokument identyfikacyjny lub identyfikację elektroniczną, dane rachunku płatniczego, dane właściwego rejestru handlowego oraz samocertyfikację zgodności oferowanych produktów lub usług z prawem Unii Europejskiej. Nie wszystkie te informacje muszą być następnie prezentowane publicznie.
Projekt onboardingu powinien wyraźnie oddzielać dane używane do wewnętrznej weryfikacji od danych przeznaczonych dla kupującego. Platforma powinna podejmować najlepsze starania w celu oceny wiarygodności i kompletności informacji, między innymi przez wykorzystanie oficjalnych, publicznie dostępnych baz lub żądanie dokumentów potwierdzających. Nie należy automatycznie uzupełniać braków na podstawie domysłów.
Przy ofercie produktu w sposób jasny, łatwo dostępny i zrozumiały powinny być dostępne co najmniej nazwa sprzedawcy, jego adres i dane kontaktowe, dane właściwego rejestru oraz samocertyfikacja, jeżeli mają zastosowanie. Praktycznym rozwiązaniem jest widoczny moduł „Sprzedawca” na karcie produktu. Powinien on być integralną częścią oferty, a nie informacją ukrytą w trudno dostępnej części panelu lub odległej podstronie.
Warto zaplanować także statusy weryfikacji, które pozwolą rozróżnić dane kompletne, wymagające potwierdzenia oraz niezgodne. Zakres informacji może zależeć od rodzaju produktu, roli danego podmiotu, właściwych przepisów sektorowych i rynku, na którym oferta jest udostępniana. Dlatego lista pól powinna być oceniona w kontekście konkretnego modelu marketplace.
Karta produktu marketplace — architektura informacji wspierająca przejrzystość i bezpieczeństwo
Warstwy informacji na karcie produktu
Karta produktu marketplace powinna porządkować informacje według ich funkcji i odpowiedzialności. Pierwszą warstwę stanowią dane sprzedawcy dostępne przy ofercie. Drugą tworzą dane producenta: nazwa, zarejestrowana nazwa handlowa lub znak towarowy, adres pocztowy i adres elektroniczny. Jeżeli producent nie ma siedziby w UE, należy przewidzieć również dane odpowiedzialnego podmiotu w UE.
Kolejna warstwa dotyczy identyfikacji produktu. Oferta powinna umożliwiać prezentację obrazu, typu i innych identyfikatorów pozwalających rozpoznać konkretny produkt. Uzupełnieniem są ostrzeżenia i informacje bezpieczeństwa w języku zrozumiałym dla konsumentów danego rynku. Takie rozdzielenie ułatwia zarówno odbiór informacji przez kupującego, jak i późniejsze powiązanie oferty z działaniami operacyjnymi.
Nie należy przedstawiać samej obecności danych, ostrzeżeń lub identyfikatorów jako potwierdzenia bezpieczeństwa. Karta produktu wspiera przejrzystość i proces zgodności, ale nie zastępuje oceny produktu ani odpowiedzialności właściwych podmiotów. Treść ostrzeżeń powinna opierać się na potwierdzonych informacjach, a nie na przypuszczeniach.
Dostępność informacji w interfejsie
Informacje wymagane przy ofercie powinny być czytelne i łatwo dostępne. Projekt nie powinien sprowadzać ich do elementów, których znalezienie wymaga wieloetapowego przechodzenia przez interfejs. Stałe sekcje, obowiązkowe pola i widoczne komunikaty pozwalają zachować spójną hierarchię informacji. Konkretna kolejność i forma komponentów są jednak decyzją projektową, ponieważ źródła nie definiują jednego obowiązkowego układu karty.
Dostępność należy oceniać w różnych sposobach korzystania z platformy, w tym na urządzeniach mobilnych. Ważne jest, aby moduł sprzedawcy, dane producenta, identyfikatory oraz ostrzeżenia nie traciły znaczenia wskutek skrócenia, ukrycia lub nieczytelnego przedstawienia. Karta powinna wspierać szybkie rozpoznanie, kto oferuje produkt, czego dotyczy oferta i czy istnieją informacje wymagające szczególnej uwagi.
Compliance by design w procesie dodawania oferty
Walidacja przed publikacją i obsługa braków
Compliance by design oznacza w tym przypadku takie zaprojektowanie formularza i procesu, aby oferta bez minimalnych informacji o bezpieczeństwie i identyfikowalności nie mogła zostać opublikowana. Walidacja powinna obejmować dane sprzedawcy, producenta, odpowiedzialnego podmiotu, produktu oraz ostrzeżeń, gdy są wymagane dla danej oferty.
Praktyczny przebieg może obejmować status roboczy, status „wymaga uzupełnienia”, weryfikację, publikację oraz blokadę. Jeżeli brakuje danych, interfejs powinien wskazać konkretne elementy wymagające uzupełnienia i umożliwić dostarczenie dokumentów. Po uzupełnieniu powinna następować ponowna weryfikacja, a decyzja powinna zostać zapisana w rejestrze.
Warto przewidzieć ścieżkę eskalacji do zespołu odpowiedzialnego za zgodność oraz rozdzielić komunikat dla sprzedawcy od statusu widocznego dla kupującego. Oferta bez wymaganych danych powinna być oznaczona jako niegotowa do publikacji albo zablokowana zgodnie z przyjętą procedurą. Źródła nie określają jednego workflow ani konkretnego czasu reakcji, dlatego te elementy pozostają decyzją operacyjną marketplace.
Obsługa ofert niezgodnych i produktów niebezpiecznych
Kontrola statusu i historii oferty
Po wykryciu braku danych, niezgodności lub zagrożenia platforma powinna móc oznaczyć ofertę, ograniczyć do niej dostęp albo ją usunąć, zgodnie z decyzją i procedurą organizacji. Działanie powinno być powiązane z identyfikacją produktu i sprzedawcy, aby można było ustalić zakres objętych ofert oraz dalsze kroki.
Istotne jest zachowanie śladu decyzji: kto i na jakiej podstawie zmienił status, czego dotyczyła decyzja oraz jakie działania wykonano. Proces powinien ograniczać ryzyko ponownego pojawienia się identycznej oferty w niezmienionej formie. Należy również uwzględnić współpracę z właściwymi podmiotami, zasady ochrony danych i procedury obowiązujące w organizacji. Statusu oferty nie należy ukrywać ani przedstawiać w sposób rozmywający odpowiedzialność.
Komunikaty o wycofaniu i ostrzeżenia dla kupujących
Struktura komunikatu bezpieczeństwa
Komunikat o wycofaniu lub zagrożeniu powinien jednoznacznie wskazywać produkt i jego identyfikatory. Powinien również przedstawiać charakter zagrożenia albo przyczynę wycofania, zakres objętej oferty, instrukcję dalszego postępowania oraz kanał kontaktu. Treść musi wynikać z potwierdzonych informacji o produkcie i właściwej procedury, a nie z przypuszczeń.
Informację należy zaprezentować przy ofercie oraz na dedykowanej stronie informacji bezpieczeństwa. Oferta powinna otrzymać jednoznaczny status, na przykład wycofania, blokady lub ograniczenia dostępu, zgodnie z decyzją organizacji. Nie należy pozostawiać aktywnej prezentacji, która mogłaby sugerować bezpieczeństwo mimo braku potwierdzenia.
W przypadku osób, które kupiły produkt przez interfejs marketplace, należy przewidzieć bezpośrednie powiadomienie oraz publikację informacji na platformie. Proces powinien zachować listę odbiorców komunikatu i zakres objętych ofert, z uwzględnieniem zasad ochrony danych. Szybkość, priorytety i sposób eskalacji powinny wynikać z procedur organizacji, ponieważ źródła nie określają jednego uniwersalnego parametru operacyjnego.
Lista kontrolna dla zespołu projektowego i wdrożeniowego
Punkty kontrolne przed wdrożeniem
Przed wdrożeniem warto sprawdzić nie tylko wygląd karty produktu, lecz także kompletność całego procesu informacji. Lista kontrolna może obejmować następujące punkty:
- Dane: kompletność informacji o sprzedawcy, producencie, odpowiedzialnym podmiocie i produkcie.
- Widoczność: dostępność danych przy ofercie oraz czytelność ostrzeżeń dla konsumenta danego rynku.
- Publikacja: skuteczna blokada oferty bez wymaganych danych identyfikowalności i bezpieczeństwa.
- Statusy: rozróżnienie oferty roboczej, wymagającej uzupełnienia, weryfikowanej, opublikowanej i zablokowanej.
- Historia: rejestr decyzji, zmian, identyfikacji produktu i sprzedawcy.
- Komunikacja: działanie oznaczeń, strony informacji bezpieczeństwa i powiadomień dla nabywców.
- Odpowiedzialność: wskazanie właścicieli procesu oraz zasad późniejszego zarządzania.
Lista nie zastępuje audytu konkretnego marketplace ani analizy właściwych przepisów sektorowych. Wymagania należy zweryfikować względem kategorii produktów, roli podmiotów i rynku udostępniania oferty. Testy powinny potwierdzać, że brak danych blokuje publikację, a komunikaty nie sugerują niepotwierdzonego bezpieczeństwa.
Projektowanie marketplace zgodnego z wymaganiami przejrzystości i bezpieczeństwa wymaga połączenia architektury informacji, procesu weryfikacji, walidacji przed publikacją oraz kontrolowanej komunikacji po wykryciu zagrożenia. DSA i GPSR wyznaczają kategorie obowiązków, lecz szczegółowy układ interfejsu, statusy i workflow pozostają decyzją projektową oraz operacyjną organizacji. Najważniejsze jest rozdzielenie danych publicznych od wewnętrznych, jednoznaczne powiązanie oferty z produktem i sprzedawcą oraz zachowanie śladu decyzji. Umów konsultację z BrandingHouse, aby stworzyć spójny wizerunek marki i materiały dopasowane do celów Twojej firmy.
