BEAM

Seedlight BEAM: jedno miejsce, z którego prowadzisz cały eCommerce, z agentami AI znającymi Twój biznes →

← Wszystkie artykuły
B2BSzymon Żynda12 min czytania

Portal zamówień B2B: co musi mieć, żeby handlowiec przestał przepisywać maile

Portal, który zdejmuje zamówienia ze skrzynki, musi umieć osiem konkretnych rzeczy: cenę tego klienta, powtórkę z historii, wklejoną listę SKU, limit kupiecki, prawdziwe terminy, akceptację po stronie klienta, dokument w ERP i uczciwy komunikat, gdy ERP milczy. Przy każdej funkcji warunek, bez którego jest tylko wyglądem, plus test odbiorczy do przejścia z dostawcą.

Portal zamówień B2B zabiera zamówienia ze skrzynki dopiero wtedy, gdy potrafi zamknąć całe zamówienie bez człowieka po Twojej stronie. To znaczy osiem rzeczy naraz: cenę widzianą przez tego konkretnego kontrahenta, powtórzenie poprzedniego zamówienia, przyjęcie wklejonej listy indeksów, widoczny limit kupiecki i saldo, prawdziwy stan z terminem, akceptację po stronie klienta, dokument sprzedaży w ERP oraz uczciwy komunikat wtedy, gdy ERP nie odpowiada. Poniżej każda z tych funkcji z warunkiem, bez którego zostaje samym wyglądem, i z testem, który możesz przejść na własnym portalu albo na demie dostawcy.

Kluczowe wnioski

  • Portal zdejmuje przepisywanie tylko wtedy, gdy zamyka całe zamówienie. Brak jednej funkcji z ośmiu wystarcza, żeby klient napisał maila z całością, bo nikt nie dzieli jednego zamówienia między dwa kanały.
  • Zanim wybierzesz funkcje, przejdź miesiąc własnej skrzynki zamówieniowej i podziel wiadomości na cztery koszyki: powtórka bez zmian, powtórka ze zmianą, pytanie przed zamówieniem, wyjątek. Portal pracuje na dwóch pierwszych.
  • Najczęściej pomijana funkcja to role po stronie klienta: kto zamawia, kto zatwierdza i kto widzi limit oraz ceny. Ujawnia się w drugim miesiącu, gdy klient prosi o drugie konto.
  • Przy kilkunastu stałych odbiorcach i kilkudziesięciu zamówieniach miesięcznie mail wygrywa: obsługuje wyjątek szybciej, nic nie kosztuje i nie wymaga utrzymania. Ten rachunek trzeba zrobić przed projektem.

Osiem rzeczy, które handlowiec dziś przepisuje ręcznie

Dzień handlowca w hurcie zaczyna się w skrzynce. W jednym mailu klient prosi „to samo co ostatnio, tylko kartonów osiem zamiast pięciu”, w drugim wisi arkusz z indeksami własnymi kupującego, w trzecim pytanie, czy pozycja jest na stanie, w czwartym prośba o cenę na większą partię. Handlowiec otwiera system, wyszukuje kontrahenta, przepisuje pozycje, sprawdza cenę kontraktową, dzwoni do księgowości po zgodę na przekroczony limit i odpisuje. Każdy z tych kroków jest osobnym miejscem, w którym da się pomylić indeks albo jednostkę.

Wąskim gardłem nie jest tu wpisywanie. Jest nim to, że wszystkie te informacje mieszkają tylko po Twojej stronie.

Stąd wniosek, który przy planowaniu zakresu wygląda niewygodnie: portal zdejmujący sześć rzeczy z ośmiu zdejmuje w praktyce zero. Klient nie podzieli jednego zamówienia między portal i maila, bo dla niego to jedna czynność. Jeśli po wejściu do portalu musi jeszcze napisać wiadomość z pytaniem o dostępność dwóch pozycji, napisze wiadomość z całym zamówieniem. To nasza ocena wynikająca z tego, jak wygląda ta praca, i najtańszy sposób jej sprawdzenia opisujemy w następnej sekcji.

Zanim policzysz funkcje, policz swoje maile

Nie podamy tu żadnego procentu zamówień, które portal przejmie, bo nie mamy opublikowanego pomiaru, a cudza liczba z branżowego raportu i tak nie opisuje Twojej skrzynki. Zamiast wyniku jest metoda. Zajmuje jedno popołudnie i daje liczbę, na której można oprzeć decyzję o zakresie.

