Agentforce w CRM: jak zaplanować pilota

Einstein Copilot to historyczna nazwa asystenta Salesforce, który został przemianowany na Agentforce. Przy ocenie nowego projektu należy więc sprawdzać aktualny typ agenta, jego działania, uprawnienia i warunki licencyjne. Sama zmiana nazwy nie oznacza, że firma otrzymała wszystkie możliwości obecnej rodziny Agentforce ani że dotychczasowa konfiguracja stała się autonomicznym procesem.

Agentforce warto rozważyć przede wszystkim wtedy, gdy konkretne zadanie zależy od danych i operacji w Salesforce. Przykładem jest przygotowanie odpowiedzi na podstawie sprawy klienta lub wykonanie jasno ograniczonej czynności w CRM. Przed zakupem trzeba jednak ustalić, czy problemem jest odnalezienie informacji, przygotowanie propozycji czy faktyczne wykonanie działania. Każdy z tych wariantów wymaga innych kontroli.

Co stało się z nazwą Einstein Copilot?

Salesforce podał w informacji o zmianie nazwy, że typ agenta Einstein Copilot for Salesforce został przemianowany na Agentforce bez zmiany funkcjonalności wynikającej z samego przemianowania. Informacja dotyczy zmiany udostępnianej od stycznia 2025 roku. Nie jest to opis całej późniejszej ewolucji platformy.

W dokumentach i istniejących wdrożeniach mogą więc występować różne nazwy. Przy inwentaryzacji zapisz faktyczny typ agenta, używane funkcje, uprawnienia i integracje. Samo odnalezienie słowa „Einstein” w umowie nie wystarczy do ustalenia, jakie możliwości są dostępne. Analogicznie nazwa Agentforce na stronie produktu nie opisuje automatycznie zawartości posiadanego pakietu.

Nie trzeba przebudowywać działającego procesu wyłącznie z powodu nazewnictwa. Potrzebna jest natomiast ponowna ocena, jeśli firma chce zmienić zakres działań: na przykład przejść od pomocy pracownikowi do obsługi klienta bez jego udziału. To zmiana odpowiedzialności, kanału i ryzyka, nawet gdy część komponentów pozostaje wspólna.

Z jakich decyzji składa się projekt agenta w CRM?

Najpierw określ zadanie biznesowe i granice. „Pomagaj sprzedawcom” jest zbyt szerokie. „Przygotuj szkic notatki po spotkaniu na podstawie wskazanych danych, bez zmiany etapu szansy” pozwala zaprojektować odbiór. W przypadku obsługi klienta równie ważne będzie określenie, kiedy agent przekazuje sprawę człowiekowi.

Następnie zdefiniuj dostępne działania. Dokumentacja akcji w Agent Script rozróżnia wywołania deterministyczne oraz działania udostępniane modelowi jako narzędzia. Zawiera również ustawienie wymagania potwierdzenia przez użytkownika. Te mechanizmy trzeba stosować zgodnie z konkretnym typem agenta i obsługiwanym scenariuszem.

Trzecia decyzja dotyczy danych. Agent może potrzebować rekordu klienta, historii sprawy i aktualnej polityki obsługi. Dane muszą być dostępne, spójne i właściwe dla danej osoby. Nie wystarczy, że gdzieś istnieje artykuł wiedzy. Trzeba ustalić, czy jest aktualny oraz czy nie koliduje z warunkami zapisanymi w konkretnej umowie.

Warstwa projektu	Pytanie wymagające odpowiedzi	Typowy błąd planowania
Zadanie	Jaki rezultat ma powstać dla użytkownika?	Ogólna obietnica pomocy w całej sprzedaży
Dane	Które rekordy i dokumenty są podstawą?	Przyjęcie, że cały CRM jest poprawny
Działania	Co agent może rzeczywiście wykonać?	Mylenie wygenerowanego tekstu z zapisem
Uprawnienia	W jakim kontekście działa każda operacja?	Oparcie kontroli na samym poleceniu
Nadzór	Kiedy człowiek przejmuje sprawę?	Eskalacja bez właściciela i dalszego procesu

Jak sprawdzić uprawnienia i skutki działania?

Salesforce w swoim przewodniku Agentforce zaleca ograniczanie zakresu akcji i wbudowanie kontroli tożsamości oraz uprawnień w działania prywatne. Dla projektu oznacza to konieczność sprawdzenia każdej ścieżki wykonania. Widoczność danych w jednym ekranie nie dowodzi poprawnego dostępu w innej integracji.

