Persona zakupowa B2B: kto podpisuje, blokuje i korzysta

Jeśli masz w firmie persony z warsztatu, mogą wyglądać tak: „Marek, 42 lata, dyrektor marketingu, lubi rower”. Taki opis łatwo zapamiętać, ale trudno wskazać ofertę, którą zmienił. W firmie usługowej zakup przechodzi zwykle przez kilka osób, a persona zakupowa B2B zbudowana ze stanowiska i wieku nie mówi, o co zapyta każda z nich.

W tym wpisie przedstawię, jak opisać personę dla każdej z trzech ról w zakupie usługi: kto podpisuje, kto może zakup zablokować i kto będzie korzystać. Dostaniesz szablon z wypełnionym przykładem, trzy kroki do zebrania danych, test oferty i przykład z naszej firmy razem z tym, czego jeszcze nie wiemy.

Czym jest persona zakupowa B2B w firmie usługowej

Persona zakupowa B2B (ang. buyer persona) to opis osoby w firmie klienta przez jej rolę w zakupie, jedną albo kilka. Opisuje między innymi, kim ta osoba jest, za co odpowiada, po czym ocenia sukces, jakie ma obiekcje i jaki dowód ją przekonuje. ICP (ang. Ideal Customer Profile, profil idealnego klienta) opisuje firmę, która kupuje, a persona osobę w tej firmie. W firmie usługowej personę przypinasz do jednej usługi i jednego ICP.

Jeśli nie masz jeszcze ICP, zacznij od niego. Opisałem to we wpisie Jak stworzyć ICP w firmie usługowej B2B. Tutaj zakładam, że wiesz, do jakich firm sprzedajesz, i chcesz ustalić, z kim w tych firmach rozmawiasz.

Wiek i hobby persony nie powiedzą ci, dlaczego zakup stanął

Najwięcej w ofercie zmieniają trzy informacje o każdej osobie przy zakupie: po czym oceni, czy usługa się udała, jakie ma obiekcje i jaki dowód ją przekona. Wiek ani hobby tego nie mówią. Stanowisko mówi trochę więcej, ale nie wystarcza. Weźmy dyrektora marketingu: w jednej firmie sam podpisuje umowę z agencją, w innej tylko pracuje z agencją, którą wybrał zarząd, i przy tym samym stanowisku zadaje inne pytania.

To ma znaczenie, bo zakupy B2B często stają w trakcie. Według raportu Forrestera z 2024 r. 86% zakupów B2B zatrzymuje się w trakcie procesu zakupowego (Forrester, 2024). Żeby ustalić, na czyim pytaniu zakup stanął, musisz wiedzieć, kto jaką rolę w nim pełnił.

Dlatego zalecam zaczynać od pytania, jaką rolę dana osoba miała w zakupie. Stanowisko dopisujesz później, żeby rozpoznać ją w firmie klienta.

Zakup usługi ma trzy role: kto podpisuje, kto blokuje, kto korzysta

Według Forrestera typowa decyzja zakupowa w B2B obejmuje dziś 13 osób w firmie kupującego i 9 osób z zewnątrz, które na nią wpływają, a przy bardziej złożonych zakupach jeszcze więcej (Forrester, 2026). Analityczka Forrestera Barbara Winters mówi w tym samym komunikacie, że przy rosnących grupach zakupowych marketerzy B2B potrzebują wiedzy osobnej dla każdej roli. W komunikacie Forrester nie podaje tych liczb osobno dla małych firm. Moim zdaniem u klienta zatrudniającego kilkanaście osób w zakupie bierze udział mniej ludzi. Niezależnie od ich liczby każdą osobę z firmy klienta, która ma w zakupie coś do zrobienia, a nie tylko doradza, da się przypisać do co najmniej jednej z trzech ról. Dlatego małej firmie usługowej wystarczą trzy role, każda z własnymi pytaniami. Osoby, które tylko doradzają, z firmy klienta albo z zewnątrz, nie dostają własnej persony: ich wpływ wpisujesz w pola „Jak kupuje” i „Co ją przekonuje”.

Rola	Kto to jest	Kto to bywa	O co pyta
Podpisuje	osoba, która zatwierdza budżet i podpisuje umowę	w małej firmie zwykle właściciel, w większej dyrektor działu albo zarząd	czy to się opłaci i czy wykonawca dowiezie
Blokuje	osoba, która poza budżetem i umową musi coś zatwierdzić albo udostępnić (dostęp do systemów, zgodę prawną, dane), zanim zakup ruszy, więc może go zatrzymać albo opóźnić	dział IT, prawnik albo wspólnik	co może pójść źle i kto za to odpowie
Korzysta	osoba, która po podpisaniu pracuje z wykonawcą albo z efektem usługi na co dzień	zespół klienta, który pracuje z wykonawcą	czy to doda jej pracy, czy jej ją odbierze

