Agentforce usuwa najtrudniejszą barierę sprzedaży: dane z wielu orgów

Legacy’owe procesy sprzedażowe rzadko padają przez brak funkcji, a częściej przez brak wspólnego kontekstu. W globalnym Salesforce potrzeba było ponad 1000 godzin manualnej pracy miesięcznie, żeby skleić footprint klientów z wielu orgów (Salesforce). Agentforce usunął ten wąski gardło w dwa tygodnie, wprowadzając deterministyczny silnik agregacji danych i natural language entry point w Deal Agent. To podejście nie tylko zmienia sposób pracy sellerów, lecz także wyznacza standard dla polskich firm działających w modelu multi-org i integrujących Salesforce z klasycznymi ERP. W tym artykule pokazuję, jak działa nowa architektura, dlaczego radzi sobie tam, gdzie tradycyjne raporty i middleware się poddają, oraz jak realnie wdrożyć podobny model w polskich orgach.

Techniczne fundamenty: silnik agregacji zamiast real-time multi-org

Customer Footprint rozwiązuje problem, który każdy większy zespół RevOps zna z autopsji: klient w systemach wygląda inaczej w każdym regionie, każda instancja Salesforce ma inny schemat, a assety mają różne daty wygasania zależne od lokalnych reguł. W podejściu opisanym przez Salesforce agregacja nie odbywa się w czasie rzeczywistym, ponieważ trafiałaby natychmiast w limity API i dawała niespójne wyniki. Zamiast tego powstała centralna warstwa agregacyjna, która normalizuje schematy, skleja hierarchie i rozwiązuje tożsamości klientów przed wykonaniem zapytania. Kluczowym mechanizmem stało się powiązanie klientów na podstawie DUNS, globalnych identyfikatorów oraz fuzzy matchingu, co usuwa zależność od różnic w strukturze Accountów i Contractów.

Dzięki temu Deal Agent nie wykonuje żadnych krzyżowych joinów podczas rozmowy z użytkownikiem. Agentforce korzysta jedynie z gotowych, zdeterministycznych danych zwróconych przez API, bez prób interpretacji czy generowania nowych wniosków. W praktyce oznacza to minimalizację halucynacji modelu oraz pełną powtarzalność wyników, co w przypadku pricingu i odnowień jest absolutnie kluczowe. Takie podejście idealnie wpisuje się w trend modularyzacji agentów, opisany przy okazji MCP w Agentforce, gdzie AI działa na konkretnych, kontrolowanych narzędziach.

Dla polskich zespołów najważniejsza lekcja jest prosta: agent nie może być odpowiedzią na chaos danych. Jeśli to, co trafia do LLM, nie jest znormalizowane, nie ma szans na stabilną automatyzację. Customer Footprint potwierdza, że najpierw porządek w strukturze danych, dopiero potem generatywny interfejs. Warto rozważyć podobny model, zwłaszcza jeśli organizacja prowadzi sprzedaż na kilku tenantach lub łączy Salesforce z ERP typu Comarch, SAP lub Dynamics.

Agentforce jako warstwa interakcji: dlaczego nie kod, tylko deklaratywne actiony

Zespół Salesforce zbudował produkcyjną integrację w dwa tygodnie, bo nie próbował tworzyć nowego interfejsu, backendu ani warstwy uwierzytelniającej. Zamiast tego cała logika konwersacyjna została skonfigurowana deklaratywnie w Agentforce: topics, actions, prompt templates i walidacje dostępów. Klucz polegał na rozdzieleniu dwóch strumieni pracy: deterministyczna integracja danych w backendzie oraz lekka warstwa interpretacji i uruchamiania flow po stronie agenta. Seller wywołuje footprint jednym zdaniem, a Agentforce orchestration zamienia to na sekwencję API-callów bez żadnych custom controllers.

Takie wzorce idealnie odzwierciedlają kierunek, który przewijaliśmy już w analizach Flow Orchestration: AI nie zastępuje automatyzacji, tylko ją wywołuje. Developerzy skupiają się więc na poprawności backendu, a admini na definicji interakcji. W praktyce oznacza to szybsze iteracje i brak potrzeby tworzenia kolejnych elementów UI, które i tak po roku okazują się martwe.

Dla polskich zespołów to model wartościowy zwłaszcza tam, gdzie backlog deweloperski blokuje szybkie poprawki w RevOps. Ułożenie agentów na deklaratywnych actionach oraz ograniczenie kodu do czystej logiki biznesowej skraca delivery i zmniejsza dług techniczny. Warto potraktować to jako wzorzec do projektowania agentów sprzedażowych, zwłaszcza w kontekście rozproszonych struktur zespołów, które coraz częściej działają z poziomu Slacka lub mobilnego UI.

Automatyzacja, która usuwa realne bottlenecks: od 3 dni do sekund