Rozdziel odczyt, przygotowanie propozycji i zapis. Agent może mieć prawo podsumować sprawę, lecz nie prawo zmienić zobowiązania wobec klienta. Warto utworzyć oddzielne działania dla tych celów. Wtedy zakres uprawnień i testów jest bardziej czytelny niż przy jednym narzędziu przyjmującym dowolne polecenie.

Przed zmianą rekordu użytkownik powinien zobaczyć konkretne wartości i cel operacji. Potwierdzenie „wykonaj zadanie” jest zbyt ogólne, jeśli w tle zmienia się kilka pól albo wysyłana jest wiadomość. Po wykonaniu trzeba odczytać rzeczywisty rezultat. Deklaracja modelu, że operacja się udała, nie zastępuje potwierdzenia systemu.

Uwzględnij również konflikty. Sprzedawca może zmienić etap szansy, gdy agent przygotowuje rekomendację. Akcja powinna sprawdzić aktualny stan przed zapisem. W przeciwnym razie zatwierdzenie poprawnego szkicu na podstawie starych danych może nadpisać nowszą decyzję człowieka.

Jak wygląda rozsądny pierwszy proces?

Przykład dydaktyczny: zespół obsługi chce przyspieszyć przygotowanie odpowiedzi dotyczącej statusu zgłoszenia. Agent odczytuje dozwolone dane sprawy i przygotowuje szkic. Pracownik widzi źródła, sprawdza treść i decyduje o wysłaniu. W pierwszym etapie agent nie zmienia statusu sprawy ani nie składa nowych obietnic klientowi.

Zakres jest celowo mały, ale pozwala sprawdzić kilka istotnych rzeczy: jakość danych, poprawność identyfikacji sprawy, użyteczność odpowiedzi i koszt korekty. Jeśli pracownicy muszą przepisywać większość tekstu, zwiększanie autonomii nie rozwiąże problemu. Najpierw trzeba ustalić, czy winny jest brak kontekstu, źle określona instrukcja czy niewłaściwy wybór zadania.

Drugi etap może obejmować wykonanie jednej ograniczonej czynności, na przykład zapis zatwierdzonej notatki. Wymaga to osobnego testu integracji, duplikatów i uprawnień. Sukces w generowaniu tekstu nie stanowi automatycznie zgody na zapis do CRM. Rozszerzenie zakresu powinno mieć własne kryteria przejścia.

Nie zaczynaj od procesu, którego sami pracownicy nie potrafią jednoznacznie opisać. Jeśli poszczególne zespoły inaczej rozumieją etap szansy albo powód zamknięcia sprawy, agent odtworzy tę niejednoznaczność. Uzgodnienie pojęć może przynieść korzyść jeszcze przed uruchomieniem AI.

Jak testować agenta przed udostępnieniem użytkownikom?

Salesforce udostępnia narzędzia do testowania agentów, opisane między innymi w materiale Agentforce Testing Center. Możliwość uruchomienia wielu prób jest przydatna, lecz jakość testu zależy od przygotowanych przypadków i oczekiwań. Sam wynik zbiorczy nie wyjaśnia konsekwencji błędnego działania.

Zestaw powinien obejmować typowe pytania, brak danych, niejednoznaczny rekord, odmowę dostępu i próbę wyjścia poza zakres. Przy operacjach zapisujących dane sprawdzaj stan systemu po wykonaniu, a nie tylko treść odpowiedzi. Użyj również sytuacji, w której zewnętrzna usługa nie odpowiada albo zwraca błąd po częściowym wykonaniu.

Przypadek testowy	Oczekiwany rezultat	Dowód do zachowania
Poprawna sprawa klienta	Szkic oparty na właściwych danych	Wskazane rekordy i odpowiedź
Dwa podobne rekordy	Doprecyzowanie przed użyciem danych	Przebieg wyboru właściwej sprawy
Brak uprawnień	Odmowa bez ujawnienia treści	Wynik kontroli dostępu
Nieaktualna polityka	Zatrzymanie lub właściwa aktualna podstawa	Źródło użyte do odpowiedzi
Powtórzone żądanie zapisu	Brak niezamierzonego duplikatu	Stan rekordu i identyfikator operacji
Zadanie poza zakresem	Przekazanie do właściwej obsługi	Powód i miejsce eskalacji

