Procesy zakupowe B2B w e-commerce - cenniki, limity, workflow, RFQ
W B2C klient widzi cenę, klika „kup", płaci kartą. W B2B kupujący to nie jedna osoba - to firma z kilkoma kupującymi, z budżetami, z workflow akceptacji, z 30-dniowym terminem płatności i kontraktem cenowym podpisanym na rok. Każdy z tych elementów to osobny proces, który musi być zaimplementowany w sklepie - albo klient odejdzie do konkurencji, która to ma.
Spis treści (11)
W skrócie
- 1. Cenniki kontraktowe per kontrahent - każdy klient ma swoją cenę
- 2. Multi-account / company structure - klient to firma z kilkoma kupującymi
- 3. Role kupujących - admin, kupujący, zatwierdzający, kontroler budżetu
- 4. Workflow akceptacji - zamówienia powyżej progu wymagają akceptacji
- 5. RFQ - zamiast koszyka, prośba o ofertę
- 6. PunchOut / OCI / cXML - integracja z systemami zakupowymi klientów korporacyjnych
- 7. Limity kredytowe - kupowanie na fakturę z terminem, z kontrolą salda
- 8. Numery referencyjne klienta - kupujący wpisuje swoje PO number, ułatwiamy księgowanie po jego stronie
Cenniki kontraktowe - core B2B
Najmocniej odróżniający element. Klient B2B nie kupuje po cenie z metki - kupuje po swojej cenie.
Modele cenników:
1. Cennik indywidualny per produkt. Klient X kupuje produkt ABC za 12 zł zamiast 15 zł.
2. Procent od cennika bazowego. Klient X dostaje -15% na całą grupę.
3. Cenniki grupowe. Grupa „klienci platynowi" widzi -10%, „złoci" -5%, „srebrni" cennik bazowy.
4. Progi ilościowe. Od 1 szt. 12 zł, od 100 szt. 10 zł, od 500 szt. 9 zł.
5. Cenniki czasowe. Od dziś do końca miesiąca cena promocyjna, potem wraca cena standardowa.
6. Hybrydowe. Klient ma indywidualną cenę, ale po przekroczeniu 1000 szt. dostaje dodatkowy próg.
7. Cenniki kontraktowe per asortyment. Klient ma cennik tylko na produkty z kategorii X (inny asortyment - cena katalogowa).
Implementacja:
Cenniki żyją w ERP (Comarch XL, SAP, Subiekt, enova mają swoje silniki). Sklep konsumuje. Sklep nie powinien duplikować logiki - zawsze pyta ERP „daj cenę dla klienta K, produkt P, ilość Q".
Cache w Redis ratuje skórę: 5-15 min TTL, klucz (klient, sku, qty). Bez cache ERP umiera w peak'u.
Cenniki kontraktowe per kontrahent.
Multi-account / company structure
W B2B kupujący to nie osoba. Jest firma. Klient B2B w sklepie to firma z kilkoma kupującymi.
Struktura typowa:
Firma ACME Sp. z o.o.
+-- Admin firmy (Anna Kowalska, dyrektor zakupów)
| +-- Tworzy konta dla kupujących
| +-- Ustawia role i uprawnienia
| +-- Widzi pełną historię firmy
|
+-- Kupujący 1 (Jan Nowak, dział produkcji)
| +-- Limit zamówienia 5000 zł
| +-- Kategoria: tylko surowce
|
+-- Kupujący 2 (Piotr Wójcik, dział R&D)
| +-- Limit zamówienia 2000 zł
| +-- Kategoria: tylko narzędzia laboratoryjne
|
+-- Zatwierdzający (Anna Kowalska, ta sama)
+-- Akceptuje zamówienia >5000 zł
Cenniki: wszystkie kupujący w firmie ACME widzą cenniki kontraktowe firmy. Nie ma „cennika per użytkownik" - cennik jest per firma.
Koszyk i historia: każdy kupujący ma swój koszyk, swoją historię. Admin widzi pełną historię firmy.
Implementacja w platformach:
- Adobe Commerce: wbudowane Companies feature
- Shopware Enterprise B2B Suite: Business Partner Management
- Magento Open Source: dorabiasz (Aheadworks B2B Suite, Amasty Company Accounts)
- BigCommerce B2B Edition: wbudowane
Multi-account dla organizacji.
Role i uprawnienia kupujących
W firmie ACME różne osoby mają różne uprawnienia:
Typowe role:
1. Buyer (kupujący). Składa zamówienia w ramach swojego limitu. Widzi cenniki, koszyk, historię.
2. Approver (zatwierdzający). Akceptuje zamówienia powyżej progu (np. powyżej 10 tys. zł). Może zatwierdzić, odrzucić, zmodyfikować.
3. Account Admin (admin firmy). Tworzy konta, zarządza uprawnieniami, widzi wszystko, może zamówić w imieniu innych.
4. Viewer / Reporting (kontroler). Tylko czyta - historia, raporty. Nie kupuje.
5. Catalog Manager. Wybiera produkty, które firma w ogóle widzi (z dużego katalogu - restricted catalog).
Granularność uprawnień:
- Limit jednorazowego zamówienia
- Dzienny / miesięczny limit
- Restricted kategorie (np. „tylko z grupy materiały biurowe")
- Restricted produkty (whitelist / blacklist konkretnych SKU)
- Magazyn źródłowy (z którego można zamawiać)
- Metody płatności (BNPL tak / nie, karta tak / nie, faktura z terminem tak / nie)
- Adresy dostawy (predefiniowane vs. dowolne)
Implementacja:
Najbardziej rozwinięte w Adobe Commerce (Companies + Roles) i Shopware Enterprise B2B Suite. Magento OS - moduły komercyjne.
Role i uprawnienia kupujących.
Workflow akceptacji zamówień
Klient B2B z dużymi obrotami nie pozwala każdemu kupować bez kontroli. Zamówienie powyżej progu = wymóg akceptacji.
Typowe progi:
- 0-1000 zł: kupujący samodzielnie
- 1000-10000 zł: zatwierdzenie szefa działu
- 10000-50000 zł: zatwierdzenie dyrektora
-
50000 zł: zatwierdzenie zarządu (czasem przez podpis elektroniczny)
Workflow:
1. Kupujący składa zamówienie 25000 zł
2. System: "Zamówienie wymaga akceptacji Dyrektora Zakupów (próg 10000 zł)"
3. Zamówienie w stanie "pending_approval"
4. Email/SMS do Dyrektora: "Zatwierdź zamówienie nr X"
5. Dyrektor wchodzi w panel: akceptuje / odrzuca / modyfikuje
6. Akceptacja → zamówienie idzie do ERP normalnie
7. Odrzucenie → email do kupującego z uzasadnieniem
Wymagania techniczne:
- State machine zamówienia:
pending_approval,approved,rejected,synced_to_erp, ... - Notyfikacje (email, SMS, in-app)
- Audyt trail (kto, kiedy, jakie akcje)
- SLA: jeśli zatwierdzający nie reaguje w X dni - escalacja
RFQ - Request For Quote
Nie wszystko sprzedajesz po cenie z katalogu. Czasem klient chce negocjować - szczególnie przy dużych ilościach lub specyficznych konfiguracjach.
Kiedy RFQ:
- Zamówienia powyżej kwoty X (np. >50 tys. zł)
- Produkty na zamówienie (custom)
- Klient prosi o lepszą cenę przy dużych ilościach
- Klient nowy, bez kontraktu, ale duży
Workflow:
1. Klient w sklepie wkłada produkty do "koszyka RFQ" (osobny od kupowego)
2. Wysyła RFQ: "wycień to z możliwie najlepszą ceną"
3. Wewnątrz: handlowiec dostaje notyfikację
4. Handlowiec analizuje (klient profil, marża, sytuacja w branży)
5. Handlowiec przygotowuje ofertę w panelu (cena per produkt + warunki płatności + dostawa)
6. System wysyła ofertę klientowi (email + dostęp w panelu)
7. Klient: akceptuje, kontruje, odrzuca
8. Akceptacja → quote przechodzi w zamówienie automatycznie
Cykl life RFQ: od minut (proste rzeczy) do tygodni (skomplikowane negocjacje).
Implementacja:
- Adobe Commerce: Negotiable Quotes (wbudowane)
- Shopware Enterprise B2B Suite: Quote Management
- Magento OS: moduły (Aheadworks Quote, Webkul)
PunchOut / OCI / cXML
Klient korporacyjny używa systemu zakupowego (SAP Ariba, Coupa, Jaggaer). Zamiast wchodzić do twojego sklepu - pytamy go w jego systemie.
PunchOut workflow:
1. Klient w SAP Ariba klika "Procure from Supplier ACME"
2. Ariba wysyła PunchOutSetupRequest do twojego sklepu (cXML)
3. Twój sklep tworzy sesję, zwraca URL
4. Klient zostaje przekierowany do sklepu, zalogowany automatycznie
5. Widzi swój katalog (cennik kontraktowy, restricted assortment)
6. Buduje koszyk
7. Klika "Transfer to Cart" (zamiast "Złóż zamówienie")
8. Sklep wysyła koszyk jako cXML PunchOutOrderMessage do Ariby
9. Ariba pokazuje kupującemu w jego systemie
10. Workflow akceptacji po stronie Ariby (kontrole budżetu, akceptacje)
11. Ariba wysyła cXML PurchaseOrder z powrotem do sklepu
12. Sklep konwertuje na właściwe zamówienie, wysyła do ERP
Wszystko trwa 1-15 minut w korporacyjnym workflow.
Standardy:
- OCI (Open Catalog Interface) - SAP-owy klasyk, HTML form parameters
- cXML (commerce XML) - Ariba, Coupa, Jaggaer
Kiedy potrzebujesz:
- Sprzedaż do korporacji, które mają SAP Ariba / Coupa / Jaggaer
- Kontrakty z dużymi sieciami przemysłowymi
- Klient wprost zażąda
Koszt wdrożenia: 30-80 tys. zł dla średniego scope.
Limity kredytowe
Klient B2B kupuje na fakturę z terminem 14-60 dni. Ma kontrakt - może kupić na 100 tys. zł, ale jeśli już ma 80 tys. niezapłacone, kolejne 30 tys. będzie zablokowane.
Workflow:
1. Klient w koszyku, suma 25000 zł
2. Soft check (cache 5 min):
- Saldo bieżące: 60000 zł niezapłacone
- Limit: 100000 zł
- Pozostały limit: 40000 zł
- Ten koszyk: 25000 zł → OK
3. Klient klika "Złóż zamówienie"
4. Hard check (sync z ERP):
- Saldo: 65000 zł (wzrosło o 5000 zł od soft check'u - nowa faktura wyszła)
- Pozostały limit: 35000 zł
- Koszyk 25000 zł → OK
5. Zamówienie wchodzi, limit zostaje zarezerwowany do momentu wystawienia faktury
Edge cases:
- Przekroczenie limitu → komunikat z opcjami (płać kartą / BNPL / kontakt z opiekunem)
- Wygasły kontrakt → blokada
- Klient nieaktywny → blokada
Limity kredytowe w sklepie B2B.
Numery referencyjne klienta (PO numbers)
Drobiazg, który robi wielką różnicę.
Klient w swojej księgowości używa numerów PO (Purchase Order). Twoje zamówienie potrzebuje takiego numeru, żeby klient mógł je zaksięgować po swojej stronie.
Implementacja:
- Pole „Twój numer PO" w checkoutcie (opcjonalne / obowiązkowe - zależnie od klienta)
- Numer trafia na fakturę
- Numer widoczny w panelu klienta + w API odpowiedziach
To 30 minut implementacji. Dla klientów korporacyjnych wartość ogromna - księgowość nie dzwoni do nich z pytaniem „co to za faktura".
Quick Order / Bulk Order
Klient B2B zna SKU. Nie przegląda katalogu - wpisuje listę.
Patterns:
- Wpisanie SKU + ilości w formularzu
- Upload CSV / XLSX
- Quick order page z autocomplete po SKU
- API endpoint dla integracji z systemami klienta
Wartość: szybkość. Klient z 100-pozycyjnym zamówieniem może to wypełnić w 2 minuty zamiast 30.
Lista zakupów / Requisition Lists
Klient kupuje regularnie te same produkty. Listy zakupowe = predefiniowane koszyki.
Use case:
- „Zamówienie miesięczne dla działu produkcji" → 80 produktów predefined
- „Awaryjny restock" → 20 produktów
- „Po kontrakcie z X" → produkty kontraktowe
Klient otwiera listę, modyfikuje ilości jeśli trzeba, kupuje wszystko jednym kliknięciem.
Faktura proforma / faktura z terminem
W B2B faktura przed zapłatą:
Faktura proforma: dokument przed zapłatą. Klient może ją wykorzystać do uzyskania środków (finansowanie zakupu, kontrola wewnętrzna). Sklep wysyła automatycznie po zamówieniu.
Faktura z terminem: standardowa faktura VAT z terminem płatności. Wystawiana po wysyłce towaru.
Korekta: zwrot, błąd, zmiana - sklep wystawia korektę. Workflow w sklepie + ERP.
FAQ
Czy mogę zrobić B2B bez wdrażania wszystkich tych procesów? Tak, na małej skali. Dla małego sklepu B2B (do 1-3 M zł obrotu) wystarczy: cenniki grupowe + login + faktura z terminem. Bez multi-account, bez workflow, bez RFQ.
Czy procesy B2B są w Magento Open Source? Częściowo. Magento OS ma cenniki grupowe, login z customer groups. Companies / Quotes / Approval Workflow - Adobe Commerce ma natywnie, OS przez moduły.
Czy Shopware ma to wszystko? W Enterprise B2B Suite - większość. Community Edition - mniej, dorabiasz.
Czy potrzebuję wszystkich procesów na raz? Nie. Zacznij od cenników + login + faktury. Pozostałe dodawaj w miarę wzrostu skali i potrzeb klientów.
Czy procesy B2B są w platformach SaaS (Shopify, BigCommerce)? Shopify Plus z B2B i BigCommerce B2B Edition - tak, większość. Mniej dojrzałe niż Adobe Commerce / Shopware EE.
Co dalej
- Konkretne procesy: Cenniki, Multi-account, Role, Workflow akceptacji, RFQ, Limity, PunchOut
- Integracje: pillar /integracje
- Platforma: pillar /platformy-ecommerce-b2b
O autorze
Jakub Owsianka
Architekt rozwiązania w WiseB2B - silniku platform B2B. Zaczynał po stronie biznesu (własne sklepy), potem deweloper, dziś projektuje wdrożenia dla sklepów z katalogami w dziesiątkach tysięcy SKU. W ostatnich latach wdrożył AI-development w zespole i funkcjonalności oparte o AI bezpośrednio w silniku sklepu.
Masz pytanie do tego artykułu?
Dodatkowy kontekst, problem z własnym wdrożeniem, druga opinia - napisz wprost. Odpowiadam osobiście w 1-2 dni robocze.