Weź jeden miesiąc ze wspólnej skrzynki zamówieniowej, nie rok, bo rok nikt nie przejdzie. Podziel wiadomości na cztery koszyki:

  • Koszyk 1, powtórka bez zmian: klient zamawia to samo co wcześniej, w tych samych ilościach.
  • Koszyk 2, powtórka ze zmianą: ten sam zestaw z inną ilością, jedną pozycją mniej albo inną datą dostawy.
  • Koszyk 3, pytanie przed zamówieniem: o dostępność, cenę, termin albo o to, czy poprzednia faktura już przeszła.
  • Koszyk 4, wyjątek: nowy produkt, nietypowy warunek, korekta, reklamacja, negocjacja.

Do każdego koszyka dopisz dwie liczby: ile wiadomości i ile minut zajmuje jedna sztuka od otwarcia maila do gotowego dokumentu. Minut nie szacuj z pamięci, bo pamięć zawyża albo zaniża zależnie od nastroju. Zmierz stoperem pięć sztuk z każdego koszyka i weź medianę. Pomnóż, zsumuj i zobacz, ile godzin miesięcznie siedzi w koszykach pierwszym i drugim, bo to jest zakres, na który portal realnie pracuje. Koszyk trzeci zdejmuje częściowo. Koszyk czwarty zostaje u człowieka i tak ma zostać.

Ta liczba jest jednocześnie budżetem projektu i jego uzasadnieniem przed zarządem.

Cena widziana oczami tego jednego klienta

Portal, który pokazuje cennik katalogowy i dopisuje „ceny do potwierdzenia przez opiekuna”, jest katalogiem z formularzem kontaktowym. Kupujący nie złoży zamówienia na cenę, której nie zna, więc napisze maila. Warunkiem wejściowym jest więc cena rozstrzygana dla zalogowanego kontrahenta w momencie wyświetlenia pozycji, razem z progami wolumenowymi widocznymi przy niej: „od 50 sztuk 38,40 zł netto”. Ten jeden element działa też w drugą stronę, bo klient sam podnosi ilość do progu, czego handlowiec przy telefonie zwykle nie proponuje.

Ekran szybkiego zamówienia w portalu B2B: przy każdej pozycji przekreślona cena katalogowa i obok niej cena netto tego klienta, stany po magazynach, po prawej wykorzystany limit kupiecki i zapisane listy do powtórzenia.
Szybkie zamówienie w portalu. Przy każdej pozycji cena katalogowa jest przekreślona, a obok stoi cena netto tego zalogowanego klienta. Po prawej limit kupiecki i listy do powtórzenia jednym kliknięciem. Ekran poglądowy, nie zrzut z konta klienta.

Drugi warunek jest techniczny i łatwo go przeoczyć na demie. Portal musi umieć wyliczyć cenę dla całego koszyka, nie tylko dla pojedynczej pozycji, bo próg naliczany od wartości zamówienia zmienia się przy każdej zmianie ilości. Samej hierarchii rozstrzygania tu nie powtarzamy, ma własny tekst: cenniki kontraktowe i umowy ramowe w B2B, a moduł opisuje usługa cenniki i wyceny B2B.

Warto sprawdzić jedno: czy dwóch różnych klientów widzi w portalu dwie różne ceny.

Powtórka zamówienia, czyli funkcja, która robi połowę roboty

Jeśli Twoje koszyki pierwszy i drugi wyszły największe, a w hurcie zwykle wychodzą, to historia zamówień jest ważniejsza od wyszukiwarki i filtrów. Klient wchodzi, widzi poprzednie zamówienie, klika „zamów ponownie”, poprawia dwie ilości i wysyła. Ważne, żeby powtórka była edytowalna przed złożeniem, bo powtórka rzadko jest identyczna. Do tego listy zapisane językiem klienta, a nie Twoim: „regał przy kasie”, „sklep Nowa Huta”, „zamówienie kwartalne”, przypisane do konkretnego miejsca dostawy.

Tutaj siedzi też szczegół, który psuje zaufanie do portalu w pierwszym tygodniu. Zamówienie z zeszłego roku zawiera pozycje wycofane, zmienione indeksy i inne jednostki. Portal, który po kliknięciu „powtórz” po cichu pominie trzy pozycje, wyprodukuje niedowiezione zamówienie i telefon do handlowca. Portal, który pokaże listę „te trzy pozycje zniknęły, dla dwóch mamy następnik”, zamyka sprawę bez człowieka.

