CRM i AI w firmie produkcyjnej B2B: jak uporządkować ofertowanie

SCENARIUSZ MODELOWY · CRM I AI · B2B · 2/3

Handlowcy chcą wysyłać oferty szybciej, technolodzy potrzebują pełnych wymagań, a produkcja nie chce dostawać nierealnych terminów. W tym scenariuszu CRM i AI pomagają uporządkować przekazywanie informacji, ale najważniejsza zmiana dotyczy zasad współpracy między działami.

Opracowanie: Maciej Korzewa · Platforma Przedsiębiorców

1. Jak było: każda oferta zaczynała się od szukania informacji

Modelowa firma produkuje elementy na zamówienie dla innych przedsiębiorstw. Jedno zapytanie dotyczy prostej powtarzalnej partii, drugie nowego detalu wymagającego analizy dokumentacji. Klient przesyła rysunek, później aktualizuje materiał, a na końcu pyta, czy da się przyspieszyć dostawę. Poszczególne ustalenia znajdują się w kilku wiadomościach i notatkach z telefonu.

Handlowiec przekazuje temat do technologa z prośbą o pilną wycenę. Technolog pyta o tolerancję, wielkość serii i aktualną wersję rysunku. Zanim otrzyma odpowiedź, pojawiają się następne sprawy. Zarząd widzi długi czas ofertowania, ale nie wie, ile dni zajmuje przygotowanie kalkulacji, a ile oczekiwanie na komplet danych.

Samodzielne wdrożenie: odtworzenie arkusza w nowym systemie

W tej fikcyjnej historii firma wcześniej próbuje wdrożyć CRM własnymi siłami. Kierownik sprzedaży tworzy kilkadziesiąt pól na podstawie wszystkich możliwych pytań technologów. Każde pole staje się obowiązkowe już przy pierwszym kontakcie. Handlowiec nie zna jeszcze odpowiedzi, więc wpisuje myślniki albo wartości orientacyjne, żeby przejść dalej.

Druga próba polega na zamówieniu integracji CRM z ERP. Dostawcy realizują przesyłanie danych, lecz firma nie ustala, które identyfikatory łączą zapytanie, ofertę i zamówienie. Aktualizacja dokumentacji nadal dociera e-mailem. Zespół zaczyna uważać, że integracja „nie działa”, choć część problemu leży w nieustalonym procesie zmian.

Dlaczego technolodzy odmawiają kolejnego systemu?

Technolodzy nie chcą przepisywać kalkulacji do CRM i obawiają się odpowiedzialności za wycenę sporządzoną na niepełnych danych. Handlowcy twierdzą, że rozbudowany formularz utrudnia rozmowę z klientem. Produkcja sprzeciwia się terminom wprowadzanym bez sprawdzenia obciążenia. Każdy dział chroni realny fragment procesu, ale wspólne spotkania kończą się wzajemnymi pretensjami.

2. Co się zmieniło: wspólna definicja gotowego zapytania

Dwie ścieżki zamiast jednego formularza dla wszystkiego

Proponowany proces rozdziela zapytania powtarzalne od nowych projektów. W pierwszej ścieżce wystarcza identyfikator wcześniej zaakceptowanego produktu, ilość i termin do sprawdzenia. W drugiej wymagane są uzgodnione parametry techniczne i dokumentacja. Lista danych wynika z potrzeb kalkulacji, a nie z możliwości programu.

Informacje są uzupełniane etapami. Pierwszy kontakt wymaga tylko danych pozwalających przejąć sprawę. Dopiero przekazanie do wyceny uruchamia kontrolę kompletności. Firma ustala również, co oznacza status „oczekujemy na klienta”, aby nie obciążać czasu pracy technologów okresem, w którym nie mogą wykonać zadania.

Jedna wersja ustaleń i jawna obsługa zmian

• Każde zapytanie ma właściciela, identyfikator i wskazaną aktualną wersję dokumentacji.
• Zmiana materiału, ilości lub parametrów uruchamia ocenę wpływu na cenę i termin.
• Oferta posiada zapis założeń oraz osobę zatwierdzającą warunki techniczne i handlowe.
• CRM pokazuje etap i odpowiedzialność; szczegółowa kalkulacja pozostaje w uzgodnionym narzędziu.
• ERP pozostaje źródłem danych, za które odpowiada: np. kartotek i zamówień. Zakres integracji jest opisany oddzielnie dla każdego przepływu.

Dostawca CRM i dostawca ERP otrzymują wspólny scenariusz odbioru. Przykładowo: klient zmienia ilość po wysłaniu oferty; system powinien zachować poprzednią wersję, wskazać potrzebę ponownej akceptacji i nie utworzyć podwójnego zamówienia. Przypadki błędów są równie istotne jak poprawny przebieg.

