Zespół eCommerce po starcie: kto jest naprawdę potrzebny

Uruchomienie platformy nie kończy projektu, tylko go zaczyna. Pierwsze pytanie brzmi zwykle „kogo teraz zatrudnić” i jest to złe pytanie. Po starcie musisz mieć obsadzone cztery funkcje: utrzymanie techniczne z wyznaczonym dyżurem, właściciela danych produktowych, obsługę klienta z dostępem do zamówień i jedną osobę odpowiedzialną za konwersję. To funkcje, nie etaty. Przy 50 zamówieniach dziennie potrafi je pokryć dwoje ludzi plus partner techniczny. Przy 500 każda z nich wypełnia komuś cały dzień.

Funkcja, nie etat: cztery role, bez których platforma się sypie

Różnica między funkcją a etatem jest praktyczna, nie semantyczna. Funkcja to zbiór decyzji, które ktoś podejmuje samodzielnie i za które odpowiada. Etat to sposób opłacenia człowieka. Jedna osoba może trzymać trzy funkcje, jeśli starczy jej czasu i kompetencji. Żadna funkcja nie może za to wisieć na dwóch osobach naraz, bo wtedy nie należy do nikogo.

Utrzymanie techniczne i dyżur

Po starcie zawsze coś się psuje: integracja przestaje odpowiadać, płatność nie wraca do sklepu, po aktualizacji znika przycisk w koszyku. Pytanie nie brzmi, czy to się zdarzy, tylko kto odbiera telefon i w jakim czasie. Dyżur trzeba zaplanować przed pierwszą awarią, bo improwizowanie w trakcie kosztuje najwięcej.

Warto podpatrzeć zespoły utrzymujące duże systemy. W książce Google Site Reliability Engineering przyjęto twarde limity: maksymalnie dwa incydenty na dwunastogodzinny dyżur, przy czym praca czysto operacyjna nie może zająć inżynierowi więcej niż połowy czasu. Sens jest prosty: dyżur, który zjada cały tydzień, przestaje być dyżurem i staje się gaszeniem pożarów.

• Kto odbiera: imiennie wskazana osoba i zastępca, nie „ktoś z zespołu”.
• W jakim czasie: osobny czas reakcji dla awarii blokującej sprzedaż i dla usterki, która może poczekać do wtorku.
• Czym dysponuje: dostęp do produkcji oraz możliwość wdrożenia poprawki i cofnięcia jej bez czekania na czyjąkolwiek zgodę.
• Co potem: krótka notatka po incydencie, żeby ta sama przyczyna nie wracała co miesiąc.

Ten sam zestaw pytań rozstrzyga, jak sklep zachowa się w szczycie sprzedaży. Co pęka wtedy najpierw i w jakiej kolejności, rozłożyliśmy na czynniki w tekście o tym, co się psuje przy dziesięciokrotnym wzroście ruchu.

Właściciel danych produktowych

To rola najczęściej pomijana i najdroższa w skutkach. Ktoś musi odpowiadać za to, że karta produktu ma komplet atrybutów, poprawne kody EAN, aktualne ceny, spójne warianty i opisy w każdym języku, w którym sprzedajesz. Bez tego psuje się wszystko po kolei: wyszukiwarka w sklepie, filtry, feedy do kanałów, rekomendacje i to, jak Twój produkt streszczają systemy AI.

Do jakości katalogu doszły obowiązki regulacyjne. Unijne rozporządzenie o ogólnym bezpieczeństwie produktów (GPSR) obowiązuje od 13 grudnia 2024 roku i obejmuje także sprzedaż online. Informacje o producencie, identyfikacji produktu i ostrzeżeniach przestały być kwestią staranności, a stały się kwestią zgodności. Ktoś musi je utrzymywać przy każdej nowej dostawie.

Właściciel danych produktowych nie musi być od pierwszego dnia osobnym etatem. Musi być nazwiskiem. Jak ogarnąć to przy szerokim katalogu bez zatrudniania trzech copywriterów, opisaliśmy w tekście o opisach produktów tworzonych z AI.