Wklejona lista indeksów zamiast wędrówki po katalogu

Kupujący zawodowo nie przeglądają katalogu. Mają swoją listę zakupową w arkuszu, często z własnymi numerami części, i nie porzucą jej dla Twojej wyszukiwarki. Portal musi więc przyjąć tę listę w takiej formie, w jakiej ona istnieje: wklejoną w pole tekstowe z dowolnym separatorem, wgraną jako plik CSV albo XLSX, z rozpoznaniem indeksu klienta obok Twojego. Mapowanie numerów kupującego na Twoje pozycje bywa najbardziej niewdzięczną częścią wdrożenia i jednocześnie tą, która decyduje, czy duży odbiorca w ogóle wejdzie do portalu.

Sama akceptacja pliku nie wystarcza. Między wklejeniem a koszykiem musi stanąć ekran uzgodnienia, który mówi wprost, co rozpoznano, czego nie rozpoznano, co jest niedostępne i gdzie jednostka się nie zgadza. Bez tego ekranu wklejanie generuje pomyłki, które ktoś potem odkręca ręcznie, czyli przepisywanie wraca innym wejściem. Najczęstsza cicha pomyłka dotyczy jednostki: klient pisze „10”, mając w głowie kartony, a portal dodaje dziesięć sztuk.

Ekran uzgodnienia jest tu ważniejszy od samego importu.

Limit kupiecki i status płatności bez telefonu do księgowości

Telefon „czy mogę wypuścić to zamówienie” jest kosztem po obu stronach: zajmuje handlowca, zajmuje księgowość i wydłuża odpowiedź do klienta o godziny. Portal zdejmuje go, gdy pokazuje cztery rzeczy: przyznany limit, jego wykorzystanie, listę nieopłaconych faktur z terminami i skutek dla tego konkretnego koszyka. Skutek jest najważniejszy i najczęściej pominięty. Klient ma wiedzieć przed złożeniem, czy zamówienie przejdzie, wstrzyma się do zapłaty, czy trafi do decyzji opiekuna.

Jest przy tym uczciwe zastrzeżenie, które trzeba postawić przed projektem, a nie po. Pokazanie salda ma sens tylko wtedy, gdy rozrachunki w źródle są aktualne. Jeśli w Twojej firmie wpłaty księgują się z dwudniowym opóźnieniem, portal pokaże jako przeterminowane faktury, które klient zapłacił w piątek. Klient dowie się o tym raz, powie o tym opiekunowi i przestanie wierzyć całej sekcji. To wtedy problem procesu księgowania, nie interfejsu, i rozstrzyga się go przed uruchomieniem.

Stany i terminy, na których klient układa swoją pracę

Przycisk „zapytaj o dostępność” jest odpowiedzią mailową przebraną w interfejs. Kupujący hurtowy potrzebuje informacji, na której ułoży własny plan: czy dostanie towar na czwartek, czy ma zamówić u kogoś innego. Ta informacja nie musi być dokładną liczbą sztuk, bo wielu dostawców słusznie jej nie pokazuje. Może być progiem i datą: „dostępne”, „do 8 sztuk”, „wysyłka 21 sierpnia”. Musi natomiast być zobowiązaniem, którego dotrzymujesz, bo stan pokazany raz nieprawdziwie kosztuje więcej niż brak stanu.

Osobno traktuj pozycje, których po prostu nie masz. Stan zero przy produkcie zamówionym u dostawcy z potwierdzoną datą to nie jest brak dostępności, to jest data. Portal pokazujący samo zero oddaje to zamówienie mailowi albo konkurencji. Do tego decyzja o częściowej realizacji, podjęta przez klienta w koszyku: wysyłamy, co jest, czy czekamy na komplet. Ta jedna opcja oszczędza dwie wiadomości przy każdym niepełnym zamówieniu.

Rytm synchronizacji i bufory mają własny tekst: integracja sklepu B2B z ERP.

Kto u klienta zamawia, a kto to zatwierdza

W firmie kupującej rzadko jest jedna osoba. Zamawia magazynier albo kierownik oddziału, zatwierdza właściciel, dyrektor albo księgowość, i to zwykle od jakiejś kwoty. Portal, który daje jednemu kontrahentowi jeden login, wypycha tę strukturę z powrotem do maila: kierownik pisze do centrali, centrala do Ciebie. Potrzeba więc wielu użytkowników na koncie kontrahenta, ról z różnym zakresem widoczności, progu kwotowego uruchamiającego akceptację, koszyka czekającego na zatwierdzenie z powiadomieniem i śladu, kto zatwierdził.