Moim zdaniem w usługach trzecia rola waży więcej niż przy zakupie programu. Przy programie osoba korzystająca ocenia narzędzie. Przy usłudze ocenia ludzi, z którymi pracuje przez cały projekt: czy odpisują, czy rozumieją jej firmę, czy nie dokładają jej zadań. Jeśli przy przedłużeniu umowy podpisujący zapyta kogoś o zdanie, zapyta właśnie ją. Bywa też, że to przyszła osoba korzystająca przekonuje resztę firmy do zakupu.

Jedna osoba może mieć kilka ról. W pięcioosobowej firmie właściciel często podpisuje i korzysta jednocześnie. Wtedy opisujesz jedną personę z dwiema rolami, ale zostawiasz pytania obu.

Przykład: trzy role przy zakupie naszej usługi

Pokażę to na naszej firmie. B2BForce sprzedaje małym firmom usługowym wdrożenie swojego repozytorium w Claude Code (jednym z agentów AI) dla kilkuosobowego zespołu. Samo repozytorium jest darmowe, płatne jest wdrożenie. Opis ról poniżej pochodzi z naszych dokumentów sprzedażowych, a nie z opisanych wdrożeń, bo case studies jeszcze nie mamy. Każda z trzech ról jest więc na razie naszym założeniem.

U nas podpisuje właściciel albo szef operacji lub marketingu: tak zapisaliśmy w ICP. Na pierwszej rozmowie z potencjalnym klientem sprawdzamy to wprost, pytając, czy rozmawiamy z osobą, która ma budżet. Przygotowujemy się na obiekcje „Sami zrobimy z darmowego repo”, „Czy to lock-in?” i „Za drogo”.

Korzystają trzy osoby z zespołu klienta: pakiet obejmuje ich konfigurację, a one muszą w ciągu pięciu dni roboczych znaleźć czas na sesje. W biznesplanie nowej oferty zapisaliśmy, że główny opór kupującego to pytanie: „a jeśli zespół nie będzie z tego korzystał?”. Zadaje je podpisujący, ale dotyczy ono osób, które korzystają. Dlatego w nowej wersji oferty przewidzieliśmy 30-dniową gwarancję zwrotu za wdrożenie.

O roli „blokuje” wiemy najmniej, bo bez case studies nie mamy opisanego zakupu, w którym by się pokazała. Z dokumentów wynikają trzy miejsca, w których zakup może stanąć. Firma musi mieć konto GitHub organizacji albo zgodzić się na jego założenie. Każda osoba potrzebuje planu Claude z dostępem do Claude Code. Do tego sami, opisując, czym różnimy się od konkurencji, piszemy o ryzyku dla własności intelektualnej klientów przy narzędziach hostowanych w cudzej chmurze, więc to samo pytanie może paść wobec nas. Za każdym z tych miejsc może stać ktoś, kto powie „nie”: osoba od IT, która zakłada konta i przydziela plany, albo wspólnik, który pilnuje umów z klientami.

Najwięcej zapisaliśmy o podpisującym, bo z nim rozmawiamy. Rola, która może zakup zatrzymać, w naszym skrypcie pierwszej rozmowy z klientem jeszcze się nie pojawia, więc chcemy ją sprawdzić w pierwszej kolejności. Jeśli u ciebie jest podobnie, zacznij zbieranie danych od roli „blokuje”.

Szablon persony: osiem pól, z których korzystasz w sprzedaży

Każde pole poniżej przydaje się przy pisaniu oferty, w rozmowie handlowej albo w marketingu. Jeśli pola nie potrafisz połączyć z żadną z tych rzeczy, nie potrzebujesz go.

Pole	Co wpisujesz	Do czego się przyda
Rola w zakupie	podpisuje, blokuje albo korzysta (może być kilka)	z kim i o czym rozmawiać
Kim jest	stanowisko, komu podlega, jakim zespołem kieruje	rozpoznanie tej osoby w firmie klienta
Za co odpowiada	za co ją rozliczają	język oferty
Po czym ocenia sukces	jedno, dwa zdania, najlepiej jej słowami	cele w ofercie i na spotkaniach kontrolnych
Jak kupuje	szybko czy po namyśle, przetarg czy polecenie, co czyta najpierw	plan rozmów i kolejność w ofercie
Obiekcje w brzmieniu, w jakim padły	2–4 zdania, także od innych osób w tej roli	sekcja pytań w ofercie, przygotowanie do rozmowy
Co ją przekonuje	rodzaj dowodu: referencja, przykład, zakres, gwarancja	wybór dowodów do oferty
Gdzie do niej dotrzeć	gdzie szuka informacji i na co nie reaguje	kanały marketingu