Najbardziej imponującym efektem wdrożenia jest redukcja manualnej pracy o około 90 procent (źródło: Salesforce). Wcześniej przygotowanie jednego footprintu trwało od jednego do trzech dni i wymagało pracy operacyjnej na wielu orgach. Teraz seller uruchamia zapytanie w Deal Agent, a w ciągu sekund otrzymuje ustandaryzowany arkusz Google na poziomie L5, zawierający ceny, liczbę subskrypcji, dane tenantów oraz statusy kontraktów. W pierwsze dwa tygodnie system wygenerował 391 raportów, eliminując zaległości kolejkowania i zwiększając o 30 procent tygodniowo liczbę zapytań.

To nie zwykła automatyzacja, ale fundamentalna zmiana w modelu operacyjnym sprzedaży. Zespół przestaje mieć strukturę „operacje jako bottleneck”, a sellerzy nie czekają już na dane, by rozpocząć pricing czy negocjacje. W polskich realiach podobny problem dotyczy szczególnie firm integrujących Salesforce z lokalnymi billingami, systemami subskrypcyjnymi i modułami sprzedażowymi ERP. Powtarzalne, manualne łączenie danych jest nadal normą, a wdrożenie agentów może realnie zwolnić zespoły RevOps o kilkadziesiąt godzin miesięcznie.

Widać tu również trend konsolidacji kontekstu sprzedażowego, rozwijany przez Salesforce m.in. w segmentach Agentforce Commerce i Data 360. Model „dane przygotowane upstream + agent jako UI” coraz częściej przebija klasyczne dashboardy i raporty, które nigdy nie obejmowały w pełni danych z różnych systemów.

Jak wdrożyć podobną architekturę w Polsce: roadmapa praktyczna

Wdrożenie Customer Footprint nie wydarzyło się dzięki magii AI, tylko dzięki precyzyjnemu rozdzieleniu procesów i warstw danych. Pierwszy krok to stworzenie stabilnego źródła prawdy: BigQuery, Snowflake lub Data Cloud z jasno zdefiniowanymi regułami normalizacji. Drugi krok to budowa deterministycznych API lub Integration Procedures (w przypadku Vlocity), które mogą zwrócić gotowe dane agentowi. Dopiero na końcu powstaje warstwa Agentforce: dekoduje intencję, uruchamia actiony i prezentuje wynik.

Polskie firmy muszą również uwzględnić RODO i data residency. Agent nie może pobierać danych z wielu tenantów bez jasnej polityki minimalizacji danych. Z tego powodu warto sięgnąć po wzorce architektoniczne pokazane w analizie Agentforce Vibes, gdzie dane zawsze przechodzą przez warstwę kontrolowaną przez metadata. To zapewnia pełną inspekcję i eliminację shadow processingu.

Największy quick win dla polskich orgów to zastosowanie wzorca footprintu w obszarach takich jak: agregacje danych billingowych, statusy subskrypcji, cross-system entitlementy czy dane produktowe z PIM. Jeśli zespół dziś generuje jakiekolwiek pliki Excel na bazie danych z kilku systemów, agent z podobną architekturą może skrócić ten proces o dzień do kilku minut.

Co dalej: modele A2A i centralizacja kontekstu klientów

Customer Footprint to tylko pierwszy krok w kierunku agentów wieloźródłowych. Spodziewanym kolejnym etapem jest przejście do architektury A2A, gdzie jeden agent pobiera dane, a drugi je przygotowuje i optymalizuje do podjęcia decyzji pricingowej. Ten trend opisaliśmy szeroko w analizie Agent-to-Agent Architecture, w której centralizacja kontekstu staje się fundamentem całej platformy. W długim terminie footprint może stać się kontekstowym profilem konta, który będzie punktem wejścia dla każdego etapu sprzedaży – od discovery po renewal.

W Polsce ta zmiana ma potencjał nie tyle do przyspieszenia sprzedaży, ile do zredukowania chaosu integracyjnego. Wiele firm posiada dzisiaj kilka instancji Salesforce lub mieszankę Salesforce, HubSpot i ERP. Agentforce może być pierwszą warstwą, która realnie je łączy bez konieczności budowania gigantycznych Data Lake pod custom integracje. Jeśli architekci wdrożą model deterministycznego agregowania upstream, agent nie będzie tylko UI – stanie się częścią governance danych.

To kierunek, który widzimy w całym rynku enterprise: AI jest użyteczne tylko wtedy, gdy działa na spójnym modelu danych. Customer Footprint to praktyczny dowód, że ta teza działa nie tylko na slajdach, ale i w realnych procesach sprzedażowych.

ZAKOŃCZENIE

Customer Footprint nie jest kolejnym chatbotem, ale wzorcem architektonicznym, który rozwiązuje problem znany wszystkim dużym zespołom sprzedażowym: jak dostarczyć sprzedawcy spójny obraz klienta bez angażowania operacji. Polskie firmy, które dzisiaj nadal polegają na manualnym łączeniu danych z ERP, billingów i kilku orgów Salesforce, mogą potraktować to jako roadmapę transformacji. Pytanie dla architektów brzmi: która część waszego procesu sprzedaży może stać się kolejnym footprintem?