Ostatnia aktualizacja: 2026-10-26
Obsługę zapytań ofertowych można automatyzować od momentu odebrania wiadomości do przygotowania szkicu odpowiedzi.
- AI może odczytywać wiadomości i załączniki, wyodrębniać dane, klasyfikować sprawy oraz sprawdzać ich kompletność.
- Odpowiedzi powinny opierać się na aktualnym katalogu, cenniku, warunkach handlowych i zatwierdzonych treściach.
- Sprawy niepełne, nietypowe lub wpływające na cenę i zobowiązania powinny trafiać do akceptacji człowieka.
Największą wartość daje automatyzacja całego przepływu informacji, a nie samo generowanie tekstu oferty. System może przyjąć e-mail, odczytać załączniki, utworzyć kartę zapytania, wykryć braki i przygotować szkic odpowiedzi. Warunkiem jest jednak wcześniejsze uporządkowanie danych oraz określenie, kiedy proces może działać automatycznie, a kiedy wymaga decyzji uprawnionej osoby.
Opisany model dotyczy zarówno zapytań otrzymywanych od klientów, jak i procesów RFQ prowadzonych wobec dostawców. W obu przypadkach podobna jest logika przepływu, ale inne mogą być wymagane dane, kryteria oceny i osoby zatwierdzające.
Co można zautomatyzować w obsłudze zapytań ofertowych
AI może wspierać kolejne etapy obsługi zapytania ofertowego — od odczytu wiadomości i załączników po przygotowanie danych do odpowiedzi.[1][2] Nie oznacza to, że wszystkie funkcje muszą działać w jednym narzędziu albo że system powinien samodzielnie podejmować decyzje handlowe.
Nie tylko generowanie tekstu oferty
Proces można podzielić na odbiór wiadomości, odczyt dokumentów, utworzenie sprawy, klasyfikację, kontrolę kompletności, dopasowanie do danych firmy, przygotowanie szkicu odpowiedzi, akceptację oraz zapis wyniku. Generowanie tekstu jest zatem jednym z etapów, a nie całą automatyzacją.
Przed wyborem technologii należy rozpisać obecny proces. Przy każdym kroku trzeba wskazać dane wejściowe, oczekiwany wynik, właściciela zadania oraz warunki przekazania sprawy dalej. Dopiero taki opis pozwala ustalić, gdzie AI jest przydatna, a gdzie wystarczy zwykła reguła workflow.
Proces dla zapytań od klientów a proces RFQ do dostawców
W zapytaniu od klienta wynikiem może być karta potrzebna do przygotowania odpowiedzi handlowej. W procesie zakupowym dane służą natomiast zebraniu i porównaniu ofert dostawców. Nie należy łączyć tych ścieżek bez rozróżnienia ich pól, statusów i kryteriów akceptacji.
Techniczna realizacja może łączyć pocztę, system obiegu pracy, CRM lub ERP. Przy projektowaniu przepływu trzeba ustalić również, czy dane obsłuży istniejący system, czy potrzebne będą dedykowane aplikacje internetowe. Sam wybór warstwy technicznej nie rozstrzyga jednak o jakości procesu — najpierw potrzebne są reguły i uporządkowane dane.
Przepływ od e-maila do karty zapytania
Praktyczny wzorzec prowadzi od nowej wiadomości przez ekstrakcję i walidację do zapisu sprawy oraz powiadomienia. W narzędziach do przetwarzania dokumentów można zdefiniować pola lub tabele przeznaczone do wyodrębnienia, a uzyskany wynik przekazać do kolejnych kroków automatyzacji.[8]
- Odbiór wiadomości. Nowy e-mail uruchamia przepływ, który pobiera treść i załączniki.
- Rozpoznanie sprawy. System określa typ zapytania i kieruje je do właściwej ścieżki obsługi.
- Ekstrakcja danych. Z wiadomości, dokumentu lub tabeli pobierane są wcześniej zdefiniowane pola.
- Walidacja. Dane są porównywane z wymaganiami dotyczącymi kompletności i formatu.
- Zapis. Wynik trafia do karty zapytania, CRM, ERP albo kolejki pracy.
- Powiadomienie lub eskalacja. Poprawnie przetworzona sprawa przechodzi dalej, a błąd lub brak danych uruchamia ustaloną ścieżkę wyjątku.
Wzorzec e-mail → ekstrakcja → walidacja → zapis → powiadomienie odpowiada oficjalnemu przykładowi architektury Microsoft dotyczącemu przetwarzania faktur.[9] W przypadku zapytań ofertowych jest to analogia procesowa, a nie potwierdzenie jakości ich odczytu. Pola, reguły i integracje trzeba dopasować do własnych dokumentów.
Jakie dane wyodrębniać z wiadomości i załączników
Karta zapytania może obejmować dane kontaktowe, przedmiot sprawy, ilość lub zakres, termin, źródło dokumentu i status kompletności. Ostateczny zestaw zależy od produktu, usługi i sposobu przygotowywania wyceny. Odczyt pola nie jest jeszcze oceną biznesową — pokazuje jedynie, jaka wartość została rozpoznana w dokumencie.
Jeżeli załącznik jest obszerny, można ograniczyć analizę do stron zawierających właściwe zapytanie lub tabelę, o ile używane narzędzie obsługuje taki parametr.[8] Nie wszystkie systemy pozwalają sterować zakresem stron w ten sam sposób.
Gdzie zapisać wynik oraz jak obsłużyć błąd
Dane powinny trafić do uporządkowanej sprawy, a nie pozostać wyłącznie w tekście wygenerowanym przez model. Karta zapytania powinna przechowywać wartości pól, ich źródło, status kompletności i informację o tym, czy potrzebna jest interwencja człowieka.
Nieudany odczyt, brak wymaganego pola lub sprzeczność nie powinny zatrzymywać się bez komunikatu. Przepływ musi przekazać sprawę do wskazanej osoby albo kolejki oraz zachować informację o rodzaju błędu.
Jak wykrywać braki, zanim powstanie oferta
Brakujące lub niejednoznaczne dane powinny uruchamiać weryfikację, a nie automatyczne zgadywanie.[3][5] System porównuje zawartość zapytania z listą wymaganych pól, oznacza odstępstwa i przygotowuje sprawę do uzupełnienia.
Lista pól wymaganych i opcjonalnych
Dla każdego typu zapytania należy określić pola wymagane, opcjonalne oraz wymagające osobnej akceptacji. Brak pola wymaganego może prowadzić do przygotowania pytania uzupełniającego, natomiast odstępstwo od standardowego zakresu — do przekazania sprawy specjaliście.
| Sygnał | Znaczenie w procesie | Działanie |
|---|---|---|
| Brak pola wymaganego | Nie ma danych potrzebnych do kontynuowania standardowej ścieżki | Oznaczyć brak i przygotować pytanie uzupełniające |
| Sprzeczne wartości | Co najmniej dwa elementy zapytania nie są ze sobą zgodne | Przekazać sprawę do wyjaśnienia |
| Wymaganie poza standardem | Zapytanie nie pasuje do zatwierdzonego katalogu lub procesu | Skierować do osoby odpowiedzialnej za zakres |
| Niejednoznaczny odczyt | System nie może bezpiecznie przypisać wartości | Wstrzymać automatyczne użycie pola i zlecić weryfikację |
Taka walidacja sprawdza zgodność z ustalonymi regułami. Nie potwierdza jednak, że każda informacja podana przez nadawcę jest prawdziwa ani że zaproponowany zakres jest korzystny dla firmy.
Macierz zgodności dla wymagań nietypowych
Macierz zgodności łączy wymaganie z właściwym źródłem danych, statusem realizacji, brakującą informacją i osobą odpowiedzialną za decyzję. Pomaga odróżnić wymagania spełnione, niepotwierdzone i pozostające poza standardem. Nie zastępuje przy tym oceny eksperta ani formalnej analizy prawnej lub technicznej.
Praktyczny rezultat to karta sprawy, która pokazuje nie tylko odczytane dane, lecz także luki, pytania uzupełniające i miejsce podjęcia decyzji. Dzięki temu brak informacji staje się kontrolowanym wyjątkiem procesowym.
Baza wiedzy, z której AI przygotowuje odpowiedź
AI powinna korzystać z kontrolowanych źródeł firmy: aktualnego katalogu, cennika, warunków handlowych i biblioteki zatwierdzonych treści.[1][2] Jest to rekomendacja dotycząca architektury procesu, a nie gwarancja poprawności. Sama baza wiedzy nie usuwa błędów, jeżeli zawiera nieaktualne dokumenty lub system wyszukuje w niej niewłaściwe informacje.
W tym kontekście RAG oznacza wyszukanie informacji w przygotowanej bazie wiedzy przed utworzeniem odpowiedzi. Model nie powinien opierać oferty wyłącznie na ogólnej wiedzy ani samodzielnie uzupełniać danych, których nie ma w zatwierdzonych źródłach.
Co powinno być źródłem obowiązującym
- Katalog produktów lub usług
- Powinien wskazywać aktualny zakres oferty i parametry, które mogą być przywoływane w odpowiedzi.
- Cennik
- Musi mieć oznaczoną wersję i właściciela odpowiedzialnego za aktualizację.
- Warunki handlowe
- Powinny rozdzielać treści standardowe od zapisów wymagających indywidualnej zgody.
- Biblioteka zatwierdzonych odpowiedzi
- Może dostarczać zaakceptowane fragmenty dotyczące powtarzalnych pytań i warunków.
- Macierz zgodności
- Powinna wskazywać, które źródło potwierdza spełnienie danego wymagania i gdzie potrzebna jest dodatkowa decyzja.
Jak utrzymać aktualność i ślad źródła
Każda kategoria danych powinna mieć właściciela, obowiązującą wersję oraz zasady dostępu. W procesie trzeba również rozstrzygnąć, co dzieje się po zmianie cennika, katalogu lub warunków: czy wcześniejszy szkic pozostaje ważny, czy wymaga ponownego przygotowania.
Ślad źródła pozwala osobie zatwierdzającej ustalić, skąd pochodzi cena, parametr lub fragment odpowiedzi. Nie daje automatycznej gwarancji poprawności, ale ułatwia kontrolę i wychwycenie rozbieżności przed wysyłką.
Co automatyzować, a co zostawić do akceptacji człowieka
Zadania powtarzalne i odwracalne można automatyzować, natomiast sprawy wpływające na cenę, zakres zobowiązania, warunki umowy albo decyzję o udziale powinny mieć punkt akceptacji człowieka.[10] To praktyczna zasada kontroli ryzyka, a nie stwierdzenie, że każde narzędzie ofertowe jest systemem wysokiego ryzyka w rozumieniu AI Act.
| Etap procesu | Możliwy poziom automatyzacji | Kiedy potrzebna jest akceptacja człowieka | Główne ryzyko |
|---|---|---|---|
| Rejestracja wiadomości | Automatyczne utworzenie sprawy | Gdy nie można rozpoznać typu lub właściciela sprawy | Błędne skierowanie zapytania |
| Ekstrakcja pól | Automatyczny odczyt z walidacją | Gdy odczyt jest niejednoznaczny albo pola są sprzeczne | Użycie błędnej wartości |
| Wykrywanie braków | Automatyczne oznaczenie i szkic pytania | Gdy brak zmienia interpretację zakresu | Kontynuowanie na niepełnych danych |
| Przygotowanie szkicu odpowiedzi | Generowanie na podstawie zatwierdzonych źródeł | Gdy odpowiedź wykracza poza standardową bibliotekę | Nieaktualna lub niepotwierdzona treść |
| Dobór ceny lub warunków | Wsparcie danymi i regułami | Przy rabacie, odstępstwie lub niestandardowym zobowiązaniu | Zmiana warunków handlowych bez zgody |
| Wysyłka oferty | Zgodnie z ustalonym poziomem uprawnień | Gdy sprawa spełnia warunek obowiązkowej akceptacji | Wysłanie niezatwierdzonej oferty |
Sygnały wymagające eskalacji
Do ścieżki wyjątku powinny trafiać sprawy z brakującymi lub sprzecznymi danymi, wymaganiami poza standardem, niestandardowym rabatem, zapisami kontraktowymi albo wynikiem, którego nie da się bezpiecznie zweryfikować. Progi eskalacji muszą wynikać z rzeczywistych zasad firmy.
Osoba zatwierdzająca powinna móc sprawdzić wynik, poprawić lub odrzucić rekomendację oraz zatrzymać kolejne działania automatyzacji.[10] Zakres konkretnych obowiązków prawnych zależy od klasyfikacji systemu i sposobu jego użycia, dlatego ogólna architektura procesu nie zastępuje analizy konkretnego wdrożenia.
Nadzór człowieka, dane i dostęp do procesu
Nadzór nie powinien sprowadzać się do formalnego kliknięcia akceptacji. Osoba podejmująca decyzję potrzebuje dostępu do danych wejściowych, źródeł wykorzystanych w odpowiedzi, wykrytych braków i historii zmian.
Trzeba również określić, kto może odczytywać wiadomości, załączniki, ceny i warunki handlowe oraz gdzie te dane są przechowywane. Zasady dostępu, retencji i użycia danych należy dopasować do architektury organizacji oraz charakteru przetwarzanych informacji. Sam opis automatyzacji nie stanowi indywidualnej oceny zgodności prawnej.
Od czego zacząć i jak ocenić pilotaż
Wdrożenie najlepiej rozpocząć od jednego powtarzalnego etapu, na przykład klasyfikacji wiadomości, ekstrakcji danych albo przygotowania szkicu. Zakres można rozszerzyć dopiero po testach.[6][7] Wybór pierwszego etapu zależy od wolumenu, jakości danych, branży i używanych systemów.
Wybór pierwszego etapu
- Rozpisz obecny przebieg sprawy od wpływu wiadomości do wysłania odpowiedzi.
- Wybierz zadanie powtarzalne, dla którego można jednoznacznie opisać dane wejściowe i oczekiwany wynik.
- Przygotuj zestaw historycznych zapytań wraz z zaakceptowanymi rezultatami.
- Zdefiniuj wymagane pola, reguły kompletności i warunki eskalacji.
- Ustal, kto ocenia poprawność wyniku i kto może zatrzymać proces.
- Sprawdź dostęp do katalogu, cennika, warunków i zatwierdzonych odpowiedzi.
- Uruchom test bez rozszerzania automatyzacji na niezweryfikowane typy spraw.
Pilotaż na historycznych przypadkach pozwala porównać wynik automatyzacji z rezultatem zaakceptowanym wcześniej przez osobę prowadzącą sprawę. Wynik dla jednego rodzaju dokumentów nie musi jednak potwierdzać jakości dla wszystkich zapytań.
Mierniki, które pokazują jakość procesu
Przed uruchomieniem należy wskazać kilka mierników: poprawność pól, kompletność danych, czas do pierwszej odpowiedzi, odsetek spraw kierowanych do człowieka i liczbę korekt.[8][9] Źródła potwierdzają znaczenie ekstrakcji, walidacji i obsługi błędów, lecz nie wyznaczają jednego obowiązkowego zestawu KPI.
Mierniki trzeba dopasować do procesu i liczyć dla porównywalnego zakresu spraw. Sama szybkość nie wystarcza, jeśli rośnie liczba błędnie odczytanych pól lub korekt wykonywanych już po przygotowaniu szkicu. Dopiero wynik pilotażu powinien rozstrzygać, czy automatyzację można rozszerzyć na następne etapy.
Źródła
- Od zapytania w mailu do gotowej oferty – jak AI obsługuje RFQ, przetargi i specyfikacje klienta, ALGORCOMP.
- Jak wdrożyć AI do obsługi zapytań ofertowych: proces dla małych firm, Qualix Software.
- Automatyzacja zapytań ofertowych RFQ z AI, VendorIQ.
- Agent AI do autonomicznej obsługi procesu pozyskiwania ofert – opracowanie, wdrożenie i szkolenie, OnePlace / Marketplanet.
- Jak wykorzystać AI do analizy zapytań i dokumentacji przetargowej?, TTMS.
- Automatyzacja zapytań ofertowych do dostawców, Kamil Rudnicki.
- Document processing model overview, Microsoft Learn.
- Automate vendor invoice processing with Power Automate and AI Builder, Microsoft Learn.
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689, EUR-Lex / Unia Europejska.
+Artykuł Sponsorowany+
