Największy problem zaczyna się po słowie „tylko”
Klient zaakceptował ofertę, a realizacja ruszyła. Po dwóch dniach pisze: „Proszę tylko zmienić materiał” albo „Dodajmy jeszcze jeden element”. Dla klienta może to wyglądać jak drobna korekta. Dla firmy oznacza inną ilość materiału, nowe operacje, zmianę terminu, dodatkowy transport albo konieczność poprawienia dokumentacji.
Jeżeli wiadomość zostanie wyłącznie w skrzynce handlowca, produkcja nadal pracuje według starej wersji. Jeśli ktoś przekaże ją ustnie, później trudno ustalić, co dokładnie uzgodniono i kto zaakceptował koszt. Potrzebny jest jeden zapis zmiany powiązany z konkretnym zleceniem.
AI może przygotować kartę zmiany, ale nie podjąć decyzję
Automatyzacja może obserwować ustalony kanał, na przykład skrzynkę przypisaną do CRM, i wychwytywać wiadomości sugerujące zmianę zakresu. Model może porównać treść z zatwierdzoną ofertą oraz przygotować szkic: czego dotyczy prośba, jaki element ma się zmienić, czego brakuje do oceny i z której wiadomości pochodzi informacja.
To nie jest jeszcze zgoda na realizację. Szkic powinien otrzymać status „do oceny”, a zespół sprawdzić wpływ na cenę, termin, materiał, dokumentację i rozpoczęte prace. Microsoft opisuje zarządzanie zmianami w Dynamics 365 Project Operations jako uporządkowany, audytowalny proces tworzenia, oceny i zatwierdzania zmian w aktywnych kontraktach projektowych. To przykład rozwiązania konkretnej platformy, ale dobrze pokazuje właściwą kolejność działań.
Przykład: zmiana materiału po rozpoczęciu produkcji
Przykład hipotetyczny: mała firma metalowa przyjęła zamówienie na serię konstrukcji malowanych proszkowo. Po uruchomieniu cięcia klient wysyła e-mail z prośbą o wykonanie części elementów ze stali nierdzewnej i utrzymanie pierwotnego terminu.
System łączy wiadomość ze zleceniem i tworzy kartę zmiany. Pokazuje pierwotny materiał, nową prośbę klienta oraz brak informacji o tym, których dokładnie elementów dotyczy zmiana. Handlowiec nie obiecuje terminu. Prosi klienta o wskazanie pozycji, a technolog sprawdza dokumentację, dostępność materiału i to, które detale zostały już wykonane.
Po ocenie powstaje nowa wersja zakresu z ceną i terminem. Klient ją akceptuje, a dopiero wtedy zatwierdzona zmiana trafia do produkcji. Stara wersja pozostaje w historii, lecz jest wyraźnie oznaczona jako nieaktualna. Jeśli klient odrzuci dopłatę lub nowy termin, zlecenie pozostaje przy poprzednim zakresie.
Jedna zmiana powinna mieć właściciela i status
Prosty przepływ może obejmować stany: zgłoszona, wymaga doprecyzowania, w ocenie, przedstawiona klientowi, zaakceptowana, odrzucona i wdrożona. Każdy stan powinien mieć właściciela oraz datę. Dzięki temu handlowiec widzi, czy czeka na technologa, a produkcja wie, czy może działać.
Zmiany standardowe, na przykład inny adres dostawy przed wysyłką, mogą mieć krótszą ścieżkę. Zmiana materiału, wymiaru, konstrukcji, terminu lub warunków odbioru wymaga oceny odpowiednich osób. Narzędzia do obsługi procesów pozwalają dodawać kroki zatwierdzania przed przejściem sprawy dalej; Atlassian opisuje takie zatwierdzenia jako element statusu workflow. Samo istnienie funkcji nie ustala jednak, kto powinien zatwierdzać zmianę w konkretnej firmie.
Co powinno trafić do historii
W karcie zmiany warto zachować oryginalną wiadomość, wcześniejszy zakres, opis proponowanej modyfikacji, załączniki, wynik oceny, decyzję klienta i osobę zatwierdzającą. Nowa wersja powinna mieć własny numer lub datę obowiązywania.
Nie wystarczy nadpisać pola „materiał” w CRM. Bez poprzedniej wartości nie da się później ustalić, dlaczego zmieniła się cena albo termin. Trzeba też zadbać, aby realizacja korzystała z zatwierdzonej wersji, a nie z pliku pobranego wcześniej na komputer.
Ograniczenia, których nie rozwiąże sam model
AI może błędnie odczytać żart, luźną sugestię albo fragment długiego wątku jako formalną zmianę. Może też nie wiedzieć, czy osoba pisząca w imieniu klienta ma prawo ją zatwierdzić. Ustalenia telefoniczne nie pojawią się w systemie, jeśli pracownik ich nie zapisze.
Model nie powinien samodzielnie wyceniać nietypowej zmiany, zatwierdzać rozwiązania technicznego ani obiecywać terminu. Szczególnie przy zmianach wpływających na bezpieczeństwo, zgodność dokumentacji lub już wykonaną pracę decyzja należy do uprawnionego człowieka. Automatyzacja ma pilnować przepływu informacji, a nie zastępować odpowiedzialność.
Jak zacząć od małego testu
Wybierz jeden rodzaj zleceń i przejrzyj wcześniejsze zmiany. Sprawdź, gdzie były zgłaszane, jakie informacje najczęściej brakowały i kto oceniał wpływ. Następnie uruchom kartę zmiany bez automatycznego aktualizowania produkcji lub ERP.
Mierz liczbę zmian znalezionych po rozpoczęciu pracy, czas potrzebny na ocenę, przypadki wykonania według starej wersji oraz prośby bez potwierdzenia klienta. Jeżeli zmiany nadal są uzgadniane poza systemem, najpierw trzeba ustalić jeden sposób ich zgłaszania.
W FindAI możemy pomóc połączyć wiadomości, CRM i obieg zlecenia tak, aby prośba klienta nie znikała między sprzedażą a realizacją. Najlepszym początkiem jest jeden powtarzalny proces i jasne wskazanie, które decyzje zawsze pozostają po stronie człowieka.
Stan na 23 października 2026. Przykład jest hipotetyczny; zakres integracji zależy od używanych systemów, API, planu i uprawnień.