Portal B2B i system zamówień dla kontrahentów

Nie zaczynamy od gotowej listy funkcji. Najpierw sprawdzamy, kto zamawia, skąd pochodzą produkty, ceny i dostępność oraz co ma się wydarzyć po wysłaniu zamówienia.

Kiedy portal B2B ma sens?

Portal warto rozważyć, gdy stały kontrahent powinien mieć własne miejsce do pracy z ofertą i zamówieniami. Najczęstsze sygnały to:

• zamówienia przychodzą przez e-mail, telefon lub różne pliki;
• pracownik przepisuje pozycje do kolejnego programu;
• kontrahenci otrzymują różne ceny, rabaty albo zakresy oferty;
• pytania o dostępność i status zamówienia powtarzają się każdego dnia;
• brak części produktu wymaga ręcznych ustaleń;
• firma chce pokazać partnerowi jego dokumenty, historię lub statusy bez udostępniania wewnętrznego systemu;
• ważne jest rozdzielenie danych i uprawnień wielu kontrahentów.

Portal nie jest potrzebny tylko dlatego, że sprzedaż odbywa się między firmami. Przy małej liczbie prostych zamówień może wystarczyć formularz, uzgodniony arkusz albo funkcja obecnego sklepu. Własne rozwiązanie ma sens wtedy, gdy zasady oferty, zamawiania albo dalszej obsługi są ważną częścią procesu i nie mieszczą się w gotowym narzędziu.

Portal B2B, API, integracja czy CRM?

Te rozwiązania mogą ze sobą współpracować, ale nie oznaczają tego samego.

Jedna firma może potrzebować portalu i API korzystających ze wspólnej oferty. Innej wystarczy integracja istniejącego sklepu z programem magazynowym. Decyzję podejmujemy na podstawie procesu, a nie nazwy technologii.

Co może obejmować portal dla kontrahentów?

Zakres dobieramy do rzeczywistego sposobu sprzedaży. Może obejmować:

Ofertę dopasowaną do odbiorcy

Kontrahent widzi produkty, warianty, ceny, rabaty i dokumenty przeznaczone dla jego konta. Najpierw trzeba wskazać, z którego systemu pochodzą te dane i kto może je zmieniać.

Dostępność i zasady zamawiania

Samo pokazanie liczby z magazynu nie zawsze wystarcza. Trzeba ustalić, czy dostępność oznacza fizyczny stan, ilość możliwą do sprzedaży, rezerwację czy informację orientacyjną. Znaczenie tej wartości wpływa na komunikaty i dalszą obsługę zamówienia.

Koszyk albo formularz zamówienia

Proces może obsługiwać jednostki, opakowania zbiorcze, minimalne ilości, własne numery zamówień, miejsca dostawy, terminy i wymagane uwagi. Są to przykłady zakresu do ustalenia, a nie stały zestaw każdej realizacji.

Statusy i dokumenty

Partner może sprawdzać uzgodnione etapy realizacji oraz pobierać przeznaczone dla niego dokumenty. Trzeba określić, który system nadaje status i kiedy informacja jest wystarczająco pewna, aby ją pokazać.

Role i uprawnienia

Jedna firma może mieć kilka osób zamawiających, osobę akceptującą i oddzielnych użytkowników tylko do podglądu. Każdy kontrahent powinien widzieć wyłącznie dane, ceny, zamówienia i dokumenty, do których ma dostęp.

Integracje

Portal może wymieniać dane z ERP, magazynem, księgowością, sklepem, systemem przewoźnika albo własną aplikacją firmy. Możliwość połączenia potwierdzamy dopiero po sprawdzeniu dokumentacji, uprawnień i środowiska testowego.

To nie jest gotowy pakiet, który zawsze obejmuje wszystkie elementy. Pierwszy etap powinien rozwiązać jeden ważny przepływ i mieć jasne kryteria odbioru.

Najważniejsze decyzje przed rozpoczęciem

Gdzie znajduje się główna oferta?

Trzeba wskazać źródło nazw, kodów, wariantów, cen i opisów. Jeżeli kilka programów może zmienić ten sam element, trzeba ustalić, który z nich ma ostatnie słowo.

Co naprawdę oznacza dostępność?

