Workflow akceptacji zamówień w sklepie B2B

W skrócie

• 1. Progi akceptacji: per kwota, per kategoria, per typ produktu
• 2. Hierarchia: 2-3 poziomy (kierownik, dyrektor, zarząd dla największych)
• 3. Notyfikacje: email + SMS + in-app
• 4. SLA: czas na decyzję (24-72h), eskalacja przy braku odpowiedzi
• 5. Audit trail: kto, kiedy, jakie akcje - niezbędne dla compliance
• 6. Implementacja: Adobe Commerce / Shopware EE B2B Suite natywnie, Magento OS przez moduły

Progi akceptacji

Najprostszy model - pojedynczy próg.

Zamówienie < 5 000 zł: Buyer kupuje samodzielnie
Zamówienie ≥ 5 000 zł: wymagana akceptacja Approver'a

Średni model - wiele poziomów.

< 5 000 zł: Buyer samodzielnie
5 000 - 25 000 zł: akceptacja kierownika działu
25 000 - 100 000 zł: akceptacja dyrektora zakupów
> 100 000 zł: akceptacja zarządu

Zaawansowany - multidim z kategoriami.

Produkty IT: standardowo Approver, > 10 000 zł kierownik IT + dyrektor zakupów
Produkty produkcyjne: standardowo Buyer, > 50 000 zł kierownik produkcji
Usługi konsultacyjne: ZAWSZE wymaga zatwierdzenia dyrektora

Konfigurowalność per firma - różne firmy mają różne polityki.

Workflow - flow zamówienia

1. Buyer (Jan) składa zamówienie 25 000 zł
2. System sprawdza progi:
   - Limit Jana: 5 000 zł (niewystarczający)
   - Próg approval: 5 000 - 25 000 zł = kierownik
3. Zamówienie wchodzi w stan "pending_approval"
4. Notyfikacja do kierownika (email + SMS + in-app)
5. Kierownik (Anna) loguje się, widzi w panelu "Approvals pending"
6. Anna otwiera zamówienie, sprawdza pozycje
7. Decyzja:
   - Approve → zamówienie idzie do ERP, normalnie
   - Reject → email do Jana z uzasadnieniem
   - Modify → Anna zmienia ilości / produkty, akceptuje zmodyfikowane
8. Jan dostaje notyfikację o decyzji

Decyzje Approver'a

Trzy typowe akcje:

1. Approve. Zamówienie idzie do ERP, dalej w realizacji. Bez zmian.

2. Reject. Zamówienie nie idzie. Buyer dostaje uzasadnienie (text field). Może złożyć ponownie z poprawkami.

3. Modify. Approver zmienia coś (usuwa pozycję, zmniejsza ilość) i akceptuje zmodyfikowaną wersję. Buyer dostaje info „zamówienie zaakceptowane z modyfikacjami: ...".

W większości implementacji opcja 3 jest opcjonalna (nie wszystkie firmy chcą tej elastyczności).

SLA i eskalacja

Co jeśli Approver nie odpowiada?

Strategia:

1. Zamówienie pending_approval, notyfikacja do Approver'a
2. Po 24h bez decyzji: reminder email do Approver'a
3. Po 48h: eskalacja - notyfikacja do następnego poziomu (Manager + Sales Rep firmy)
4. Po 72h: automatyczne anulowanie ALBO automatyczne odbicie do Buyer'a (zależnie od polityki firmy)

SLA musi być konfigurowalne per firma - niektóre firmy mają „24h" jako standard, niektóre „1 tydzień".

Notyfikacje

Kanały:

• Email (zawsze)
• SMS (jeśli klient ma skonfigurowane)
• In-app notification (dashboard w panelu)
• Webhook do systemów klienta (Slack, Teams) - zaawansowane

Co w treści:

• Numer zamówienia
• Buyer (kto złożył)
• Kwota
• Termin akcji (SLA)
• Link do panelu (direct deep link do zamówienia)

Częstotliwość:

• Pierwsze powiadomienie: natychmiast
• Reminder: po 24h (jeśli nie reaguje)
• Eskalacja: po 48h

Audit trail - compliance

Każda akcja w workflow musi być logowana:

