Zapytanie ofertowe wpada na skrzynkę w środę po południu. Ktoś otwiera rysunek, mierzy otwór, liczy elementy montażowe, sprawdza w cenniku, czy ten wariant materiału jest jeszcze dostępny, i odpisuje. W piątek klient dopytuje, co się zmieni, jeśli hala będzie miała dwie bramy zamiast jednej — i cała procedura startuje od początku.

Nikt nie traktuje tego jako kosztu. To po prostu praca, którą ktoś wykonuje, bo tak się ją robiło od zawsze i robi się nadal. Tymczasem po drugiej stronie leży propozycja wdrożenia aplikacji, która policzy to samo w kilkadziesiąt sekund — i ta propozycja ma cenę wypisaną wprost. Jedna liczba jest widoczna, druga rozpuszczona w liście płac. Stąd wrażenie, że aplikacja jest droga, a zespół tani.

W tym artykule robimy rachunek, którego zwykle nikt nie robi. Pokazujemy też, co siedzi w środku takich aplikacji — bo skala tego, co liczą, jest zwykle dużym zaskoczeniem dla osoby, która zamawia „coś do wyceny na stronę".

Pierwszy błąd w tym rachunku to utożsamienie kosztu pracownika z jego pensją. Pracodawca dokłada do wynagrodzenia brutto ponad 20% w składkach i wpłatach — ZUS, PPK, Fundusz Pracy, FGŚP. Skala jest dobrze widoczna na dolnym progu: przy minimalnym wynagrodzeniu 2026 roku, czyli 4 806 zł brutto, całkowity koszt zatrudnienia wynosi 5 790,28 zł miesięcznie. W przypadku handlowców do podstawy dochodzi jeszcze prowizja rzędu 10–40%. Realna stawka godzinowa osoby, która liczy Twoje wyceny, jest więc wyraźnie wyższa niż liczba na pasku.

Drugi błąd jest poważniejszy: liczymy tylko wyceny, które skończyły się sprzedażą.

Zrób ten rachunek u siebie

Nie podajemy tu gotowych liczb, bo w każdej firmie są inne. Potrzebujesz czterech:

1. Całkowity koszt osoby, która przygotowuje wyceny — z narzutami, nie z paska.
2. Jaką część jej czasu zajmuje liczenie i odpisywanie na zapytania. U większości naszych klientów to nie 10%, jak się wydaje przed pomiarem.
3. Ile zapytań wpada miesięcznie.
4. Ile z nich nie kończy się zamówieniem.

Punkty 2 i 4 są tu najważniejsze. Za wyceny, które nic nie przyniosły, płacisz dokładnie tyle samo, co za te wygrane — i płacisz co miesiąc, niezależnie od koniunktury.

Do tego dochodzi koszt, którego nie widać w żadnej tabeli: pomyłka. Przy ręcznym liczeniu błąd jest kwestią czasu, a jego cena bywa zaskakująca — jedno z opisywanych na polskim rynku wdrożeń konfiguratora u producenta okien ograniczyło liczbę pomyłek o 64%, eliminując straty sięgające 80 tysięcy złotych rocznie. To liczba z rynku, nie z naszego wdrożenia — ale rząd wielkości daje do myślenia.

I tu dochodzimy do sedna. Aplikacja do wyceny to koszt jednorazowy z niewielkim ogonem utrzymania. Ręczne ofertowanie to koszt cykliczny, rosnący razem z liczbą zapytań — im lepiej działa Twój marketing, tym więcej płacisz za liczenie. Cała asymetria siedzi w tym jednym zdaniu.

Uczciwie trzeba pokazać też drugą stronę. Dedykowany konfigurator kosztuje w Polsce od około 25 tysięcy złotych netto w wersji podstawowej, a rozbudowane platformy B2B — z polityką cenową, progami rabatowymi i uprawnieniami użytkowników — zwykle mieszczą się w przedziale 60–200 tysięcy. Nie ma co udawać, że to mało.

Zaraz jednak dopowiedzmy rzecz, o której w takich tekstach zwykle się nie pisze: to jest górna półka i większość firm jej nie potrzebuje. Te kwoty dotyczą rozbudowanych systemów z wieloma modułami, integracjami i obsługą sieci dystrybutorów. Bardzo często wystarcza aplikacja, która liczy jedną rzecz i robi to dobrze — kilka pól, jasna reguła, gotowe zestawienie. Takie wdrożenia zamykamy zwykle w tygodniu pracy i w kwocie kilku tysięcy złotych. Nie ma w nich rysunków rozkroju ani polityki cenowej dla dystrybutorów, ale zdejmują z człowieka dokładnie tę samą powtarzalną robotę.

