Portal zamówień B2B dla dystrybutorów: zakres

Portal zamówień B2B pozwala zatwierdzonym klientom przeglądać przypisany im katalog i ceny, składać lub ponawiać zamówienia oraz sprawdzać dokumenty synchronizowane z ERP. Zakres warto podzielić na etapy: najpierw konta, ceny i zamówienia, później płatności oraz akceptacje. Próba uruchomienia wszystkiego naraz często opóźnia start i obniża wykorzystanie portalu.

Czym jest portal zamówień B2B?

Portal zamówień B2B to markowy kanał internetowy, w którym zatwierdzeni dystrybutorzy i klienci handlowi mogą samodzielnie prowadzić część relacji zakupowej. Po zalogowaniu przeglądają katalog dostępny dla swojego konta, widzą uzgodnione ceny, tworzą nowe zamówienie lub ponawiają poprzednie, a także odnajdują dokumenty przypisane do konta: oferty, zamówienia, faktury, noty korygujące i dostawy. ERP pozostaje systemem ewidencji. Portal jest oknem na dane ERP i egzekwuje reguły określające, co dane konto może zobaczyć i zrobić.

Warto odróżnić portal od trzech rozwiązań, z którymi bywa mylony:

• Sklep internetowy. Zwykle oferuje ceny detaliczne, otwartą rejestrację i płatność kartą. Portal dystrybutora działa odwrotnie: dostęp przyznaje się konkretnemu kontu, ceny wynikają z umowy, a płatność podlega uzgodnionym warunkom zamiast standardowej ścieżce koszyka.


• Strefa klienta w serwisie marketingowym. Może ułatwiać pobieranie plików i obsługę zgłoszeń, ale bez katalogu, cen i obsługi zamówień nie ogranicza telefonów do działu sprzedaży.


• PDF z cennikiem wysłany e-mailem. To rozwiązanie, z którego wielu dystrybutorów korzysta przed wdrożeniem portalu: dokument jest aktualny w dniu wysłania, może być błędny tydzień później i nie daje łatwego wyszukiwania według konta.

Tabela funkcji: wymagane, przydatne, późniejsze

Listy funkcji dostawców często pokazują wszystkie możliwości naraz. Podział wdrożenia na fazy ułatwia przygotowanie pierwszego wydania do uruchomienia. W tabeli funkcje rozdzielono na te, których zwykle wymaga pierwsza wersja, rozszerzenia drugiej fazy i możliwości, które można odłożyć do czasu zebrania danych o rzeczywistym użyciu.

Tabela A: funkcja | cel | faza (1/2/3) | zależność od ERP

Faza 1 powinna zmienić codzienny sposób składania zamówień. Jeśli dystrybutor może się zalogować, zobaczyć własne ceny, ponowić zamówienie z poprzedniego miesiąca i przesłać je do ERP, kanał telefoniczny i arkuszowy zaczyna stopniowo ustępować portalowi. Fazy 2 i 3 dodają obsługę finansów oraz zarządzania. Wymagają wcześniejszych decyzji organizacji dotyczących limitów kredytowych, księgowości i akceptacji; samo oprogramowanie nie może ich za firmę podjąć.

Integracja ERP i CRM

Integracja rozstrzyga, czy portal odzwierciedla działanie firmy, czy jest tylko stroną z formularzem logowania. Przed wyborem architektury zapisz odpowiedzi na cztery pytania:

1. Kierunek synchronizacji. Dane podstawowe — konta, produkty, ceny i warunki handlowe — zwykle płyną z ERP do portalu. Zamówienia, zapytania o ofertę i płatności wracają do systemów firmy. Każda inna zmiana powinna mieć właściciela: kto może zmienić cenę i w którym systemie taka zmiana jest zapisywana?


2. Częstotliwość synchronizacji. Możliwy jest nocny import zbiorczy, odświeżanie w ciągu dnia albo synchronizacja zbliżona do bieżącej. Ceny i limity kredytowe uzasadniają częstsze aktualizacje niż zdjęcia produktów, dlatego mieszany harmonogram jest normalnym rozwiązaniem: dane krytyczne odświeża się częściej, treści katalogowe rzadziej.


