power CRM / Wszystko o CRM / Zapytanie ofertowe (RFP) na system CRM lub ERP: jak je napisać

Zapytanie ofertowe (RFP) na system CRM lub ERP: jak je napisać

„Szukamy nowoczesnego, intuicyjnego systemu CRM, który usprawni naszą sprzedaż”. Tak zaczyna się większość zapytań, które trafiają do dostawców, i to jest dokładnie ten moment, w którym wybór zaczyna się sypać. Pod takie zdanie podpisze się każdy system na rynku. Dwa tygodnie później na stole leży pięć ofert, których nie da się porównać, pięć dem dopasowanych do mocnych stron każdego sprzedawcy i decyzja, która de facto sprowadza się do tego, kto lepiej prezentował. W projektach wdrożeniowych widać, że firma, która wysłała ogólnikowe zapytanie, oddała kontrolę nad procesem dostawcom, zanim w ogóle usiadła do rozmów.

Dobre zapytanie ofertowe (RFP, request for proposal) odwraca tę sytuację. To Ty narzucasz kryteria, a dostawcy odpowiadają na te same pytania, więc oferty stają się porównywalne. Nie przypadkiem ponad 60% niepowodzeń wdrożeń bierze się z fazy zbierania wymagań i wyboru (Godlan, 2025), a RFP jest głównym narzędziem tej fazy. W tym materiale pokazujemy, jak działa mechanika wyboru, jak napisać wymaganie, które naprawdę różnicuje dostawców, oraz jak zbudować scoring, który zamienia „wrażenie z prezentacji” w liczbę.

Spis treści

  • Po co w ogóle pisać RFP, gdy można po prostu porozmawiać z dostawcami
  • Koszt złego zapytania, czyli dlaczego ogólniki są drogie
  • Jak naprawdę działa rynek wyboru CRM i ERP
  • Typy zapytań i typy dostawców, których spotkasz
  • Proces, czyli RFP krok po kroku
  • Scoring ofert, narzędzie do obiektywnego porównania
  • Czerwone flagi i błędy, które psują wybór
  • Najczęściej zadawane pytania (FAQ)
  • Źródła

Po co w ogóle pisać RFP, gdy można po prostu porozmawiać z dostawcami

RFP robi trzy rzeczy, których seria rozmów z handlowcami nie osiągnie. Po pierwsze, zmusza Twoją firmę do spisania, czego naprawdę potrzebuje, a nie czego dostawca chce sprzedać. Po drugie, sprawia, że wszyscy odpowiadają na te same pytania, więc oferty da się zestawić obok siebie. Po trzecie, daje pozycję negocjacyjną: konkretne wymaganie wymusza konkretne „tak” albo „nie”, a nie ogólnik, w którym wszystko brzmi dobrze.

Brzmi banalnie, dopóki nie zobaczysz, ile decyzji w firmach zapada bez tego dokumentu. Faza wymagań jest tak ważna właśnie dlatego, że ponad 60% porażek wdrożeniowych zaczyna się tutaj, jeszcze zanim ktokolwiek podpisze umowę (Godlan, 2025). Wybór systemu jest trudniejszy, niż się wydaje na pierwszym spotkaniu, bo na spotkaniu wszystko wygląda dobrze. RFP jest pierwszym miejscem, w którym przewaga prezentacyjna dostawcy przestaje działać.

Koszt złego zapytania, czyli dlaczego ogólniki są drogie

Ogólnikowe zapytanie wygląda na oszczędność czasu, a jest najdroższym dokumentem w całym projekcie. Konsekwencje są przewidywalne. Oferty są nieporównywalne, bo każdy dostawca interpretuje „intuicyjny” po swojemu i opisuje akurat to, w czym jest dobry. Demo pokazuje mocne strony sprzedawcy, a nie Twój proces. Decyzja przesuwa się w stronę emocji i sympatii, a nie dopasowania do firmy. Koszt tego błędu nie ujawnia się w dniu podpisania umowy, tylko pół roku później, gdy okazuje się, że system nie obsługuje kluczowego procesu, integracja z ERP jest „w planach”, a wyjście z danymi kosztuje więcej niż samo wdrożenie.