I tu jest rzecz, którą warto powiedzieć wprost: w małej firmie efekt bywa nawet większy niż w dużej. Nie w złotówkach, ale procentowo — bo w firmie trzyosobowej wyceny liczy zazwyczaj właściciel, czyli osoba o najdroższej godzinie i najdłuższej liście rzeczy, które tylko ona może zrobić. Odzyskanie jej dwóch wieczorów w tygodniu zmienia więcej niż odciążenie jednego handlowca w zespole dwudziestu.

Twierdzimy więc tylko tyle: niezależnie od tego, czy mówimy o kilku tysiącach czy o kilkuset, to jedyna z dwóch pozycji, którą ktokolwiek w ogóle policzył.

Wcześniej wycena wyglądała tak: rysunek techniczny w CAD-zie, ręczny obmiar, przełożenie go na materiały według reguł, które znała tylko najbardziej doświadczona osoba w firmie, sprawdzenie cennika, złożenie tego w mail. Przy każdej zmianie wymiaru — od nowa.

Warto powiedzieć wyraźnie: to nie było zaniedbanie, to była racjonalna decyzja. Reguły zużycia materiału naprawdę są trudne i naprawdę wymagają doświadczenia. Dwa przykłady z naszej pracy, żeby pokazać poziom rozgałęzienia.

Pierwszy dotyczy tego, jak zbudowany jest system produktowy. Jeśli narożniki i łączniki są w nim osobnymi produktami, aplikacja musi doliczać je według liczby rogów i długości obwodu. Jeśli natomiast docina się je z tego samego materiału co reszta — liczymy tylko metry bieżące. To zupełnie inna logika obliczeń, prowadząca do innego zestawienia i innej ceny, choć klient wpisał dokładnie te same wymiary.

Drugi jest jeszcze mniej oczywisty, bo nie ma go w wymiarach wcale. Dwa zamówienia o identycznej geometrii mogą wymagać dwóch różnych materiałów, bo jedno pójdzie do chłodni, a drugie na stanowisko spawalnicze. Pytanie „gdzie to będzie pracować" bywa więc ważniejsze od pytania „ile to ma metrów" — i dobra aplikacja zadaje oba, w tej właśnie kolejności.

Takich rozgałęzień w jednym systemie produktowym jest kilkadziesiąt i prawie żadnego nie da się odgadnąć z zewnątrz.

Dopóki ta wiedza nie jest zapisana w sposób policzalny, jedynym miejscem, w którym może mieszkać, jest głowa kosztorysanta. A głowa kosztorysanta bierze urlop, choruje i czasami odchodzi do konkurencji.

Dziś te same reguły są kodem. Nie dlatego, że kod jest mądrzejszy — dlatego, że jest zapisany, powtarzalny i dostępny o trzeciej w nocy. Rynek mierzy to zresztą od lat. W badaniach dotyczących systemów klasy CPQ 78% firm raportuje skrócenie czasu przygotowania wyceny o ponad połowę, a średnie skrócenie całego cyklu sprzedaży wynosi 28%. Uporządkowanie procesu konfiguracji i wyceny pozwala też przygotować około 49% więcej ofert w tej samej jednostce czasu. Polskie wdrożenia opisuje się podobnie: droga od briefu do wysłanej oferty skraca się z jednego–trzech dni do kilkudziesięciu minut.

Zwróćmy jednak uwagę, co dokładnie się tu zmieniło, bo to nie jest historia o szybkości. Że komputer liczy szybciej od człowieka, wiedzieliśmy przed CPQ i przed internetem. Prawdziwa zmiana jest inna:

Wiedza o produkcie przestała być zasobem jednej osoby, a stała się aktywem firmy.

To rozróżnienie brzmi jak figura retoryczna, a ma bardzo praktyczne skutki. Aktywo można sprawdzić, poprawić, powielić i przekazać dalej — z wiedzą w czyjejś głowie nie da się zrobić żadnej z tych czterech rzeczy. Można je udostępnić dystrybutorowi, żeby liczył sam, i można je — o czym pod koniec — podać dalej maszynie. Cena jest jedna: aktywo trzeba utrzymywać, i do tego też jeszcze wrócimy.

Ta część jest zwykle niedoceniana, bo trudniej ją policzyć niż oszczędność czasu.