3. Obsługa awarii. Co zrobi portal, gdy ERP będzie niedostępny albo rekord nie przejdzie walidacji: umieści operację w kolejce, odrzuci ją czy pokaże ostatni znany stan z wyraźnym ostrzeżeniem? Cicha awaria może sprawić, że dystrybutor złoży zamówienie po cenie z poprzedniego tygodnia. Wyjaśnienie sporu będzie wtedy obowiązkiem sprzedawcy, nie klienta.


4. Uzgadnianie. Jak firma potwierdzi, że każde zamówienie z portalu utworzyło dokładnie jeden dokument ERP — bez duplikatów, braków i rekordów przekonwertowanych tylko częściowo? Potrzebny jest raport operacyjny, który ktoś przegląda codziennie podczas pierwszych miesięcy działania. To także jeden z testów odbiorowych opisanych niżej.

Katalog wielojęzyczny i wielowalutowy

Eksporterzy wcześnie stykają się z językami i walutami; taniej rozstrzygnąć te kwestie przed wdrożeniem niż przebudowywać później strukturę portalu.

Języki. Katalog wymaga tłumaczeń nazw produktów, kategorii i dokumentów. W strukturze kont należy przechowywać preferowany język, żeby klient nie musiał wybierać go przy każdej wizycie. Trzeba rozstrzygnąć dwie kwestie praktyczne. Kto odpowiada za tłumaczenia i jak często są aktualizowane? Katalog przetłumaczony tylko częściowo może wyglądać gorzej niż wersja wyłącznie angielska, jeśli kupujący zauważy niespójności. Druga kwestia dotyczy dokumentów: czy oferty i faktury mają być tworzone w języku interfejsu, czy w języku wymaganym przez system finansowy firmy? To nie jest wyłącznie decyzja techniczna — faktura w niewłaściwym języku może stać się problemem księgowym.

Waluty. Ceny ustalone w jednej walucie powinny być wyświetlane w tej walucie niezależnie od miejsca, z którego odwiedza portal klient. Mieszanie waluty prezentacji z walutą umowną prowadzi do sporów. Jeśli konto rozlicza się w więcej niż jednej walucie, reguła powinna być zapisana w danych ERP, nie tylko w ustawieniach portalu. Portal nie powinien samodzielnie wymyślać kursu przeliczeniowego.

Obie kwestie należy dopasować do etapowania. Eksporter sprzedający na 3 rynkach może uruchomić fazę 1 w językach faktycznie używanych w zamówieniach na tych rynkach, a kolejne wersje katalogu dodać wraz z realnym popytem. Ogólną zasadę pracy z językami w serwisach handlowych — jeden właściciel, jedno źródło treści i jedna ścieżka aktualizacji — opisuje strona marketingu internetowego. Dotyczy ona katalogu portalu tak samo jak pozostałych stron firmy.

Bezpieczeństwo i role

Portal otwiera dostęp do danych handlowych, dlatego jego projektowanie zaczyna się od reguł dostępu:

• Dostęp jest nadawany, nie zakładany samodzielnie. Zespół firmy tworzy konto na podstawie konta klienta w ERP. Alternatywą może być otwarta rejestracja z etapem zatwierdzania, ale zwiększa liczbę przypadkowych zgłoszeń i zaciera granicę między klientem a osobą zainteresowaną.


• Uprawnienia zależne od roli. Kupujący może przygotować i złożyć zamówienie w określonym limicie, zatwierdzający je zwalnia, a użytkownik z prawem podglądu odczytuje dokumenty. Limity są częścią warunków handlowych, nie dodatkiem technicznym: określają, kto w organizacji klienta może ją zobowiązać do zakupu.


• Izolacja kont. Poważnym błędem w tej klasie produktu jest pokazanie jednemu dystrybutorowi cen lub dokumentów innego. Widoczność danych należy sprawdzić osobno dla każdego konta; ten wymóg powinien znaleźć się w testach odbiorowych.


• Ślad audytowy. System zapisuje, kto złożył zamówienie, kto je zatwierdził, kto i kiedy zmienił cenę. Informacje powinny być przechowywane jako dane, a nie tylko w plikach logów, których nikt nie ma obowiązku czytać. W sporach handlowych taki zapis częściej rozstrzyga sprawę niż pamięć uczestników.


