Dlaczego w ogóle o tym mówimy
Pytanie „dlaczego software house odrzuca klientów” brzmi niewygodnie — większość firm IT nie przyznaje się do tego publicznie, bo boi się zniechęcić zleceniodawców. W praktyce jest odwrotnie: firma, która mówi wprost kiedy i dlaczego odmawia, buduje więcej zaufania niż taka, która bierze każdy projekt bez pytań.
Powód jest prosty. Jeśli zgadzamy się na projekt, który od początku nie ma szans się udać — niezależnie od tego jak dobry jest kod czy jak sprawny zespół — to nie jest sukces sprzedażowy. To odroczona porażka, która i tak wyjdzie na jaw, tylko później i drożej. Kwalifikacja klienta IT nie chroni tylko nas — chroni też Was przed podpisaniem umowy, której wynik biznesowy jest z góry przesądzony.
Konkretna liczba z ostatniego kwartału
W ostatnim kwartale DC House odrzuciło 3 z 8 zapytań, które trafiły do pierwszej, kwalifikacyjnej rozmowy — 37,5%. To nie jest liczba wymyślona na potrzeby tego artykułu ani wygładzona statystyka z prezentacji sprzedażowej — to prosty rachunek z ostatnich trzech miesięcy pracy.
Ta proporcja — mniej więcej co trzecie zapytanie — jest wystarczająco wysoka, żeby zauważalnie wpływać na miesięczny wynik sprzedażowy. Gdyby celem było wyłącznie maksymalizowanie liczby podpisanych umów, łatwiej byłoby złagodzić kryteria i przyjąć więcej z tych 3 odrzuconych zapytań. Fakt, że tego nie robimy, mimo realnego kosztu w postaci utraconego przychodu, jest najlepszym dowodem, że to nie jest deklaracja na pokaz — to konsekwentnie stosowana zasada, która kosztuje realne pieniądze co kwartał.
Powód pierwszy — rozjazd budżetu z zakresem
Najczęstszy scenariusz: klient ma wyobrażenie projektu wartego kilkanaście tysięcy złotych, a rzeczywisty zakres — po rozmowie o tym co faktycznie ma być zrobione — wymaga budżetu kilkukrotnie wyższego.
To nie jest sytuacja, w której „da się taniej, jeśli pójdziemy na skróty”. Pójście na skróty w tym momencie oznacza dokładnie to samo odroczone niepowodzenie — projekt zostanie zrobiony, ale w wersji okrojonej na tyle, że nie rozwiąże pierwotnego problemu, dla którego klient w ogóle się zgłosił. Na papierze wygląda to jak sukces: umowa podpisana, faktura wystawiona, kod oddany. W praktyce klient po trzech miesiącach wraca z pytaniem, dlaczego nic się nie zmieniło w codziennej pracy zespołu.
Uczciwsza odpowiedź w takiej sytuacji to wprost powiedzieć: przy tym budżecie możemy zrobić X, nie Y — i zostawić klientowi decyzję, czy X mu wystarczy, zamiast udawać że Y jest możliwe za ułamek realnej ceny. Gdy projekt ma sens, dopiero wtedy pojawia się Zwiad — i dopiero po nim cena z umowy jest ostateczna.
Powód drugi — przekonanie, że AI rozwiąże problem organizacyjny
Coraz częściej zapytania brzmią: „chcemy wdrożyć AI, żeby rozwiązać problem z [chaosem w danych / brakiem komunikacji między działami / powtarzającymi się błędami w zamówieniach]”.
Problem w tym, że w większości takich przypadków źródłem problemu nie jest brak technologii — jest nim proces, który nigdy nie został uporządkowany. AI (czy jakakolwiek automatyzacja) zbudowana na chaotycznym procesie nie naprawia chaosu — automatyzuje go, tylko szybciej i na większą skalę. Jeśli nikt w firmie nie wie, kto jest właścicielem konkretnego pola danych, żaden model językowy tego nie ustali za Was.
W takich sytuacjach uczciwa odpowiedź brzmi: najpierw trzeba ustalić kto jest odpowiedzialny za które dane i jak realnie wygląda proces, dopiero potem ma sens rozmowa o narzędziach — nawet jeśli to oznacza, że najpierw potrzebny jest Zwiad, nie wdrożenie AI wprost. Czasem wynik Zwiadu brzmi: „najpierw macierz odpowiedzialności danych i jeden wspólny proces, potem ewentualnie agent”. To nie jest odmowa technologii — to właściwa kolejność.
Powód trzeci — brak gotowości organizacyjnej na zmianę
Ostatni, najtrudniejszy do zdiagnozowania na pierwszej rozmowie powód: firma technicznie chce zmiany, ale organizacyjnie nie jest na nią gotowa — nowy system wymaga, żeby ludzie zmienili sposób pracy, a nikt w firmie nie ma mandatu ani chęci, żeby to wyegzekwować.
Wdrożenie w takich warunkach kończy się zwykle tym samym scenariuszem: nowy system stoi obok starych nawyków, zespół po cichu wraca do Excela, a inwestycja w oprogramowanie nie przynosi żadnej z obiecanych korzyści — nie dlatego że system był zły, tylko dlatego że nikt go realnie nie zaczął używać.
Sygnały bywają subtelne już na pierwszej rozmowie: „zróbcie system, a my jakoś wdrożymy ludzi”, brak osoby odpowiedzialnej za adopcję po stronie klienta, albo oczekiwanie że zmiana procesu „zrobi się sama”, bo narzędzie jest wygodniejsze. Bez właściciela zmiany po Waszej stronie nie bierzemy projektu — bo wiemy, czym to kończy się pół roku później.
Co się dzieje, gdy mimo wszystko powiemy tak
Kilka razy zdarzyło się zignorować własne sygnały ostrzegawcze — presja czasu, chęć domknięcia miesiąca sprzedażowego, nadzieja że tym razem będzie inaczej. Wynik był za każdym razem ten sam: projekt, który technicznie się zakończył, ale biznesowo nie przyniósł klientowi obiecanej wartości, bo pierwotny problem (budżet, proces, gotowość organizacyjna) nigdy nie został rozwiązany, tylko przykryty nowym oprogramowaniem.
To jest dokładnie ta lekcja, która stoi za decyzją mówienia NIE wcześniej, nie później — koszt rozczarowania po nieudanym wdrożeniu jest wyższy, dla obu stron, niż koszt niezręcznej rozmowy na starcie.
Jak to wygląda w praktyce — pierwsza rozmowa, nie Zwiad
Odrzucenie nie następuje po podpisaniu umowy ani nawet po Zwiadzie — dzieje się już podczas pierwszej, bezpłatnej rozmowy (45 minut), zanim ktokolwiek zapłaci za cokolwiek. To jest właśnie sens tego etapu: sprawdzić, czy w ogóle warto iść dalej, zanim obie strony zainwestują czas i pieniądze w coś, co ma niewielkie szanse się udać. Umówienie rozmowy nie zobowiązuje do Zwiadu — zobowiązuje tylko do uczciwej odpowiedzi po 45 minutach.
Jeśli po tej rozmowie odpowiedź brzmi „nie teraz” — mówimy to wprost, zamiast przeciągać temat albo próbować sprzedać coś, czego klient jeszcze nie potrzebuje. Jeśli odpowiedź brzmi „tak, warto iść dalej” — kolejnym krokiem jest Zwiad IT krok po kroku: mapa procesów, ocena danych i wycena, zanim padnie decyzja o wdrożeniu.
Sygnał, że warto zapytać wprost, zanim zaczniecie projekt
Jeśli podczas pierwszej rozmowy z jakąkolwiek firmą IT (nie tylko z nami) nikt nie zadaje pytań o budżet, proces czy gotowość zespołu na zmianę — to sam w sobie jest red flag przy wyborze firmy IT. Firma, która bierze każdy projekt bez weryfikacji, nie robi tego z odwagi. Robi to dlatego, że nie ponosi kosztu niepowodzenia — ten koszt w całości spada na klienta, długo po tym jak faktura została opłacona. Kiedy firma IT nie powinna brać projektu? Dokładnie wtedy, gdy te pytania są niewygodne albo celowo pomijane.
To nie jest wyjątek — to konsekwentna zasada
Te trzy powody nie są listą sporządzoną post factum, żeby uzasadnić pojedyncze, niewygodne decyzje. To konsekwentnie stosowana zasada, sprawdzana przy każdym nowym zapytaniu, niezależnie od tego jak duży jest potencjalny kontrakt czy jak bardzo brakuje akurat projektów w kalendarzu. Presja żeby zignorować te sygnały bywa realna — zwłaszcza w miesiącach ze słabszą sprzedażą — ale to właśnie wtedy najłatwiej o decyzję, której koszt wychodzi na jaw dopiero kilka miesięcy później.
Różnica między odmową a brakiem pomocy
Odrzucenie zapytania nie oznacza zostawienia klienta bez żadnej odpowiedzi. W większości przypadków rozmowa kończy się konkretną wskazówką — czego brakuje, w jakiej kolejności warto to poukładać, czy sensowniejsze byłoby zacząć od mniejszego, tańszego kroku zamiast od razu od pełnego wdrożenia. To różnica między „nie, do widzenia” a „nie teraz, i oto dlaczego” — druga opcja zostawia klienta w lepszym punkcie niż zastał, nawet bez podpisanej umowy.
Czasem ta wskazówka brzmi: wróćcie za pół roku z innym budżetem. Czasem: najpierw uprośćcie jeden proces wewnętrznie, potem wróćcie na Zwiad. Czasem: potrzebujecie właściciela zmiany w zarządzie, zanim ktokolwiek napisze kod. Żadna z tych odpowiedzi nie jest odmową pomocy — jest mapą, której często brakuje po rozmowie z firmą IT, która mówi „tak” na wszystko.
Dlaczego to akurat DC House mówi o tym głośno
Wiele firm IT zapewne stosuje podobną selekcję klientów wewnętrznie, nie mówiąc o tym publicznie — bo brzmi to ryzykownie z punktu widzenia marketingu. Decyzja żeby mówić o tym wprost wynika z prostego założenia: klient, który rozumie zasady kwalifikacji zanim zadzwoni, przychodzi na pierwszą rozmowę lepiej przygotowany — wie czego się spodziewać, nie traktuje pytań o budżet czy gotowość zespołu jako przesłuchania, tylko jako naturalny element rozmowy.
To też filtr sam w sobie: klienci, którym nie podoba się takie podejście — którzy oczekują, że każda firma IT powie „tak” na wszystko — zwykle sami rezygnują z kontaktu, zanim dojdzie do pierwszej rozmowy. To oszczędza czas obu stronom, nie tylko DC House.
Co dzieje się z tymi 3 na 8 dalej
Odrzucone zapytanie rzadko kończy się całkowitą ciszą. W większości przypadków klient dostaje konkretną wskazówkę — czy problem leży w budżecie (i wtedy warto wrócić za pół roku, gdy sytuacja finansowa firmy się zmieni), czy w kolejności działań (najpierw uporządkować proces, dopiero potem myśleć o narzędziu), czy w gotowości zespołu na zmianę (i wtedy sugerujemy zacząć od mniejszego, testowego kroku, zanim zdecydują się na pełne wdrożenie).
Część z tych 3 na 8 wraca po kilku miesiącach, gdy sytuacja się zmieniła — budżet się znalazł, proces został uporządkowany wewnętrznie, albo zespół był już gotowy na zmianę, której wcześniej unikał. To pokazuje, że odrzucenie nie jest ostateczne — jest odroczeniem do momentu, w którym projekt faktycznie ma szansę się udać, zamiast wymuszaniem go na siłę w warunkach, które od początku były przeciwko niemu.
Jeśli rozpoznajesz u siebie jeden z tych trzech sygnałów — albo chcesz sprawdzić, czy Wasz projekt w ogóle ma szansę przejść kwalifikację — umów bezpłatną rozmowę (45 min). Na koniec i tak usłyszysz konkretną odpowiedź: tak, idziemy w Zwiad — albo nie teraz, i oto dlaczego.