Klient, który ma dostęp do aplikacji, nie pyta „ile to kosztuje" — sprawdza. I to jest różnica jakościowa, nie ilościowa. Sprawdza przy tym trzy warianty, czego mailem nigdy by nie zrobił, bo dopytywanie o trzecią wersję tej samej wyceny jest po prostu niekomfortowe. Przy okazji zaczyna rozumieć, dlaczego droższy wariant jest droższy. To nie przypadek, że opisywane na rynku wdrożenia z konfiguracją i natychmiastową wyceną raportują wyraźnie wyższą konwersję i wyższą średnią wartość zamówienia. Klient, który sam poskładał rozwiązanie, częściej wybiera pełniejszy zestaw.

Zmienia się też punkt startu rozmowy. Zapytanie, które trafia do handlowca, jest już skonfigurowane i policzone — więc rozmowa zaczyna się od „czy przy takim natężeniu ruchu to rzeczywiście najlepszy wariant", a nie od „ile okien ma mieć ten dom" i „jakie są wymiary otworu". Pytania, które zabierały pierwsze dziesięć minut każdej rozmowy, są już odpowiedziane, i to przez klienta. To znacznie lepsza rozmowa dla obu stron — wymagająca zupełnie innych kompetencji: doradczych, nie rachunkowych.

Aplikacja pracuje przy tym po obu stronach biurka. Handlowiec dostaje dokładnie to samo narzędzie: składa wycenę u siebie i wysyła klientowi link tylko do odczytu. Klient klika, ląduje w gotowym podsumowaniu i nie może niczego przestawić — a jednocześnie ma wszystko przed oczami, zamiast tabelki wklejonej w treść maila. Ten sam mechanizm pozwala wrócić do wyceny po dwóch tygodniach albo przekazać ją koledze.

Ta sama aplikacja łapie przy tym klienta w różnych momentach decyzji, zależnie od tego, gdzie ją postawimy: inaczej pracuje jako pełna podstrona dla kogoś, kto dopiero szuka, a inaczej jako okno wywoływane przy wybranym już produkcie. Wracamy do tego w następnej sekcji, bo z tego wynika więcej, niż się wydaje.

Na koniec efekt uboczny, o którym mało kto myśli przy zamawianiu: dane. Każda kalkulacja to informacja o tym, jakich wymiarów i wariantów szukają klienci oraz — co jeszcze ciekawsze — w którym kroku się zatrzymują. Po kilku miesiącach wiecie o swoim rynku rzeczy, których nie powie żadna ankieta.

Tu musimy się rozprawić z jednym słowem. „Kalkulator" sugeruje pole, w które wpisuje się metry, i pole, w którym pojawia się cena. Czasem naprawdę o to chodzi — i wtedy nie ma w tym nic złego, o czym pisaliśmy wyżej. Kłopot pojawia się, gdy tym samym słowem opisuje się coś o zupełnie innej skali, bo wtedy rozmowa o budżecie startuje od złej kotwicy. Dlatego dalej mówimy o aplikacjach — i poniżej pokazujemy, na czym polega różnica.

Skala logiki. Jedna z aplikacji, które rozwijamy, obsługuje kilka niezależnych modułów obliczeniowych dla jednego producenta — każdy z osobnym zestawem reguł, osobnym doborem produktów i osobnym sposobem prezentacji wyniku. Sama logika liczenia jest dziś większą częścią tej aplikacji niż jej interfejs, i jest obudowana zestawem testów. Nie z powodów estetycznych: pomyłka w zestawieniu materiału kosztuje kogoś realne pieniądze, a wychodzi dopiero przy montażu, gdy zamówienie jest już dostarczone.

Problemy, które trzeba w takiej aplikacji rozwiązać, dzielą się na trzy klasy — i żadna z nich nie jest dodawaniem. Co ciekawe, te same trzy klasy wracają w branżach, które z pozoru nie mają ze sobą nic wspólnego.

Optymalizacja rozkroju materiału. Jak pociąć materiał, żeby kupić go mniej — czy chodzi o listwy na wymiar, pasy z rolki, czy arkusze blachy. To klasyczny problem optymalizacyjny, w którym nie ma jednego oczywiście najlepszego rozwiązania, więc algorytm rozkroju porównuje kilka strategii cięcia i wybiera tę, która zostawia mniej odpadu. Wynik nie kończy się na liczbie w zestawieniu — trafia też na plan rozkroju do druku, z którym można wejść do warsztatu i wykonać cięcia dokładnie tak, jak zostały policzone.

