Produktyzacja usług: jak z projektu na miarę zrobić pakiet
Produktyzacja usług w pięciu krokach: wybór usługi, zakres, wyłączenia, cena bez historii godzin i test pakietu na trzech klientach, z przykładem audytu.
Jak zamienić usługę robioną na miarę w pakiet w stałej cenie? W pięciu krokach. Wybierz usługę, którą zrobiłeś już kilka razy z podobnym zakresem. Zapisz jej stały zakres, rezultat i termin. Zdecyduj, co zostaje na miarę i jak to wyceniasz osobno, i zapisz to jako listę wyłączeń. Policz cenę z czasu ostatnich realizacji, a jeśli nie masz rzetelnych godzin, z rozpisanych kroków z zapasem. Na koniec sprawdź pakiet na trzech kolejnych klientach i dopiero po nich popraw zakres i cenę. Cenę liczysz po zakresie i wyłączeniach, bo przy stałej cenie błąd w zakresie kosztuje ciebie, a nie klienta.
W tym wpisie przedstawię te kroki, przykład pakietu zbudowanego z audytu robionego dotąd na miarę i sytuacje, w których pakiet nie ma sensu.
Czym jest produktyzacja usług
Produktyzacja usług to zamiana usługi wycenianej osobno dla każdego klienta w pakiet, który ma stały zakres, rezultat, termin i cenę, ustalone przed rozmową z klientem. Kolejny klient dostaje ten sam pakiet. Zmieniają się dane wejściowe, czyli jego firma i jego materiały, a nie lista prac ani cena.
Przy stałej cenie ryzyko błędnego zakresu bierzesz na siebie
Promethean Research, firma badawcza, która ankietuje agencje cyfrowe (głównie z Ameryki Północnej), w raporcie z 2025 roku opisuje stałą cenę jako model, w którym agencja szacuje koszt projektu i dolicza marżę. Klient dostaje pewną kwotę do budżetu, a sprawna agencja może zarobić więcej niż przy stawce godzinowej. Większość ryzyka leży jednak po stronie agencji, bo błędy w określeniu zakresu łatwo zjadają marżę. Dlatego według autorów raportu ten model najlepiej pasuje do przewidywalnego, dobrze określonego zakresu. Przy rozliczeniu godzinowym jest odwrotnie: ryzyko ponosi głównie klient, a model pasuje do zakresu, którego nie da się przewidzieć (raport, s. 34).
David Maister pisał w 2002 roku, że wielu klientów chce stałej ceny, bo martwi się o wydajność firm, które zatrudnia, i chce kontrolować budżet („Responding to Fee Pressure”). Moim zdaniem z opisu Promethean wynika kolejność pracy: do pakietu nadaje się usługa, której zakres znasz już z kilku realizacji.
Pięć kroków od usługi na miarę do pakietu
- Wybierz usługę. Wejście: lista projektów z ostatnich 12–24 miesięcy. Wyjście: jedna usługa i lista jej realizacji. Dobra kandydatka ma co najmniej trzy realizacje o podobnym zakresie, kroki, które potrafisz spisać przed startem, klientów, którzy na początku pytają o to samo, i rezultat, który klient może sprawdzić.
- Zapisz zakres, rezultat i termin. Wejście: realizacje z kroku 1. Wyjście: lista prac, rezultat i termin. Do zakresu bierzesz tylko prace, które były w każdej realizacji. Te, które pojawiły się tylko u niektórych klientów, odkładasz do kroku 3. Jak zapisać zakres tak, żeby cały zespół mówił o usłudze to samo, opisałem we wpisie jak opisać usługę.
- Zdecyduj, co zostaje na miarę. Wejście: prace odłożone w kroku 2. Wyjście: lista wyłączeń i sposób wyceny każdego z nich: osobna usługa, dopłata za element albo odmowa z poleceniem kogoś innego. Wyłączenia piszesz słowami klienta, przy rzeczach, o które zapyta: nie „integracje poza zakresem”, tylko „podłączenie sklepu do systemu magazynowego wyceniamy osobno”. Maister pisał, że przy stałej cenie firma musi bardzo precyzyjnie zapisać, co jest, a co nie jest w zakresie.
- Policz cenę. Wejście: zakres z kroku 2, wyłączenia z kroku 3 i czas ostatnich realizacji. Wyjście: cena i warunek jej zmiany. Jeśli masz godziny z projektów, bierzesz czas, jaki w ostatnich realizacjach zajęły prace z zakresu (bez prac z listy wyłączeń z kroku 3), mnożysz przez koszt godziny zespołu (wynagrodzenia z narzutami, nie stawka sprzedażowa) i doliczasz marżę, tak jak w opisie stałej ceny u Promethean, a do tego zapas na to, czego nie przewidziałeś. Jeśli godzin nie masz albo są niepełne, rozpisz zakres na kroki, oszacuj każdy z osobą, która go wykonywała, i dolicz zapas tak samo. Wysokość marży i zapasu zależy od twojej firmy. Zapas zmniejszasz, gdy notatki z kroku 5 pokażą, ile praca trwa naprawdę. Przed pierwszą sprzedażą zapisz też, co po teście z kroku 5 zmieni cenę, razem z progiem, na przykład: „jeśli co najmniej połowa rozmów o pakiecie w czasie testu skończy się odmową, w której klient wskazał cenę, a nie zakres, obniżamy cenę”. Odmowa z powodu zakresu oznacza zmianę pakietu, nie ceny.
- Sprawdź pakiet na trzech klientach. Wejście: pakiet z kroków 2–4. Wyjście: poprawiony zakres, cena i wyłączenia. Przy pierwszych trzech realizacjach notujesz, ile czasu zajęła każda, co klient chciał dodać i co zrobiłeś poza zakresem. Przy każdej rozmowie o pakiecie w tym czasie notujesz, czy skończyła się zakupem, a jeśli nie, czy klient wskazał cenę, czy zakres. Pakiet możesz pokazać na stronie już w czasie testu jako nową usługę. Zakres, wyłączenia i cenę (według warunku z kroku 4) zmieniasz po trzecim kliencie, na podstawie tych notatek. Jeśli trzeci klient się nie pojawia, ustal z góry, po ilu rozmowach o pakiecie oceniasz warunek z kroku 4 bez czekania na trzecią sprzedaż. Trzech klientów to moim zdaniem minimum: jeden może być wyjątkiem, a na dziesięciu mała firma czekałaby wiele miesięcy.
Maister radził też, żeby przyjrzeć się, jak firma wykonuje projekty, i szukać sposobów obniżenia ich kosztu: w obsadzie, szkoleniu, metodyce i narzędziach. Przy stałej cenie godzina zaoszczędzona na powtarzalnej pracy zostaje w marży, więc notatki z kroku 5 służą też do tego.
Przykład: audyt wydajności aplikacji jako pakiet
To ilustracja, nie prawdziwa firma: weźmy software house, który w ostatnich dwóch latach co najmniej trzy razy robił audyt wydajności aplikacji webowej. Za każdym razem wycenił go w godzinach. Część prac powtarzała się we wszystkich audytach, a część była tylko u niektórych klientów.
| Pole | Na miarę (dotąd) | Pakiet (ilustracja) |
|---|---|---|
| Zakres | ustalany w rozmowie, za każdym razem trochę inny | pomiar szybkości do pięciu ekranów wskazanych przez klienta, przegląd zapytań do bazy i konfiguracji serwera, raport, jedno spotkanie z zespołem klienta |
| Rezultat | raport w różnej formie | lista poprawek według priorytetu, z szacunkiem pracy dla zespołu klienta |
| Termin | „zależy od zakresu” | dwa tygodnie od otrzymania dostępów |
| Cena | godziny razy stawka, znana po projekcie | stała: średni czas prac z zakresu w ostatnich audytach razy koszt godziny zespołu, plus marża i zapas |
| Warunek zmiany ceny | brak | po teście: co najmniej połowa rozmów o pakiecie zakończona odmową z powodu ceny, a nie zakresu |
| Wyłączenia | brak listy | „wdrożenie poprawek w kodzie wyceniamy osobno po audycie”, „przebudowę architektury aplikacji robimy jako osobny projekt na miarę”, „aplikacji na iOS i Androida nie audytujemy, polecamy firmę, która się nimi zajmuje” |
Pierwsze trzy audyty w pakiecie software house prowadzi z notatkami czasu i próśb klientów, a przy rozmowach o pakiecie zapisuje powody odmów. Jeśli każdy z trzech klientów poprosi też o wdrożenie poprawek, firma rozważy dodanie najczęstszych poprawek do zakresu z nową ceną.
Kiedy pakiet nie ma sensu
Pakiet nie pomoże, gdy:
- zakresu nie da się przewidzieć, na przykład przy rozwoju produktu klienta bez specyfikacji; według Promethean do takiej pracy pasuje rozliczenie godzinowe, w którym ryzyko ponosi głównie klient,
- nie masz trzech podobnych realizacji, więc nie wiesz, które prace się powtarzają,
- chcesz zamienić całą ofertę na pakiety naraz.
W badaniu Promethean opublikowanym w 2025 roku większość agencji łączyła modele cenowe. Najczęstsze połączenie to godziny, stała cena i abonament (28% agencji). Tylko na stałej cenie opierało się 4% agencji, tylko na abonamencie również 4%, a tylko na godzinach 5% (raport, s. 35). Moim zdaniem pakiet jest więc jednym z modeli obok rozliczeń godzinowych i abonamentu, a nie ich następcą.
Najczęstsze pytania
Czym pakiet różni się od abonamentu?
Pakiet ma stały zakres, rezultat i koniec. Abonament to stała opłata miesięczna za pracę albo dostępność, która trwa, dopóki klient jej nie wypowie. Po zakończeniu pakietu możesz zaproponować abonament na dalszą pracę.
Czy podawać cenę pakietu na stronie?
Moim zdaniem tak, także w czasie testu: pewna kwota do budżetu to jeden z powodów, dla których klienci wybierają stałą cenę, a cena na stronie pozwala klientowi ocenić pakiet przed pierwszą rozmową. Po teście aktualizujesz ją razem z zakresem.
Co zrobić, gdy klient chce „trochę więcej”?
Pokaż listę wyłączeń i wyceń dodatek osobno, tak jak ustaliłeś w kroku 3. Jeśli to samo „trochę więcej” powtarza się u kolejnych klientów, rozważ dodanie go do zakresu przy poprawkach w kroku 5.
Podsumowanie
Jeśli każdą ofertę piszesz od zera, zalecam zacząć od listy projektów z ostatnich 12–24 miesięcy i wybrać jedną usługę z co najmniej trzema podobnymi realizacjami. Zapisz jej zakres z wyłączeniami, policz cenę i sprawdź pakiet na trzech kolejnych klientach. Sami zamieniliśmy szerokie wdrożenie na mały, powtarzalny pakiet w Claude Code (Claude Code Team Start), a to, co do niego nie weszło, wyceniamy osobno jako wdrożenie custom. Pakiet jest nowy, więc tak jak w kroku 5 pokazujemy go na stronie od razu, a zakres i cenę poprawimy po pierwszych realizacjach.
Każdą metodę z tego bloga możesz też uruchomić jako skill w otwartym repo B2BForce. Zobacz, co jest w repo