• Tożsamość i pojedyncze logowanie. Więksi dystrybutorzy mogą wymagać SSO połączonego z własnym katalogiem użytkowników. Warto zaplanować tę funkcję później, nie na samym początku: większości kont wystarczają zaproszenia i hasła, dopóki centrala nie zażąda federacji tożsamości.


• Ochrona danych. Dane klientów w portalu podlegają obowiązkom firmy dotyczącym ewidencji klientów. W operacjach w Turcji stosuje się ramy KVKK, a dla klientów europejskich GDPR. Kontekst współpracy z partnerem programistycznym omawia strona outsourcingu IT.

Rozwiązanie własne czy platforma?

Wybór nie sprowadza się abstrakcyjnie do oprogramowania własnego lub pakietowego. Trzeba ustalić, którą warstwę kupuje firma i za co będzie odpowiadać.

Tabela B: wariant | co zapewnia | co trzeba utrzymywać | kiedy pasuje

Wielu eksporterów wybiera przy pierwszym wdrożeniu rozwiązanie pośrednie. Nie należy jednak zakładać, że jest najtańsze: konektor jest utrzymywanym produktem i generuje powracające koszty. Szerszy model wyboru między konfiguracją, zakupem i budową omawia materiał o ERP szytym na miarę i pakietowym. Dla portalu ważny jest dodatkowy test: cennik każdego konta i zamówienie przekazane do ERP muszą być poprawne w sposób możliwy do wykazania. Wybierz rozwiązanie, które pozwala to potwierdzić przy najniższym powtarzalnym koszcie.

Etapowe wdrożenie i testy odbiorowe

Uruchomienie portalu może zawieść po cichu, jeśli „działa” oznacza jedynie, że działała demonstracja. Każda faza powinna mieć zapisane testy odbiorowe wykonywane na prawdziwych kontach i danych:

1. Widoczność katalogu dla konta. Zaloguj się jako 2 różnych dystrybutorów. Każdy powinien widzieć dokładnie własny zestaw produktów i żadnych informacji o drugim koncie. Trzeba to sprawdzić celowo, a nie zakładać.


2. Poprawność cen. Dla próbki kont i produktów porównaj ceny portalu z ERP, uwzględniając reguły grup cenowych, progów i indywidualnych umów. Ten test chroni relację handlową: błędna cena widoczna na portalu może wyglądać klientowi jak stale obowiązująca oferta, więc jest poważniejszym problemem niż pomyłka w pojedynczej wycenie.


3. Spójność zamówienia. Zamówienie złożone w portalu ma utworzyć dokładnie jeden dokument ERP z właściwymi produktami, ilościami, jednostkami i cenami; raport uzgodnieniowy musi to potwierdzić. Sprawdź też obsługę błędu: zamówienie zablokowane regułą ma otrzymać jasny komunikat, nie zniknąć bez wyjaśnienia.


4. Status i dokumenty. Faktura i dostawa zapisane w ERP powinny pojawić się w widoku właściwego konta, ze zgodnym statusem i w uzgodnionym czasie synchronizacji.


5. Warunki i limity. Sprawdź warunki płatności i limity kredytowe dla kont oraz zachowanie reguł blokowania i oznaczania zamówień. Testuj wartości na granicy limitu, nie tylko wygodny przypadek pośrodku.


6. Codzienne działania. Przetestuj ponowienie, szybkie zamówienie po numerze artykułu i wyszukiwanie na listach produktów 2 prawdziwych dystrybutorów, a nie na katalogu demonstracyjnym. Wdrożenie zależy od tych trzech ścieżek, a ich rzetelny test kosztuje ułamek budowy portalu.

Najczęściej zadawane pytania

Czy najpierw potrzebujemy ERP?

Nie trzeba wdrażać nowego ERP, ale dane podstawowe muszą być wiarygodne: konta, produkty, cenniki i warunki. Jeśli znajdują się wyłącznie w arkuszach, portal zacznie automatycznie powielać błędy dla poszczególnych klientów. W takiej sytuacji rozsądna kolejność to najpierw uporządkowanie danych, często w już używanym, lecz niewykorzystanym ERP, a dopiero potem uruchomienie portalu. Perspektywę ERP przedstawia strona Odoo dla firm handlowych.

