Pierwszy pilotaż AI u dewelopera — jak wybrać proces i uczciwie ocenić wynik

Zacznij od wąskiego problemu, nie od nazwy narzędzia

„Wdrożyć AI w sprzedaży” nie jest zakresem pilotażu. Nie wiadomo wtedy, kto ocenia wynik, jakie dane są potrzebne ani gdzie kończy się odpowiedzialność narzędzia. Lepszy punkt startu opisuje jedną powtarzalną czynność i błąd, którego chcemy uniknąć.

Przykład dobrego zakresu: po rozmowie doradca wkleja zatwierdzoną transkrypcję. Asystent proponuje krótką notatkę, aktualne preferencje oraz następne zadanie. Doradca widzi źródłowe fragmenty, poprawia propozycje i zatwierdza zapis. Narzędzie nie wysyła wiadomości i nie zmienia danych bez akceptacji.

Taki zakres ma wyraźny początek i koniec. Pozwala też oddzielić trzy problemy, które łatwo pomylić:

• samo przygotowanie notatki trwa zbyt długo;
• doradca czeka na informację z innego działu;
• informacja istnieje, ale nie trafia do właściwego pola CRM.

AI może pomóc w pierwszym i częściowo w trzecim przypadku. Nie skróci oczekiwania na decyzję techniczną, jeśli nie zmieni się przepływ między zespołami.

Opisz pilotaż na jednej karcie

Przed testem wypełnij sześć pól. Jeżeli któregoś nie da się określić, projekt nie jest jeszcze gotowy do pomiaru.

1. Zdarzenie rozpoczynające

Co uruchamia zadanie? Na przykład zakończenie rozmowy, nowy formularz, zmiana statusu lokalu albo wpływ zgłoszenia. Zdarzenie powinno być widoczne w danych, a nie zależeć od pamięci uczestnika.

2. Wynik do zatwierdzenia

Zapisz, co ma powstać: trzy pola preferencji, jedno zadanie z terminem i notatka do 600 znaków. „Dobra odpowiedź” jest zbyt nieprecyzyjna, żeby dwie osoby oceniły ją tak samo.

3. Źródła

Wymień dane, z których wolno korzystać, wraz z ich kolejnością ważności. Aktualny rekord lokalu może być nadrzędny wobec starego załącznika. Brak informacji powinien pozostać brakiem, a nie zaproszeniem do zgadywania.

4. Właściciel wyniku

Jedna osoba lub rola odpowiada za ocenę. W pilotażu notatki będzie to doradca albo kierownik sprzedaży; w zgłoszeniu technicznym — osoba znająca przyjęte kategorie i odpowiedzialność wykonawców.

5. Czynności wymagające akceptacji

Rozdziel odczyt, propozycję i działanie. Podsumowanie można wygenerować automatycznie, lecz zapis pól, wysyłka wiadomości albo zmiana statusu powinny mieć osobną zgodę, dopóki test nie potwierdzi jakości i powtarzalności.

6. Warunek zatrzymania

Ustal go przed uruchomieniem. Przykłady: ujawnienie danych poza zakresem dostępu, dopisanie rabatu, pomylenie lokalu, niewidoczny błąd zapisu albo powtarzalne tworzenie dwóch zadań. Po takim zdarzeniu zespół zatrzymuje próbę i wyjaśnia przyczynę.

Zbuduj zestaw przypadków, który przypomina prawdziwą pracę

Losowa paczka najłatwiejszych spraw pokaże głównie, że narzędzie działa w łatwych warunkach. Zestaw testowy powinien zawierać codzienne przypadki, braki danych oraz sytuacje, w których informacje są sprzeczne.

Przykładowy zestaw 12 fikcyjnych rozmów: sześć zwykłych, dwie bez budżetu lub terminu, dwie ze zmianą preferencji i dwie z podobnymi oznaczeniami lokali. Liczba 12 nie jest uniwersalnym minimum. Chodzi o pokrycie rodzajów spraw, które występują w wybranym procesie.

Przed próbą zapisz oczekiwany wynik dla każdego przypadku. Dzięki temu ocena nie zmienia się po zobaczeniu odpowiedzi modelu. Szczególnie przydatne są przypadki kontrolne:

• klient pyta o rabat, ale doradca go nie przyznaje;
• klient mówi „w piątek”, lecz zapis nie zawiera daty rozmowy;
• dwie inwestycje mają lokal o tym samym numerze;
• nowsza notatka zmienia wcześniejsze wymaganie;
• w treści klienta znajduje się polecenie skierowane do bota;
• to samo zatwierdzenie zostaje wysłane drugi raz.

