Podsumowanie rozmowy z klientem przez AI: jak oddzielić ustalenie od sugestii

Po rozmowie z klientem powstaje notatka: termin wdrożenia ustalono na czerwiec, projekt obejmie trzy oddziały, a ofertę wyśle dział handlowy. Problem w tym, że czerwiec padł jako propozycja, liczba oddziałów była pytaniem, a osoba odpowiedzialna za ofertę nie została wskazana. Notatka brzmi porządnie, lecz zmienia sens spotkania. Przy automatycznym podsumowaniu właśnie takie różnice wymagają uwagi.

AI może pomóc uporządkować materiał z rozmowy, wskazać zadania i skrócić czas przygotowania notatki. System powinien jednak odróżniać ustalenie od sugestii oraz pokazywać, czego nie udało się potwierdzić. Zanim zapisze wynik w CRM lub wyśle go uczestnikom, warto ustalić źródło informacji, sposób sprawdzenia i osobę odpowiedzialną za decyzję.

Jeśli planujesz podobny proces, wyślij brief z opisem rozmów, odbiorców notatki i systemu, do którego ma trafić wynik. Wystarczy fikcyjny przykład ustalenia i pytania otwartego. Nie przesyłaj nagrań klientów, danych poufnych ani haseł podczas pierwszego kontaktu.

Ustal, do czego ma służyć notatka

Wyobraźmy sobie firmę projektującą aplikacje. Po spotkaniu handlowym zespół potrzebuje informacji o problemie klienta, zakresie do doprecyzowania i terminie kolejnej rozmowy. Osoba przygotowująca ofertę nie musi otrzymywać każdego zdania z godzinnego spotkania. Potrzebuje natomiast wiedzieć, które wymagania zostały potwierdzone, a które stanowią jedynie pomysł do sprawdzenia. To przykład projektowy, nie opis konkretnego spotkania.

Przed wyborem narzędzia warto zapytać przyszłych użytkowników, jakie decyzje podejmują na podstawie notatki. Inny zakres może być potrzebny zespołowi handlowemu, inny osobie planującej wdrożenie, a jeszcze inny uczestnikowi, który otrzyma podsumowanie po spotkaniu. Nie każdy powinien automatycznie widzieć wszystkie szczegóły rozmowy. Zakres dostępu i treści zależy od procesu.

Uzgodnijcie prostą strukturę: temat rozmowy, potwierdzone ustalenia, pytania otwarte i proponowane następne kroki. Można też wskazać osobę odpowiedzialną oraz termin, ale tylko wtedy, gdy zostały rzeczywiście ustalone. Jeśli uczestnicy powiedzieli „wrócimy do tego w przyszłym tygodniu”, system nie powinien sam dopisywać konkretnej daty i przypisywać jej przypadkowej osobie.

Dobra struktura pomaga, lecz nie zastępuje weryfikacji treści. O tym, jak przygotować asystenta odwołującego się do źródła, piszemy w artykule o asystencie AI do firmowej wiedzy. Przy rozmowach źródłem może być transkrypcja, notatka uczestnika albo inny materiał przyjęty w danym procesie.

Oddziel decyzję od propozycji

W rozmowach padają zdania warunkowe, zastrzeżenia i pomysły odłożone do dalszego sprawdzenia. Sformułowanie „moglibyśmy zacząć od jednego oddziału” nie musi oznaczać decyzji o zakresie wdrożenia. Podobnie „prawdopodobnie mamy API” nie jest potwierdzeniem dostępnej integracji. System powinien zachować ten stopień pewności zamiast zamieniać każdą sugestię w fakt dokonany.

Przy każdym istotnym punkcie warto móc wrócić do fragmentu materiału źródłowego. Jeżeli notatka podaje termin lub kwotę, osoba sprawdzająca powinna zobaczyć, skąd pochodzi ta informacja i czy rozmówcy rzeczywiście ją zatwierdzili. Oznaczenie źródła nie gwarantuje poprawności interpretacji, ale pomaga znaleźć miejsce wymagające uwagi.

Zaplanujcie sposób oznaczania braków. Gdy nie wiadomo, kto ma przygotować ofertę, w notatce może pojawić się zadanie „ustalić osobę odpowiedzialną”. Nie powinno pojawiać się nazwisko wybrane na podstawie tego, kto ostatni się odezwał. Jeżeli materiał jest nieczytelny albo wypowiedź urwana, właściwym wynikiem bywa pytanie do uczestnika zamiast pewnego zdania.

Podobnie należy postępować ze sprzecznymi wypowiedziami. Termin zaproponowany na początku rozmowy mógł zostać później zmieniony. System powinien wskazać ostatnie potwierdzone ustalenie albo pozostawić sprawę do wyjaśnienia, gdy nie da się rozstrzygnąć znaczenia. Osoba zatwierdzająca notatkę potrzebuje możliwości poprawienia wyniku przed zapisaniem go w miejscu, z którego korzystają inni.