Czy każdy klient może mieć własny cennik?

Tak. Cennik przypisany do konta jest podstawą portalu, a nie funkcją dodatkową. Może wynikać z grupy cenowej, progów lub indywidualnej umowy; dane powinny być zapisane w ERP i wyświetlane dla właściwego konta. Portal nie powinien sam kalkulować cen. Każda cena widoczna dla dystrybutora musi dać się powiązać z umową zawartą przez zespół handlowy.

Jak zatwierdzać zamówienia?

Zwykle są 2 poziomy. W organizacji klienta proces należy do jego zespołu: kupujący przygotowuje propozycję, zatwierdzający ją zwalnia, opcjonalnie w granicach limitu. Portal może obsługiwać te role w fazie 3. Po stronie sprzedawcy zamówienie trafia do ERP i przechodzi normalną obsługę. Portal nie zastępuje kontroli działu sprzedaży; usuwa ponowne wprowadzanie danych i część telefonów związanych ze złożeniem zamówienia.

Czy portal obsługuje wiele języków?

Tak, ale zakres należy określić dla każdej fazy. Tłumaczenia katalogu, preferencja językowa konta i tłumaczone dokumenty są 3 odrębnymi zadaniami. Fazę 1 uruchom w językach używanych przy zamówieniach na aktywnych rynkach, a pozostałe dodawaj wraz z rzeczywistym popytem. Właściciela tłumaczeń i ścieżkę aktualizacji opisano w sekcji o wielu językach.

Kto jest właścicielem danych?

Firma. Konta, ceny, zamówienia, dokumenty i historia pozostają jej danymi i zapisami w ERP. Umowa z wykonawcą portalu powinna wskazywać dostęp do hostingu, prawa do kodu źródłowego lub konfiguracji oraz sposób eksportu danych po zakończeniu współpracy. Strona outsourcingu IT omawia własność intelektualną i warunki wyjścia w kontekście umów programistycznych.

Jak wdrażać dystrybutorów?

Zacznij od klientów składających najwięcej zamówień, zaproś ich osobiście i w pierwszej wiadomości podaj 3 rzeczy: dane logowania, informację, gdzie zobaczą swój cennik, oraz kontakt do konkretnej osoby. Obserwuj właściwy sygnał adopcji: nie samą liczbę logowań, lecz udział ponawianych zamówień składanych przez portal. Przez kilka tygodni zamówienie z portalu potwierdzane telefonicznie jest normalne. Taki sposób pracy ustąpi, gdy klient będzie mógł sprawdzić poprawność cen i dokumentów — temu służą testy odbiorowe opisane wyżej.

Źródła i standardy

• Typowy zestaw funkcji opisany na stronie — konta, cenniki według kont, ponawianie zamówień, faktury i noty korygujące, widoczność danych na poziomie konta, role z limitami, terminy płatności i bramki płatnicze — odpowiada ogólnym listom możliwości publikowanym przez dostawców portali B2B. Nie deklarujemy wyniku wydajnościowego, kosztu ani czasu realizacji.
• Dwa opisane modele wdrożenia to portal natywny dla ERP oraz platforma handlowa, taka jak Shopify, synchronizowana z ERP przez oprogramowanie pośredniczące lub konektory. Nie deklarujemy partnerstwa z żadnym dostawcą platformy.
• Kwestie procesu i zarządzania uzupełniają strony serwisu: materiał o ERP szytym na miarę i pakietowym, lista kontrolna RFP dla dostawców, Odoo dla firm handlowych oraz outsourcing IT z Turcji, dotyczący obowiązków ochrony danych, własności intelektualnej, warunków zakończenia współpracy i projektowania pilotażu.
• Strona nie podaje przykładów klientów, budżetów portalu ani czasu trwania projektów. Zakres, etapy i warunki handlowe ustala się dla każdego projektu w ofercie.

Powiązane strony

Tworzenie oprogramowania · ERP szyty na miarę lub pakietowy · Lista kontrolna RFP dla dostawców · Odoo ERP dla firm handlowych · Marketing internetowy · Poproś o wycenę