1. Cel procesu (dlaczego)
Nie chodzi o „potwierdzenie dla formalności”, tylko o:
- zamknięcie rozbieżności oferta ↔ zamówienie
- przeniesienie odpowiedzialności (co jest po czyjej stronie)
- zabezpieczenie logistyki i terminu
2. Moment uruchomienia procesu
Trigger:
- każde zamówienie, które:
- różni się od oferty
- LUB zawiera dodatkowe wymagania
- LUB dotyczy dostawy bezpośredniej do klienta końcowego
W praktyce:
👉 niemal każde zamówienie B2B
3. Struktura procesu (prosty workflow)
Krok 1 – Check zgodności (handlowiec / PM)
Checklist (maks 2–3 min):
- produkt / ilości / ceny ✔
- adres dostawy ✔
- warunki dostawy ✔
- termin ✔
- dodatkowe wymagania ✔
👉 wynik:
- A: zgodne → szybkie potwierdzenie
- B: niezgodne → potwierdzenie warunkowe
Krok 2 – Klasyfikacja rozbieżności
Nie wszystko jest równie ważne.
Podziel na 3 poziomy:
🔴 Krytyczne (blokują start)
- zmiana adresu
- zmiana Incoterms
- sztywny termin vs warunkowy
- wymagania klienta (np. Synthos)
🟡 Operacyjne
- oznaczenia paczek
- kontakt do odbioru
- godziny dostaw
🟢 Neutralne
- forma wysyłki FV
- drobne uwagi
Krok 3 – Decyzja
Na podstawie powyższego:
- brak 🔴 → potwierdzenie bezwarunkowe
- jest 🔴 → potwierdzenie z założeniami
Krok 4 – Potwierdzenie do klienta (klucz procesu)
Struktura maila (bardzo ważne)
1. Potwierdzenie zakresu
Confirmujemy przyjęcie zamówienia nr…
2. Zakres (skrót)
- produkt
- ilość
- wartość
3. KLUCZOWE ZAŁOŻENIA (to jest sedno)
np.:
- dostawa do Synthos – potwierdzona
- realizacja: 4–5 tygodni od potwierdzenia
- dostawa zgodnie z naszym standardem logistycznym (DAP / transport organizowany przez nas)
- wymagania logistyczne zostaną uwzględnione
4. Braki / pytania (jeśli są)
- osoba kontaktowa po stronie odbioru
- potwierdzenie terminu
5. Zamknięcie
Brak uwag traktujemy jako potwierdzenie powyższych warunków
4. Zasada kluczowa (najważniejsza w całym procesie)
👉 Nie pytasz klienta „czy wszystko OK”
👉 TY definiujesz warunki i dajesz mu możliwość sprzeciwu
To zmienia:
- kto kontroluje proces
- kto ponosi ryzyko
5. Wersja ultra-prosta (do wdrożenia od jutra)
Możesz wprowadzić od razu:
Szablon 5 linijek
Confirmujemy przyjęcie zamówienia nr XXX na podstawie oferty XXX.Zakres:
- [produkt / ilość / wartość]Założenia realizacyjne:
- termin: [X tygodni od potwierdzenia]
- dostawa: [DAP / wg ustaleń]
- adres: [xxx]Uwzględnimy przekazane wymagania logistyczne.Brak uwag traktujemy jako potwierdzenie powyższych warunków.
6. Gdzie ten proces daje największą wartość
Najbardziej chroni przy:
- dostawach do zakładów (Synthos, Orlen itd.)
- projektach Ex (wysokie wymagania)
- zamówieniach przez pośredników (jak MWN)
7. Co by się zmieniło w tym konkretnym case
Gdyby ten proces był użyty:
- adres Synthos → jawnie potwierdzony
- DAP vs kurier → wyjaśnione
- termin → ustawiony zgodnie z ofertą
- wymagania logistyczne → przekazane i zaakceptowane
👉 praktycznie 0 ryzyka operacyjnego
8. Jeśli chcesz kolejny krok
Mogę:
albo przygotować 3 gotowe szablony maili (simple / medium / strict)
przerobić to na procedurę firmową (1 strona PDF)
albo zrobić wersję pod CRM / n8n (automatyzacja)
| # | Obszar | Oferta | Zamówienie / mail | Status | Uwagi kluczowe |
|---|---|---|---|---|---|
| 1 | Towar + cena + ilość + JM | Oprawa 10 szt / 157,59 EUR; Uchwyt 20 szt / 2,90 EUR; Transport 30 EUR | Identyczne | ✔ Zgodne | Brak różnic |
| 2 | Cena sumaryczna | 1 663,90 EUR | 1 663,90 EUR | ✔ Zgodne | Brak różnic |
| 3 | Termin realizacji | 4–5 tygodni od potwierdzenia | 11.05.2026 (data sztywna) | ⚠️ Niejednoznaczne | Wymaga potwierdzenia czy termin mieści się w lead time |
| 4 | Warunki płatności | 14 dni, przelew | 14 dni, przelew | ✔ Zgodne | Brak różnic |
| 5 | Dane do faktury | MWN Trade | MWN Trade + wysyłka FV na wskazany mail | ✔ Zgodne | Dodatkowy wymóg operacyjny (księgowość) |
| 6 | Warunki dostawy | DAP (Incoterms 2020) | „kurier” | ❗ Rozbieżność | Niezgodność formalna – brak jasności odpowiedzialności |
| 7 | Adres dostawy | Szczecin | Synthos, Oświęcim | ❗ Rozbieżność | Zmiana miejsca dostawy (wpływ na logistykę/koszt) |
| 8 | Osoba odbierająca + kontakt | Brak wskazania | Telefon jest, brak konkretnej osoby | ⚠️ Niepełne | Ryzyko operacyjne przy dostawie |
| 9 | Wymagania logistyczne | Brak | Numer zamówienia na paczce, procedury ochrony, godziny przyjęć | ❗ Nowe wymagania | Krytyczne – bez spełnienia brak odbioru |
| 10 | Dodatkowe warunki klienta | OWS Wolff | Zakaz pobrania, brak zmiany adresu, oznaczenia | ❗ Rozbieżność | Klient wprowadza własne warunki |
| 11 | Pole komentarza | Brak | Istotne instrukcje dostawy | ⚠️ Uzupełnione | Musi być przekazane do logistyki |
odsumowanie:
To zamówienie jest handlowo poprawne, ale formalnie i operacyjnie nie jest w pełni zgodne z ofertą.
Najważniejsze fakty:
- ✔ Produkt, ceny, ilości – pełna zgodność
- ❗ Dostawa, termin i warunki logistyczne – zmienione przez klienta
Główne ryzyko:
Nie wynika z produktu, tylko z dostawy do Synthosu (procedury, oznaczenia, ograniczenia czasowe) oraz niejednoznacznych warunków transportu i terminu.
Sedno:
To nie jest „realizujemy i wysyłamy”, tylko:
„realizujemy po krótkim potwierdzeniu warunków”
Bez tego:
- ryzyko nieprzyjęcia dostawy
- ryzyko sporu o termin
- ryzyko przerzucenia odpowiedzialności na Was
Wniosek końcowy:
Zamówienie jest OK do realizacji, ale wymaga krótkiego, formalnego doprecyzowania 2–3 kluczowych punktów przed startem.
Poniżej uporządkowana, precyzyjna definicja momentu uruchomienia procesu + pierwszego etapu weryfikacji – gotowa do wdrożenia jako standard.
Moment uruchomienia procesu
Trigger:
Otrzymanie od klienta wiadomości (mail) zawierającej potwierdzenie zamówienia – w treści maila i/lub w załączniku (np. PDF zamówienia).
Czyli:
- klient „przekuwa ofertę w zamówienie”
- następuje przejście: oferta → potencjalna umowa
Cel tego etapu
Nie „przyjęcie zamówienia”, tylko:
weryfikacja, czy zamówienie = dokładna akceptacja oferty
Etap 1 – Weryfikacja zgodności (core procesu)
Źródła danych (co analizujesz)
Zawsze równolegle:
- Nasza oferta
- Załącznik klienta (zamówienie PDF)
- Treść maila klienta
👉 Kluczowe:
Mail często zawiera rzeczy, których NIE ma w zamówieniu (np. Synthos).
Zakres weryfikacji (checklista operacyjna)
1. Zakres handlowy
- produkty
- ilości
- ceny
- wartość całkowita
👉 wynik: zgodne / niezgodne
2. Termin
- oferta: warunkowy (np. 4–5 tygodni)
- zamówienie: często konkretna data
👉 pytanie:
czy klient nie „nadpisuje” terminu?
3. Warunki dostawy
- Incoterms z oferty
- zapis w zamówieniu / brak zapisu / „kurier”
👉 to jest jeden z najczęstszych konfliktów
4. Adres dostawy
- czy zgodny z ofertą?
- czy zmieniony?
- czy jest dostawa bezpośrednia do klienta końcowego?
5. Wymagania logistyczne (mail!)
- oznaczenia paczek
- procedury zakładowe
- godziny przyjęć
- wymagania wobec kierowcy
👉 to jest często „ukryta część zamówienia”
6. Dane formalne
- dane do faktury
- numer zamówienia do umieszczenia
- dodatkowe instrukcje (np. wysyłka FV)
Wynik etapu (decyzja binarna)
✔ Scenariusz A – pełna zgodność
Zamówienie = oferta (brak zmian)
👉 przechodzisz do:
- potwierdzenia zamówienia (formalność)
❗ Scenariusz B – rozbieżności
Jakakolwiek zmiana w:
- dostawie
- terminie
- adresie
- wymaganiach
👉 przechodzisz do:
- potwierdzenia warunkowego (kluczowy krok procesu)
Zasada krytyczna
Zamówienie klienta NIE jest automatycznie wiążące, jeśli różni się od oferty
I dokładnie dlatego:
- ten etap istnieje
- i NIE może być pomijany
Najczęstszy błąd (który eliminujesz tym procesem)
Zespół widzi:
- ceny się zgadzają ✔
- produkt się zgadza ✔
→ i uruchamia realizację
Ignorując:
- logistykę
- termin
- warunki
👉 to generuje 90% problemów później
Minimalna wersja do wdrożenia (1 zdanie operacyjne)
Każde zamówienie otrzymane od klienta musi zostać zweryfikowane z ofertą (mail + załącznik), a w przypadku jakiejkolwiek rozbieżności wymaga formalnego potwierdzenia warunków przed rozpoczęciem realizacji.
Jeśli chcesz kolejny krok
Możemy teraz:
- zamienić to w checklistę do Excela / CRM (klikana)
- albo zrobić schemat decyzyjny (flow)
- albo rozpisać role (kto co robi: handlowiec / PM / logistyka)
zrobić schemat decyzyjny (flow) rozpisać role (kto co robi: handlowiec / PM / logistyka)
Poniżej masz gotowy schemat decyzyjny (flow) + jasny podział ról. To jest wersja operacyjna – do wdrożenia bez „filozofii”.
1. Schemat decyzyjny (flow)
START
Otrzymanie zamówienia (mail + załącznik)
⬇
Krok 1 – Weryfikacja zgodności (Handlowiec / PM)
Sprawdź równolegle:
- oferta
- zamówienie (PDF)
- treść maila
⬇
Decyzja 1: Czy zakres handlowy się zgadza?
(produkt / ilość / cena / wartość)
- ✔ TAK → dalej
- ❌ NIE → STOP → korekta z klientem (Handlowiec)
⬇
Decyzja 2: Czy warunki są zgodne z ofertą?
(adres / Incoterms / termin / płatność)
- ✔ TAK → dalej
- ❌ NIE → oznacz jako ROZBIEŻNOŚĆ KRYTYCZNA
⬇
Decyzja 3: Czy są dodatkowe wymagania klienta?
(mail: Synthos, oznaczenia, procedury, godziny itd.)
- ❌ NIE → dalej
- ✔ TAK → oznacz jako ROZBIEŻNOŚĆ OPERACYJNA
⬇
Decyzja 4: Czy występują rozbieżności?
- ❌ NIE →
👉 Potwierdzenie zamówienia (bezwarunkowe)
👉 przejście do realizacji - ✔ TAK →
👉 Potwierdzenie warunkowe do klienta
👉 czekasz na brak sprzeciwu / akceptację
⬇
Krok 5 – Zwolnienie do realizacji
Po:
- akceptacji klienta
LUB - braku sprzeciwu
👉 przekazanie do produkcji/logistyki
2. Schemat w skrócie (do powieszenia na ścianie)
ZAMÓWIENIE → WERYFIKACJA→ zakres OK?
NO → korekta
YES ↓→ warunki OK?
NO → potwierdzenie warunkowe
YES ↓→ wymagania dodatkowe?
YES → potwierdzenie warunkowe
NO ↓→ potwierdzenie → realizacja
3. Podział ról (kluczowy element)
🟦 Handlowiec (owner procesu)
Odpowiada za:
- analizę zamówienia vs oferta
- identyfikację rozbieżności
- komunikację z klientem
- wysłanie potwierdzenia
Podejmuje decyzje:
- czy zamówienie jest zgodne
- czy trzeba wysłać potwierdzenie warunkowe
NIE oddaje odpowiedzialności za:
- interpretację warunków
- kontakt z klientem
🟨 PM / Inżynier (jeśli dotyczy)
Wchodzi gdy:
- projekt jest technicznie złożony
- są zmiany konfiguracji
- są niejasności techniczne
Odpowiada za:
- potwierdzenie zgodności technicznej
- ocenę wpływu zmian na:
- termin
- wykonanie
Nie zajmuje się:
- logistyką
- formalnym potwierdzeniem zamówienia
🟩 Logistyka / Produkcja
Wchodzi DOPIERO po potwierdzeniu zamówienia
Odpowiada za:
- organizację transportu
- uwzględnienie wymagań klienta:
- oznaczenia paczek
- procedury zakładu
- godziny dostawy
Nie podejmuje decyzji:
- o warunkach dostawy
- o zmianach vs oferta
4. Kluczowe zasady (żeby to działało)
Zasada 1 – jeden właściciel
👉 zawsze Handlowiec = owner
Zasada 2 – brak „cichej akceptacji”
👉 każda rozbieżność = jawne potwierdzenie
Zasada 3 – logistyka nie analizuje zamówienia
👉 dostaje gotowe, zatwierdzone warunki
Zasada 4 – mail klienta = część zamówienia
👉 nie tylko PDF się liczy
5. Co to rozwiązuje w praktyce
Po wdrożeniu:
- brak „niedostarczonych przesyłek” (Synthos, Orlen itd.)
- brak sporów o termin
- brak chaosu między działami
- jasna odpowiedzialność
6. Jeśli chcesz kolejny krok
Mogę:
- zrobić z tego diagram (Mermaid / grafika do prezentacji)
- przygotować checklistę do CRM / Excela (klikalną)
- albo szablony maili przypięte do każdego scenariusza (A/B)