HubSpot CPQ pozwala budować oferty (quoty) z biblioteki do 100 000 produktów i wystawiać je z flat pricing albo tiered pricing (volume-based, stair-based, graduated). W tym poście pokazuję, co dokładnie wymaga subskrypcji i seata Revenue Hub, jak wybrać model cenowy i gdzie wpina się Stripe jako payment processor w polskim B2B.
Miesiąc temu klient z B2B usługowego (około 30 osób) pokazał mi swój proces ofertowania: Google Docs z template'em, ręczne liczenie rabatów wolumenowych w Excelu, PDF mailem, a potem \"prześlij jeszcze wersję z inną ceną, bo klient chce 5 licencji zamiast 3\". Ośmiu handlowców, każdy liczy inaczej. Sales Lead nie wie, ile realnie schodzi z marży. Klasyk.
Mieli już Sales Hub Professional. Pytanie było jedno: co dokładnie dokupić, żeby oferty powstawały natywnie w HubSpocie i nie skończyło się kolejnym Excelem obok CRM-a.
Co to jest HubSpot CPQ i co realnie robi
HubSpot CPQ (Configure, Price, Quote) to zestaw narzędzi do tworzenia quotów, zarządzania nimi i ich akceptacji bezpośrednio w HubSpocie. Ujednolica sposób, w jaki powstają quoty, prowadzi approvale rabatów i zbiera akceptację klienta przed podpisaniem. CPQ jest dostępny w subskrypcjach Revenue Hub Professional i Enterprise, a część funkcji dodatkowo wymaga przypisanego seata.
W praktyce składa się z trzech warstw:
- Product library - katalog produktów i usług, które sprzedajesz. Każdy produkt ma pricing model, opis, SKU.
- Quotes - dokument ofertowy generowany z deala, z line itemami wciąganymi z product library, z elektroniczną akceptacją i opcjonalnym signing envelope.
- Approvals plus buyer acceptance - workflow zatwierdzania rabatów przed wysłaniem oferty, potem akceptacja po stronie klienta.
Dla kogo HubSpot CPQ ma sens, a dla kogo nie
HubSpot CPQ z tiered pricing pasuje, jeżeli sprzedajesz pakiety B2B z rabatami wolumenowymi, masz już Sales Hub w HubSpocie i chcesz trzymać całą sprzedaż w jednym systemie. Nie pasuje, jeżeli masz 3 SKU flat-priced bez rabatów albo negocjujesz każdą ofertę osobno, bez powtarzalnego modelu cenowego.
Konkretnie ma sens, gdy masz powtarzalny cennik z progami, kilku handlowców liczy dziś rabaty każdy po swojemu, a Sales Lead nie widzi realnej marży schodzącej na ofertach. Nie ma sensu, gdy masz 3 produkty flat-priced bez rabatów wolumenowych (wtedy zwykły Sales Hub z line itemami wystarczy), sprzedajesz przez marketplace zamiast przez handlowca, albo każda oferta to indywidualny custom bez powtarzalnej reguły cenowej.
Jeżeli nie masz jeszcze HubSpota i sprawdzasz, czy to w ogóle dobry wybór, zacznij od decyzji, czy HubSpot jest dla Ciebie, zanim dokupisz Revenue Hub. A jeżeli myślisz o przejściu z CRM-a, który już ma quoting, zobacz, jak wygląda czyste przejście z Pipedrive, Salesforce czy Zoho.
Product library: do 100 000 produktów, ale rzadko tyle potrzebujesz
Product builder pozwala dodać do biblioteki całą ofertę firmy i wciągać produkty jako line itemy do deali i quotów. Limit techniczny to 100 000 pozycji, ale w B2B SaaS i professional services zwykle mieścisz się w 20-200 SKU, czyli jednej rodzinie produktowej z wariantami.
Każdy produkt konfigurujesz z konkretnym pricing modelem. I tu pojawia się pierwszy realny wybór.
Flat pricing vs tiered pricing - kiedy który
Flat pricing to jedna cena za jednostkę niezależnie od ilości, a tiered pricing to różne stawki dla różnych ilości. Flat wystarczy w zwykłym Sales Hubie; tiered wymaga subskrypcji Revenue Hub.
Sprzedajesz wdrożenie za 15 000 PLN? Flat. Licencja Starter za 500 PLN miesięcznie? Flat. Prosty przypadek, nie potrzebujesz Revenue Hub, żeby to wystawić. Natomiast tiered pricing HubSpot stosuje głównie do rabatów wolumenowych i modeli usage-based: cloud software, professional services per godzina, produkty konsumpcyjne. Tu potrzebujesz subskrypcji Revenue Hub.
Volume-based, stair-based, graduated - trzy modele tiered pricing
HubSpot ma trzy warianty tiered pricing i różnią się fundamentalnie tym, jak liczą cenę końcową. Volume-based stosuje jedną cenę za wszystkie jednostki wg totalnego wolumenu, a graduated liczy każdy próg osobno. Zły model kończy się rozmową z klientem \"dlaczego liczycie inaczej niż w umowie\".
| Model | Jak liczy | Kiedy stosować | Przykład (100 licencji, tier: 1-50=100 PLN, 51-100=80 PLN) |
|---|---|---|---|
| Volume-based | Jedna cena za jednostkę dla wszystkich sztuk, wg totalnego wolumenu | Rabat \"jak przekroczysz X, wszystko taniej\" | 100 x 80 PLN = 8 000 PLN |
| Stair-based | Jedna cena za jednostkę dla wszystkich sztuk (jak volume), ale schodkowo | Podobnie jak volume, dyskretne progi | 100 x 80 PLN = 8 000 PLN |
| Graduated | Każdy tier płatny osobno - jednostki 1-50 po jednej stawce, 51-100 po drugiej | Klasyczne \"brackets\" jak progi podatkowe | (50 x 100) + (50 x 80) = 9 000 PLN |
Volume-based i graduated dają różne wyniki. To nie jest niuans - to 1 000 PLN różnicy na ofercie 100 licencji. Zanim wpiszesz cokolwiek do product library, dogadaj z Sales Leadem, który model pasuje do tego, jak obiecywaliście rabaty klientom przez ostatnie lata.
Co dokładnie wymaga Revenue Hub seata
Podział jest taki: subskrypcja Revenue Hub odblokowuje tiered products i price books na poziomie portalu, a dodanie tiered priced product do konkretnego quote'a wymaga przypisania Revenue Hub seata do usera, który tę ofertę tworzy. To dwie osobne rzeczy i tu klienci gubią się najczęściej.
Czyli:
- Subskrypcja Revenue Hub Professional lub Enterprise - odblokowuje tiered pricing i price books na poziomie portalu.
- Revenue Hub seat - przypisany do konkretnego usera, pozwala mu dodać tiered priced product jako line item w quote.
Konsekwencja jest praktyczna: nie kupujesz seata dla każdego handlowca. Kupujesz subskrypcję Revenue Hub na portal (Pro albo Enterprise), a seaty przydzielasz tym userom, którzy realnie budują quoty z tiered pricing. Reszta zespołu (SDR-y, marketing, support) pracuje na Sales Hub seatach bez dopłaty za Revenue Hub.
Dla klienta z początku wyszło tak: 3 handlowców z Revenue Hub seatem, 5 pozostałych na Sales Hub Pro. Nie 8 x Revenue Hub.
Legacy quotes - jeżeli masz stary portal
Jeżeli twój portal jest starszy, możliwe, że działasz na legacy quotes i nie potrzebujesz nowej subskrypcji do samych ofert. Quoty są częścią HubSpot CPQ i dostępne z Commerce Hub Professional lub Enterprise, a legacy quotes działają na kontach bez Commerce Hub Pro/Enterprise utworzonych przed 3 września 2025. Nowe portale wymagają Commerce Hub albo Revenue Hub, żeby ruszyć CPQ. Sprawdź, na czym siedzisz, zanim dokupisz tiered pricing.
Ile to kosztuje i jak wpiąć Stripe jako payment processor
Revenue Hub Professional to około 95 USD za usera miesięcznie, a Enterprise około 140 USD, płacisz to tylko za seaty robiące tiered quoty. Do zbierania płatności podpinasz Stripe, bo Stripe payment processing jest dostępny dla wszystkich subskrypcji HubSpot i działa międzynarodowo z pewnymi wyjątkami, w tym w Polsce. HubSpot Payments (natywny) działa tylko w USA, UK i Kanadzie, więc dla polskiego B2B Stripe to default.
Po podpięciu Stripe zbierasz jednorazowe i cykliczne płatności online z faktur, payment linków i quotów. Klient akceptuje ofertę, klika \"zapłać\", trafia na checkout Stripe, po opłaceniu HubSpot tworzy payment record i podpina go do deala.
Dla ofert z tiered pricing działa to tak samo: quote wylicza cenę końcową wg modelu (volume, stair, graduated), klient akceptuje total, Stripe przetwarza płatność. Nie ustawiasz pricing logic osobno w Stripe, bo HubSpot przekazuje już policzoną kwotę.
Licencja to nie wdrożenie
Jeden szczegół, o którym mało kto mówi: jeżeli kupisz licencję bezpośrednio ze strony HubSpota, na fakturze często ląduje obowiązkowy onboarding rzędu 1500 EUR, który w praktyce jest prezentacją produktu. Kupując tę samą licencję w tej samej cenie przez partnera, tej opłaty nie płacisz, bo za wdrożenie odpowiada partner. Za porównywalny budżet dostajesz konfigurację product library i pricing modeli pod własny proces, a nie odtworzenie slajdów. Przy CPQ to szczególnie istotne, bo tu największa robota to nie kliknięcie licencji, tylko ustalenie, jak wasze rabaty mają się liczyć.
Jak poskładać CPQ w praktyce - kolejność wdrożenia
U klientów wdrażam CPQ w tej kolejności, żeby nie budować product library trzy razy, jeżeli w drugim tygodniu zmieni się model rabatowania. Discovery pricing modeli idzie zawsze na początek, konfiguracja techniczna na końcu.
- Discovery pricing modeli. Sesja 90 minut z Sales Leadem: jak faktycznie negocjujecie rabaty, ile jest tierów, czy to volume, stair czy graduated. Bez tego product library będzie zła.
- Struktura biblioteki produktów. Ustalamy SKU, kategorie, które produkty flat, a które tiered. W B2B SaaS zwykle: licencje = tiered (graduated), setup/onboarding = flat, addony = flat lub tiered zależnie od charakteru.
- Revenue Hub seat assignment. Przypisujemy seaty tylko tym userom, którzy realnie robią oferty z tiered products. Reszta na Sales Hub.
- Quote template. Konfigurujemy template oferty z brandingiem, warunkami handlowymi, załącznikami. Template tworzy admin raz.
- Stripe connection plus test. Podpinamy Stripe, testujemy end-to-end: quote wygenerowany, klient testowy akceptuje, płatność przechodzi, deal się aktualizuje.
- Approval workflows. Dopiero teraz. Jeżeli sprzedaż ma reguły typu \"rabat powyżej 15% wymaga akceptacji Sales Leada\", konfigurujemy approval steps na quote.
Czego HubSpot CPQ NIE robi
Trzy realne ograniczenia, które warto znać przed wdrożeniem, i to, jak je obchodzimy. Żadne z nich nie blokuje wdrożenia w polskim B2B, ale każde wymaga świadomej decyzji.
- Nie robi complex product configuration. Jeżeli sprzedajesz produkt z 15 opcjami, które nawzajem się wykluczają (klasyczny industrial CPQ), HubSpot ma product bundles i variants, ale to nie jest configurator na poziomie DealHub. Dla większości B2B usługowego i SaaS to nie problem.
- Nie liczy polskiego VAT-u automatycznie - VAT dokładasz jako osobny line item albo integracją z księgowością (iFirma, Fakturownia, wFirma).
- Faktury VAT PL nie są natywne - Stripe wygeneruje invoice po angielsku w swoim formacie, do polskiej FV wpinasz osobne narzędzie księgowe.
Te punkty rozwiązujemy zwykle integracją z lokalnym systemem księgowym przez Make.com albo własny kod - to robota na 3-5 dni w typowym B2B, nie architektura na miesiąc. Cały ten stack ofert, płatności i raportowania przychodu układamy w ramach wdrożenia Revenue Hub.
