Własny panel zamówień przy 5000+ zamówień miesięcznie: kiedy abonament przestaje się spinać

Zapytanie, które niedawno do nas trafiło, zaczynało się od listy rzeczy, których klient nie chce. Sprzedawca robiący 6–7 tysięcy zamówień miesięcznie poza szczytem sezonu szukał jednego panelu na trzy konta Allegro i jedno konto Erli, z szybkim nadawaniem paczek prosto z tej samej listy. Bez fakturowania, bez paragonów, bez magazynu, bez modułu cenowego. I z możliwie niskim kosztem utrzymania, bo gotowe platformy przy tej skali kosztują go już za dużo.

To jedno z lepiej postawionych zapytań, jakie dostajemy, i nie ze względu na skalę. Ktoś sam narysował granicę zakresu, zanim usiadł do rozmowy o pieniądzach. Takie projekty przewracają się właśnie na zakresie, nie na wolumenie.

Poniżej rozkładam ten scenariusz na części: rachunek po obu stronach, budowa panelu od środka, czego świadomie nie robi i kiedy odradzamy. Same koszty integratorów rozpisaliśmy osobno, w tekście o tym, co robić, gdy Baselinker drożeje.

TL;DR: Abonament integratora rośnie z liczbą zamówień, a koszt własnego panelu rośnie z jego zakresem. Przy kilku tysiącach zamówień miesięcznie i naprawdę wąskim zakresie (zamówienia z marketplace'ów, statusy obsługi, etykiety) rachunek potrafi się odwrócić. Warunkiem jest utrzymanie minimalizmu i zabezpieczenie się przed uzależnieniem od jednego wykonawcy.

Dwie różne krzywe kosztów

Koszt integratora rośnie z wolumenem. Koszt własnego panelu rośnie z zakresem. Na tym polega cała ta decyzja.

Integratory rozliczają się progowo od liczby obsłużonych zamówień. Sprzedajesz więcej, wchodzisz w wyższy próg i płacisz więcej za ten sam zestaw funkcji. Do tego pozycje spoza pierwszego rzędu cennika: dopłaty za kolejne konta marketplace, moduły włączane osobno, przekroczenia progu w listopadzie. Ta konstrukcja irytuje sprzedawców po kilku latach wzrostu, bo faktura rośnie razem ze sprzedażą, choć zakres użycia stoi w miejscu.

Własny panel ma odwrotny profil. Budowę płacisz raz, potem stałą kwotę niezależną od wolumenu: serwer, backupy, monitoring, opieka. Sześć i dwanaście tysięcy zamówień to na tej samej maszynie ta sama faktura. Rośnie za to inna oś: każdy nowy moduł i każdy nowy kanał sprzedaży jest osobnym projektem.

Jest jeszcze koszt, który w takich zestawieniach ginie: Twój czas. U integratora idzie na obejścia i arkusze pomocnicze, przy własnym panelu na projekt, testy i wdrożenie obsługi. Nie ma go na żadnej fakturze.

Jak policzyć punkt przecięcia u siebie

Nie podam tu kwot, bo każda byłaby zmyślona: cenniki integratorów są progowe i zmieniają się, a wycena panelu zależy od zakresu. Podam za to rachunek, który robimy z klientem na pierwszej rozmowie. Zajmuje kwadrans i zwykle rozstrzyga sprawę bez żadnej analizy.

Weź horyzont trzech lat. Krótszy zawsze wygrywa abonament, dłuższy to już wróżenie.

Zostajesz na integratorze: roczny koszt w obecnym progu razy trzy, plus skok progu, jeśli planujesz wzrost sprzedaży, plus dopłaty za dodatkowe konta i moduły, plus szczyt sezonu, plus wycenione godziny obejść.

Budujesz panel: koszt budowy, plus serwer i opieka razy trzydzieści sześć miesięcy, plus bufor na zmiany w API marketplace'ów (my zakładamy kilka dni pracy rocznie), plus okres równoległy, w którym płacisz jeszcze za stare rozwiązanie.

Jeśli druga strona wychodzi wyraźnie niżej, a zakres mieści się na jednej kartce, rozmowa o budowie ma sens. Jeśli różnica jest niewielka, zostań przy abonamencie: za kilkanaście procent oszczędności nie warto brać na siebie systemu, przez który przechodzą wszystkie zamówienia w firmie.

Najczęstszy błąd w tym rachunku to porównanie samego abonamentu z samym kosztem serwera, bez opieki. Oszczędność wygląda wtedy spektakularnie aż do pierwszej awarii.

Co dokładnie miałby robić ten panel

Zakres z opisywanego zapytania mieści się w pięciu punktach: pobieranie zamówień z trzech kont Allegro i jednego konta Erli do jednej listy, widok tej listy dla działu obsługi z sensownym wyszukiwaniem, własne statusy obsługi, nadanie przesyłki i wydruk etykiet dla wielu zamówień naraz, odesłanie numeru przesyłki i statusu z powrotem do marketplace'u.

Poza zakresem świadomie zostają faktury i paragony, magazyn, zarządzanie ofertami, ceny, wiadomości do kupujących, raporty zarządcze oraz hurt. Nie dlatego, że są niepotrzebne, tylko dlatego, że w tej firmie już gdzieś działają albo działać nie muszą.

Ta jedna kartka waży więcej niż wybór technologii. Zakres opisany w pięciu punktach da się zbudować, odebrać i utrzymać. Zakres opisany jako „coś w rodzaju Baselinkera, tylko nasze" skończy się gorszą kopią za wyższą cenę.

Architektura minimalnego panelu

Allegro: kolejka zdarzeń, nie odpytywanie listy

Allegro udostępnia oficjalne REST API i portal dla deweloperów. Rejestrujesz w nim własną aplikację, dostajesz identyfikator i sekret, a konta sprzedawcy autoryzujesz przez OAuth 2.0. Trzy konta to jedna aplikacja i trzy osobne autoryzacje, czyli trzy komplety tokenów do przechowania i cyklicznego odświeżania. Jest też środowisko testowe, w którym całość składasz przed produkcją.

Najważniejsza jest mechanika pobierania zamówień. Nie odpytujesz co minutę o listę wszystkich zamówień, bo tak przekroczysz limity zapytań i będziesz gubić zmiany. Allegro udostępnia kolejkę zdarzeń zamówień: strumień faktów w rodzaju „nowe zamówienie", „gotowe do realizacji", „kupujący anulował", „zmienił się status realizacji". Panel czyta ten strumień od miejsca, w którym skończył ostatnio, i zapisuje u siebie identyfikator ostatnio przetworzonego zdarzenia.

Wynikają z tego dwie decyzje, których nie da się pominąć. Kursor musi być trwale zapisany w bazie, a nie w pamięci procesu. I trzeba pamiętać, że zdarzenia są dostępne w oknie ostatnich 24 godzin: jeśli integracja stanie na dłużej, luki nie nadrobisz z kolejki i trzeba sięgnąć po zwykłą listę zamówień z zakresem dat. Dlatego do panelu wchodzi od razu alert, który krzyczy, gdy kursor przestaje się przesuwać. Bez niego o problemie dowiesz się od klientów.

W drugą stronę API pozwala ustawić status realizacji i dopiąć numer przesyłki, więc kupujący widzi tracking bez udziału człowieka. Zwroty i reklamacje mają osobne zasoby. Szerszy przegląd tego, co jeszcze da się tu zautomatyzować, jest w tekście o automatyzacji sprzedaży na Allegro.

Erli: sprawdź to, zanim ktokolwiek wyceni panel

Tu potrzebna jest szczerość zamiast pewności siebie. Erli nie ma publicznego portalu dla deweloperów pod adresami, pod którymi szuka się go odruchowo. Integracja istnieje, bo Erli jest obecne w gotowych integratorach, ale o zakres API i warunki dostępu pytasz bezpośrednio Erli. To pierwsza rzecz do zrobienia w projekcie, przed architekturą i przed wyceną.

Odpowiedź prowadzi do jednego z trzech scenariuszy. Zakres porównywalny z Allegro: Erli wchodzi do panelu tak samo. Zakres okrojony, na przykład odczyt zamówień bez odsyłania statusów: większość obsługi robisz w panelu, a wąski fragment zostaje w panelu Erli jako spisana procedura. Brak sensownej drogi integracji: zostaje import pliku albo zostawienie samego Erli u integratora na najniższym progu, bo jedno konto z małym wolumenem kosztuje ułamek pełnego abonamentu. Ten ostatni wariant bywa najrozsądniejszy.

Jedna kolejka i statusy obsługi

Zamówienia z czterech kont i dwóch platform muszą trafić do wspólnego modelu danych, inaczej panel będzie tylko czterema zakładkami obok siebie. Normalizujesz więc do jednej struktury: źródło i konto, numer u źródła, kupujący i adres, pozycje, metoda dostawy, status płatności, znaczniki czasu. Odpowiedzi z API warto zachować też w oryginalnej postaci, bo przy pierwszej rozbieżności to jedyny sposób, żeby ustalić, kto ma rację.

Na to nakładasz własne statusy obsługi i w tym siedzi cała wartość takiego panelu. Nie kopiuj statusów Allegro, bo one opisują transakcję, a nie Twoją pracę. Potrzebujesz krótkiej listy stanów z magazynu: do spakowania, spakowane, nadane, wstrzymane, problem. Pięć wystarcza w większości firm, a każdy dołożony ponad to zwiększa liczbę zamówień wiszących w stanie, którego nikt nie rozumie. Osobno trzymasz mapowanie tych statusów na statusy marketplace'ów, żeby jedno kliknięcie zamykało obie sprawy.

Zwrotów nie budujesz jako modułu z obsługą księgową. Wystarczy, że zgłoszenie pobrane z API ląduje w panelu jako sprawa ze statusem i osobą odpowiedzialną, obok zamówienia, którego dotyczy. Chodzi tylko o to, żeby zwrot przestał być mailem ginącym w skrzynce na dwa tygodnie.

Fizycznie to mniej, niż brzmi: baza danych, backend z kilkoma zadaniami w tle (czytanie zdarzeń, odświeżanie tokenów, nadawanie przesyłek), prosty interfejs webowy dla obsługi i jedna maszyna wirtualna z backupem. Bez klastra i bez mikroserwisów. Przez dostępne dziś drogi budowy takich wewnętrznych narzędzi przeszliśmy w tekście o aplikacji wewnętrznej zamiast Excela.

Nadawanie paczek: broker czy kurier bezpośrednio

Drugi filar panelu to wysyłka. Masz dwie drogi i przy tej skali warto rozważyć obie naraz.

Przy 5–7 tysiącach paczek miesięcznie masz zwykle siłę negocjacyjną na własną umowę u przewoźnika, który obsługuje większość wysyłek. Rozsądny wariant to więc hybryda: bezpośrednia integracja z tym jednym, broker jako jedno wejście do reszty. Panel wystawia jeden przycisk „nadaj", a wybór ścieżki dzieje się pod spodem, na podstawie metody dostawy z zamówienia.

API zwraca etykietę jako plik do druku: PDF na drukarkę laserową albo ZPL na termiczną. I tu jest rzecz, która przy tej skali decyduje o powodzeniu wdrożenia bardziej niż cokolwiek innego. Praca musi iść paczkami: zaznaczasz kilkadziesiąt zamówień, panel zamawia przesyłki, składa jeden plik do druku i wpisuje numery z powrotem do zamówień oraz do marketplace'u. Wzorzec „jedno kliknięcie równa się jedna etykieta" działa poprawnie i zabija dzień pracy przy trzystu paczkach.

Reszta to szczegóły, które wychodzą dopiero na produkcji: automaty paczkowe wybrane przez kupującego, przesyłki pobraniowe, gabaryty liczone z pozycji zamówienia, ponowne nadanie po nieudanym doręczeniu. Każdy z osobna drobiazg, razem spora część projektu.

„Panele zamówień, które budujemy, nie przewracają się od wolumenu. Przewracają się od zakresu. Pół roku po starcie ktoś prosi o fakturowanie, potem o stany magazynowe, a po roku firma utrzymuje własnego, gorszego Baselinkera za własne pieniądze. Najtrudniejsza część takiego projektu to nie kod, tylko pilnowanie listy rzeczy, których panel nie robi." — Mikołaj Brunka, założyciel NoCodeWork

Czego ten panel nie robi

Minimalizm nie jest tu oszczędnością na budowie. To sposób na utrzymanie kosztu opieki na poziomie, dla którego cała operacja miała sens. Każdy moduł, którego nie ma, to zestaw rzeczy, których nie musisz pilnować. Brak fakturowania zdejmuje z Ciebie numerację, korekty, stawki VAT, KSeF i noce, w których coś zmienia się w przepisach. Bez magazynu nie ma lokalizacji, rezerwacji ani inwentaryzacji. A bez modułu cenowego żaden automat nie zejdzie Ci poniżej marży o trzeciej w nocy.

Moduły dokłada się później i przez API, a nie przez rozbudowę panelu wszerz. Faktury wystawia system fakturowy wywołany z panelu, na przykład Fakturownia albo inFakt przez API. Stany magazynowe zostają tam, gdzie są dziś, a panel je tylko odczytuje. Ta granica jest najtańszą rzeczą w projekcie i jednocześnie tą, o którą najczęściej trzeba się spierać z własnym zespołem.

Uczciwie: razem z modułami tracisz gotowe integracje na kolejne kanały, aktualizacje robione za Ciebie i rynkową szybkość reakcji na zmiany u marketplace'ów. Podział ról między gotowym systemem sprzedażowym a warstwą integracyjną rozpisaliśmy w tekście Baselinker czy n8n w e-commerce.

Ryzyka, o których trzeba powiedzieć wprost

Marketplace'y zmieniają API. Allegro publikuje zmiany i wycofania z wyprzedzeniem, ale ktoś po Twojej stronie musi to czytać i wdrażać. U integratora ten koszt rozkłada się na tysiące klientów, u Ciebie jest w całości Twój. Lekarstwo: umowa na opiekę z określonym czasem reakcji i nazwiskiem osoby oraz stały punkt w kalendarzu na przegląd komunikatów dla deweloperów. Bez tego panel działa świetnie przez rok i przestaje w najgorszym możliwym tygodniu.

Sezon. Panel obsługujący 6 tysięcy zamówień w lutym musi przeżyć listopad przy kilkukrotnie większym ruchu. Test na realnym wolumenie przed sezonem i alerty na kolejkę zdarzeń to element odbioru projektu, nie luksus.

Pojedynczy wykonawca. Najpoważniejsze ryzyko tego modelu i traktujemy je poważnie także wtedy, gdy wykonawcą jesteśmy my. Zabezpieczenie ma cztery elementy: repozytorium kodu w Twojej organizacji, a nie u wykonawcy; serwer, domeny, konta chmurowe i klucze do API założone na dane Twojej firmy; dokumentacja jako warunek odbioru, czyli instrukcja uruchomienia środowiska od zera, opis integracji i procedura na awarię; umowa przenosząca majątkowe prawa autorskie i wprost dopuszczająca zlecenie zmian komuś innemu. Rozpisaliśmy to punkt po punkcie w tekście o tym, co musi zawierać umowa na automatyzację, a scenariusz awaryjny w instrukcji przejęcia systemu po poprzednim wykonawcy. Ten sam zestaw stosujemy przy customowym CRM-ie i każdym innym systemie szytym na miarę.

Przełączenie. Nie zaczynasz od wyłączenia dotychczasowego systemu. Przez pełny cykl, łącznie ze zwrotami i zamknięciem miesiąca, oba rozwiązania pracują równolegle: panel czyta te same zamówienia, obsługa działa po staremu, a Ty porównujesz liczby. Przełączasz się, gdy się zgadzają. Ten okres kosztuje podwójnie i musi być w budżecie od początku.

Historia. Zamówień sprzed wdrożenia zwykle nie migrujesz. Zostawiasz je w trybie odczytu i przez rok utrzymujesz najtańszy dostęp do starego systemu. Migracja historii potrafi kosztować więcej niż sam panel i prawie nigdy się nie zwraca.

Kiedy nie budować

• Za mała skala. Nasza praktyczna zasada: jeśli abonament integratora nie mieści się w pierwszej piątce kosztów operacyjnych, to nie jest problem do rozwiązywania kodem. Przy kilkuset zamówieniach miesięcznie ta rozmowa nie ma sensu ekonomicznego, niezależnie od tego, jak bardzo cennik irytuje.
• Wiele marketplace'ów, zwłaszcza zagranicznych. Amazon, eBay, Kaufland, zagraniczne odsłony Allegro. Każdy z własnym API i własnym tempem zmian. Tu integrator wygrywa zakresem integracji, nie ceną: u niego nowy kanał jest przełącznikiem, u Ciebie kolejnym projektem. Abonament rosnący z wolumenem to w tym scenariuszu uczciwa cena.
• Potrzebujesz modułów, które wycinasz. Jeśli w ciągu roku i tak dojdzie fakturowanie, magazyn i reguły cenowe, budujesz gorszą kopię gotowej platformy. Lepszym ruchem jest negocjacja cennika albo zmiana dostawcy.
• Nie ma właściciela po Twojej stronie. Ktoś musi być gospodarzem tego systemu: zgłaszać zmiany, testować przed sezonem, odbierać alerty. Bez tej osoby panel po roku staje się czarną skrzynką, której nikt nie rusza.
• Model biznesowy w ruchu. Jeśli właśnie wchodzisz w hurt, dropshipping albo sprzedaż zagraniczną, poczekaj. Panel budowany pod procesy, które za pół roku będą wyglądać inaczej, to najdroższy sposób na naukę.

FAQ

Od ilu zamówień miesięcznie własny panel zamówień ma sens?

Nie ma progu działającego dla wszystkich, bo decyduje relacja trzech rzeczy: wysokości abonamentu w Twoim progu, wąskości zakresu, którego naprawdę używasz, i liczby kanałów sprzedaży. Z naszej praktyki rozmowa robi się poważna dopiero przy kilku tysiącach zamówień miesięcznie, przy jednym lub dwóch marketplace'ach i przy zakresie mieszczącym się na jednej kartce. Przy kilkuset zamówieniach albo przy pięciu kanałach gotowy integrator wygrywa niemal zawsze.

Czy własny panel zamówień jest zgodny z regulaminem Allegro?

Tak. Allegro udostępnia oficjalne REST API oraz portal dla deweloperów, w którym rejestrujesz własną aplikację i autoryzujesz swoje konta sprzedawcy przez OAuth. Obowiązują limity zapytań i regulamin korzystania z API, więc integrację projektuje się pod te limity, na przykład czytając kolejkę zdarzeń zamiast odpytywać listę zamówień w pętli. Ryzykowny jest nie sam fakt integracji, tylko to, co przez nią robisz.

Co się stanie, gdy Allegro zmieni API?

Zmiany są zapowiadane z wyprzedzeniem i publikowane w komunikatach dla deweloperów, ale ktoś musi je przeczytać i wdrożyć u Ciebie. Przy własnym panelu ten obowiązek przechodzi na Ciebie i na firmę sprawującą opiekę, dlatego umowa serwisowa z czasem reakcji jest częścią kosztu, a nie dodatkiem. Zaplanuj kilka dni pracy rocznie na utrzymanie zgodności oraz monitoring, który wykryje problem szybciej niż klienci.

Czy taki panel obsłuży kilka kont Allegro naraz?

Tak, i to jeden z głównych powodów, dla których w ogóle się go buduje. Rejestrujesz jedną aplikację w portalu dla deweloperów, a każde konto sprzedawcy autoryzujesz osobno, przechowując dla niego własny komplet tokenów. Panel pokazuje zamówienia ze wszystkich kont na jednej liście, z oznaczeniem źródła, i pilnuje, żeby status oraz numer przesyłki wróciły na właściwe konto.

Czy da się zbudować taki panel bez programisty, na no-code?

Częściowo. Warstwę pobierania zamówień, odsyłania statusów i zamawiania przesyłek składa się w n8n, a listę i statusy obsługi da się postawić na gotowej bazie w rodzaju NocoDB czy Airtable. To dobry i tani sposób na sprawdzenie hipotezy przed większym projektem. Przy kilku tysiącach zamówień miesięcznie i pracy paczkami zwykle dochodzi się jednak do granicy wygody interfejsu i wtedy przepisuje się samą warstwę widoku, zostawiając automatyzacje tam, gdzie są.

Podsumowanie

Własny panel zamówień to zamiana kosztu rosnącego z wolumenem na koszt stały, okupiona przejęciem odpowiedzialności za system, przez który przechodzą wszystkie Twoje zamówienia. Przy kilku tysiącach zamówień miesięcznie, jednym lub dwóch marketplace'ach i wąskim zakresie ta zamiana potrafi się spinać. Przy pięciu kanałach sprzedaży i rosnącej liście modułów nie spina się prawie nigdy.

Jeśli decydujesz się na budowę, o wyniku przesądzą dwie rzeczy. Zakres, czyli lista funkcji, których panel nie ma, broniona także pół roku po starcie. I zabezpieczenie przed uzależnieniem od wykonawcy: repozytorium, konta i klucze na Twoje dane, dokumentacja jako warunek odbioru, umowa pozwalająca Ci odejść. Ustalone na początku kosztują niewiele, dokładane później bywają nie do odzyskania.

Zanim cokolwiek zbudujesz, przelicz opisany wyżej rachunek na trzy lata, na własnym cenniku i własnym wolumenie. Jeśli chcesz przejść przez niego z kimś, kto takie panele buduje i widział też te nieudane, umów bezpłatną konsultację. Powiemy wprost, jeśli przy Twojej skali sensowniejsze będzie zostanie na gotowej platformie i wynegocjowanie cennika.

Przeczytaj również

• Baselinker drożeje: alternatywy i rachunek kosztów integratora
• Kiedy gotowy CRM przestaje wystarczać: customowy CRM w praktyce
• Aplikacja wewnętrzna zamiast Excela: czym ją zbudować w 2026
• Automatyzacja sprzedaży na Allegro: co realnie się da zautomatyzować
• Fakturownia i inFakt przez API: faktury, które wystawiają się same