Obsługa klienta, która widzi zamówienie

Po starcie większość zgłoszeń to pytania o status przesyłki, zwrot i zmianę adresu. Kluczowe nie jest to, ilu masz konsultantów, tylko czy widzą to samo, co system: status płatności, numer przesyłki, historię zmian zamówienia. Obsługa bez dostępu do danych tworzy drugą kolejkę pracy, bo każde zgłoszenie eskaluje do kogoś, kto ten dostęp ma.

Powtarzalne pytania da się zdjąć automatyzacją, ale dopiero wtedy, gdy proces jest opisany. Automatyzacja nieopisanego procesu przyspiesza tylko bałagan. Jak układamy to w praktyce, pokazaliśmy przy okazji automatycznej obsługi pytań o status zamówienia.

Jedna osoba odpowiedzialna za konwersję

Konwersja jest rolą, a nie tematem cotygodniowego spotkania. Jeśli za wynik odpowiada „marketing z IT”, nie odpowiada nikt: marketing tłumaczy się jakością ruchu, IT wydajnością, a koszyk dalej przecieka w tym samym miejscu. Ta osoba nie musi umieć programować. Musi umieć czytać lejek, stawiać hipotezy i mieć mandat, żeby zatrzymać wdrożenie, które psuje zakupy.

Do tej roli należy też pilnowanie, czy front po kolejnych zmianach nadal spełnia wymagania dostępności. Unijna dyrektywa o dostępności produktów i usług (EAA) jest stosowana od 28 czerwca 2025 roku i obejmuje handel elektroniczny, choć mikroprzedsiębiorstwa świadczące usługi są z tych obowiązków wyłączone. Wystarczy jeden dobrze zrobiony przegląd checkoutu, żeby zobaczyć, ile zostaje na stole przy okazji: listę punktów zebraliśmy w audycie porzuconych koszyków.

Skala zmienia zestaw ról bardziej niż branża

Uniwersalna lista stanowisk nie działa, bo ta sama funkcja przy różnej skali oznacza zupełnie inny nakład pracy. Wygodniejszym punktem wyjścia jest liczba zamówień dziennie i liczba kanałów sprzedaży. Poniższa tabela to nasz punkt startowy do rozmowy z klientem po wdrożeniu, a nie badanie rynku: traktuj ją jako rząd wielkości do skorygowania własnymi danymi.

Orientacyjny punkt wyjścia, nie badanie rynku pracy. Progi zamówień są umowne: przy drogim, skomplikowanym produkcie przesuwają się wyraźnie w dół.

Funkcje nie pojawiają się nagle wraz ze wzrostem. One odklejają się od osób, które dotąd robiły wszystko naraz. Właściciel sklepu przy 50 zamówieniach dziennie sam pilnuje konwersji i sam poprawia opisy. Przy 200 nie ma już na to czasu, ale zwykle nadal tego nie oddaje, bo „zawsze tak było”. Dokładnie w tym miejscu najciszej wykrwawia się marża.

Role, które zależą od modelu sprzedaży

Cztery funkcje opisane wyżej są wspólne dla każdego sklepu. Reszta zależy od tego, jak sprzedajesz, a nie od tego, jak duży masz zespół.

B2B: właściciel procesu zamówienia, nie administrator sklepu

W B2B wartość siedzi w cennikach per klient, limitach kupieckich, akceptacjach i dokumentach sprzedaży. To wszystko żyje w ERP, więc kluczowa rola po starcie to ktoś, kto rozumie proces zamówienia po obu stronach i potrafi rozstrzygnąć, gdzie jest źródło prawdy. Zatrudnienie w tym miejscu programisty zamiast właściciela procesu kończy się integracją, która robi dokładnie to, co ktoś kiedyś powiedział na jednym spotkaniu.

