Base dla fulfillmentów — czego brakuje i jak to nadrobić
Base (znana też jako BaseLinker) to doskonałe narzędzie dla sprzedawców — ale operatorzy fulfillmentu trafiają na ściany. Pięć kluczowych luk, z których każda kosztuje czas lub pieniądze, i jak je zamknąć.
Spis treści
Spis treści
- Base jest świetna — ale nie dla Ciebie
- Luka 1: Multi-tenant — jeden account, wielu klientów
- Luka 2: Per-client pricing — brak rozliczania
- Luka 3: Brak widoku dla klienta końcowego
- Luka 4: Awizacje — nadal przez maila
- Luka 5: Brak systemu ticketów per klient
- Wniosek: warstwa nad Base
Base jest świetna — ale nie dla Ciebie
Base (znana też jako BaseLinker) to jeden z najlepszych systemów do zarządzania zamówieniami w polskim e-commerce. Integruje ponad 1000 platform, obsługuje automatyczne reguły, drukuje etykiety, synchronizuje stany. Jeśli jesteś sprzedawcą z jednym sklepem — Base jest dla Ciebie.
Ale operator fulfillmentu to nie sprzedawca. Operator to firma, która obsługuje innych sprzedawców — 5, 10, 20 klientów jednocześnie, każdy z własną konfiguracją, cennikiem, oczekiwaniami i statusem prawnym. I tutaj Base ma fundamentalne luki.
Nie jest to krytyka Base — to narzędzie doskonale robi to, do czego zostało zaprojektowane. Ale jeśli używasz go jako centrum zarządzania całym fulfillmentem, prędzej czy później natrafisz na każdą z poniższych ścian.
Luka 1: Multi-tenant — jeden account Base, wielu klientów
Problem
Base działa per konto. Jeden operator najczęściej ma jedno konto Base i wpina do niego konta klientów przez integracje marketplace’ów lub własne sklepy. Ale wszystkie te zamówienia mieszają się w jednej przestrzeni.
Nie ma natywnej koncepcji “klienta fulfillmentu” w Base. Nie możesz powiedzieć: “to są zamówienia klienta A, tamte — klienta B, i każdy widzi tylko swoje.”
Jak operatorzy radzą sobie dziś
Najczęściej: osobne konto Base per klient. Brzmi sensownie, dopóki nie masz 10 klientów — wtedy żonglujesz 10 logowaniami, 10 konfiguracjami i 10 abonamentami. Koszt: co najmniej 1 000-3 000 PLN/mc na same abonamentów, nie licząc czasu na zarządzanie.
Alternatywnie: jeden wspólny account Base z tagami jako separator klientów. Szybko staje się chaosem przy >5 klientach.
Jak to naprawić
Warstwa nad BL, która rozumie pojęcie “klient fulfillmentu”: izoluje jego zamówienia, stany, historię i uprawnienia. Każdy klient widzi tylko swoje dane.
Luka 2: Per-client pricing — brak rozliczania
Problem
Base nie ma wbudowanego mechanizmu rozliczeń między operatorem a klientem. Możesz wystawić fakturę przez zewnętrzny system, ale Base nie powie Ci: “klient X miał 23 palety przez 15 dni, 430 zamówień wychodzących, 18 zwrotów — oto rachunek.”
To, jak zbierane są dane do faktury, zależy w 100% od Ciebie. A ponieważ nie ma natywnego miejsca na ceny per klient — większość operatorów wraca do Excela.
Jak operatorzy radzą sobie dziś
Excel. Tagi + raporty CSV + ręczne przeliczanie. Lub własny skrypt na Base API (kosztowny w utrzymaniu). Szczegółowo opisaliśmy to w artykule 5 metod rozliczania fulfillment per klient w Base.
Jak to naprawić
System z natywnym cennikiem per klient: każdy klient ma własny zestaw stawek (magazynowanie, przyjęcia, wysyłki, zwroty, usługi dodatkowe), a system automatycznie nalicza na podstawie danych z BL.
Luka 3: Brak widoku dla klienta końcowego
Problem
Twój klient (sklep e-commerce) chce wiedzieć: ile ma towaru, gdzie są zamówienia, co wróciło jako zwrot. W Base możesz mu dać dostęp do swojego konta — ale wtedy widzi dane wszystkich Twoich klientów. To dyskwalifikujące.
Brak bezpiecznego, izolowanego widoku dla klienta końcowego to jeden z największych braków Base z perspektywy 3PL.
Jak operatorzy radzą sobie dziś
Wysyłanie raportów PDF mailem raz w tygodniu. Rozmowy telefoniczne na pytanie “ile mam towaru?”. Arkusze Google Sheets z ograniczonym dostępem. Żadne z tych rozwiązań nie skaluje się i nie buduje zaufania.
Jak to naprawić
Dedykowany portal klienta: chroniony dostępem, zsynchronizowany z Base, pokazujący tylko dane danego klienta. Opisaliśmy to szczegółowo w artykule Portal klienta dla fulfillmentu — czy ma sens?.
Luka 4: Awizacje — nadal przez maila
Problem
Klient ma dostawę jutro. Musi Cię powiadomić: kiedy przyjedzie TIR, ile palet, jakie SKU, numer CMR. W BL nie ma formularza awizacji. Nie ma systemu, który przyjmie tę informację, zapisze ją i przypisze do konkretnego klienta.
Efekt: awizacje lądują w mailach. Część trafia do spamu, część gubi się w wątku z innymi tematami, część wpada w sobotę kiedy nikt nie sprawdza. Magazyn dowiaduje się o dostawie ze spóźnieniem.
Jak operatorzy radzą sobie dziś
Formularz Google Forms (bezpłatny, ale brak integracji). Maile na dedykowany adres. Telefon. Żadne z tych rozwiązań nie synchronizuje się z resztą systemu.
Jak to naprawić
Awizacje jako część portalu klienta: klient wypełnia formularz (data, liczba palet, SKU, CMR), awizacja trafia do systemu z przypisaniem do klienta i daty, Twój magazyn widzi to w kalendarzu dostaw. Powiadomienia automatyczne.
Luka 5: Brak systemu ticketów per klient
Problem
Klient ma problem. Zamówienie wyszło z błędnym adresem. Towar uszkodzony. Nie zgadza mu się faktura. Pisze maila. Mail ląduje w ogólnej skrzynce support@. Ktoś odpowiada. Klient pyta ponownie. Mail gubi się w wątku z 20 innymi tematami.
Base ma funkcję notatek do zamówień, ale to nie jest system wsparcia. Nie ma historii per klient, SLA, priorytetu, statusu.
Jak operatorzy radzą sobie dziś
Maile. W lepszym przypadku: Freshdesk lub Zendesk (koszt: 200-500 PLN/mc), ale bez integracji z BL i danymi klienta fulfillmentu.
Jak to naprawić
Tickety zintegrowane z portalem klienta: klient otwiera ticket, widzi jego status, dostaje powiadomienie o odpowiedzi. Ty widzisz wszystkie tickety per klient z pełnym kontekstem (stany, historia zamówień, faktury).
Wniosek: warstwa nad Base
Żadna z tych luk nie jest “błędem” Base — Base po prostu nie jest zaprojektowana jako platforma multi-tenant dla operatorów fulfillmentu. To narzędzie dla sprzedawców.
Rozwiązanie to warstwa biznesowa nad BL, która zamyka wszystkie pięć luk jednocześnie:
| Luka | Rozwiązanie |
|---|---|
| Multi-tenant | Izolacja klientów w jednym systemie |
| Per-client pricing | Automatyczne rozliczenia per klient |
| Brak widoku klienta | Portal klienta white-label |
| Awizacje | Moduł awizacji z notyfikacjami |
| Tickety | System wsparcia per klient |
To właśnie jest v5v: warstwa biznesowa nad Base, która sprawia, że jako operator fulfillmentu możesz skupić się na operacjach, a nie administracji. Zobacz /cennik lub umów rozmowę żeby dowiedzieć się jak szybko możesz wdrożyć to u siebie.