Poniżej szablon wypełniony we wszystkich ośmiu polach. Przykład pochodzi z przykładowych plików w repo B2BForce i opisuje wymyśloną 14-osobową firmę, która sprzedaje operatorom logistycznym migrację platformy i automatyzację wydań oprogramowania. Firma, osoba i liczby są fikcyjne, a obiekcje przetłumaczyłem z angielskiego.

Pole	Podpisujący: CTO operatora logistycznego (przykład fikcyjny)
Rola w zakupie	podpisuje i ma budżet do pewnej kwoty; powyżej niej podpisuje też dyrektor finansowy
Kim jest	kieruje zespołem 8–40 inżynierów, podlega COO albo prezesowi; wyrósł z programowania i nadal przegląda kod; w firmie od 5 do 15 lat, więc historię systemu traktuje osobiście
Za co odpowiada	za dowiezienie planu rozwoju uzgodnionego z biznesem i za działanie systemu, żeby nie być powodem, przez który odchodzi klient firmy; przy każdym weekendowym wydaniu te dwie rzeczy ciągną w przeciwne strony
Po czym ocenia sukces	dwóch starszych programistów pracuje nad planem rozwoju, a nie nad testami regresji; on sam może wziąć tydzień urlopu w trakcie cyklu wydania bez organizowania zastępstwa
Jak kupuje	reaktywnie i szybko, gdy coś się wydarzy; przy tej skali nie robi formalnego przetargu, ale prosi o rozmowę z kimś, kto miał ten sam problem; czyta zakres przed ceną
Obiekcje w brzmieniu, w jakim padły	„Mam budżet na ludzi, nie na konsultantów.” „Czym to się różni od procesu wydań, który mój zespół mógłby zbudować w spokojniejszym miesiącu?” „Co się stanie, kiedy odejdziecie?”
Co ją przekonuje	nazwany projekt u podobnego operatora, konkretnie opisane przekazanie pracy zespołowi i uczciwa lista tego, co jest poza zakresem; oferta, która obiecuje procent mniej błędów, brzmi jak wykonawca, który nie wie, skąd ta liczba się bierze
Gdzie do niej dotrzeć	branżowe konferencje operacyjne, rozmowy z innymi CTO z logistyki, dłuższe teksty, które nazywają problem weekendowych wydań; nie reaguje na zimne sekwencje maili, które zaczynają się od ogólnej obietnicy efektywności

Przykład z repo opisuje tylko CTO. Nie podaje pytań dyrektora finansowego, a z wykonawcą pracują tam inżynierowie, którzy dziś robią wydania. Według tej metody pytania dyrektora finansowego trafiłyby do obiekcji CTO, a jeden z inżynierów dostałby osobną personę.

Oferta dla tej osoby musi odpowiedzieć na pytanie „Co się stanie, kiedy odejdziecie?”, na przykład opisem przekazania pracy zespołowi z pola „Co ją przekonuje”. Bez tej odpowiedzi przegra u niej niezależnie od ceny.

Jak zebrać persony i sprawdzić ofertę w czterech krokach

Kroki 1–3 wypełniają pola szablonu, krok 4 sprawdza na nich ofertę. Pracujesz na jednej usłudze naraz.

Wypisz osoby przy ostatnich zakupach. Wejście: umowy, wątki mailowe i notatki z 3–5 ostatnich zakupów tej usługi. Przy każdym zakupie zapisz, kto podpisał, kto musiał coś zatwierdzić albo udostępnić i kto potem pracował z twoim zespołem albo z efektem waszej pracy. Jeśli jedną rolę pełniło kilka osób, na przykład IT i prawnik przy roli „blokuje” albo kilku programistów przy roli „korzysta”, wybierz do opisu tę, która miała największy wpływ na zakup albo przedłużenie. Wyjście: pola „Rola w zakupie” i „Kim jest”.
Zbierz pytania i obiekcje każdej roli. Wejście: maile z pytaniami sprzed podpisania, notatki z rozmów handlowych, pytania z zapytań ofertowych i krótkie rozmowy z dwoma, trzema klientami. Dobre pytanie do klienta: „Kto jeszcze musiał się zgodzić i o co pytał?”. Zapytaj też, jak szukał wykonawcy, kto mu doradzał i skąd się o was dowiedział. Pytania innych osób w tej samej roli dopisz do obiekcji wybranej persony. Wyjście: pola „Obiekcje w brzmieniu, w jakim padły”, „Za co odpowiada”, „Jak kupuje” i „Gdzie do niej dotrzeć”.
Ustal, po czym każda rola ocenia sukces. Wejście: rozmowy po zakończonych projektach, przedłużenia i rezygnacje, maile z pochwałami i skargami. Zapytaj, co przesądziło o wyborze waszej firmy. Wyjście: pola „Po czym ocenia sukces” i „Co ją przekonuje”.
Przetestuj ostatnią ofertę. Wejście: persony z kroków 1–3 i ostatnia wysłana oferta. Dla każdej persony sprawdź, czy oferta nazywa cel, po którym ta osoba oceni sukces, i czy znajdzie w niej odpowiedź na swoje obiekcje i dowód, któremu ufa. Wyjście: lista zmian w ofercie.