To samo zadanie wraca w logistyce. Jak ułożyć paletę i jak rozplanować załadunek naczepy, żeby wyjechała pełna, to ten sam problem pakowania — tylko w trzech wymiarach i z dodatkowymi ograniczeniami: masa, nacisk na osie, kolejność rozładunku. Producent listew i spedytor są od siebie tak daleko, jak to możliwe, a pod spodem mają ten sam rachunek do zrobienia. W transporcie widać to zresztą wyjątkowo dosłownie: każda paleta, która zmieściła się dodatkowo, to ułamek przejazdu, którego nie trzeba wykonać — a przy kilkuset wyjazdach w roku te ułamki sumują się w kwoty, o których decyduje zarząd, nie magazynier.

Geometria, która nie jest tym, co narysował użytkownik. Powierzchnia, na której faktycznie leży materiał, bywa innym wielokątem niż ten widoczny na ekranie: obramowanie ma swoją grubość, wnęka drzwiowa powiększa pole, choć nie ma jej w obrysie, a komin czy świetlik trzeba ominąć i uszczelnić osobno. Osobna sprawa to trzeci wymiar — z podanych punktów wysokości budujemy model nachylonej powierzchni, a potem tłumaczymy go na policzalne warianty produktu. Dopóki tego nie zrobimy, pochyłość jest informacją na rysunku, a nie pozycją w zamówieniu.

Reguły, które wykluczają błędne kombinacje. Dobrze opisane zależności między produktami sprawiają, że aplikacja podpowiada poprawny zestaw i nie pozwala złożyć czegoś, czego nie da się zbudować albo czego nie wolno tam zastosować. Bywa, że wybór materiału odblokowuje jedne akcesoria i wyklucza inne, a przekroczenie pewnej szerokości otworu zmienia wymagany sposób montażu. To doświadczenie kosztorysanta zamienione w bezpiecznik — i często najbardziej doceniana funkcja, choć nikt jej nie widzi.

Jak bardzo takie rzeczy trzeba robić dokładnie, dobrze pokazuje jedna sytuacja z naszej pracy. Prosty pomysł „dodajmy margines bezpieczeństwa do wymiarów" okazał się, przy kształcie ze skosem, rozdmuchiwać jeden z wymiarów ponad dwukrotnie względem zamierzonego zapasu. Poprawnie trzeba przesunąć krawędzie równolegle, a nie dodać liczbę do wymiaru — i dopiero wtedy zapas jest tam, gdzie miał być. W wycenie materiału różnica między „prawie dobrze" a „dobrze" to nadmiar w zamówieniu, za który ktoś zapłaci.

Co użytkownik dostaje na wyjściu. Nie ekran z wynikiem, a dokumenty gotowe do pracy: zestawienie materiałów, arkusz kalkulacyjny, wydruk, rysunki rozkroju, zapisaną kalkulację do wznowienia po tygodniu. To granica między narzędziem poglądowym i narzędziem pracy — i praktyczny test, czy aplikacja rzeczywiście zdejmuje robotę z człowieka, czy tylko przenosi ją w inne miejsce.

Kto to potem utrzyma? To najczęstsze pytanie decydenta i zasługuje na uczciwą odpowiedź. W dobrze zaprojektowanej aplikacji reguły zużycia nie są zaszyte w kodzie — są danymi w katalogu produktowym. Producent zmienia u siebie wydajność produktu albo długość elementu, a aplikacja liczy po nowemu, bez naszego udziału i bez wdrożenia. Bez tego rozdzielenia każda zmiana w ofercie byłaby zleceniem dla programisty — i po roku nikt już by tej aplikacji nie aktualizował, bo prościej byłoby policzyć ręcznie.

I najważniejsze: to nie zakładka, to produkt. Aplikacja jest hostowana raz, a osadzana wielokrotnie — na stronie firmowej producenta, w jego systemie B2B, w sklepie, na stronach partnerów handlowych i na dedykowanych landing page'ach pod kampanie reklamowe. Aktualizacja w jednym miejscu trafia od razu do wszystkich osadzeń. Alternatywa, czyli kopia kodu na każdej stronie, umiera przy trzecim wdrożeniu, gdy trzeba poprawić jedną regułę w dziesięciu miejscach.