Testy trzeba powtarzać po zmianie instrukcji, działań, danych i modelu. Zachowaj wersje konfiguracji oraz przypadki, które wcześniej ujawniły błąd. Dzięki temu poprawa jednego scenariusza nie pozostanie niezauważoną regresją w drugim. Część prób powinna być wykonywana przez osoby znające rzeczywisty proces, a nie wyłącznie przez konfiguratora.

Jak porównać Agentforce z inną architekturą?

Jeśli praca i dane koncentrują się w Salesforce, integracja z CRM może przemawiać za wykorzystaniem Agentforce. Jeżeli proces obejmuje wiele innych systemów, trzeba policzyć także połączenia, tożsamość i utrzymanie działań poza CRM. Logo platformy nie eliminuje kosztu integracji.

Porównanie z asystentem biurowym powinno dotyczyć rodzaju zadania. Microsoft Copilot dla firm może odpowiadać na potrzeby pracy z dokumentami i komunikacją, podczas gdy dany projekt Agentforce ma obsługiwać operacje CRM. Nie należy deklarować, że jeden produkt obejmuje wszystko, co robi drugi, bez sprawdzenia konkretnych funkcji, licencji i integracji.

Do kalkulacji włącz licencje, zużycie, przygotowanie danych, budowę działań, testowanie i pracę zespołu nadzorującego. Koszt licz na zakończoną poprawnie sprawę. Jeśli agent regularnie wymaga ponownego wykonania zadania przez pracownika, samo skrócenie pierwszej odpowiedzi nie dowodzi oszczędności.

Przed decyzją zakupową zapisz granice pilota oraz warunki jego zatrzymania. Ustal, kto odpowiada za incydenty i jak wrócić do dotychczasowego procesu. Dalszym krokiem jest określenie zakresu działań agenta półautonomicznego: co może odczytać, co przygotować i co wykonać dopiero po potwierdzeniu. Taki kontrakt będzie użyteczny niezależnie od wybranej platformy.

Jaki wynik pilota uzasadnia dalsze wdrożenie?

Ustal jeden rodzaj spraw, na przykład przygotowanie odpowiedzi na zapytanie dotyczące istniejącej umowy. Zapisz, które obiekty CRM są źródłem, jakie pola agent może odczytać i jakie działanie wymaga akceptacji opiekuna klienta. Dobierz próbę zawierającą poprawne dane, brak zgody, nieaktualny kontakt, dwa rekordy o podobnej nazwie i prośbę o zmianę warunków umowy. Wynik testu powinien mówić, czy agent wybrał właściwą ścieżkę, a nie tylko czy jego odpowiedź brzmiała przekonująco.

Agentforce Testing Center wspiera scenariusze testowe dla odpowiedzi i działań. Dokumentacja Salesforce zaznacza, że testy mogą modyfikować dane CRM, dlatego przeprowadzaj je w środowisku sandbox i kontroluj zużycie. Własne przypadki graniczne są potrzebne obok scenariuszy generowanych automatycznie. Po teście potwierdź rzeczywisty stan rekordu oraz zapis zdarzenia. Tekst „zaktualizowano” nie stanowi dowodu zapisu.

Do decyzji dołącz koszt obsługi całej sprawy: pracę konfiguratora, utrzymanie danych, nadzór człowieka, zużycie platformy i poprawki po błędach. Porównaj go z dotychczasowym procesem dla podobnych spraw. Ustal próg błędów, po którym agent traci możliwość wykonywania danego działania, oraz osobę podejmującą decyzję o ponownym uruchomieniu. Rozszerzenie na kolejny proces wymaga nowej próby uprawnień i skutków działania. Sukces w odczytywaniu danych nie jest automatycznym pozwoleniem na zapis.

Przed rozpoczęciem eksploatacji przygotuj sposób obsługi sprzeciwu klienta. Jeśli agent zaproponował błędną informację, opiekun powinien umieć odtworzyć dane wejściowe i wskazać, czy błąd pochodził z rekordu, instrukcji czy działania narzędzia. Ustal też, kto aktualizuje test po naprawie. Bez takiej pętli ta sama pomyłka wróci po zmianie konfiguracji.

Zespół powinien przetestować użytkownika o ograniczonych uprawnieniach oraz sprawę należącą do innego opiekuna. Odpowiedź nie może ujawniać danych, których ta osoba nie widzi w zwykłym interfejsie. Zapis audytowy ma pokazywać wykonaną operację i jej wynik, bez polegania na podsumowaniu wygenerowanym przez model.