Dochodzi do tego rytm zmian regulacyjnych. Obowiązkowy KSeF ruszył etapami w 2026 roku: od 1 lutego dla największych podatników i od 1 kwietnia dla pozostałych. Dostawca oprogramowania dowiezie funkcję, ale nie weźmie odpowiedzialności za Twój proces, więc ktoś po Twojej stronie musi pilnować takich terminów. Jak wygląda dobrze zrobiona wymiana danych, rozłożyliśmy na części w tekście o integracji sklepu B2B z ERP.

Marketplace: kompetencja kanałowa, zwykle kupowana

Sprzedaż na Amazonie, Allegro czy Kauflandzie to osobny zawód: inne zasady listingów, inna reklama, inne przyczyny blokad konta. Przy jednym czy dwóch kanałach rzadko wypełnia to etat, a pomyłka kosztuje szybciej niż we własnym sklepie. Dlatego częściej opłaca się kupić tę kompetencję na zewnątrz, na przykład w obsłudze kont marketplace prowadzonej przez siostrzaną agencję Amazonway, i zostawić u siebie jedną osobę, która pilnuje asortymentu, cen i marży w kanałach.

Ekspansja zagraniczna: język jest najmniejszym problemem

Nowy rynek dokłada obowiązki, nie tylko tłumaczenia. Lokalne metody płatności, zwroty, obsługa w danym języku, terminy dostaw i zgodność z lokalnymi wymogami to praca, która nie znika po uruchomieniu wersji językowej. Rola, której tu najczęściej brakuje, to nie tłumacz, tylko właściciel rynku: ktoś, kto odpowiada za wynik jednego kraju i ma prawo powiedzieć, że drugi trzeba odłożyć.

Co kupić na zewnątrz, a co trzymać u siebie

Podział nie przebiega wzdłuż linii „techniczne kontra biznesowe”. Przebiega wzdłuż dwóch pytań: jak często potrzebujesz danej kompetencji i ile kosztuje utrzymanie jej w formie. Kompetencja używana raz na kwartał traci aktualność szybciej, niż zdążysz z niej skorzystać.

• Zwykle warto kupić: infrastrukturę i bezpieczeństwo, dyżur poza godzinami pracy, wydajność, wdrożenia integracji, głębszy rozwój platformy, rzadkie specjalizacje kanałowe.
• Zwykle warto mieć u siebie: wiedzę o asortymencie i marży, kontakt z klientem, decyzje cenowe, priorytety rozwoju i właścicielstwo danych.
• Prawie nigdy nie warto dzielić: odpowiedzialności za konwersję i za dane produktowe. Rozproszona odpowiedzialność za wynik oznacza brak odpowiedzialności.

Kiedy własny zespół jest po prostu lepszy

Będziemy uczciwi wbrew własnemu interesowi: są sytuacje, w których wewnętrzny zespół wygrywa z każdym partnerem zewnętrznym, także z nami.

• Wysoka częstotliwość zmian: gdy wdrażasz coś na produkcję kilka razy w tygodniu, koszt komunikacji z zewnętrznym zespołem zjada oszczędność.
• Unikalna domena: produkty na wymiar, konfiguratory, reguły rabatowe, których nie da się opisać w dokumencie bez utraty połowy sensu.
• Skala, która wypełnia etat: jeśli praca jest ciągła i przewidywalna, etat wychodzi taniej niż kupowanie tych samych godzin.
• Platforma jako przewaga, nie koszt: gdy sklep jest produktem, a nie narzędziem operacyjnym, własność zespołu ma wartość strategiczną.

Model rozliczenia też nie jest obojętny, bo inaczej planuje się pracę przy stałym zakresie, a inaczej przy rozliczeniu godzinowym. Plusy i minusy obu podejść zestawiliśmy w tekście o stałym zakresie kontra godzinach.

Jak nie uzależnić się od jednego dostawcy