Sprawdź jakość materiału wejściowego

Podsumowanie zależy od tego, co faktycznie trafiło do systemu. Transkrypcja może pominąć fragment, błędnie zapisać nazwę produktu albo przypisać wypowiedź niewłaściwej osobie. Jeśli rozmowa odbywa się w kilku językach, znaczenie mogą mieć również nazwy własne i ustalenia wypowiedziane w różnym tempie. Warto przewidzieć sposób oznaczenia miejsc, których nie udało się odczytać lub przypisać.

Przy testach nie wystarczy jedno nagranie w dobrych warunkach. Przygotujcie przykłady o różnej strukturze rozmowy, z przerwaniem wypowiedzi, niejednoznacznym terminem oraz zmianą wcześniejszej propozycji. Materiały powinny być dobrane i przechowywane zgodnie z zasadami organizacji. Można zacząć od przygotowanych scenariuszy z fikcyjnymi danymi, a dopiero później zdecydować, czy potrzebne są inne przykłady.

Jeśli system korzysta z transkrypcji innego dostawcy niż model podsumowujący, ustalcie granicę odpowiedzialności obu usług. Błędny zapis nazwy klienta może pochodzić z pierwszego etapu, a niewłaściwy wniosek z drugiego. Rozdzielenie tych sytuacji pomaga poprawić proces bez zgadywania. O ustalaniu źródeł danych piszemy w artykule o integracji systemów i źródłach danych.

Nie każda rozmowa musi być nagrywana, aby powstała użyteczna notatka. W niektórych procesach wystarczy szkic przygotowany przez uczestnika i uporządkowany przed zapisaniem. Wybór zależy od celu oraz przyjętych zasad. Zanim uruchomicie nagrywanie lub przekazywanie materiału do zewnętrznej usługi, sprawdźcie wymagania właściwe dla uczestników, miejsca i sposobu użycia danych.

Zaprojektuj przegląd przed wysłaniem

Osoba zatwierdzająca powinna widzieć proponowaną notatkę w formie, którą da się poprawić. Przydatne jest wyraźne oddzielenie ustaleń od pytań otwartych i możliwość sprawdzenia fragmentu źródła. Zespół może też potrzebować pola wskazującego, czy dany punkt wolno przekazać uczestnikom zewnętrznym. Nie każda wewnętrzna obserwacja powinna automatycznie znaleźć się w wiadomości do klienta.

Przed wysyłką trzeba sprawdzić adresatów, treść i załączniki, jeśli występują. Potwierdzenie powinno dotyczyć konkretnej wersji notatki. Jeżeli po akceptacji ktoś istotnie zmieni treść lub odbiorcę, proces może wymagać ponownej decyzji zgodnie z zasadami firmy. Takie rozdzielenie propozycji i działania opisujemy w artykule o zatwierdzaniu działań AI.

Warto również przewidzieć odmowę publikacji notatki. Uczestnik spotkania może uznać, że zapis pomija istotny warunek albo zawiera informację nieprzeznaczoną dla pozostałych osób. System powinien pozwolić wrócić do wersji roboczej, a pracownik musi wiedzieć, czy wcześniej wysłana wiadomość wymaga sprostowania. Po wysyłce nie każdą informację da się po prostu cofnąć jednym przyciskiem.

Dobrze określić czas przeznaczony na przegląd oraz zastępstwo, gdy opiekun sprawy jest nieobecny. Zautomatyzowane przygotowanie treści nie kończy procesu, jeśli nikt nie ma obowiązku jej sprawdzić. Kolejka oczekujących podsumowań powinna pokazywać właściciela, czas oczekiwania i kolejny krok, zamiast gromadzić wersje robocze bez decyzji.

Ustal przepływ i czas przechowywania danych

Mapa danych powinna obejmować źródło rozmowy, transkrypcję, usługę podsumowującą, miejsce przeglądu i system przechowujący zatwierdzoną notatkę. Przy każdym etapie zapytajcie, kto może zobaczyć materiał, czy powstaje kopia i jak długo jest potrzebna. Dzienniki techniczne oraz narzędzia pomocy mogą stanowić dodatkowe miejsca przetwarzania, dlatego również trzeba je uwzględnić.

Dokumentacja OpenAI dotycząca kontroli danych w API opisuje różne kategorie przechowywania oraz opcje zależne od używanej funkcji i warunków usługi. Nie należy przenosić tych informacji na każdego dostawcę ani zakładać, że wszystkie ustawienia są dostępne lub włączone na danym koncie. Przed wdrożeniem sprawdźcie aktualną dokumentację, konfigurację i umowę dotyczącą wybranego rozwiązania.