Stan magazynowy może zmienić się pomiędzy wyświetleniem oferty a przyjęciem zamówienia. Ustalamy, czy system ma rezerwować towar, potwierdzać zamówienie od razu, czy przekazywać je do późniejszej weryfikacji.

Kto może zobaczyć i zmienić dane?

Ceny, rabaty, dokumenty i historia zamówień mogą być różne dla każdej firmy oraz roli. Uprawnienia trzeba sprawdzać w całym procesie, a nie tylko ukryć przycisk na ekranie.

Co dzieje się po wysłaniu zamówienia?

Zamówienie może trafić do panelu, ERP, magazynu albo do akceptacji pracownika. Trzeba ustalić jego identyfikator, status początkowy, zasady korekty i sposób poinformowania kontrahenta o wyniku.

Jak obsługujemy błąd i ponowienie?

Przerwane połączenie nie może po cichu zgubić zamówienia ani utworzyć drugiej kopii po ponownej próbie. Osoba odpowiedzialna powinna widzieć, co zostało przyjęte, co czeka i co wymaga poprawy.

Jak sprawdzamy, czy pierwszy etap działa?

Kryteria odbioru wynikają z procesu, a nie tylko z wyglądu ekranów. Dla przykładowego portalu można sprawdzić, czy:

• kontrahent widzi wyłącznie swoją ofertę, ceny, zamówienia i dokumenty;
• poprawne zamówienie trafia do właściwego klienta i zawiera wszystkie pozycje;
• brak produktu, niepoprawna ilość albo brak wymaganego pola daje czytelny komunikat;
• ponowienie tej samej operacji nie tworzy drugiego zamówienia;
• zmiana statusu pochodzi z uzgodnionego źródła i jest widoczna dla właściwej osoby;
• błąd integracji pozostawia informację potrzebną do reakcji;
• dane w portalu i systemie firmy można porównać po zakończeniu scenariusza.

Takie przypadki ustalamy przed odbiorem. Dzięki temu rezultat nie sprowadza się do stwierdzenia, że formularz wysłał dane albo API odpowiedziało bez błędu.

Można zacząć od mniejszego zakresu

Pełny portal nie musi powstać w jednym etapie. Pierwsza wersja może obsłużyć:

• jedną grupę kontrahentów;
• ograniczony katalog albo jeden rodzaj zamówienia;
• jedną ścieżkę od złożenia zamówienia do potwierdzenia;
• ręczną akceptację po stronie firmy;
• jedno połączenie z systemem źródłowym;
• podstawowy zestaw statusów i komunikatów.

Mniejszy zakres ma sens tylko wtedy, gdy tworzy zamknięty i użyteczny proces. Nie warto dzielić projektu w miejscu, które zmusi pracowników do ponownego przepisywania tych samych danych albo pozostawi zamówienie bez odpowiedzialnej osoby.

Doświadczenie: HUB-2-API

W 2018 roku stworzyliśmy system dla firmy handlującej częściami samochodowymi na rynku niemieckim. HUB-2-API importował dużą listę produktów z Excela, publikował i edytował oferty na eBay.de, pobierał zamówienia oraz udostępniał panel do ich obsługi.

Trzech klientów zamawiającego z Francji korzystało z API B2B. Ich systemy mogły pobrać ofertę, sprawdzić dostępność i złożyć zamówienie. Dzięki temu klient nie musiał ręcznie zarządzać każdą zmianą oferty w marketplace, a jego partnerzy mogli składać zamówienia w uporządkowany sposób.

To projekt historyczny, który nie jest już używany. Nie przedstawiamy go jako gotowego portalu ani współczesnej integracji. Pokazuje jednak nasze doświadczenie w połączeniu katalogu, dostępności, zamówień, panelu operacyjnego i kanału B2B.

Zobacz pełne case study HUB-2-API.

Jak zaczynamy współpracę?

