O czym jest ten film
- Jak wyceniać automatyzacje AL na podstawie wartości dla klienta, a nie liczby przepracowanych godzin.
- Rozbiór jednego realnego projektu (agent umawiający spotkania) — każda liczba i skąd się wzięła.
- „Złota reguła” 10-krotnego zwrotu z inwestycji w pierwszym roku i jak ją komunikować.
- Czym naprawdę jest abonament utrzymaniowy (maintenance) i czym się różni od dodawania nowych funkcji.
- Dlaczego rozliczanie godzinowe premiuje wolniejszą pracę i kiedy mimo to jest w porządku.
- Trójka pojęć: koszt, wartość, cena — i zasada „to cena uzasadnia koszt, a nie odwrotnie”.
- Framework pytań na rozmowie odkrywającej: „dlaczego to / dlaczego teraz / dlaczego ja” oraz metoda LRP.
- Jak wyciągnąć od klienta liczby, gdy nie chce ich podać — pytania szacujące i „proxy”.
- Pakiety cenowe w trzech wariantach i psychologia „środkowej opcji”.
- Etapowanie płatności wokół obiektywnych kamieni milowych, obsługa scope creepu i kwestia kosztów API/tokenów.
Redakcyjne tłumaczenie
Wstęp: dużo sprzedaży, dużo błędów w wycenie
Sprzedałem ponad sto systemów automatyzacji opartych na AI — i wiele z nich wyceniłem źle. Zaniżałem stawki, źle szacowałem zakres, rzucałem przypadkowe liczby, których nie potrafiłem obronić, gdy ktoś pytał wprost: „Skąd wziąłeś tę kwotę?”. W tym materiale opowiem wszystko, co wiem o wycenie rozwiązań AI. Przeprowadzę cię przez jeden realny projekt, który sprzedałem — każdą pojedynczą liczbę — a na koniec będziesz umiał wziąć dowolny projekt, zamienić liczby samego klienta w cenę, którą da się obronić, i pobierać płatność etapami, tak żeby nigdy nie nieść na sobie więcej niż jakieś trzydzieści dni nieopłaconej pracy.
Nazywam się Nate. Uczyłem setki tysięcy osób, jak budować agentów AI i jak wdrażać ich w firmach. Wyskalowałem własną agencję do ponad 100 tysięcy dolarów miesięcznie, a potem ją sprzedałem. Doszliśmy do momentu, w którym minimalne wejście we współpracę z nami to był abonament 20 tysięcy dolarów miesięcznie. Zakładam, że właśnie w takim miejscu wielu z was chce się kiedyś znaleźć.
Przykład: agent umawiający spotkania
Ten przykład to agent do umawiania spotkań (appointment setting). Firma miała pracowników, którzy ręcznie ustawiali te spotkania — mniej więcej dwadzieścia leadów tygodniowo, każdy zabierał człowiekowi około godziny. Ci pracownicy kosztowali firmę jakieś 40 dolarów za godzinę „all in” (ze wszystkimi kosztami). Dwadzieścia godzin tygodniowo po 40 dolarów to około 800 dolarów tygodniowo. Pomnóż to przez 52 tygodnie w roku i wychodzi 41 600 dolarów rocznie.
Zanim powiedziałem klientowi cokolwiek o cenie, przeprowadziłem go przez całe rozwiązanie: jak agent będzie działał, jak wygląda testowanie, jak zmieni się jego szybkość reakcji na leada (speed to lead) i jakość leadów. Musiałem też zadać mnóstwo pytań w ramach tego, co nazywamy fazą odkrywania (discovery). Niektórzy klienci chcą rozmawiać o cenie od razu, ale uczciwa odpowiedź brzmi: żeby dać ci trafny orientacyjny szacunek, naprawdę muszę głębiej zrozumieć złożoność systemu i to, jak będzie wyglądał, kiedy zostanie w pełni zintegrowany z waszymi realnymi procesami.
Potem wyceniłem sam build na jakieś 13% tej rocznej kwoty, co dało 5500 dolarów. Firma płaciłaby więc 5500 dolarów za system, który w ciągu roku miał jej oddać 41 600 dolarów — czyli mniej więcej 7,5-krotność początkowej inwestycji.
Złota reguła: pokaż dziesięciokrotny zwrot
Zwykle mówię, że złota reguła brzmi: trzeba umieć pokazać klientowi, że jego inwestycja zwróci się dziesięciokrotnie w ciągu roku, bo taka matematyka bardzo utrudnia powiedzenie „nie”. W tym konkretnym przykładzie te brakujące 2,5-krotności (do pełnej dziesiątki) tłumaczyłem tak: obecny punkt wyjścia to około 20 leadów tygodniowo, ale w miarę jak firma odzyska czas dzięki systemowi i cały proces stanie się płynniejszy, ta bazowa liczba leadów prawdopodobnie zacznie rosnąć — do 21, potem 23, potem 27. I to właśnie tam zarabiamy im jeszcze więcej.
Oczywiście coś takiego to projekcja i nie można wejść i powiedzieć, że się to gwarantuje. Uważaj więc z jakimikolwiek gwarancjami i wiązaniem przychodu z konkretnymi wynikami. Ogólna idea jest jednak taka, że im więcej system jest używany, tym bardziej firma rośnie, co z kolei jeszcze bardziej wykorzystuje system. Tworzy się fajny efekt koła zamachowego (flywheel).
Utrzymanie (maintenance) to nie nowe funkcje
Na wierzchu builda ustawiliśmy standardowy plan utrzymaniowy — 400 dolarów miesięcznie. Chcę jasno powiedzieć, czym to jest, bo wiele osób źle rozumie słowo „maintenance”. Te 400 dolarów miesięcznie nie jest po to, żebym co miesiąc doklejał nowe funkcje. To jest gwarancja, że build dalej robi to, na co się umówiliśmy. Jeśli coś się zepsuje, zmieni się API, wyjdzie nowy model albo pojawią się dziwne przypadki brzegowe wymagające drobnej korekty, żeby system dalej spełniał zakres — to jest po mojej stronie i pokrywa to abonament klienta. Ale nowa funkcjonalność to zupełnie osobna rozmowa.
Przy abonamentach utrzymaniowych trzymam liczby bardzo prosto i jednakowo we wszystkich projektach. Na tym etapie kariery nasz pakiet utrzymaniowy to 400 dolarów miesięcznie. Musisz jednak uważać: jeśli dostarczasz system za, powiedzmy, 30 tysięcy dolarów i jego utrzymanie kosztuje ciebie oraz twój zespół więcej niż 400 dolarów miesięcznie — czyli tracisz na tym pakiecie — to oczywiście nie możesz tyle liczyć. Przy dobrze zaprojektowanych i dobrze zbudowanych automatyzacjach utrzymanie nie powinno być zbyt czasochłonne. Jeszcze raz: jest duża różnica między utrzymywaniem a dodawaniem drobnych ulepszeń i nowej funkcjonalności.
Błąd: brak pomiaru stanu „po”
Duży błąd, który popełniłem w tym projekcie: kiedy byłem już na produkcji, powinienem był wrócić i zmierzyć, ile ten system był naprawdę wart. Nie zrobiłem tego. Nie miałem stanu „po”, nie miałem liczby opisującej transformację. Zemściło się to przy następnej rozmowie, gdy próbowałem zdobyć więcej zleceń.
Dlatego upewnij się, że na starcie łapiesz punkt wyjścia — w tym przypadku około 20 leadów tygodniowo i czas reakcji na leada — a potem robisz follow-up po miesiącu, po dwóch, po trzech i udowadniasz klientowi, że te liczby idą w kierunku, którego firma chce, dzięki twojemu systemowi. Może to trochę przypominać chwalenie się, ale nie jest: jeśli nie zaświecisz reflektorem na te liczby, to nawet gdy twoje automatyzacje naprawdę pomagają firmie, właściciel może tego nie odczuć i nie docenić. To ty musisz te rzeczy wydobywać na wierzch.
Dlaczego nie rozliczać się godzinowo
Oczywiste pytanie: dlaczego po prostu nie rozliczać się od godziny? Krótki ukłon w stronę Jonathana Starka — specjalisty od wyceny, który wystąpił na AI’s Live i powiedział na ten temat kilka świetnych rzeczy. (Informacja dodatkowa: Jonathan Stark to konsultant znany z propagowania „value pricing” i odejścia od stawek godzinowych.)
Problem z rozliczeniem godzinowym jest taki, że opłaca ci się być wolnym. Wyobraź sobie dwie osoby w zespole rozliczane po tyle samo — 150 dolarów za godzinę: twój najlepszy programista i najwolniejszy. Wpada nowa funkcja; najlepszy załatwia ją w jeden dzień, więc fakturujesz jeden dzień. Wolny robi to w trzy dni, więc fakturujesz trzy dni. Właśnie zarobiłeś trzy razy więcej na gorszym, wolniejszym pracowniku. A jeśli twój najlepszy przyspieszy, zarobisz na nim mniej. Czyli bycie dobrym w robocie faktycznie obcina twój dochód. Chodzi o bodźce. Czy chciałbyś zatrudnić kogoś, kto ma bodziec, żeby pracować wolniej i wyciągnąć z ciebie więcej? Raczej nie.
Przenieś to do roku 2026. Stajesz się naprawdę dobry w narzędziu takim jak Claude Code czy cokolwiek, czego używasz, i robisz w jedno popołudnie coś, co kiedyś zajmowało tydzień. (Informacja dodatkowa: w oryginale „cloud code” — to przejęzyczenie transkrypcji, chodzi o Claude Code, narzędzie do programowania z AI.) Przy rozliczeniu godzinowym to popołudnie właśnie ścięło twój dochód.
Nie mówię, że godzinowo nigdy nie wolno. Przy pierwszych dwóch–trzech projektach, gdy nie masz jeszcze na co wskazać, nie masz dowodów, rozliczenie godzinowe jest bezpieczniejszą prośbą — łatwiejszą dla właściciela firmy i dobrym punktem startu. Może 100 dolarów za godzinę. Ale potem przestań rozliczać się godzinowo.
Trzy pojęcia: koszt, wartość, cena
Skoro nie wyceniasz od godzin, to od czego? Trzeba rozdzielić trzy słowa: koszt, wartość i cena. Koszt to podłoga — liczba, poniżej której byś odszedł. Wartość to sufit — najwyższa kwota, ile całe to przedsięwzięcie jest w ogóle warte dla firmy. Cena to dowolna liczba pomiędzy tymi dwiema, na której się umówicie.
Przy buildach AI ta przepaść jest ogromna, bo cokolwiek kosztowało cię zbudowanie i uodpornienie systemu, ich sufit jest wyżej. I zapamiętaj: koszt nie uzasadnia ceny — to cena uzasadnia koszt.
Jonathan podał świetny przykład ogrodnika. Wyobraź sobie, że kosi ci trawnik co tydzień za 100 dolarów. Pewnego tygodnia zjawia się, robi dokładnie tę samą robotę na tym samym trawniku i mówi, że teraz jest 200 dolarów, bo kupił nową, ładną ciężarówkę i jego koszty wzrosły. Tak to nie działa. Nikt tego nie akceptuje. Koszt nie uzasadnia ceny. To cena uzasadnia koszt.
Sufit klienta i jedna rozmowa, żeby go znaleźć
Sufit klienta to liczba, od której naprawdę wyceniasz, i masz jedną rozmowę, żeby go znaleźć. Poznając firmę i potrzebne automatyzacje, odkrywasz zakres tak samo, jak odkrywasz wartość dla firmy. Zaczynasz od tego, że pozwalasz im wszystko z siebie wyrzucić: „Opowiedz mi wszystko, co wiesz na ten temat, co próbowaliście w przeszłości, co zadziałało, gdzie ciągle się zacina”. Twoim zadaniem jest słuchać, powtarzać i drążyć. Uruchamiasz ten framework LRP (listen, repeat, poke — słuchaj, powtarzaj, drąż), żeby wyciągnąć jak najwięcej informacji. Robisz mnóstwo notatek, a potem robisz zwrot: pytasz, co się dzieje po zakończeniu projektu. Jaki jest najlepszy możliwy scenariusz i co konkretnie zmieni się w firmie, gdy to zacznie działać.
Trzy kubełki pytań: dlaczego to / dlaczego teraz / dlaczego ja
Potem uruchamiasz trzy kubełki pytań: dlaczego to, dlaczego teraz i dlaczego ja.
- Dlaczego to — sprawdzasz, czy to, o co proszą, faktycznie da im pożądany efekt, bo często nie da. Przyszli, prosząc o „agenta AI”, ale prawdziwym rozwiązaniem może być prosty deterministyczny skrypt i powiadomienie na Slacku.
- Dlaczego teraz — to kwestia pilności. Jeśli zamyka się jakieś okno albo depcze im po piętach konkurencja, to dla ciebie realne pieniądze.
- Dlaczego ja — to ten trochę niewygodny. Pytasz wprost: dlaczego nie zrobicie tego wewnętrznie? Nie dałoby się tego „vibe-code’ować”? (Informacja dodatkowa: „vibe coding” to zbudowanie czegoś na szybko z pomocą AI, bez głębokiej inżynierii.) Nie dałoby się dać tego stażyście? Chcesz to zadać, bo to pytanie wydobywa obiekcje, które już siedzą im w głowie. Albo usłyszysz je teraz, na rozmowie, i je obsłużysz, albo zabiją ci deal później, gdy będą czytać ofertę lub rozmawiać z zespołem.
Kiedy dają realną odpowiedź w stylu „no, mój bratanek pewnie by to zbudował”, nie kłócisz się. Mówisz: „Tak, pewnie postawiłby jakąś wersję tego, ale chciałbym wiedzieć, kto będzie tego pilnował o drugiej w nocy, gdy zaktualizuje się model? I kto pomoże wam to skalować, gdy przepustowość okaże się dużo większa, niż się spodziewacie, i gdy zrobi się bardziej złożone?”. Potem zatrzymujesz się i pozwalasz im odpowiedzieć — bo ich odpowiedź to prawdziwy powód, dla którego szukają kogoś do wynajęcia.
Kiedy klient tylko naciska na cenę
Jeśli klient ciągle naciska na liczbę, zanim zdążysz zadać te pytania — nie wyrzucaj jej z siebie. Szczerze: jeśli ciągle naciska na cenę i chce tylko wyciągnąć od ciebie wycenę, żeby porównać cię z kilkoma innymi dostawcami, to prawdopodobnie czerwona flaga i lepiej wyjść z takiej rozmowy. Twarda prawda jest taka, że niektórzy szukają po prostu najtańszej siły roboczej. Nie szukają konsultanta ani partnera — a właśnie tak chcesz się pozycjonować. Niewiele zrobisz, żeby zmienić zdanie takiej osobie, poza powiedzeniem: „To, co wnoszę, jest inne — inny poziom eksperckości” — i to tu opierasz się na swoich dowodach. Ale niektórzy wiedzą, że mogą pójść na Upwork po dużo tańszą robotę, i po prostu to zrobią. Nie bierz tego do siebie.
Jak wyciągnąć liczby, gdy klient ich nie podaje
Sporo klientów nie poda ci liczb ot tak — nie chcą zdradzać pensji ani dokładnych wyników finansowych. I nie muszą. Zacznij od trzech pytań:
- Ile czasu to wam dzisiaj zajmuje?
- Ile osób się tego dotyka?
- Co się dzieje, gdy coś pójdzie źle?
To wszystko pytania szacujące. Mierzą sufit, nie build. Potem dokładasz kolejne pytania „proxy”: „Ile macie lokalizacji?”, „Ile tego wpada w najbardziej ruchliwe dni?”.
Wiem, że część z was działa na platformach zleceniowych, gdzie trzeba wpisać liczbę w ofercie, zanim w ogóle porozmawiasz z człowiekiem. Nadal możesz zrobić wersję tego. Ogłoszenie prawie zawsze zdradza wolumen, liczbę osób albo pozwala oszacować złożoność i częstotliwość. Wyceniasz na tej podstawie i mówisz swoje założenie na głos: „Wyceniłem to przy założeniu, że jest tego około 200 miesięcznie; jeśli to nie tak, wskoczmy na 15-minutową rozmowę, a dostosuję cenę i trochę przebudujemy zakres”. To zamienia zimną cenę w powód, żeby zadzwonili i pogadali z tobą.
Szybki test: jeśli nie potrafisz wyznaczyć liczby, jeśli czujesz, że nie rozumiesz wartości na tyle, by ją trafnie podać, to sygnał, że nie jesteś jeszcze gotowy pisać tej oferty. Potrzebujesz więcej informacji.
Jak wyliczyć cenę i uzasadnić ją na głos
Masz już liczbę wartości — całkowitą, zannualizowaną, za pierwszy rok. Ja lubię brać jako punkt startowy między 10% a 20% tej liczby. Podajesz cenę i zakładasz, że następne zdanie z ich ust brzmi: „Możesz mi wyjaśnić, jak doszedłeś do tej ceny?”. Musisz odpowiedzieć pewnie: „Ok, to automatyzacja obsługi klienta. Zajmuje przedstawicielowi godzinę dziennie ręcznie, a godzina jego czasu to około 50 dolarów — tyle to kosztuje firmę. Rocznie wychodzi około 12 tysięcy dolarów. 10% z 12 tysięcy to 1200 dolarów, więc build kosztuje 1200 dolarów. Zachowawczo licząc, dziesięciokrotnie zwrócicie tę inwestycję już w pierwszym roku”.
Pakiety w trzech wariantach
Gdy to spisujesz, nie wysyłaj jednej ceny. Ja zawsze robiłem pakiety w warstwach — starter, growth i scale, albo jakkolwiek chcesz je nazwać. Zanim dojdziesz do opcji, na górze oferty są trzy krótkie akapity i żaden z nich nie jest o tobie ani o twojej cenie. Są o tym, gdzie firma jest teraz — ich słowami i z ich liczbami; gdzie powiedzieli, że chcą być; i dlaczego to ty jesteś osobą, która im tam pomoże dzięki twojej eksperckości w AI i twoim systemom.
Bierzesz wartość pierwszego roku — dla równości powiedzmy 100 tysięcy. Opcja pierwsza to 10%, czyli 10 tysięcy. Opcja druga to 25%, czyli 25 tysięcy. Opcja trzecia to 50%, czyli 50 tysięcy. Rzucam zgrubne liczby, ale oczywiście, wspinając się po tych progach, musisz oferować inną wartość — więcej funkcjonalności albo inne wyniki. To wciąż musi mieć sens. Środkowa opcja jest tą zaprojektowaną, żeby wygrać: dolna wygląda cienko, górna może trochę zaboli, a środkowa wygląda „bardziej właściwie”. Psychologicznie dzieje się coś ciekawego: gdy dajesz jedną liczbę, ich decyzja brzmi „czy w ogóle pracować z tą osobą?”. Gdy dajesz trzy liczby, decyzja przesuwa się na „jak pracować z tą osobą — którą z tych ofert wybrać?”.
Myśl o wpływie na wynik firmy, nie tylko o zaoszczędzonych godzinach
Jedna z najbardziej dochodowych automatyzacji, jakie widziałem, była jedną z najprostszych: brała codzienne zamówienia telefoniczne ekipy budowlanej i zamieniała je na format tekstowy, którego ekipa już używała. Tyle. Oszczędzała tylko jakieś 45 minut dziennie, ale pomagała uniknąć około 12 tysięcy dolarów miesięcznie strat z błędów w harmonogramowaniu. Ta druga liczba to nie odzyskane godziny jak w przykładzie z agentem umawiającym spotkania — to twarde dolary, które firma traciła co miesiąc przez błędy i niekonsekwencję ludzi. Dlatego oszczędzenie 45 minut dziennie było tu warte tak dużo więcej.
Dobry punkt startu to myślenie o oszczędzanych godzinach. Ale w miarę nabierania doświadczenia zaczynasz myśleć o wpływie na wynik finansowy całej firmy. Wróć do przykładu z agentem umawiającym spotkania — przypisaliśmy wartość tylko do oszczędzanego czasu, do czasu, który odkupywaliśmy firmie. A gdybyśmy pomyśleli, ile realnie zarabia firmie jedno umówione i domknięte spotkanie? Gdyby każda domknięta sprzedaż była warta 5 tysięcy dolarów, moglibyśmy wycenić ten system dużo wyżej i pewnie policzyć za tę automatyzację znacznie więcej. Ale to twoja rola, żeby zakomunikować tę wartość — właściciel firmy sam od razu tego nie zobaczy.
Niedoszacowanie zakresu i kamienie milowe
Chcę pogadać o niedoszacowaniu zakresu (underscoping). To błąd numer jeden, który popełniałem na starcie. Powodował przesuwanie terminów i kłótnie o kamienie milowe. Sam scoping to osobny temat, nie na ten materiał — tu chodzi bardziej o poprawne ustawienie kamieni milowych.
Powiedzmy, że mamy projekt za 9 tysięcy dolarów i chcemy podzielić go na główne kamienie milowe: jeden w połowie drogi i jeden po wypchnięciu systemu na produkcję. Myślę o nich w kategorii: co jesteśmy w stanie dostarczyć w 30 dni? Każdy kamień milowy jest oddalony o 30 dni i to co 30 dni dostajesz zapłatę. Możesz to rozbić na trzy płatności, jeśli masz dwa główne kamienie: pierwsza na start, druga po osiągnięciu pierwszego kamienia, ostatnia po osiągnięciu ostatniego.
Ale to działa tylko wtedy, gdy z każdym kamieniem milowym nie da się dyskutować. Musi być tak obiektywny, że nie ma żadnej dwuznaczności. Obiektywny mógłby brzmieć tak: na tym kamieniu milowym w rękach właściciela jest system AI — POC, proof of concept (dowód słuszności koncepcji) — z którym może realnie rozmawiać; gdy właściciel wysyła pytanie, agent pobiera dane z bazy i odpowiada w minutę. To wszystko jest sprawdzalne, proste do zapisania i klient może sam to zweryfikować. Nie twierdzimy, że baza jest już idealnie zoptymalizowana, ani że wszystkie odpowiedzi są idealne czy poprawne — tylko że to działa, że pobiera z bazy i odpowiada. To obiektywne.
Subiektywny kamień milowy to na przykład „agent skrzynki działa zgodnie z oczekiwaniami”. No dobrze — co jest oczekiwane? Możecie się o to przerzucać tygodniami, nie dostaniesz zapłaty i zrobi się frustrująco. Do tego zaczynają prosić o rzeczy, których nie było na pierwotnej liście, bo wszystko jest tak mgliste.
Obsługa scope creepu
Kiedy zaczynają rozszerzać zakres (scope creep), to w rzeczywistości świetny znak — oznacza, że są podekscytowani i już wyobrażają sobie dalszą współpracę z tobą. Nie mówię „o nie”. Mówię: „Świetny pomysł, widzę, jak dodałby wartości systemowi. Wrzućmy to na backlog do wersji drugiej projektu”. W miarę jak pojawiają się kolejne pomysły, po prostu dokładasz je do backlogu — bo chcesz mieć pewność, że jak najszybciej domkniecie już ustalone kamienie milowe i dostarczycie firmie jak najwięcej wartości.
Gdy cena im się nie podoba
Co robić, gdy zobaczą twoją cenę i im się nie spodoba — „to dużo drożej, niż myślałem, to nie mieści się w naszym budżecie”. Powiedz coś w stylu: „Ok, brzmi to tak, że 20 tysięcy nie mieści się teraz w budżecie. Może zredukujmy trochę zakres i zacznijmy od mniejszego projektu? Gdy to zacznie działać i odzyskiwać wam czas oraz nowy biznes, przejdziemy razem do kolejnego elementu, bo już go w zasadzie rozpisaliśmy”. Tak unikasz nauczenia klienta, że twoja cena spada za każdym razem, gdy się skrzywi. Nie dewaluujesz też swojej pracy — redukujesz zakres, a to jest fair.
Koszty API, tokenów i testowania
Ostatnia rzecz to inne koszty typowe dla tych systemów: koszty API, subskrypcje chmurowe, zużycie tokenów. Ja zawsze mówiłem: konto klienta, karta klienta, za każdym razem. Twoje honorarium jest za projektowanie, konsulting, budowę i testy. Tokeny to rachunek za media, a rachunki za media idą na nazwisko klienta. Kiedyś zaczynałem od prowadzenia wszystkiego pod własnym rozliczeniem i fakturowania klienta co miesiąc — robiło się z tego bałagan. Niańczyłem billing, musiałem przypominać się klientom, a oni nie mieli pojęcia, za co płacą, co potencjalnie nadwyrężało zaufanie.
Powinieneś też podać w ofercie spodziewany miesięczny koszt działania z założeniem wolumenu obok niego. To nie gwarancja, tylko szacunek, ile to typowo będzie kosztować miesięcznie w pełnej produkcji — a ponieważ system idealnie będzie używany coraz częściej, koszty prawdopodobnie też będą rosły z miesiąca na miesiąc.
Jedna rzecz do przemyślenia w wycenie: zwykle jest sporo kosztów testowania. Jeśli robisz to dobrze, wydajesz sporo pieniędzy na testy, zanim cokolwiek trafi na produkcję. Te koszty testowania mogą realnie wynieść od 100 dolarów do kilku tysięcy, zależnie od tego, jak rygorystyczne są twoje ewaluacje (evals) i proces QA — a moim zdaniem powinny być całkiem rygorystyczne. Zwykle wliczam to w cenę końcową, podbijając ją o jakiś tysiąc, dwa albo trzy, zależnie od wielkości automatyzacji i tego, ile testowania przewiduję. Im więcej AI i autonomii w systemie, tym więcej testów.
Co do samej wyceny AI: nawet największe firmy — McKinsey, Salesforce — wszyscy próbują to rozgryźć i nikt nie ma jednej złotej odpowiedzi. Wiele osób może się nie zgodzić z częścią tego, co mówię, i to w porządku. Ale nie czułem się dobrze, mówiąc: „Drodzy państwo, dajcie proszę ten klucz API, i ten, i ten”, a potem — zanim damy im jakikolwiek POC czy pokażemy jakąkolwiek wartość — wydając kilkaset ich dolarów na same testy. Nie sądzę, żeby to był dobry sposób na rozpoczęcie partnerstwa. Dlatego w testach płaciliśmy za wszystko sami, a gdy przenosiliśmy rzecz na produkcję, podmienialiśmy klucze API na klienta — za compute i cokolwiek innego, co nas kosztowało.
Jedna rzecz do zabrania
Jeśli masz wynieść z tego jedną jedyną rzecz na następną rozmowę odkrywającą albo sprzedażową, niech to będzie ta: zanim wypowiesz jakąkolwiek liczbę, doprowadź do tego, żeby klient sam ci powiedział, ile ten problem go kosztuje — swoimi słowami, na głos. Gdy ta liczba już leży na stole w ich języku, twoja cena jest po prostu ułamkiem liczby, którą sami podali. Sprzedajesz wynik, a rachunek to tylko sposób, w jaki ten wynik zostaje dostarczony.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wyceniaj od wartości dla klienta, a nie od godzin
Na czym polega: Cena powinna być ułamkiem (zwykle 10–20%) rocznej wartości, jaką system daje firmie, a nie funkcją godzin twojej pracy. Rozliczenie godzinowe nagradza wolność i karze rosnącą sprawność.
Jak stosować: Policz roczną wartość (np. zaoszczędzone godziny × stawka × 52 tygodnie) i weź z niej 10–20% jako punkt wyjścia. Rozliczenie godzinowe zostaw na pierwsze 2–3 projekty, gdy nie masz jeszcze dowodów — wtedy ok. 100 dolarów/godz. jest bezpieczniejszą prośbą.
Na co uważać: Nie próbuj uzasadniać ceny swoimi kosztami („kupiłem nową ciężarówkę”) — to cena uzasadnia koszt, nie odwrotnie. Klient płaci za wynik, nie za twój nakład.
2.Celuj w komunikowany zwrot 10× w pierwszym roku
Na czym polega: Dziesięciokrotny zwrot w rok tworzy matematykę, której trudno odmówić. Jeśli sam czas oszczędzony daje tylko 7,5×, brakującą część dołóż realistyczną projekcją wzrostu (efekt koła zamachowego).
Jak stosować: Pokaż liczbowo: inwestycja X, zwrot 10X. Uzasadnij, że w miarę używania systemu firma odzyskuje czas, rośnie i używa systemu jeszcze więcej.
Na co uważać: Projekcja to nie gwarancja. Nie obiecuj konkretnych wyników i nie wiąż swojego honorarium z przychodem klienta — to droga do sporów.
3.Maintenance to utrzymanie sprawności, nie nowe funkcje
Na czym polega: Stały abonament (u autora 400 dolarów/mies.) gwarantuje tylko, że build dalej robi to, na co się umówiono — naprawy, zmiany API, nowe modele, przypadki brzegowe. Nowa funkcjonalność to osobna rozmowa i osobne pieniądze.
Jak stosować: Trzymaj stawkę utrzymaniową prostą i jednakową dla wszystkich projektów. Jasno rozgranicz w umowie „utrzymanie” od „rozbudowy”.
Na co uważać: Sprawdź, czy stała stawka pokrywa realny koszt utrzymania danego systemu — przy dużym, złożonym wdrożeniu ryczałt może przynieść stratę. Dobrze zbudowane automatyzacje nie powinny być kosztowne w utrzymaniu.
4.Zmierz i nagłośnij stan „po” wdrożeniu
Na czym polega: Bez liczby opisującej transformację (przed/po) tracisz argument przy sprzedaży kolejnych zleceń temu klientowi. Właściciel może nie odczuć korzyści, jeśli mu jej nie pokażesz.
Jak stosować: Zapisz punkt wyjścia na starcie (np. 20 leadów/tydz., czas reakcji). Rób follow-up po 1, 2 i 3 miesiącach, pokazując ruch liczb w pożądanym kierunku.
Na co uważać: To nie chwalenie się, tylko konieczność — jeśli sam nie zaświecisz reflektora na wyniki, nikt ich nie zauważy. Zaplanuj pomiar, zanim wejdziesz na produkcję.
5.Rozdziel koszt, wartość i cenę
Na czym polega: Koszt to podłoga (poniżej odchodzisz), wartość to sufit (ile to warte dla firmy), cena to dowolny punkt między nimi. Przy AI ta przepaść jest ogromna.
Jak stosować: Skup wysiłek rozmowy na odkryciu sufitu — wartości dla klienta — bo to od niego wyceniasz, a nie od własnego kosztu.
Na co uważać: Masz zwykle jedną rozmowę, żeby odkryć sufit. Jeśli nie potrafisz wyznaczyć liczby, nie jesteś gotów pisać oferty — zbierz więcej informacji.
6.Prowadź discovery frameworkiem LRP i pytaniami „dlaczego to / teraz / ja”
Na czym polega: Najpierw pozwól klientowi wszystko wyrzucić, słuchaj–powtarzaj–drąż (LRP), potem zapytaj o stan po projekcie. Trzy kubełki: dlaczego to (czy rozwiązanie da efekt), dlaczego teraz (pilność = pieniądze), dlaczego ja (wydobywa ukryte obiekcje).
Jak stosować: Pytanie „dlaczego nie zrobicie tego wewnętrznie / nie da tego stażyście?” celowo wyciąga obiekcje na wierzch, żebyś obsłużył je na rozmowie, a nie stracił deal później. Po zadaniu — zamilcz i słuchaj.
Na co uważać: Gdy klient tylko naciska na cenę, żeby porównać cię z innymi dostawcami — to czerwona flaga (szuka najtańszej roboczej siły, nie partnera). Nie wyrzucaj liczby przed odkryciem wartości.
7.Wyciągaj liczby pytaniami szacującymi, gdy klient ich nie poda
Na czym polega: Klient nie musi zdradzać pensji. Trzy pytania mierzą sufit: ile czasu to zajmuje dziś, ile osób się tego dotyka, co się dzieje, gdy pójdzie źle. Do tego pytania proxy (liczba lokalizacji, wolumen w szczycie).
Jak stosować: Na platformach zleceniowych, gdzie trzeba podać cenę bez rozmowy, oszacuj z ogłoszenia i powiedz założenie na głos: „Wyceniłem przy ok. 200 sztukach/mies.; jeśli inaczej, zdzwońmy się na 15 minut”. To zamienia zimną cenę w powód do rozmowy.
Na co uważać: Jeśli nie czujesz wartości na tyle, by podać liczbę — to sygnał, że jeszcze nie czas na ofertę.
8.Podawaj trzy pakiety zamiast jednej ceny
Na czym polega: Warianty (np. 10%, 25%, 50% wartości) przesuwają decyzję klienta z „czy z nim pracować?” na „jak z nim pracować — którą opcję wziąć?”. Środkowa opcja jest zaprojektowana, by wygrać.
Jak stosować: Na górze oferty daj trzy krótkie akapity o kliencie (gdzie jest teraz jego słowami i liczbami, gdzie chce być, dlaczego to ty pomożesz), a dopiero potem opcje. Wyższe progi muszą mieć realnie większą wartość/funkcjonalność.
Na co uważać: Progi nie mogą być pustym mnożeniem ceny — każdy wyższy musi nieść więcej. Dolny ma wyglądać cienko, górny lekko zaboleć, środkowy „właściwie”.
9.Płatności etapowe wokół obiektywnych kamieni milowych
Na czym polega: Dziel projekt na kamienie oddalone o ~30 dni (płatność co ~30 dni), żeby nie nieść więcej niż miesiąc nieopłaconej pracy. Każdy kamień musi być tak obiektywny, że nie da się z nim dyskutować.
Jak stosować: Definiuj sprawdzalnie: „w rękach właściciela jest POC, agent na pytanie pobiera dane z bazy i odpowiada w minutę”. Unikaj sformułowań w stylu „działa zgodnie z oczekiwaniami” — to prosi się o tygodnie sporów.
Na co uważać: Scope creep traktuj jako dobry znak (klient się angażuje), ale przekierowuj pomysły na „backlog wersji drugiej”, zamiast wpychać je w bieżący kamień milowy.
10.Tokeny i API na koncie klienta; testy wlicz w cenę
Na czym polega: Koszty tokenów/API/chmury to „rachunek za media” i idą na kartę klienta. Twoje honorarium jest za projekt, konsulting, budowę i testy. Testy przedprodukcyjne bywają kosztowne (od 100 do kilku tysięcy dolarów).
Jak stosować: Podaj w ofercie szacowany miesięczny koszt działania z założeniem wolumenu (i uprzedź, że będzie rósł z użyciem). Fazę testów finansuj sam, a przy przejściu na produkcję podmień klucze API na klienta. Koszt testów wlicz w cenę, podbijając ją o 1–3 tys. dolarów zależnie od skali.
Na co uważać: Prowadzenie billingu klienta pod własnym kontem robi bałagan i nadwyręża zaufanie. Nie każ klientowi płacić za testy, zanim zobaczy jakąkolwiek wartość (POC) — to zły start partnerstwa.