Najdroższy jest tu efekt domina. Zły wybór generuje migracje, dorabianie funkcji, niską adopcję i często ponowne wdrożenie. Część kosztu, którą firmy ignorują na etapie zapytania, to całkowity koszt posiadania (TCO): utrzymanie, integracje, koszty wyjścia i ryzyko vendor lock-in. RFP jest najtańszym momentem, żeby te koszty wyciągnąć na wierzch, bo dostawca odpowiada wtedy na piśmie i jeszcze konkuruje o kontrakt.

Jak naprawdę działa rynek wyboru CRM i ERP

Tu zaczyna się część, o której rynek mówi niechętnie. Dostawca nie jest Twoim doradcą, jest stroną transakcji, i to jest naturalne, a nie złośliwe. Mechanika sprzedaży systemów ma kilka stałych elementów, które łatwo rozpoznać, gdy raz się je zobaczy.

Pierwszy mechanizm to demo pod mocne strony. Sprzedawca prezentuje proces, w którym jego system błyszczy, i prowadzi rozmowę tak, by nie dotknąć obszarów słabych. Jeśli nie narzucisz własnych scenariuszy, zobaczysz spektakl, a nie test. Drugi mechanizm to sterowanie shortlistą: „porównania” i materiały dostawcy są tak zbudowane, żeby konkurencja wypadała blado w kategoriach akurat dla niego korzystnych. Trzeci to eskalacja ceny po podpisie, gdy „drobne dostosowania”, dodatkowe integracje i moduły okazują się płatne, a koszt wyjścia z danymi pojawia się dopiero w umowie. Czwarty to presja czasu, czyli „promocja tylko w tym kwartale”, której jedynym celem jest skrócenie Twojej analizy.

Wniosek nie jest taki, że dostawcy oszukują. Wniosek jest taki, że proces trzeba kontrolować metodą, a nie zaufaniem do prezentacji. RFP, własne scenariusze demo i scoring oparty na wagach przesuwają kontrolę z powrotem na stronę kupującego. Niezależność i twarde dane są tu jedyną realną redukcją ryzyka, dlatego coraz więcej zarządów sięga po niezależne doradztwo przy wyborze CRM i ERP.

Typy zapytań i typy dostawców, których spotkasz

Zanim napiszesz RFP, warto rozpoznać, z jakim typem zapytania i jakim typem dostawcy masz do czynienia. To zmienia sposób czytania ofert.

Typ Jak się objawia Co z tym zrobić
Zapytanie życzeniowe Lista ogólników: nowoczesny, intuicyjny, elastyczny. Każdy dostawca odpowie „tak”. Zamień każdy punkt na wymaganie sprawdzalne na demo.
Zapytanie z folderu dostawcy Lista funkcji skopiowana z materiałów jednego producenta. Wróć do procesów. RFP pisze się po audycie, nie z broszury.
Zapytanie procesowe Wymagania wynikają z realnych procesów i punktów bólu. To wzorzec. Dodaj wagi i scenariusze demo.
Dostawca pudełkowy Gotowy CRM lub ERP, mało zmian, szybkie wdrożenie, sztywny zakres. Sprawdź, czy Twoje kluczowe procesy mieszczą się bez przeróbek.
Dostawca szyjący na miarę Wszystko „da się zrobić”, koszt i czas rosną z każdą zmianą. Pytaj o cenę dostosowań i koszty utrzymania kodu na własność.
Integrator branżowy Doświadczenie w Twojej branży i w integracji z ERP. Wymagaj referencji z wdrożeń podobnych do Twojego.

Wybór między gotowym a szytym na miarę to osobna decyzja kosztowa i ryzykowa, rozkładamy ją na czynniki w materiale o tym, czy kupić gotowy CRM, czy zbudować szyty na miarę.

Proces, czyli RFP krok po kroku