Ta funkcja niemal nigdy nie pojawia się w pierwszym briefie. Ujawnia się w drugim miesiącu, gdy klient prosi o dodatkowe konto „dla Ani z magazynu”, a Ty odkrywasz, że Ania zobaczy wtedy wszystkie ceny kontraktowe, limit kupiecki i saldo firmy. Do tego dochodzi przypisanie miejsc dostawy do użytkowników, żeby kierownik jednego sklepu nie zamawiał przypadkiem na drugi. Zakres ról ustala się razem z klientem, nie za niego.

Co portal wysyła do ERP i co mówi klientowi, gdy ERP milczy

Zamówienie z portalu ma dwa różne „przyjęte”: przyjęte przez portal i zarejestrowane w ERP jako dokument sprzedaży. Klient widzi pierwsze, Twoja logistyka pracuje na drugim, a między nimi jest kolejka, która czasem staje. Dlatego status widoczny w portalu ma odpowiadać etapowi, w którym zamówienie faktycznie jest, a numer dokumentu z ERP powinien do klienta wracać. Ten numer wygląda na drobiazg, a jest jedynym dowodem dla kupującego, że jego zamówienie wyszło z portalu i weszło do Twojej firmy.

Po lewej wiersz zamówienia widziany przez handlowca z ceną kontraktową i progiem wolumenowym, po prawej dokument zamówienia sprzedaży, który z niego powstaje w ERP, z polami identyfikatora zewnętrznego, cennika, źródła ceny i wyniku sprawdzenia limitu.
Ten sam wiersz po obu stronach integracji. Zwróć uwagę na dwa pola: price_source zapisuje, skąd wzięła się cena, więc po miesiącach da się na to odpowiedzieć, a external_id sprawia, że powtórzone wysłanie nie utworzy w ERP drugiego dokumentu.

Awaria wymiany danych zdarzy się i lepiej mieć rozstrzygnięte z góry, co wtedy widzi klient. Trzy decyzje do podjęcia przed uruchomieniem, bo dotyczą obietnicy wobec kupującego, a nie kodu:

  • Czego portal nie obiecuje bez ERP: cena z ostatniej synchronizacji zwykle jest bezpieczna, stan sprzed doby nie jest.
  • Kto dowiaduje się pierwszy: handlowiec przed klientem, żeby zdążył zadzwonić, zamiast tłumaczyć się po fakcie.
  • Co widzi klient: „zamówienie przyjęte, potwierdzimy ilości w ciągu godziny” buduje zaufanie, fałszywe „w realizacji” je wypala.

Kolejki, ponowienia i polską specyfikę Comarcha, Subiekta oraz enovy bierze na siebie sklep B2B z integracją ERP.

Zebrane w jednym miejscu, z warunkiem wejściowym przy każdej funkcji:

FunkcjaWarunek, bez którego jest tylko wyglądemCo wtedy robi klient
Cena kontraktowaRozstrzygana dla zalogowanego kontrahenta i dla całego koszykaPisze maila z pytaniem o cenę
Powtórka z historiiEdytowalna, z jawną informacją o pozycjach wycofanychWysyła zamówienie, które trzeba korygować telefonicznie
Wklejona lista SKUEkran uzgodnienia: rozpoznane, nierozpoznane, jednostkiZałącza arkusz do maila, jak dotąd
Limit i saldoAktualne rozrachunki w źródle plus skutek dla tego koszykaDzwoni do opiekuna, opiekun do księgowości
Stan i terminPróg albo liczba z datą, także dla pozycji od dostawcyPyta mailem, a przy braku odpowiedzi zamawia u konkurencji
Akceptacja u klientaRole, próg kwotowy i powiadomienie o koszyku do zatwierdzeniaPrzenosi obieg zgód do własnej poczty
Dokument w ERPNumer dokumentu wracający do portaluDzwoni z pytaniem, czy zamówienie doszło
Zachowanie przy awariiUczciwy status i powiadomienie handlowca przed klientemTraci zaufanie do portalu po jednym zdarzeniu

Nasza ocena warunków wejściowych, wynikająca z tego, jak działają te procesy, a nie z testu nazwanych platform. Traktuj kolumnę środkową jako listę pytań do dostawcy.

Handlowiec zostaje, zmienia mu się kolejka