Ustalcie, czy do przygotowania podsumowania potrzebne są pełne dane identyfikujące uczestników. Być może wystarczy robocze oznaczenie osoby, a właściwe powiązanie zostanie zachowane w systemie firmowym. Trzeba jednak sprawdzić, czy usunięcie nazw nie pozbawi notatki potrzebnego sensu albo nie pozostawi informacji, które nadal pozwalają rozpoznać rozmówcę. O przygotowaniu źródeł piszemy w artykule o porządku w danych przed wdrożeniem AI.

Zapisujcie w CRM tylko to, co jest potrzebne dla dalszej pracy i dostępne właściwym osobom. Jeśli notatka trafia do kilku miejsc, określcie źródło obowiązującej wersji oraz sposób sprostowania błędu. Korekta w jednym narzędziu nie zawsze aktualizuje pozostałe kopie. Odpowiedzialność za tę zmianę należy ustalić przed pierwszą wysyłką do zespołu.

Testuj rozbieżności i poprawki

Przygotujcie zestaw pytań kontrolnych związanych z rzeczywistymi zadaniami. Czy notatka odróżnia propozycję od zaakceptowanego zakresu? Czy wskazuje brak decyzji o terminie? Czy nie przypisuje zadania osobie, która go nie przyjęła? Czy osoba sprawdzająca może znaleźć fragment źródła i poprawić wynik? Oczekiwane zachowanie warto zapisać przed oceną odpowiedzi.

W testach przyjrzyjcie się również odmowie, błędowi integracji i zmianie treści po akceptacji. Jeśli zapis w CRM nie powiódł się po przygotowaniu notatki, użytkownik powinien wiedzieć, czy może bezpiecznie ponowić operację. W artykule o integracjach API i webhookach opisujemy, dlaczego otrzymanie komunikatu i wykonanie zadania są osobnymi etapami.

Zachowajcie przykłady pomyłek w sposób zgodny z zasadami danych i sprawdzajcie je po zmianie modelu lub instrukcji. Przy ocenie nie wystarczy policzyć, ile notatek powstało. Potrzebne są również przypadki, w których wynik został poprawiony, oraz przegląd informacji, które błędnie uznano za potwierdzone. Więcej o przygotowaniu scenariuszy piszemy w tekście o testowaniu asystenta AI.

Warto także ustalić, jak postępować po zgłoszeniu korekty przez klienta. Jeżeli odbiorca odpowie, że termin albo zakres został opisany niewłaściwie, pracownik powinien móc odnotować wyjaśnienie przy tej samej sprawie. System nie musi automatycznie uznawać każdej nowej wiadomości za ostateczną decyzję. Może wskazać rozbieżność i poprosić opiekuna o potwierdzenie, zanim zmieni dane wykorzystywane w planowaniu. Jeśli zespół chce później analizować powtarzające się uwagi z wielu rozmów, powinien osobno określić zasady analizy opinii klientów.

Przy podsumowaniach cyklicznych spotkań szczególne znaczenie ma odróżnienie nowych ustaleń od informacji przeniesionych z poprzedniej rozmowy. Zadanie, które w zeszłym tygodniu było otwarte, może być już zakończone. Dlatego każda notatka powinna mieć datę spotkania, źródło oraz zakres, do którego się odnosi. Zespół może następnie połączyć ją z wcześniejszą sprawą, zachowując widoczność zmian i osób odpowiedzialnych.

Dobrze przetestować także granice dostępu. Uczestnik spotkania może widzieć podsumowanie, ale nie mieć prawa otworzyć wszystkich wcześniejszych dokumentów klienta. Z kolei pracownik, który przejmuje sprawę, może potrzebować szerszego kontekstu po nadaniu mu odpowiednich uprawnień. O tym, dlaczego ograniczenia powinny obowiązywać również przy pobieraniu źródła, piszemy w artykule o uprawnieniach do dokumentów.

Na koniec warto uzgodnić właściciela procesu i sposób zgłaszania nieprawidłowych podsumowań. Jeżeli poprawki wskazują na powtarzającą się pomyłkę, zespół może dodać podobny przypadek do testów. Zmianę instrukcji lub narzędzia należy następnie sprawdzić na wcześniejszych przykładach, aby lepszy wynik dla jednej rozmowy nie ukrył pogorszenia w innym rodzaju spotkań.

Pierwszą wersję warto ograniczyć do jednej grupy rozmów i zespołu, który może ocenić poprawność wyników. Po próbie łatwiej zdecydować, które informacje nadają się do automatycznego przygotowania, a gdzie konieczny jest dodatkowy przegląd. W automatyzacjach i workflow liczy się cały obieg decyzji, od źródła po osobę, która z niej skorzysta.