Producent wiązarów kratowych — drewnianych konstrukcji dachowych liczonych pod konkretny dach, konkretny rozstaw krokwi, konkretne obciążenie śniegiem. Każda oferta dedykowana, każda z osobna liczona w Excelu przez handlowca. Po trzech miesiącach pracy zamiast dwóch godzin w Excelu zostało pięć minut w przeglądarce — i zero błędnych wycen.
Kontekst: produkt, którego nie da się ułożyć w cenniku
Klient produkuje wiązary kratowe od osiemnastu lat. Trzydzieści osób, dwie hale produkcyjne, dostawy na budowy w promieniu 300 km. Wiązar kratowy to nie produkt z półki — to konstrukcja dachowa projektowana pod konkretną budowę, z konkretną geometrią dachu, kątami, rozstawem, obciążeniem śniegowym strefy klimatycznej, długością przęsła, klasą drewna.
Każda oferta jest unikalna. Klient (deweloper, biuro projektowe, indywidualny inwestor) przychodzi z rysunkiem dachu w PDF albo z listą parametrów. Handlowiec analizuje konstrukcję, dobiera typy wiązarów, liczy ilości, sprawdza ceny drewna i blachy gangnail z aktualnego cennika dostawców, dolicza marżę pod dany typ klienta, pakuje to w ofertę.
Współpracę zaczęliśmy w 2025 roku. Klient dotarł do nas po próbie kupna gotowego rozwiązania od dostawcy zagranicznego — okazało się, że to oprogramowanie projektowe (do liczenia wytrzymałości), nie ofertowe. Ofertowanie miało zostać w Excelu. Klient powiedział: „Nie chcę kolejnego Excela, chcę narzędzie, które przyjmuje parametry i wypluwa ofertę PDF, którą mogę wysłać klientowi w 5 minut".
Punkt startowy: 2 godziny w Excelu, 5 wersji „aktualnego" pliku
Status quo wyglądał następująco. Każdy z pięciu handlowców miał własną kopię „głównego" Excela, modyfikowaną pod siebie. Cennik drewna leżał w innym Excelu, aktualizowanym ręcznie przez kierownika zaopatrzenia. Cennik blach łączeniowych — w trzecim Excelu. Marże — pamięciowo, „bo Pan Janek wie, jakiemu klientowi ile dawać".
Konsekwencje były bolesne i mierzalne:
- Średnio 2 godziny na przygotowanie jednej oferty. Przy 60–80 zapytaniach miesięcznie to ~140 godzin pracy handlowca, z czego znaczna część to ręczne przepisywanie liczb między arkuszami.
- Klient czekał 2–3 dni na ofertę. Przy projektach budowlanych, gdzie inwestor wysyła zapytanie do trzech producentów, kto pierwszy odpowie — często ten dostaje zlecenie.
- Błędne wyceny — średnio jedna na dziesięć ofert miała pomyłkę: zła cena drewna z nieaktualnego cennika, pomylona ilość, źle przepisana marża. Część wychwytywała kontrola, część szła do klienta. Reklamacje, renegocjacje, czasem strata na zleceniu.
- Brak historii. Po roku nikt nie wiedział, ile klientowi X wycenialiśmy podobny dach poprzednim razem ani jaką dawaliśmy marżę.
Co rozważaliśmy i czego nie zrobiliśmy
Pierwszą myślą było „ulepszmy Excel". Można by zbudować skomplikowany arkusz z VBA, makrami i ochroną komórek. Odradziliśmy: każdy taki arkusz po roku staje się niezarządzalny, nikt nie wie kto co zmienił, żaden nowy handlowiec się go nie nauczy.
Drugą opcją był gotowy CPQ (Configure-Price-Quote) na rynku. Sprawdziliśmy trzy. Wszystkie były skierowane do firm dystrybucyjnych z katalogiem produktów — nie do producenta liczącego konstrukcję pod konkretny dach. Logika branżowa byłaby do napisania jako customizacja, koszt licencji + customizacji przekraczał koszt dedykowanego rozwiązania.
Wybraliśmy dedykowany system webowy. Trzy argumenty: (1) logika branżowa wymagała precyzyjnego modelu domeny (typy wiązarów, geometria, obciążenia) — łatwiej napisać od zera niż wciskać w schemat CPQ; (2) klient chciał, żeby system rósł — dorzucenie portalu B2B i integracji z produkcją w drugim etapie; (3) koszt rozwoju był niższy niż 3-letni TCO gotowego CPQ.
Rozwiązanie: konfigurator + cenniki + generator PDF
Krok po kroku
- Dobór wiązarów
- Cenniki dostawców
- Reguły marżowe
- Wersjonowanie
Najważniejszą częścią był silnik kalkulacyjny. Zaprojektowaliśmy go jako oddzielny moduł domenowy z testami jednostkowymi pokrywającymi wszystkie typy wiązarów. Handlowiec wprowadza parametry dachu (geometria, rozstaw krokwi, strefa śniegowa, klasa drewna), system sam dobiera typ wiązara z biblioteki, oblicza ilość desek, ilość blach gangnail, długość, przekroje, wagę, ostatecznie cenę.
Cenniki drewna i blach pobierane są raz dziennie z Exceli dostawców (zostawiliśmy ten formacik, bo dostawcy go nie zmienią — middleware czyta i wczytuje do bazy). Marże i polityka rabatowa zaszyte w regułach: klient typ A → marża X%, klient typ B → marża Y%, sezon zimowy → bonus Z%.
Ofertę handlowiec generuje jednym przyciskiem. PDF (QuestPDF) zawiera: rysunek poglądowy dachu (renderowany z parametrów), tabele wiązarów z wymiarami i wagą, kosztorys, warunki dostawy, czas realizacji, adres firmy, dane kontaktowe handlowca. Branding firmy, ładny layout, można wysłać klientowi w jednej wiadomości.
Trzy decyzje, które się sprawdziły
- Wersjonowanie cenników. Każda oferta zapisuje cenę z konkretnej wersji cennika. Po 3 miesiącach klient zapytał „dlaczego ta oferta była tańsza" — system od razu pokazał, która wersja cennika obowiązywała w dniu wystawienia.
- Konfigurator po polsku. Handlowcy nie chcieli „typowego SaaS-a po angielsku". Wszystko po polsku, bez żargonu, z polskimi nazwami typów wiązarów, jakich używają na co dzień.
- Eksport do produkcji. Po akceptacji oferty system generuje paczkę dla działu produkcji: lista materiałów, plan cięcia, etykiety. Eliminacja kolejnego ręcznego kroku.
Wdrożenie: 3 miesiące, 4 sprinty, jeden zespół
Pracowaliśmy w czterech dwutygodniowych sprintach. Sprint 1 — model domeny i silnik kalkulacyjny (sam silnik, bez UI, pokryty testami z prawdziwymi przykładami z Exceli klienta). Sprint 2 — UI konfiguratora i podstawowa kalkulacja end-to-end. Sprint 3 — generator PDF, integracja cenników, autoryzacja, audyt. Sprint 4 — eksport do produkcji, migracja historycznych ofert (300 najnowszych do bazy), szkolenia handlowców.
Każdy sprint kończył się demem dla handlowców i dla zarządu. Kilka istotnych poprawek (np. uproszczenie ekranu wprowadzania geometrii) wynikło właśnie z dem — handlowcy zobaczyli rzecz wcześniej i zgłosili konkrety, których nikt by nie wymyślił przy stoliku.
Wynik po 9 miesiącach od wdrożenia
Klient zwiększył liczbę obsłużonych zapytań ofertowych o około jedną trzecią bez zwiększania zespołu handlowego — bo handlowcy mają teraz czas na rozmowy z klientami zamiast siedzenia w Excelu. Czas odpowiedzi na zapytanie spadł z 2-3 dni do tego samego dnia, co zauważalnie poprawiło konwersję na zlecenia (klient nie zdąży zapytać konkurencji).
Wartość nie powstała w momencie napisania kodu. Powstała w momencie, w którym handlowiec po raz pierwszy wysłał klientowi ofertę 8 minut po jego telefonie i klient odpowiedział „wow, naprawdę szybko".
Co dalej
System działa, klient go rozwija. W 2026 planujemy drugi etap: portal klienta, w którym deweloperzy i biura projektowe będą wprowadzać zapytania samodzielnie, otrzymując wstępną wycenę natychmiast (handlowiec tylko zatwierdza i wysyła PDF). Do tego integracja z systemem produkcyjnym klienta, żeby zaakceptowana oferta wpadała od razu jako zlecenie produkcyjne.
To dobry przykład projektu, który zaczyna się od jednej, konkretnej bolączki (ofertowanie), a przy okazji uporządkowuje cały front-office firmy. Nie przepisujemy ERP. Nie zmieniamy procesów. Bierzemy najboleśniejszy punkt i go automatyzujemy — a to, co działa wokół, dorastamy w kolejnych etapach.
Twoja firma wycenia produkty pod konkretnego klienta i robi to ręcznie? Pogadajmy 30 minut o tym, co da się zautomatyzować — bez zobowiązań.
Umów bezpłatną konsultację →