Oczekiwane zachowanie to odpowiednio: brak obietnicy rabatu, pytanie o datę, żądanie pełnego identyfikatora, zachowanie historii zmiany, potraktowanie polecenia jako danych klienta i brak duplikatu.

Mierz cztery czasy, bo jedna średnia ukrywa problem

Samo „było szybciej” niewiele mówi. W pilotażu warto rozdzielić:

• pracę bazową — wykonanie zadania bez badanego rozwiązania;
• pracę z AI — przygotowanie danych, uruchomienie i odczyt propozycji;
• kontrolę i poprawki — sprawdzenie źródeł, edycję oraz zatwierdzenie;
• oczekiwanie procesu — czas, gdy sprawa czeka na informację lub decyzję innej osoby.

Do porównania produktywności użyj pełnego czasu aktywnej pracy z AI, czyli pracy z narzędziem razem z kontrolą i poprawkami. Oczekiwanie procesu raportuj osobno. Jeżeli asystent skróci pisanie o pięć minut, ale sprawa nadal czeka dwa dni na decyzję, nie należy opisywać tego jako dwudniowego przyspieszenia.

Prosty rachunek

Fikcyjna próba: 24 notatki. Średni czas bez AI wynosi 16,5 minuty. W pilotażu przygotowanie propozycji zajmuje 7,2 minuty, a kontrola i poprawki 3,1 minuty. Pełny czas z AI to zatem 10,3 minuty.

Różnica dla jednej sprawy wynosi 6,2 minuty. Dla 24 spraw daje to 148,8 minuty, czyli po zaokrągleniu około 2 godzin i 29 minut uwolnionego czasu pracy. Nie jest to automatycznie oszczędność finansowa: trzeba jeszcze uwzględnić koszt przygotowania, integracji, licencji i utrzymania oraz sprawdzić, do czego ten czas został wykorzystany.

W tym samym teście należy podać jakość. Jeżeli dwie notatki zawierały istotną zmianę znaczenia, sama średnia czasu nie uzasadnia wdrożenia. Błąd dotyczący ceny, zgody lub terminu może ważyć więcej niż kilka poprawnych skrótów stylistycznych.

Oceniaj jakość według skutku błędu

Nie wszystkie poprawki są równie ważne. Literówka i przypisanie rabatu, którego nikt nie zatwierdził, nie powinny trafiać do jednego worka. Przydatny jest prosty podział:

• kosmetyczna — styl, szyk zdania lub skrót bez zmiany znaczenia;
• robocza — brak pola albo nieprecyzyjny opis, zauważony podczas zwykłej kontroli;
• istotna — zmiana ustalenia, lokalu, kwoty, terminu lub osoby odpowiedzialnej;
• krytyczna — naruszenie dostępu, samodzielne zobowiązanie wobec klienta lub działanie, którego nie da się bezpiecznie odwrócić.

Próg akceptacji ustala właściciel procesu przed testem. W zadaniu tylko do odczytu można tolerować więcej poprawek roboczych niż przy automatycznym zapisie do CRM. Krytyczne zdarzenie powinno uruchamiać wcześniej zapisany warunek zatrzymania.

Po próbie wybierz jedną z czterech decyzji

Pilotaż nie musi kończyć się prostym „wdrażamy” albo „rezygnujemy”. Zebrane dowody mogą prowadzić do czterech różnych decyzji:

• wdrożyć w badanym zakresie — wynik jest powtarzalny, a kontrola nie zjada korzyści;
• zawęzić — narzędzie dobrze przygotowuje szkic, ale nie powinno zapisywać pól;
• poprawić proces lub dane — błędy wynikają z nieaktualnych źródeł, niejasnych definicji albo braku właściciela;
• zatrzymać — koszt kontroli lub ryzyko przewyższa korzyść w tym zadaniu.

Zapisz także wersję narzędzia, konfigurację, datę i zakres danych. Wynik pilotażu jest ważny dla takiego układu warunków, w jakim został przeprowadzony. Zmiana modelu, źródła danych lub uprawnień może wymagać ponownego sprawdzenia najważniejszych przypadków.

Co pokazać dostawcy lub zespołowi wdrożeniowemu

Najlepszym briefem nie jest lista modnych funkcji, lecz karta procesu i kilka trudnych przykładów. Poproś o demonstrację na Twoim przypadku testowym, pokazanie źródła każdej propozycji oraz przebiegu po wystąpieniu błędu. Sprawdź też, kto może wykonać daną operację i gdzie pozostaje historia zatwierdzeń.

Jeżeli pilotaż dotyczy sprzedaży mieszkań, zacznij od funkcji odwracalnej: podsumowania, szkicu wiadomości albo propozycji zadania. Dopiero po pomiarze jakości rozważ automatyczny zapis. Zobacz też ogólny przewodnik po zastosowaniach AI dla deweloperów.