Kroki 1 i 4 opierają się na dokumentach, które już masz. Kroki 2 i 3 wymagają rozmów z klientami, a te w praktyce rozkładają się na kilka tygodni, bo klienci mają swoje kalendarze. Na koniec będziesz mieć od jednej do trzech person dla tej usługi. Więcej rzadko się przydaje, bo oferty i tak nie da się napisać pod pięć osób naraz.

Kiedy metodę trzeba dopasować: mała firma, nowa usługa, stare persony

W bardzo małych firmach klienta jedna osoba robi wszystko: właściciel podpisuje, korzysta i sam zatwierdza dostęp do systemów. Wtedy masz jedną personę z trzema rolami.

Gdy usługa jest nowa i nie ma jeszcze zakupów, kroki 1 i 3 nie mają wejścia, a krok 2 opiera się tylko na rozmowach handlowych. Zapisz persony jako założenia z dokumentów, tak jak my w przykładzie wyżej, i poprawiaj je po każdej rozmowie handlowej. Pamiętaj też, że persony, których nikt nie aktualizuje, opisują dawne zakupy, a nie dzisiejsze.

Najczęstsze pytania

Czym persona zakupowa różni się od ICP?

ICP opisuje firmę, która kupuje usługę, i sytuację, w której zaczyna szukać pomocy. Persona opisuje osobę w tej firmie i jej rolę w zakupie. Najpierw powstaje ICP, potem persony dla tego ICP.

Ile person potrzebuje firma usługowa?

Zalecam od jednej do trzech na jedną usługę, po jednej na każdą rolę, którą u twoich klientów pełni osobna osoba. Jeśli u klientów ta sama osoba podpisuje i korzysta, wystarczą dwie.

Jak często aktualizować persony?

Po zdarzeniach, nie według kalendarza: po przegranym zakupie, po przedłużeniu albo rezygnacji klienta i po zmianie usługi. Każde takie zdarzenie przynosi nowe obiekcje albo nowe kryteria sukcesu do wpisania.

Persony w repo B2BForce

Repozytorium B2BForce to wspólny folder plików z historią zmian i z gotowymi instrukcjami dla agenta AI, takiego jak Claude Code, Cursor albo Codex. Takie instrukcje nazywamy skillami. Skill marketing-icp tworzy dla jednej usługi jedno ICP i od jednej do trzech person.

Każda persona ma pole decision_role z rolą w zakupie (na przykład economic_buyer, gatekeeper, user_buyer, champion) oraz pola na definicję sukcesu, obawy, obiekcje i rodzaje dowodu. Moim zdaniem wartości z repo przekładają się na role z tego wpisu tak: economic_buyer to „podpisuje”, gatekeeper to „blokuje”, user_buyer to „korzysta”, a champion to zwykle osoba korzystająca, która przekonuje resztę firmy. W schemacie pole ma jedną wartość z listy, więc przy osobie z kilkoma rolami wpisuję tę, która najbardziej wpływa na zakup, a pozostałe opisuję w treści persony.

Persony trafiają do workspace/marketing/icp/personas/. Zanim agent przygotuje tekst marketingowy albo sekwencję maili sprzedażowych, repo sprawdza, czy usługa ma ICP i co najmniej jedną personę, a bez nich zatrzymuje pracę. Repo jest na licencji MIT: github.com/b2bforce/b2bforce. Więcej na stronie open source.

Podsumowanie

Opisuj role w zakupie, a nie wiek i hobby, bo to role zmieniają ofertę. Na początek weź 3–5 ostatnich zakupów jednej usługi i przy każdym wypisz, kto podpisał, kto mógł zablokować i kto potem korzystał. Jeśli przy którejś roli nie wiesz, o co pytała, od niej zacznij rozmowy z klientami.

Każdą metodę z tego bloga możesz też uruchomić jako skill w otwartym repo B2BForce. Zobacz, co jest w repo