Ten ostatni przypadek wart jest osobnego akapitu, bo tu argument kosztowy z pierwszej sekcji domyka się po drugiej stronie. W kampanii Google Ads czy Meta Ads płacisz za klik niezależnie od tego, co się po nim stanie. Jeśli na landing page'u czeka formularz kontaktowy, kupiłeś zapytanie — czyli obietnicę, że ktoś z Twojego zespołu poświęci na nie czas, i to niezależnie od tego, czy było poważne. Jeśli czeka konfigurator, ten sam klik kupuje coś zupełnie innego: klienta, który sam się zakwalifikował i sam podał parametry. Ktoś, kto przeszedł pięć kroków wyceny, jest nieporównywalnie dalej w decyzji niż ktoś, kto wpisał adres e-mail — a koszt dotarcia do obu był identyczny.

Jest i drugi, mniej oczywisty zysk, czysto techniczny. Formularz daje jedno zdarzenie konwersji: wysłano albo nie. Aplikacja daje ich kilka — wejście do konfiguracji, przejście kolejnych kroków, dotarcie do podsumowania, pobranie zestawienia. Dla osoby optymalizującej kampanię to różnica między pomiarem raz na kilkadziesiąt kliknięć a stałym strumieniem sygnałów, na których algorytmy reklamowe faktycznie potrafią się uczyć. Widać też, które słowa kluczowe przyciągają ludzi kończących konfigurację, a które tylko takich, co ją otwierają i zamykają — czyli można optymalizować na jakość ruchu, nie na jego ilość. Sama zmiana tego, co stoi za kliknięciem, potrafi zrobić dla opłacalności kampanii więcej niż dowolna korekta stawek.

Zachowanie każdego osadzenia jest przy tym kwestią konfiguracji, nie osobnej wersji aplikacji: język, dostępne moduły, sposób wyświetlania, a także to, jakie ceny widzi dany odbiorca. I to jest wątek, który zwykle decyduje o powodzeniu projektu B2B — producent, jego dystrybutor i klient końcowy nie mogą widzieć tych samych liczb, a jednocześnie mają korzystać z jednego narzędzia. Rozwiązuje się to zasadą prostą do wypowiedzenia i wcale nie prostą do wdrożenia: każde osadzenie dostaje wyłącznie te ceny, które wolno mu zobaczyć — decyduje o tym serwer, nie przeglądarka.

Podobnie z koszykiem. Aplikacja osadzona w cudzym sklepie nie dopisuje do niego nic samodzielnie — prosi stronę, na której jest osadzona, a operację wykonuje już ta strona, ze swoją sesją i swoimi cenami. Wygląda to jak komplikacja, a jest jedyną drogą, która działa stabilnie i nie zmusza nikogo do zaufania obcemu skryptowi w kwestii cen. Tą samą drogą jadą opisane wyżej zdarzenia do analityki.

Do tego dochodzi kontrola nad zasięgiem: to właściciel decyduje, kto może osadzić aplikację u siebie — poza listą dozwolonych domen po prostu się nie uruchomi. W modelu, w którym narzędzie trafia do sieci dystrybutorów, to nie drobiazg, a warunek wejścia.

Zsumujmy tę sekcję, bo to jest właściwa odpowiedź na tytuł artykułu. Aplikacja, o której mówimy, jest jednocześnie narzędziem sprzedaży producenta, narzędziem pracy jego dystrybutorów i kanałem, przez który obaj docierają do klienta końcowego. To nie koszt marketingowy — to produkt z własnym modelem przychodu. I dlatego nie mierzy się go ceną wdrożenia, a tym, co zastępuje i co umożliwia.

Odpowiedź brzmi nudno, ale jest prawdziwa: technologię wybiera miejsce, w którym aplikacja ma żyć, a nie preferencje zespołu.

Gdy w środku jest ciężka geometria, rysowanie i przeliczanie w czasie rzeczywistym, sięgamy po Angulara z biblioteką do grafiki dwuwymiarowej — plus tryb pracy offline, bo część naszych użytkowników liczy na budowie, a nie w biurze. Gdy aplikacja musi wejść w istniejący sklep albo CMS, kluczowa jest nie technologia, a model osadzenia: jedno hostowane wdrożenie zamiast mnożenia wersji. Gdy aplikacja jest wabikiem na stronie treściowej, liczy się widoczność w wyszukiwarce i szybkość — tu naturalnym wyborem jest Next.js. Katalog produktów, ceny i uprawnienia najczęściej stoją na PHP i Laravelu albo po prostu na istniejącym backendzie klienta, a tam gdzie ważna jest wygoda redakcji treści, wchodzą WordPress, Drupal lub Payload CMS — zależnie od tego, kto będzie tę treść prowadził i jak rozbudowana jest struktura serwisu. Vue i React pojawiają się wtedy, gdy aplikacja ma być komponentem w cudzym, już działającym front-endzie — i wtedy dyskusja o naszych upodobaniach jest bezprzedmiotowa.

