Sześcioosobowa firma montażowa i cztery arkusze Excela. Modelowe przejście przez jedno popołudnie: co napisać w promptcie, co powstaje samo, co trzeba doszlifować ręcznie i co realnie zmienia się w pierwszym miesiącu.
Ten tekst to przejście przez jedno popołudnie - od czterech arkuszy Excela do działającej ewidencji zleceń. Jest napisany jako modelowy przypadek małej firmy montażowej, ale kolejność kroków i miejsca, w których zwykle się zacina, odpowiadają temu, co widzimy najczęściej przy zakładaniu pierwszego workspace'u.
Stan wyjściowy: cztery arkusze i jedna tablica korkowa
Sześć osób. Dwóch monterów w terenie, jeden handlowiec, jedna osoba w administracji, właściciel i jego żona zajmująca się fakturowaniem. Zlecenia: montaże wnętrz, zwykle 15 do 40 równocześnie w toku.
Gdzie to wszystko żyło przed tym popołudniem:
- zlecenia_2026.xlsx - główny arkusz, którego nikt nie mógł otwierać jednocześnie z kimś innym
- kontakty.xlsx - klienci, czasem zdublowani
- terminy.xlsx - co i kiedy trzeba zrobić, aktualizowany nieregularnie
- godziny.xlsx - karty pracy monterów, uzupełniane wstecz pod koniec miesiąca
- tablica korkowa w biurze, na której wisiały papierowe zamówienia
Bolesny punkt, który przeważył szalę: dwa razy w ciągu pół roku firma zapomniała wystawić fakturę za skończone zlecenie. Raz na 2 700 €.
Co napisałem w promptcie
Nic technicznego. Dosłownie to:
Potrzebuję ewidencji zleceń dla firmy montażowej. Przy każdym zleceniu chcę wiedzieć, kim jest klient, jaki jest termin montażu, który monter je realizuje, ile godzin przepracował i czy zostało zafakturowane. Chcę widzieć, co trzeba zrobić w tym tygodniu, i chcę dostawać powiadomienie, gdy zlecenie jest gotowe, a nie ma faktury.
Żadnej „bazy relacyjnej", żadnego „silnika workflow". Opis tego, co system ma robić, w takiej kolejności, w jakiej mi się to nasunęło.
Z opisu powstał plan, nie od razu gotowa rzecz
System najpierw pokazał, co zamierza założyć - bazy danych, relacje i automatyzacje. Zbudował je dopiero po zatwierdzeniu.
Co z tego powstało (i co musiałem doszlifować)
Po jakichś dwudziestu minutach stały trzy powiązane bazy danych - Zlecenia, Klienci, Monterzy - plus karty czasu pracy powiązane ze zleceniem. Do tego trzy widoki: kalendarz montaży, tabela niezafakturowanych i kanban według statusu.
Co pasowało od razu:
- relacje między zleceniem a klientem (jedno zlecenie, jeden klient; klient może mieć wiele zleceń)
- karta godzin przypisana do zlecenia i do montera
- widok „ten tydzień" jako kalendarz
Co musiałem doszlifować ręcznie:
- Statusy zlecenia. Wygenerowane były ogólne (Nowe / W toku / Gotowe). U nas jest pięć statusów, w tym „Czeka na materiał", który jest u nas najczęstszą przyczyną opóźnień. Zmiana nazw i dodanie nowych zajęły parę minut.
- Kto co widzi. Monterzy nie powinni widzieć cen. To ustawia się osobno - i dobrze, bo to jest coś, czego maszyna nie powinna wymyślać za nas.
- Treść przypomnienia. Automatyczny e-mail miał generyczną treść. Przepisałem go, żeby brzmiał jak my.
Ogólnie: prompt zrobił 80% struktury, reszta to było ustawianie, nie budowanie.
Najtrudniejsza część nie była techniczna
Najdłużej zastanawiałem się, czym właściwie jest zlecenie. Czy zlecenie to jeden montaż, czy całe zamówienie od klienta, które może obejmować trzy montaże. Tego pytania nie rozwiąże za nas żadne narzędzie - ale to godzina myślenia, nie miesiąc programowania.
Automatyzacja, dla której to wszystko powstało
Jedna reguła, dwa warunki:
Gdy zlecenie ma status „Gotowe" dłużej niż 3 dni i nie ma podpiętej faktury, wyślij mi e-mail.
To jest całe rozwiązanie problemu, który kosztował firmę 2 700 €. Ustawienie zajęło jakieś sześć minut.
Druga reguła doszła tydzień później, gdy się okazało, że monterzy zapominają wpisywać godziny:
Każdy piątek o 15:00 wyślij monterowi listę zleceń, przy których był w tym tygodniu, a nie ma do nich karty godzin.
Co się zmieniło po miesiącu
Trzy rzeczy, mierzalne:
Fakturowanie. W pierwszym miesiącu dwa zlecenia, które wcześniej by przepadły, zafakturowane na czas. To samo w sobie spłaciło system na kilka lat do przodu.
Koniec wersji arkusza. Przestało istnieć pytanie „który arkusz jest aktualny". Nie dlatego, że ludzie się poprawili, tylko dlatego, że jest już tylko jeden.
Poranna odprawa. Skróciła się z dwudziestu minut do pięciu, bo nie trzeba już na głos przechodzić, co gdzie jest. Kalendarz montaży pokazuje to samo szybciej.
Co się natomiast nie zmieniło: monterzy nadal czasem zapominają wpisać godziny. System tylko w piątek o tym przypomina. Narzędzie nie zmienia nawyków, tylko skraca czas, po którym błąd wychodzi na jaw.
Gdybym miał zrobić to jeszcze raz
Trzy rzeczy, które zrobiłbym inaczej:
- Zacząłbym skromniej. Na samym początku spróbowałem dodać jeszcze magazyn materiałów. Niepotrzebnie - po dwóch tygodniach nikt z niego nie korzystał. Dodać można w każdej chwili.
- Zaangażowałbym ludzi wcześniej. Zbudowałem to sam, a potem im pokazałem. Gdybym zapytał administrację wcześniej, zaoszczędziłbym sobie dwóch przeróbek widoków.
- Nie przenosiłbym całej historii. Zaimportowałem trzy lata starych zleceń. Wystarczyłby ostatni rok - reszta tylko zaśmieciła widoki.
Kto szuka bardziej szczegółowej, krok po kroku instrukcji dla części sprzedażowej, znajdzie ją w poradniku CRM na miarę bez programisty. Praktyczny sposób przenoszenia danych opisuje tekst Migracja z Excela lub Notion. A jeśli zastanawiasz się, kiedy w ogóle warto odejść od arkuszy, odpowiada na to artykuł Kiedy Excel przestaje wystarczać. Cały proces od decyzji po pierwszy miesiąc działania prowadzi przewodnik po systemie firmowym na miarę.
Najczęstsze pytania o start własnego systemu
Czy naprawdę poradzi sobie z tym osoba nietechniczna?
Poradzi, jeśli potrafi opisać, jak działa jej firma. To jest ta trudniejsza część - i nikt jej za nas nie zrobi. Wykonanie techniczne jest dziś sprawą drugorzędną.
Ile czasu powinienem na to przeznaczyć?
Na pierwszą używalną wersję liczcie jedno popołudnie. Na wersję, z której zespół jest zadowolony, dwa do trzech tygodni normalnej pracy i bieżącego dopracowywania.
Co jeśli się okaże, że zaprojektowałem to źle?
To się zdarza niemal zawsze i to jest w porządku. Pola, statusy i relacje można zmieniać w trakcie działania - inaczej niż w wytworzonej aplikacji, gdzie zmiana modelu danych to zadanie dla programisty.