Portal nikogo tu nie zastępuje. Zdejmuje z handlowca wpisywanie pozycji, sprawdzanie stanu i telefon do księgowości, a zostawia mu to, czego portal nie umie: negocjację, wyjątek, nowy produkt w ofercie klienta, reklamację i rozmowę z odbiorcą, który dopiero rozważa większy zakup. Praktyczna zmiana wygląda tak, że zamiast listy zamówień do przepisania handlowiec dostaje listę klientów, którzy w tym miesiącu jeszcze nie zamówili. Tej drugiej listy dziś zwykle nikt nie prowadzi, bo nie ma z czego jej zrobić.

Jedna rzecz przy tym potrafi wywrócić całe wdrożenie i leży poza technologią. Handlowiec, który podejrzewa, że zamówienie z portalu nie wejdzie do jego prowizji, nie wyśle klientowi linku, a klient bez linku nie założy konta. Zasady wynagradzania zamówień samoobsługowych rozstrzygnij przed uruchomieniem portalu. To decyzja handlowa z bezpośrednim skutkiem technicznym, bo bez niej adopcja zostanie niska, a nikt w firmie nie będzie wiedział dlaczego.

Adopcję portalu robią ludzie, którzy mają wysłać do niego klientów.

Kiedy portal nie ma sensu i mail wygrywa

Przy kilkunastu stałych odbiorcach i kilkudziesięciu zamówieniach miesięcznie poczta jest lepszym narzędziem, i mówimy to jako firma, która takie portale buduje. Mail obsługuje wyjątek szybciej niż jakikolwiek interfejs, nie wymaga wdrażania klientów, nie kosztuje nic i nie trzeba go utrzymywać ani aktualizować. Portal zaczyna wygrywać na powtarzalności, więc jeśli Twoje koszyki pierwszy i drugi z sekcji o liczeniu maili są małe, rachunek nie wyjdzie i lepiej wrócić do niego za rok.

Trzy sytuacje, w których odradzamy projekt niezależnie od skali:

  • Każde zamówienie jest negocjowane: przy sprzedaży projektowej portal obsłuży sam koniec procesu, a przepisywanie siedzi na jego początku.
  • Jeden duży odbiorca zamawia przez EDI: to zadanie dla integracji w jego standardzie, nie dla portalu z logowaniem.
  • Dane w ERP nie nadają się do pokazania: stan liczony ręcznie i cennik żyjący w arkuszu obok systemu dadzą portal, któremu klienci przestaną wierzyć po dwóch tygodniach. Najpierw dane.

Uczciwie o rachunku, bez ukrywania kwot: budowa platformy B2B mieści się u nas w widełkach etapu Engineering, od 60 000 zł netto, typowo 80 000 do 200 000 zł zależnie od katalogu, liczby integracji i zakresu migracji, plus utrzymanie od 3 500 zł netto miesięcznie. To zakres, nie oferta, a konkretna liczba wychodzi z rozmowy o konkretnym projekcie; model rozliczenia opisuje cennik. Przy kilkudziesięciu zamówieniach miesięcznie ten rachunek zwykle się nie domyka i wtedy to mówimy.

Test odbiorczy: osiem pytań do przejścia na demie

Ta lista jest wynikiem całego tekstu i da się ją przejść w godzinę, na własnym portalu albo na środowisku dostawcy. Każde pytanie ma sprawdzalną odpowiedź, więc nie da się jej zamknąć zapewnieniem, że „to konfigurujemy”.

  • Zaloguj się jako dwóch różnych kontrahentów i porównaj tę samą pozycję. Widzisz dwie ceny?
  • Powtórz zamówienie z zeszłego roku. Ile pozycji wypadło i czy portal powiedział, dlaczego?
  • Wklej listę z jednym błędnym indeksem, jedną pozycją niedostępną i jedną w kartonach. Ile różnych komunikatów zobaczyłeś?
  • Wejdź jako klient z jedną fakturą po terminie. Widzisz limit, tę fakturę i skutek dla koszyka?
  • Znajdź pozycję ze stanem zero i potwierdzoną datą od dostawcy. Co widzi kupujący?
  • Dodaj drugiego użytkownika bez prawa zatwierdzania i złóż zamówienie powyżej progu. Kto dostał powiadomienie?
  • Złóż zamówienie i sprawdź, czy numer dokumentu z ERP wrócił do portalu.
  • Odetnij połączenie z ERP na dziesięć minut i złóż zamówienie. Co zobaczył klient i kiedy dowiedział się handlowiec?