RFP nie jest dokumentem, który pisze się „na wyczucie”. To proces o ustalonej kolejności, w której każdy krok zabezpiecza następny.

  1. Audyt procesów AS-IS. Najpierw mapujesz, jak firma pracuje dzisiaj i gdzie boli. Wymagania w RFP mają wynikać z procesów, a nie z folderu dostawcy. To dlatego RFP pisze się po, a nie przed audytem procesów AS-IS.
  2. Cel i kryteria sukcesu. Jeden, dwa mierzalne cele: skrócenie czasu ofertowania, pełny widok 360 klienta, mniej ręcznego przepisywania danych między systemami.
  3. Wymagania funkcjonalne. Każde powiązane z procesem i napisane tak, żeby dostawca odpowiedział „tak”, „nie” lub „częściowo”, bez miejsca na ogólnik.
  4. Wymagania techniczne. Integracje (ERP, e-mail, telefonia), eksport danych, RODO, warunki wyjścia. To tu chowa się TCO.
  5. Scenariusze do demo. Dwa, trzy realne procesy z Twojej firmy, które dostawca ma pokazać na żywo na Twoich danych, a nie na swojej prezentacji.
  6. Wagi i scoring. Ustalasz wagi wymagań zanim zobaczysz oferty. To one chronią przed uleganiem najlepszemu handlowcowi.
  7. Wysyłka, ocena, krótka lista, negocjacje. Oferty wracają na tych samych pytaniach, więc trafiają wprost do tabeli oceny.

Tu pojawia się skala. W dużych organizacjach sama odpowiedź na zapytanie potrafi angażować średnio 9 osób i 25 godzin pracy (Loopio, 2026). Dla małej i średniej firmy nie potrzebujesz takiej machiny. Wystarczy od 1 do 2 strony konkretnych wymagań, od 2 do 3 scenariusze do demo i tabela oceny. Zasada jest prosta: lepiej krótkie RFP z wymaganiami sprawdzalnymi niż trzydziestostronicowy dokument ogólników, na który każdy odpowie „tak”.

Scoring ofert, narzędzie do obiektywnego porównania

To jest serce metody i jednocześnie część, którą większość firm pomija. Składa się z dwóch elementów: poprawnie napisanego wymagania i tabeli oceny z wagami.

Najpierw wymaganie. Większość zapytań jest tak ogólna, że nie różnicuje dostawców. Porównaj lewą i prawą kolumnę.

Wymaganie słabe (każdy odpowie „tak”) Wymaganie dobre (różnicuje)
„System ma być intuicyjny” „Dodanie nowej szansy ma zajmować maks. 5 pól i 2 kliknięcia”
„System ma wspierać ofertowanie” „Oferta generowana z szablonu, z danymi klienta z bazy i cennikiem”
„System ma integrować się z ERP” „Dwukierunkowa integracja z ERP (Comarch Optima): kontrahenci, faktury, salda”
„System ma dawać raporty” „Raport lejka wg etapu i handlowca, eksport do XLS, odświeżany na żywo”
„System ma być bezpieczny” „Eksport całej bazy do CSV/XLS na żądanie, bez opłat, w 24h”

Dobre wymaganie jest sprawdzalne. Na demo możesz powiedzieć „pokażcie”, a w ofercie dostawca musi napisać wprost „tak”, „nie” albo „częściowo”. Każde takie wymaganie wynika z realnego procesu i punktu bólu, dlatego mapowanie wymagań na procesy jest fundamentem dobrego zapytania (Creately).

Gdy spłyną odpowiedzi, nie czytaj ich po kolei. Zestaw je w jednej tabeli oceny. Każde wymaganie dostaje wagę (od 1 do 3), a ocena spełnienia przez dostawcę to 0 (brak), 1 (częściowo) lub 2 (pełne). Punkty to waga razy ocena.

Wymaganie Waga Dostawca A Dostawca B
Integracja z Comarch Optima 3 2 (6 pkt) 1 (3 pkt)
Ofertowanie z szablonu 3 2 (6 pkt) 2 (6 pkt)
Eksport danych bez opłat 2 2 (4 pkt) 0 (0 pkt)
Aplikacja mobilna 1 1 (1 pkt) 2 (2 pkt)
Suma ważona   17 11

Nagle „wrażenie z prezentacji” zamienia się w liczbę opartą na Twoich priorytetach. Dostawca B prezentował się świetnie i wygrał mobilność, ale przegrał tam, gdzie miałeś najwyższe wagi: integracja z ERP i eksport danych bez opłat. To jest dokładnie ta różnica, której nie zobaczysz, czytając oferty po kolei. Wagi ustalasz wcześniej, bo to one bronią Cię przed najlepszym handlowcem.

Czerwone flagi i błędy, które psują wybór