1. Krótko kwalifikujemy potrzebę. Bezpłatna rozmowa do 20 minut służy ustaleniu, kto zamawia, gdzie znajduje się oferta i który fragment procesu sprawia dziś największy problem. Nie jest analizą ani gotową wyceną.
2. Ustalamy, czy potrzebna jest analiza. Przy wielu rolach, cenach, źródłach danych albo niepewnych integracjach proponujemy osobny płatny etap. Jeśli później realizujemy projekt, koszt analizy wliczamy w koszt realizacji.
3. Wybieramy pierwszy użyteczny etap. Zapisujemy zakres, odpowiedzialność systemów, ważne wyjątki, kryteria odbioru, termin i indywidualną wycenę.
4. Budujemy i sprawdzamy cały przepływ. Testujemy nie tylko prawidłowe zamówienie, lecz także brak danych, zmianę dostępności, ponowienie i błąd połączenia.
5. Ustalamy dalszy rozwój i utrzymanie. Kolejne grupy kontrahentów, funkcje i integracje powstają jako osobno uzgodnione etapy.

Nie musisz przygotowywać specyfikacji technicznej. Do pierwszej rozmowy wystarczy opis obecnego sposobu zamawiania, używanych programów i sytuacji, które wymagają ręcznej pracy.

Najczęstsze pytania

Czy portal B2B zastąpi CRM albo ERP?

Nie musi ich zastępować. Portal jest kanałem pracy kontrahenta. CRM może nadal obsługiwać relacje i sprzedaż, a ERP lub program magazynowy ofertę, stany i dokumenty. Zakres integracji zależy od możliwości tych systemów i uzgodnionego źródła danych.

Czy kontrahenci mogą mieć różne ceny i produkty?

Takie rozwiązanie można zaprojektować, jeśli istnieją jasne reguły oraz wiarygodne źródło oferty i cen. Przed potwierdzeniem zakresu trzeba sprawdzić wyjątki, sposób identyfikacji kontrahenta i aktualizację danych.

Czy portal i API mogą działać razem?

Tak. Portal może służyć osobom, które chcą zamawiać w przeglądarce, a API partnerom korzystającym z własnego systemu. Oba kanały powinny stosować te same reguły oferty, uprawnień i przyjmowania zamówień.

Czy można wykorzystać dane z Excela?

Arkusz może być źródłem pierwszego importu albo wspieranym kanałem wymiany. Trzeba jednak sprawdzić identyfikatory, formaty, braki i odpowiedzialność za aktualizację. Przy regularnej pracy lepszym źródłem może być system magazynowy, ERP lub inna aplikacja firmy.

Ile kosztuje portal B2B i jak długo trwa realizacja?

Koszt i termin zależą między innymi od liczby ról, zasad cenowych, katalogu, sposobu liczenia dostępności, obiegu zamówienia, integracji i migracji danych. Potwierdzamy je po ustaleniu zakresu. Przy bardziej złożonym procesie najpierw wyceniamy osobny etap analizy.

Czy trzeba od razu przenosić wszystkich kontrahentów?

Nie. Można rozpocząć od wybranej grupy, ograniczonej oferty i jednego pełnego scenariusza zamówienia. Warunkiem jest zachowanie spójnego procesu i jasnych zasad dla osób, które pozostają jeszcze poza portalem.

Co przesłać na początek?

W pierwszej wiadomości opisz:

• kto składa zamówienia i jak robi to dzisiaj;
• gdzie znajduje się oferta, ceny i informacja o dostępności;
• jakie programy uczestniczą w dalszej obsłudze;
• które dane są przepisywane ręcznie;
• jakie wyjątki najczęściej wymagają kontaktu z pracownikiem;
• co kontrahent powinien móc sprawdzić bez telefonu lub e-maila.

Nie przesyłaj przez formularz haseł, kluczy API, kopii bazy, rzeczywistych zamówień ani danych klientów. Jeśli takie materiały okażą się potrzebne, ustalimy bezpieczny sposób ich przekazania po uzgodnieniu zlecenia.

CTA: Opisz swój proces zamówień

Jeśli chcesz najpierw samodzielnie zebrać podstawowe informacje, użyj bezpłatnego kreatora opisu projektu.

Zobacz także integracje systemów i API, dedykowany CRM i system obsługi zleceń oraz analizę biznesową i zakres MVP aplikacji.

Dokumenty w procesie kontrahenta

Jeżeli dokumenty przesyłane przez kontrahenta wymagają kontroli, akceptacji, poprawy albo przekazania do innego programu, zobacz także elektroniczny obieg dokumentów i DMS.