Zamówienie #12345
  - 2026-06-17 10:30 - Created by Jan Nowak (Buyer), kwota 25 000 zł
  - 2026-06-17 10:30 - Status changed to "pending_approval"
  - 2026-06-17 10:31 - Notyfikacja sent to Anna Kowalska (Approver)
  - 2026-06-17 14:25 - Anna Kowalska otworzyła zamówienie
  - 2026-06-17 14:32 - Anna Kowalska modified item "Produkt X" qty 100 → 80
  - 2026-06-17 14:33 - Anna Kowalska approved order
  - 2026-06-17 14:33 - Status changed to "approved"
  - 2026-06-17 14:34 - Zamówienie wysłane do ERP (Comarch XL #DOK-2026-5678)

Konieczne dla:

• Audytu wewnętrznego klienta (skąd to zamówienie? kto zatwierdził?)
• ISO compliance (klienci z ISO 9001 wymagają tej traceability)
• Dochodzenia w razie reklamacji ("kto akceptował błędne zamówienie?")

Konfiguracja per firma

Workflow nie jest hardkodowany - konfigurowalny per firma w panelu Sales Rep / handlowca:

Firma: ACME Sp. z o.o.

Approval Rules:
  Rule 1: Suma zamówienia >= 5000 zł
    → Requires approval from: Kierownik Działu
    → SLA: 24h
    → Escalation: Dyrektor Zakupów

  Rule 2: Suma zamówienia >= 50 000 zł
    → Requires approval from: Dyrektor Zakupów
    → SLA: 48h
    → Escalation: Zarząd

  Rule 3: Kategoria = "Usługi Konsultacyjne"
    → ALWAYS requires approval from: Dyrektor Zakupów
    → SLA: 72h

Buyer może być również auto-Approver dla niskich kwot (limit Buyer 5k = jego zamówienia do 5k bez approval).

Zamówienie pending - view dla Buyer'a

Buyer widzi swoje zamówienia w panelu. Specyficzne statusy:

• pending_approval - czeka na zatwierdzenie
• approved - zatwierdzone, w realizacji
• rejected - odrzucone (Buyer może edytować i złożyć ponownie)
• auto_cancelled - anulowane przez SLA timeout

Notyfikacja in-app: „Twoje zamówienie #12345 zostało zatwierdzone przez Anna Kowalska, jest teraz w realizacji".

Implementacja w platformach

Adobe Commerce:

• Wbudowany Approval Workflow w Companies + B2B feature
• Konfigurowalne progi w panelu administracyjnym
• Notyfikacje email out-of-the-box

Shopware Enterprise B2B Suite:

• Order Approvals module
• Multi-level approval z eskalacją
• Konfigurowalne per Business Partner

Magento Open Source:

• Dorabiasz przez Aheadworks B2B Suite, Amasty, lub custom
• Custom: state machine na zamówieniu, role + permissions, notyfikacje przez Symfony Messenger

Custom (Symfony / Laravel):

• State machine library (e.g., Symfony Workflow component)
• Database: order_status, order_approvals, audit_log

Najczęstsze problemy

1. Hard-coded progi. Workflow z progiem 5000 zł wbity w kod. Klient prosi „chcemy 7500" - release sklepu. Powinno być konfigurowalne.

2. Brak audit trail. Tylko status zamówienia, brak logu kto i kiedy zmieniał. Reklamacja klienta: „kto to zatwierdził?". Odpowiedź: „nie wiemy".

3. Brak notyfikacji push do mobile. Approver na meeting'u, nie ma laptopa. Email nie przychodzi natychmiast. Workflow staje.

Rozwiązanie: push notification + SMS dla krytycznych.

4. Brak SLA / eskalacji. Approver na urlopie. Zamówienia czekają tygodnie. Klient frustracja.

5. Approver = Buyer (ten sam user). Człowiek nie może akceptować własnego zamówienia. Wymóg „dwie różne osoby".

6. Workflow per zamówienie, nie per zmiana. Buyer złożył, zatwierdzono, później zmieniono ilości (faktura partial). Brak ponownej akceptacji - czy potrzebna? Polityka decyzyjna firmy.

FAQ

Czy workflow akceptacji blokuje wysyłkę do ERP? Tak. Zamówienie pending_approval NIE idzie do ERP. Dopiero po approve.

Czy mogę pominąć approval dla zaufanych klientów / produktów? Tak - konfigurowalne. „Wyłączenia" per kategoria lub konkretny produkt.

Czy workflow działa dla guest checkout? Nie. Guest nie ma firmy → brak approval workflow. Tylko zalogowane Companies.

Czy mogę mieć workflow akceptacji per ostrzeżenie cenowe? Tak - „zamówienie powyżej standardowej ceny" → wymaga approval. Rzadkie, ale możliwe.

Co z workflow w przypadku zmiany cen (cennik kontraktowy się zmienił między approval a wysyłką)? Pattern: cena z momentu approval'u zostaje (snapshot). ERP wystawia fakturę z tą ceną. Późniejsze zmiany cennika nie wpływają na zatwierdzone zamówienie.

Co dalej

• Pillar procesów B2B: Procesy zakupowe B2B
• Multi-account (struktura): Multi-account
• Role: Role i uprawnienia
• Limity kredytowe: Limity kredytowe