Od czego zacząć w tym tygodniu

Nie potrzebujesz wykonawcy, żeby zrobić dwie pierwsze rzeczy: podzielić miesiąc skrzynki na cztery koszyki i przejść osiem pytań powyżej na tym, co masz dziś. Z tymi dwiema kartkami rozmowa o zakresie przestaje być licytacją funkcji. U nas taki portal jest częścią platformy, z której klient prowadzi cały swój eCommerce z jednego miejsca, i budujemy go frameworkiem BEAM, zaczynając od przeglądu danych, cen i tego, co realnie udostępnia ERP. Sam moduł opisuje usługa portal zamówień B2B, szerszy zakres platforma hurtowa.

Jeśli szukasz kolejności wdrażania tego w czasie, opisaliśmy ją w tekście o cyfryzacji hurtu w 90 dni.

FAQ

Czym portal zamówień B2B różni się od zwykłego sklepu internetowego?

Sklep pokazuje jedną cenę wszystkim i przyjmuje płatność z góry. Portal B2B rozstrzyga cenę dla zalogowanego kontrahenta, pracuje na cenach netto, obsługuje limit kupiecki z odroczoną płatnością, wiele miejsc dostawy, wielu użytkowników na jednym koncie z akceptacją zamówień oraz zamawianie po indeksach i z historii. Różnica leży w modelu danych i uprawnieniach, więc rzadko da się ją nadrobić wtyczką do sklepu detalicznego.

Czy klienci hurtowi w ogóle będą chcieli zamawiać sami?

Chcą wtedy, gdy portal jest dla nich szybszy od maila, i tylko wtedy. Kupujący zawodowo mierzy to w minutach: wejście, powtórka poprzedniego zamówienia, sprawdzenie salda, potwierdzenie. Jeśli którykolwiek krok wymaga kontaktu z opiekunem, wraca do poczty, bo tam całą sprawę zamyka jednym akapitem. Adopcja zależy więc od kompletności funkcji i od tego, czy handlowcy rozdają link, a nie od szkolenia klientów.

Co zrobić, jeśli mój ERP nie prowadzi limitów kupieckich ani salda?

Wtedy limit trzeba gdzieś ustanowić, zanim portal go pokaże. Bywa, że mieszka on w pamięci handlowca albo w arkuszu księgowości; wtedy pierwszy krok jest procesowy, a nie techniczny. Możliwe jest też rozwiązanie pośrednie: portal pokazuje listę nieopłaconych faktur z terminami, którą ERP zwykle ma, i nie pokazuje limitu, dopóki nie istnieje. Lepiej pokazać mniej, ale prawdziwie.

Czy portal zabierze pracę handlowcom?

Zabiera im przepisywanie i telefony do księgowości, zostawia negocjacje, wyjątki i pozyskiwanie. Warto natomiast rozstrzygnąć zasady prowizji od zamówień samoobsługowych przed uruchomieniem, bo handlowiec, który podejrzewa stratę, nie wyśle klientowi linku do portalu. To jest najczęstsza przyczyna niskiej adopcji i nie ma nic wspólnego z jakością interfejsu.

Ile zamówień miesięcznie uzasadnia portal zamówień?

Nie da się podać progu, który byłby uczciwy dla wszystkich, bo koszt jednego zamówienia różni się między firmami o rząd wielkości. Uzasadnia go powtarzalność, nie sama liczba: policz godziny siedzące w powtórkach z własnej skrzynki metodą czterech koszyków i zestaw je z widełkami budowy i utrzymania. Przy kilkudziesięciu prostych zamówieniach miesięcznie ten rachunek zwykle wychodzi na korzyść poczty.

Mamy portal, a duża sieć nadal przysyła zamówienia plikiem. Dlaczego?

Duzi odbiorcy pracują we własnych systemach zakupowych i nie wchodzą do portali dostawców, bo to dla nich krok w tył. Ich zamówienia obsługuje się integracją w standardzie, którego oni używają, czyli EDI albo uzgodnionym formatem pliku. Portal i EDI nie konkurują ze sobą: portal obsługuje długi ogon odbiorców, integracja obsługuje kilku największych.

Dziennik

Szymon Żynda

Współzałożyciel Seedlight · platformy eCommerce, AI, SEO i GEO

Więcej od tego autora

Newsletter

Dziennik prosto na skrzynkę

Nowe wpisy i wnioski z realnych wdrożeń, co jakiś czas. Zero spamu, wypisujesz się jednym kliknięciem.