Uzależnienie od dostawcy rzadko bierze się z outsourcingu jako takiego. Bierze się z braku dostępów i braku dokumentacji. Test jest brutalnie prosty: gdyby Twój partner techniczny zniknął jutro, ile dni zajmie innemu zespołowi przejęcie systemu? Jeśli odpowiedź brzmi „nie wiem”, masz problem niezależnie od tego, jak dobrze układa się współpraca.

• Kod: repozytorium należy do Ciebie, a partner ma do niego dostęp, nie odwrotnie.
• Dostępy: konta chmurowe, domena, bramka płatności i analityka założone na Twoją firmę, z Twoim administratorem.
• Dokumentacja: architektura, opis integracji i runbooki awaryjne utrzymywane razem z kodem, a nie pisane dopiero przy rozstaniu.
• Technologie: rozwiązania standardowe zamiast prywatnego frameworka dostawcy, którego nikt inny nie zna.
• Umowa: zapisane wyjście, okres przekazania i obowiązek transferu wiedzy, ustalone na starcie, kiedy wszyscy się jeszcze lubią.

To jest też uczciwy kontekst dla tego, co robimy sami. Seedlight buduje platformy frameworkiem BEAM i zostaje po starcie w etapie Maintenance and Growth, ale sensem tego etapu jest zdjęcie z Ciebie dyżuru i utrzymania, a nie przejęcie kontroli nad Twoim systemem. Jeśli partner nie chce oddać dostępów albo trzyma dokumentację wyłącznie u siebie, to nie jest kwestia stylu pracy. To sygnał ostrzegawczy, niezależnie od tego, czyj jest szyld.

Cztery błędy rekrutacyjne, które widać po kilku miesiącach

Po starcie firmy popełniają zaskakująco powtarzalne błędy. Wszystkie wynikają z jednego: zatrudnia się pod narzędzie albo pod poczucie braku, zamiast pod decyzję, która nie ma właściciela.

• Programista zamiast właściciela procesu: firma zatrudnia developera, bo „coś trzeba poprawiać”, ale nikt nie umie powiedzieć mu co i po co. Efektem jest droga osoba wykonująca cudze zlecenia bez priorytetów.
• Brak właściciela danych produktowych: katalog jest niczyj, więc pogarsza się miesiąc po miesiącu, a koszt widać dopiero w wyszukiwarce sklepu i w feedach do kanałów.
• Rozmyta odpowiedzialność za konwersję: odpowiadają wszyscy, czyli nikt, i nikt nie ma mandatu, żeby zatrzymać wdrożenie psujące koszyk.
• Zespół budowany na zapas: etaty tworzone pod plan sprzedaży, który jeszcze się nie wydarzył, zamiast pod pracę, która już regularnie występuje.

Najkosztowniejszy jest pierwszy, bo wygląda na najbardziej słuszny. Własny developer bez właściciela procesu i bez backlogu spędza pierwszy kwartał na poznawaniu systemu, a drugi na zadaniach, które partner zamknąłby w kilka dni. Kolejność jest odwrotna: najpierw nazwij decyzje i procesy bez właściciela, potem policz, ile godzin tygodniowo naprawdę zajmują, i dopiero wtedy zdecyduj, czy to etat, czy pozycja w abonamencie.

Co zrobić w pierwszym miesiącu po starcie

Zamiast planu zatrudnień na rok zrób ćwiczenie mieszczące się na jednej kartce.

• Wypisz funkcje: utrzymanie i dyżur, dane produktowe, obsługa klienta, konwersja, integracje, kanały dodatkowe.
• Przypisz nazwiska: jedno nazwisko na funkcję, plus zastępca dla dyżuru.
• Ustal czasy reakcji: osobno dla awarii blokującej sprzedaż i dla usterki, która może poczekać.
• Policz godziny: przez miesiąc notuj realny czas poświęcony każdej funkcji, zanim przeliczysz to na etaty.
• Zdecyduj, co kupujesz: na podstawie tych godzin, nie na podstawie przeczucia.