Ta lista jest u nas dłuższa, ale reguła zawsze ta sama. Zanim wybierzemy narzędzie, odpowiadamy na jedno pytanie: gdzie ta aplikacja będzie mieszkać przez najbliższe pięć lat i kto będzie ją wtedy utrzymywał. Wybór podyktowany modą na tym pytaniu przegrywa zawsze.

W naszym warsztacie — już dziś. Sztuczna inteligencja wyraźnie skraca drogę od reguły biznesowej do kodu i testów, pomaga wyłapywać przypadki brzegowe i utrzymywać dokumentację. Pisaliśmy o tym szerzej w kontekście projektowania UX/UI, a w aplikacjach obliczeniowych działa to podobnie. Z jednym istotnym ograniczeniem: reguły zużycia i tak muszą przyjść od producenta, a poprawność sprawdzamy o ręcznie policzony przykład wzorcowy. To kryterium odbioru, którego żaden model nie zastąpi — bo punktem odniesienia jest rzeczywistość, nie wiarygodnie brzmiąca odpowiedź.

W przyszłości — jako rdzeń tych aplikacji. Klienci już dziś pytają modele o produkty, zanim trafią na stronę producenta. Ruch z narzędzi AI do sklepów wzrósł o 125% rok do roku, a w sezonie zakupowym 2025 sztuczna inteligencja wpłynęła na 20% globalnej sprzedaży online, wartej 262 miliardy dolarów. Standardy handlu agentowego, ogłoszone przez Google i OpenAI, mają już po kilkudziesięciu dużych uczestników.

Nasz wniosek jest może mniej efektowny, niż sugerowałby nagłówek: zmieni się interfejs, a nie fundament. Formularz w wielu przypadkach ustąpi rozmowie — ale silnik reguł zostaje, tylko przestaje być czymś, w co kliknie człowiek, a staje się narzędziem, po które sięgnie agent. Kto ma dziś reguły policzalne, otestowane i dostępne przez API, jest na to gotowy. Kto ma je w głowie handlowca — nie jest, niezależnie od tego, jak dobry jest ten handlowiec. To temat na osobny wpis i wrócimy do niego.

Ten tekst był wstępem. W kolejnych wpisach chcemy zejść z poziomu ogólnych zasad na poziom konkretnego wdrożenia i odpowiedzieć na pytania, które w takim projekcie zawsze wracają:

• Jak zebrać reguły zużycia od producenta, gdy katalog zawiera karty techniczne, ale nie dane w formie gotowej do liczenia.
• Co robimy, gdy wynik aplikacji różni się od wyniku kosztorysanta — bo na początku projektu różni się prawie zawsze, i nie zawsze myli się aplikacja.
• Jak przebiega wdrożenie u sieci dystrybutorów, gdzie każdy widzi inne ceny i ma inne uprawnienia.

Kilka z aplikacji, które budujemy, można obejrzeć od strony użytkownika:

• Arco AZ — generalny dystrybutor membran hydroizolacyjnych EPDM. Odbiorcami aplikacji są profesjonaliści: dekarze, wykonawcy, architekci i kierownicy budów, czyli osoby, które wynik natychmiast weryfikują na budowie.
• Kurtyny Pasowe — producent kurtyn paskowych w wielu odmianach: spawalniczych, do chłodni, antystatycznych, trudnopalnych. Obietnica ze strony brzmi „zamów kurtynę pasową w kilku prostych krokach" — i to jest dobry opis celu, bo prostota po stronie użytkownika jest tu efektem, nie punktem wyjścia.
• Mafika — producent modułowych domów mobilnych. Tutaj aplikacja nie jest osobną podstroną, a zakładką na karcie konkretnego modelu. Dobry przykład tego, o czym pisaliśmy wyżej: sposób osadzenia bywa ważniejszy niż sama aplikacja, bo decyduje o tym, w którym momencie decyzji klient ją spotka.

Jeśli w Twojej firmie ktoś liczy wyceny ręcznie i nikt nigdy nie policzył, ile to kosztuje — zacznij od ramki na początku tego artykułu. Wynik zwykle wystarcza, żeby rozmowa o budżecie wyglądała inaczej.