AI pomaga czytać i porządkować, nie przejmuje odpowiedzialności technicznej

AI przygotowuje roboczą listę wymagań z zatwierdzonych źródeł oraz wskazuje pytania bez odpowiedzi. Może zestawić różnice między opisami kolejnych wersji zapytania. Każdy wynik ma odnośnik do źródła; niejednoznaczność trafia do człowieka. Odczyt z dokumentacji technicznej wymaga sprawdzenia przez kompetentnego pracownika, szczególnie gdy plik zawiera skan lub rysunek.

Model nie zatwierdza tolerancji, zamiennika materiału, kosztu ani terminu. Propozycję tekstu oferty tworzy dopiero po zatwierdzeniu danych wejściowych. Narzędzie dostaje dostęp wyłącznie do uzgodnionych zasobów, z uwzględnieniem poufności dokumentacji klientów. Gdy nie ma dostatecznych informacji, oczekiwanym zachowaniem jest wskazanie braku danych, a nie wygenerowanie wiarygodnie brzmiącej odpowiedzi.

Jak ograniczyć opór bez obiecywania łatwej zmiany?

Pilotaż obejmuje jeden typ zleceń i wspólną parę: handlowiec oraz technolog. Osoby te testują kompletny przebieg, w tym zwrot niepełnego zapytania i zmianę dokumentacji. Zgłoszony problem ma właściciela i termin decyzji. Technolog nie musi codziennie raportować w kolejnym narzędziu, jeżeli status można wiarygodnie przekazać z używanego środowiska.

Kierownictwo uznaje czas testów i szkolenia za część pracy. Nie oczekuje, że pracownicy wdrożą system po godzinach i równocześnie utrzymają niezmienioną liczbę wycen. Po pilotażu instrukcja opisuje kilka podstawowych sytuacji, a nie wszystkie funkcje CRM. Stara ścieżka zgłoszeń zostaje zamknięta dopiero po potwierdzeniu, że nowa obsługuje także wyjątki.

3. Co to daje firmie: przewidywalny obieg ofert

Modelowy efekt organizacyjny to możliwość ustalenia, na co czeka oferta i kto może odblokować kolejny krok. Handlowiec nie musi pytać wszystkich o status, technolog otrzymuje uzgodniony zestaw informacji, a produkcja ma wyraźny udział w potwierdzaniu warunków realizacji. To projektowany rezultat opisanej zmiany, a nie raport z wykonanej realizacji.

AI może ograniczyć część pracy przy czytaniu korespondencji i przygotowywaniu wersji roboczych. Jeśli jednak sprawdzanie jego odpowiedzi zajmuje więcej czasu niż przygotowanie notatki samodzielnie, dany przypadek nie powinien być skalowany. Wdrożenie funkcji nie jest wystarczającym argumentem za jej używaniem.

Jak ocenić rezultat bez mylących wskaźników?

• Czas od kompletnego zapytania do oferty: oddzielony od oczekiwania na dane klienta.
• Liczba zwrotów do uzupełnienia: z rozróżnieniem braków handlowych, technicznych i zmiany zakresu.
• Korekty po akceptacji: ze wskazaniem przyczyn, np. nieaktualnego załącznika.
• Weryfikacja AI: rodzaje przeoczonych wymagań i czas potrzebny do poprawy szkicu.

Zapytania powtarzalne należy porównywać z powtarzalnymi, a nowe projekty z podobnymi nowymi projektami. Średnia ze wszystkich ofert może ukryć zmianę struktury zamówień. W tym modelowym opisie nie przypisujemy firmie wzrostu marży ani skrócenia czasu o określony procent.

Gdzie potrzebny jest dyrektor transformacji?

Kluczowe zadanie to doprowadzenie do wspólnych decyzji sprzedaży, technologii, produkcji i dostawców IT. Osoba koordynująca program pilnuje źródeł danych, granic odpowiedzialności oraz tego, by harmonogram wdrożenia uwzględniał pracę zespołu. Bez tego kolejna integracja może jedynie szybciej przesyłać niejednoznaczne informacje.

Wniosek dla zarządu

Warto zacząć od jednego typu ofert i sprawdzić pełną ścieżkę, zanim firma kupi kolejne moduły. Warunkiem przejścia do następnego etapu powinny być uzgodnione odbiory, akceptowalna jakość danych i zdolność zespołu do samodzielnej pracy w nowym procesie.

Przeczytaj również: kiedy firma potrzebuje zewnętrznego dyrektora transformacji. Pozostałe materiały znajdziesz na blogu Platformy Przedsiębiorców.