Dwa raporty, dwie różne sprzedaże
Handlowcy liczą z CRM-u, księgowość z faktur, a zarząd dostaje obie liczby na tym samym spotkaniu. Spotkanie zaczyna się od ustalania, która z nich jest prawdziwa, a nie od decyzji.
Buduję zestawienia i panele liczone z tych samych danych, na których firma pracuje na co dzień, bez sklejania plików i ręcznego poprawiania formuł. A gdy dane przestaną spływać, raport ma to powiedzieć wprost, a nie pokazywać liczby sprzed tygodnia jako aktualne.
Raport, którego liczby trzeba sprawdzać, nie oszczędza czasu. Przenosi tylko pracę z tworzenia zestawienia na jego weryfikację.
Handlowcy liczą z CRM-u, księgowość z faktur, a zarząd dostaje obie liczby na tym samym spotkaniu. Spotkanie zaczyna się od ustalania, która z nich jest prawdziwa, a nie od decyzji.
Ktoś pobiera pliki z trzech systemów, skleja je w arkuszu i naprawia formuły, które znowu się rozjechały. Raport jest gotowy w południe i już wtedy opisuje miniony tydzień.
Prowizje, zwroty i należności liczy się wstecz, z maili i notatek, bo w trakcie miesiąca nikt nie zapisywał ich w jednym miejscu. Każde takie odtwarzanie kończy się dyskusją.
Źródło przestało zasilać raport, ale wykres wygląda normalnie, tylko się nie rusza. Nic nie świeci na czerwono, więc nikt tego nie zauważa, a decyzje zapadają na podstawie stanu, który już nie istnieje.
Zaczynał jako prosta lista, a dziś ma tysiąc wierszy, kilka zakładek i komórki, w których mieści się po parę informacji naraz. Działa, dopóki ktoś nie doda kolumny w złym miejscu.
Raport składa ktoś, kto zna wszystkie wyjątki i ręczne korekty. Gdy jest na urlopie, raportu nie ma, a gdy raport jest, nikt inny nie potrafi go obronić.
Zaczynam od pytania, na które raport ma odpowiadać, i od tego, gdzie dziś rodzi się każda liczba. Potem wybieramy jedno zestawienie, które kosztuje najwięcej ręcznej pracy, i doprowadzam je do produkcji, zanim dojdą kolejne.
Każda zmiana statusu zamówienia trafia do historii: z jakiego etapu, na jaki, kiedy i kto ją zrobił. Prowizja jest przypięta do zamówienia, z którego wynika, więc na koniec miesiąca nikt nie musi jej odtwarzać.
Stan każdej sprawy, na przykład zamówienia albo wpłaty, jest jawnie zapisany w systemie, a panel pokazuje go na żywo. Sprawa w złym stanie jest widoczna od razu, a nie dopiero wtedy, gdy klient napisze z pytaniem, gdzie są jego pieniądze.
Gdy proces działa w arkuszu Google, poprawki mogą wskoczyć od razu przy edycji komórki: format numeru telefonu poprawia się sam, a dane stałego klienta uzupełniają się po jego numerze identyfikacyjnym. Wiersz jest poprawny w chwili zapisu, więc SMS nie trafia na źle zapisany numer, a stałego klienta nikt nie wpisuje od nowa.
Dwa typowe sposoby, w jakie panel kłamie: pokazuje metryki, których dane źródłowe dawno usunięto, albo zadanie synchronizacji zgłasza sukces, nie zapisując niczego. Dlatego liczby w panelu powinny być przeliczane ze źródła za każdym razem, a żaden przebieg nie powinien ogłaszać sukcesu, dopóki nie odczyta z powrotem tego, co zapisał.
Przy przenoszeniu danych z płatnego systemu bez eksportu sprawdzanie na oko łatwo gubi pojedyncze wpisy, w tym takie, które później okazują się ważne, na przykład przyszłe rezerwacje pokazane jako wolne terminy. Wyłapuje to dopiero mechaniczne porównanie danych źródłowych z nową bazą. Import liczy się jako skończony wtedy, gdy takie porównanie się domyka, a nie wtedy, gdy ekran wygląda dobrze.
Kilka typowych zastosowań w tym obszarze. Twój proces może wyglądać inaczej, dlatego zaczynam od rozmowy o nim.
Aktualne liczby zamiast raportu z zeszłego tygodnia, dla każdego z odpowiednim zakresem danych.
CRM, księgowość i arkusze połączone w jednym miejscu, bez ręcznego sklejania.
Co tydzień do właściwych osób, w tej samej formie i o tej samej porze.
Spadek sprzedaży albo zalegające zamówienia widać od razu, a nie na koniec miesiąca.
Duplikaty, brakujące pola i różne formaty zapisu poprawiane przy imporcie.
Pliki od handlowców albo oddziałów zbierane i łączone automatycznie.
Czas, koszt i przychód policzone razem dla każdego zlecenia, nie szacowane.
AI odpowiada na pytanie o liczby i pokazuje, z których danych je wzięła.
Sprzedaż albo obłożenie na kolejne tygodnie policzone z Waszych danych, z widocznym założeniem.
Błędny NIP, e-mail czy kwota zostają wyłapane w formularzu, zanim trafią do raportu.
Cztery kroki. Pierwszy jest bezpłatny i często wystarcza, żeby wiedzieć, czy w ogóle jest o czym rozmawiać.
Rozmawiamy o jednym procesie: co się w nim dzieje, ile razy w miesiącu i gdzie ucieka czas. Jeśli nie ma tu czego automatyzować, powiem to na tej rozmowie.
Dostajesz proces opisany z zaznaczonymi miejscami strat, proponowany zakres, widełki kosztu i szacowany czas, razem z listą rzeczy, których nie warto ruszać.
Każdy etap kończy się czymś, co da się włączyć do pracy i ocenić w liczbach, zanim ruszy kolejny. Zamiast kwartału ciszy i jednego dużego uruchomienia.
Zespół uczy się na Waszych danych, dokumentacja i dostępy zostają po Waszej stronie. Jestem przy pierwszych nietypowych przypadkach, bo te pojawiają się po starcie, nie w dniu uruchomienia.
Zależy od liczby źródeł i od tego, czy dane da się pobrać przez API, czy tylko z ręcznego eksportu. Pierwsza, 30-minutowa rozmowa jest bezpłatna. Po obejrzeniu, skąd dziś biorą się Twoje liczby, dostajesz widełki dla swojego przypadku, a nie ofertę napisaną w ciemno.
Nie zawsze. Przy kilkudziesięciu zamówieniach i jednej osobie obsługującej cały proces arkusz Google bywa właściwym narzędziem. Przestaje wystarczać, gdy jedna komórka zaczyna mieścić kilka informacji naraz, bo wtedy automat, który go czyta, zaczyna się mylić i pomijać wpisy, które powinien przetworzyć. Od tego momentu dane powinny należeć do bazy, a arkusz może zostać jako widok na nie.
Zwykle nie. Suma, średnia i porównanie z poprzednim miesiącem to zapytanie do bazy, które za każdym razem daje ten sam wynik i nie zużywa ani jednego tokenu. Model językowy ma sens tam, gdzie odpowiedzi nie da się policzyć wprost, na przykład przy krótkim streszczeniu zapytania od klienta. Wtedy pracuje na Twoich danych i nie jest pytany o liczby, które są w tabeli.
To częsty punkt wyjścia i pierwsza część pracy, a nie przeszkoda. Zaczynam od mechanicznego porównania źródeł z tym, co trafia do raportu, bo sprawdzanie na oko regularnie przepuszcza brakujące wpisy. Lepiej poznać skalę problemu przed zbudowaniem panelu niż po.
Nie, i nie będę udawał, że jest inaczej. Dobrze znam bazy operacyjne, na których firma pracuje na co dzień: uprawnienia, historię zdarzeń i raporty liczone prosto z nich. Hurtownia danych dla dużej organizacji to pokrewna, ale osobna specjalizacja. Jeśli jej potrzebujesz, powiem to na pierwszej rozmowie, zamiast brać projekt, którego nie dowiozę.
Kod piszą agenty AI. Ja odpowiadam za specyfikację, decyzję o architekturze, review, wdrożenie i za to, co się dzieje, gdy coś przestanie działać na produkcji. Gdy projekt potrzebuje więcej rąk, dołączają developerzy CetusPro, software house'u z Rzeszowa.
Dostępu do danych pilnuje sama baza danych, a nie ukryty przycisk w aplikacji, więc handlowiec technicznie nie odczyta cudzych klientów. Klucze i hasła do usług są poza kodem. Każda zmiana, zanim trafi na produkcję, przechodzi automatyczne sprawdzenia, w tym skan pod kątem wycieku sekretów. Kod i dane zostają po Waszej stronie.
Tak, i zwykle tak to wygląda: zaczynamy od jednego procesu, a kolejne dochodzą etapami. Kod jest w Waszym repozytorium razem z dokumentacją, więc rozbudowę może zrobić też ktoś inny niż ja.
Trzydzieści minut wystarczy, żeby powiedzieć, czy jest tu co automatyzować. Jeśli nie ma, usłyszysz to wprost, zanim powstanie jakakolwiek oferta.
Bez zobowiązań. Bez oferty, zanim zrozumiem proces.
Zobacz, co już zbudowałem →albo napisz na hello@kamiljan.com · LinkedIn