W realnych implementacjach te same błędy wracają niezależnie od branży i wielkości firmy.

  • Ogólniki zamiast wymagań. „Intuicyjny, nowoczesny” nie różnicuje nikogo i jest najczęstszym błędem, jaki robi większość firm.
  • Kopiowanie listy funkcji dostawcy. Wtedy RFP jest pisane pod jego produkt, a konkurencja wypada gorzej z definicji.
  • Brak scenariuszy do demo. Bez nich zobaczysz prezentację mocnych stron, a nie swój proces.
  • Brak pytania o wyjście. Eksport danych i warunki rozwiązania umowy to wymaganie, nie szczegół. Tu rodzi się vendor lock-in.
  • Brak wag i tabeli. Bez nich decyzja wraca do pytania „który lepiej wypadł na spotkaniu”.
  • Presja czasu od dostawcy. „Promocja tylko w tym kwartale” to sygnał, że ktoś chce skrócić Twoją analizę, a nie obniżyć Twój koszt.

Jest jeszcze jedna flaga, którą firmy lekceważą: brak planu adopcji. Najlepiej wybrany system bywa nieużywany, jeśli zespół go nie przyjmie, dlatego warto już w RFP pytać o wsparcie wdrożeniowe i szkolenia, a osobno zaplanować adopcję CRM w zespole. Dobre RFP to najtańszy sposób, żeby porównać dostawców uczciwie i wejść na demo z konkretną listą do odhaczenia.

Najczęściej zadawane pytania (FAQ)

Czy mała firma w ogóle potrzebuje RFP na system CRM lub ERP?

W lekkiej formie tak. Nie chodzi o trzydziestostronicowy dokument, lecz o od 1 do 2 strony konkretnych, sprawdzalnych wymagań i od 2 do 3 scenariusze do demo. To wystarcza, żeby porównać dostawców obiektywnie, zamiast wybierać „pod prezentację”.

Co odróżnia dobre wymaganie w RFP od złego?

Sprawdzalność. „System ma być intuicyjny” potwierdzi każdy dostawca. „Dodanie szansy w maks. 5 polach i 2 kliknięciach” można zweryfikować na demo. Dobre wymaganie wynika z realnego procesu i daje jednoznaczne „tak” albo „nie”.

Kiedy pisać RFP, przed czy po audycie procesów?

Po. Wymagania w RFP powinny wynikać z mapy procesów i punktów bólu. Pisanie RFP bez audytu kończy się listą skopiowaną z folderu dostawcy, czyli zapytaniem pisanym pod cudzy produkt.

Jak porównać oferty, które wszystkie brzmią dobrze?

Tabelą oceny. Każde wymaganie dostaje wagę i punktację spełnienia przez dostawcę, a suma ważona zamienia wrażenia w liczbę opartą na Twoich priorytetach, ustalonych zanim zobaczysz oferty. To największa różnica między wyborem metodą a wyborem na emocjach.

Czy w RFP pytać o cenę od razu?

Tak, ale w kontekście modelu i zakresu (liczba licencji, co wchodzi we wdrożenie, koszty utrzymania), a nie samej kwoty. Dorzuć pytanie o warunki wyjścia i eksport danych, bo to część kosztu, którą najłatwiej przeoczyć.

Jak rozpoznać, że dostawca prowadzi demo pod swoje mocne strony?

Po tym, że prezentacja idzie według jego scenariusza, a nie Twojego. Antidotum jest proste: narzuć od 2 do 3 własne scenariusze z realnymi procesami firmy i poproś, żeby pokazał je na żywo. To, czego dostawca unika, jest zwykle ważniejsze od tego, co eksponuje.

Czy RFP chroni przed vendor lock-in?

Częściowo, jeśli zawiera twarde wymagania dotyczące eksportu danych, formatów i warunków rozwiązania umowy. Bez tych punktów koszt wyjścia ujawnia się dopiero w umowie i potrafi przewyższyć koszt samego wdrożenia.

Źródła

  1. Godlan (2025), ERP Implementation Failure Statistics, ponad 60% niepowodzeń wiąże się z fazą wymagań i wyboru. godlan.com/erp-implementation-failure-statistics
  2. Loopio (2026), RFP Response Trends and Benchmarks, średnio 9 osób i 25 godzin na odpowiedź na RFP. loopio.com
  3. Creately, ERP Business Process Mapping, powiązanie wymagań z procesami. creately.com/guides/erp-bpm