Integracja z Salesforce w konfiguracji, którą już macie
Salesforce w firmie, która ma go od kilku lat, to nie czysty CRM, tylko warstwy ustawień po kilku osobach: obiekty własne, pola wymagane, reguły walidacji, profile i zestawy uprawnień. Spinamy go z systemem fakturowym, zamówieniami i hurtownią tak, żeby integracja weszła w tę konfigurację, a nie obok niej. Zmiany testujemy na sandboxie, na produkcję idzie paczka, którą Wasz admin przejrzy przed wdrożeniem.
- 2 do 6 tygodniod warsztatu do spiętego Salesforce'a, zależnie od tego, ile obiektów własnych i reguł uprawnień wchodzi w zakres
- 14 dniod warsztatu do pierwszej automatyzacji działającej na sandboxie, na kopii Waszych danych
- 5 do 10 sekundtyle zajmuje BOND-owi odpowiedź na pytanie o dane z Salesforce'a, bez budowania raportu
Problem
Dlaczego Salesforce robi mniej, niż za niego płacicie?
Salesforce wdrożył u Was partner cztery lata temu. Administrator, który to potem prowadził, zmienił pracę, a jego ustawienia zostały. Handlowiec wypełnia dwanaście pól wymaganych na szansie sprzedaży i połowy z nich nikt już nie czyta. Kontroler prowadzi własny arkusz, bo raport z Salesforce'a pokazuje inną liczbę i nikt nie umie powiedzieć, skąd ta różnica się bierze.
Powód nie jest zaskakujący: konfiguracja rosła warstwami i nikt jej nie zamykał. Obiekt własny założony pod jeden projekt, reguła walidacji dopisana pod jeden wyjątek, dwie automatyzacje robiące to samo z dwóch stron. Kiedy dochodzi do tego integracja z systemem fakturowym, przewraca się na pierwszym polu wymaganym, o którym nikt jej nie powiedział, i wtedy zaczyna się szukanie winnego zamiast szukania reguły.
Trzecia rzecz jest techniczna i decyduje o harmonogramie. Salesforce rozlicza zapytania API w oknie 24 godzin dla całej organizacji, a wysokość limitu zależy od edycji i liczby licencji, co opisuje dokumentacja Salesforce dla programistów. Integracja, która odpytuje rekord po rekordzie, potrafi zużyć ten limit przed końcem dnia i zatrzymuje wtedy każdą inną integrację w tej samej organizacji. Dlatego wolumen idzie przez Bulk API, a zmiany odbieramy jako zdarzenia, nie przez odpytywanie co kwadrans.
- Handlowiec wypełnia pola wymagane, których nikt nie czyta, i robi to najszybszą możliwą wartością
- Kontroler prowadzi arkusz obok Salesforce'a, bo raportowi nie ufa
- Ta sama firma siedzi w Salesforce jako trzy konta po fuzji i migracji
- Nikt nie wie, która automatyzacja zmieniła etap szansy sprzedaży
- Zmiana w konfiguracji idzie prosto na produkcję, bo sandbox ma dane z zeszłego roku
Dlaczego teraz
Co się zmieniło, że da się to zrobić bez przebudowy Salesforce'a?
Salesforce ma osobne środowiska testowe i to zmienia sposób pracy z gotową konfiguracją. Zmianę projektujemy na sandboxie, a na produkcję idzie paczka zmian metadanych, którą Wasz administrator albo partner może przejrzeć przed wdrożeniem. Dokumentacja podaje okna odświeżania sandboxów: Full raz na 29 dni, Partial Copy raz na 5 dni. Dlatego termin testu na świeżych danych ustalamy na starcie projektu, a nie w tygodniu przełączenia.
Druga zmiana dotyczy tego, gdzie mieszka logika. Flow w Salesforce jest najlepszym miejscem na reguły dotyczące samego Salesforce'a: zadanie po zmianie etapu, przypisanie właściciela konta, walidacja pola. Gdy reguła musi zapytać system fakturowy o status płatności albo dopisać wiersz do hurtowni, logika idzie do n8n albo Make, a Salesforce zostaje miejscem zapisu wyniku. Warstwę techniczną, czyli uwierzytelnianie, limity i obsługę błędów, opisujemy osobno na stronie o integracji przez API.
Trzecia zmiana to agent AI. Raport w Salesforce odpowie na pytanie, które ktoś przewidział w dniu jego budowy. BOND, nasz firmowy agent AI, czyta z Salesforce'a zapytaniem SOQL i odpowiada zwykłym zdaniem w 5 do 10 sekund, na przykład na „które konta z segmentu enterprise nie miały aktywności od 60 dni”. Pytanie zadaje osoba, która raportu zbudować nie umie, i to jest tu cała różnica.
Co się zmienia
Co dostajecie ze spiętego Salesforce'a?
Integracja wchodzi w Waszą konfigurację, nie obok niej
Zanim cokolwiek napiszemy, czytamy przez API obiekty własne, pola wymagane, reguły walidacji i automatyzacje, które już działają. Integracja zna te reguły od pierwszego zapisu, więc nie wywala się na polu, o którym nikt jej nie powiedział.
Spis obiektów, pól wymaganych i reguł blokujących zapis, zrobiony przed pierwszą linią kodu
Zmiana idzie przez sandbox, nie przez produkcję
Nowe pola, zmienione reguły i scenariusze uruchamiamy najpierw na sandboxie z kopią Waszych danych. Na produkcję trafia paczka zmian metadanych, którą da się przejrzeć i wycofać.
Test na sandboxie odświeżonym w oknie, które dopuszcza dokumentacja: Full 29 dni, Partial Copy 5 dni
Limit zapytań przestaje być ryzykiem
Wolumen idzie przez Bulk API, a zmiany w rekordach odbieramy jako zdarzenia, nie przez odpytywanie co kwadrans. Zużycie limitu mierzymy przed przełączeniem i po nim, więc widać, ile miejsca zostało innym integracjom.
Zużycie okna 24 godzin policzone przed wdrożeniem i po nim, nie oszacowane
Uprawnienia opisane pole po polu
Integracja pracuje jako osobny użytkownik z zestawem uprawnień zawężonym do pól, które są w zakresie. Nikt nie dostaje dostępu do całej organizacji, bo tak było szybciej przy uruchamianiu.
Osobny użytkownik integracyjny, uprawnienia do odczytu i do zapisu ustalone rozdzielnie
Wasz administrator albo partner wie, co robimy
Zakres zmian w metadanych przekazujemy na piśmie przed wdrożeniem i ustalamy, kto jest właścicielem której warstwy. Nasza praca nie wchodzi w konflikt z pracą partnera, który utrzymuje Wasz Salesforce.
Podział na piśmie: kto zmienia metadane, kto utrzymuje scenariusze poza Salesforce'em
Pytanie o dane z Salesforce'a bez budowania raportu
Zarząd, magazyn i księgowość pytają zwykłym zdaniem i dostają odpowiedź z aktualnych danych. Nikt nie uczy się układania raportów po to, żeby raz w tygodniu sprawdzić jedną liczbę.
Odpowiedź z zapytania SOQL w 5 do 10 sekund, bez pracy administratora
Dowód
Czy sami spinacie CRM z agentem AI?
Tak, i uczciwie: CRM-em w agencji naszych założycieli jest HubSpot, nie Salesforce. Mechanizm jest ten sam, czyli odczyt i zapis przez API pod kontrolą uprawnień, a poniżej jest skala tej pracy razem z tym, czego ta liczba NIE dowodzi.
Wdrożone u nas. To nie są wdrożenia u klienta zewnętrznego, tylko w spółkach założycieli JustAutomate. Piszemy to wprost, bo dowód, którego nie da się sprawdzić, nie jest dowodem.
JustBotich agentJustIdea Agency, agencja performance marketingu, około 30 osób
- 23
- osób z firmy pracuje z agentem
- 38
- systemów wpiętych na stałe
- 112
- procesów chodzi bez człowieka
- 475
- tysięcy linii kodu agenta
Agent spięty z CRM, formularzami na stronie, Slackiem i hurtownią danych. Rekordy powstają ze zgłoszeń z formularzy, z reklam i z poleceń, a agent pisze do CRM jako osobny użytkownik z zawężonym zakresem uprawnień.
8 z 38 systemów, w których pracuje
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Przedtem
- Kontakt i firmę zakładał w CRM człowiek: czytał zgłoszenie, przepisywał dane z maila i sam sprawdzał, czy firmy już tam nie ma. Kompletność danych zależała od tego, kto akurat miał czas.
- Po zmianie
- Agent zakłada kontakt i firmę, sprawdza duplikat po domenie, uzupełnia dane firmowe i powiadamia zespół na Slacku. Człowiek wchodzi dopiero przy rozmowie z klientem.
3 432 operacje na leadach i 1 301 na zgłoszeniach z formularzy w 30 dni, bez udziału człowieka
A u Ciebie
Co, jeśli nasz Salesforce jest zbyt zagracony?
Cztery zdania, które słyszymy najczęściej przy Salesforce, i to, co na nie odpowiadamy.
Jeśli szukasz czegoś obok, są osobne strony: wdrożenie i integracja CRM, gdy CRM-u jeszcze nie ma albo trwa wybór, integracja z HubSpot, gdy porównujecie systemy, oraz agent AI spięty z CRM, gdy problemem jest dostęp do danych, a nie ich przepływ. Dane osobowe kontaktów przetwarzamy według rozporządzenia 2016/679, więc okres przechowywania rekordów, które nigdy nie weszły w proces sprzedaży, ustalamy razem z Wami.
Nasz Salesforce konfigurował ktoś, kto już u nas nie pracuje.
To najczęstszy punkt startowy i dlatego audyt konfiguracji jest u nas osobnym krokiem, nie wstępem do wdrożenia. Czytamy przez API obiekty, pola, reguły walidacji i automatyzacje, a potem podajemy liczby: ile pól jest realnie wypełnianych, ile stoi puste od roku, które reguły blokują zapis z zewnątrz. Dostajecie ten raport przed jakąkolwiek zmianą i możecie go użyć bez nas.
Nie damy dostępu do produkcji firmie z zewnątrz.
I nie musicie. Pracujemy na sandboxie, a na produkcji zaczynamy od odczytu przez osobnego użytkownika integracyjnego z zawężonym zestawem uprawnień. Paczkę zmian metadanych może wdrożyć Wasz administrator albo partner, my przekazujemy ją do przejrzenia razem z listą tego, co się zmienia. Zapis na produkcji włączamy po pilocie, na wąskiej liście operacji.
Mamy partnera Salesforce, który to utrzymuje.
Dobrze i zwykle zostaje. Dzielimy zakres na piśmie: partner jest właścicielem metadanych i konfiguracji w Salesforce, my odpowiadamy za warstwę poza nim, czyli scenariusze w n8n albo Make, hurtownię i agenta AI. Przy każdym polu, które trzeba założyć, mówimy o tym wcześniej, żeby nie okazało się, że dwie firmy zmieniają tę samą regułę w dwóch kierunkach.
Zaczynamy myśleć, że Salesforce jest dla nas za duży.
Wtedy powiemy to wprost, zamiast sprzedawać integrację. Salesforce ma sens, gdy proces sprzedaży ma wiele etapów i wyjątków, gdy potrzebujecie kontroli dostępu na poziomie pola i historii zmian do audytu, i gdy jest kto ma tym administrować. Przy pięciu handlowcach, jednym procesie i bez wymagań audytowych taniej wychodzi prostszy CRM, a różnicę w rachunku widać w pierwszym roku.
- Salesforce
- Obiekty standardowe i własne, pola wymagane, reguły walidacji, Flow, profile i zestawy uprawnień, sandbox
- Faktury i księgowość
- Fakturownia, iFirma, Comarch Optima, Subiekt, sevDesk
- Sprzedaż i zamówienia
- BaseLinker, Allegro, Shopify, WooCommerce, PrestaShop
- Praca zespołu
- Google Workspace, Microsoft 365, Slack, Notion, ClickUp, Jira, Asana
- Dane i hurtownia
- BigQuery, Google Sheets, GA4, bazy SQL
- Warstwa automatyzacji
- Make, n8n, Zapier, własne integracje przez API
Co zastajemy w konfiguracji Salesforce i co z tym robimy
Siedem rzeczy, które przy istniejącej organizacji Salesforce blokują integrację najczęściej. Druga kolumna jest tu ważniejsza od trzeciej, bo większość opóźnień bierze się z tego, że nikt nie sprawdził tych warunków przed startem.
| Co zastajemy w konfiguracji | Dlaczego blokuje integrację | Co z tym robimy |
|---|---|---|
| Pole wymagane na obiekcie własnym | zapis z zewnątrz odpada, bo integracja nie zna tego pola | wartość domyślna albo zdjęcie pola z listy wymaganych, sprawdzone na sandboxie |
| Reguła walidacji z warunkiem na profilu | przechodzi handlowcowi, wywala użytkownika integracyjnego | warunek rozszerzony o użytkownika integracyjnego, wdrożony paczką metadanych |
| Bezpieczeństwo na poziomie pola | integracja czyta rekord, ale nie widzi połowy pól | zestaw uprawnień zawężony do pól z zakresu, spisany pole po polu |
| Duplikaty kont po migracji albo fuzji | ta sama firma jako trzy konta, raport się nie sumuje | dopasowanie po NIP, domenie i rozmytej nazwie, scalanie po zatwierdzeniu reguł |
| Odpytywanie rekord po rekordzie | limit zapytań w oknie 24 godzin kończy się przed końcem dnia | Bulk API do wolumenu, zdarzenia zmian zamiast odpytywania co kwadrans |
| Kilka automatyzacji na tym samym obiekcie | nie wiadomo, która zmieniła etap szansy sprzedaży | inwentaryzacja automatyzacji i jedna warstwa reguł na obiekt |
| Sandbox z danymi z zeszłego roku | test przechodzi, produkcja się wywala na realnym rekordzie | odświeżenie Partial Copy albo Full w oknie, które dopuszcza dokumentacja |
Wiersze to punkt wyjścia. U większości firm audyt wyłapuje trzy albo cztery z nich, a kolejność naprawy ustalamy na warsztacie razem z osobą, która administruje Waszym Salesforce.
Jak to robimy
Pięć kroków od zagraconej organizacji do spiętego Salesforce'a
Każdy krok kończy się czymś, co możesz ocenić, zanim zdecydujesz o następnym.
Warsztat
Rozkładamy proces sprzedaży na etapy i pytamy przy każdym: gdzie ta informacja powstaje, kto ją dziś przepisuje i kto z niej korzysta. Ustalamy też, kto po Waszej stronie ma prawo zmieniać konfigurację Salesforce'a, bo od tego zależy harmonogram.
Audyt konfiguracji
Czytamy przez API obiekty własne, pola, reguły walidacji, automatyzacje, profile i zestawy uprawnień. Liczymy fakty: co jest wypełniane, co stoi puste, ile jest duplikatów kont, ile zapytań zużywają dzisiejsze integracje w oknie 24 godzin. Raport dostajecie przed jakąkolwiek zmianą.
Zakres uprawnień i podział logiki
Zakładamy użytkownika integracyjnego i zawężamy jego uprawnienia do pól z zakresu, rozdzielnie dla odczytu i dla zapisu. Dzielimy reguły: co zostaje we Flow Salesforce'a, co idzie do n8n albo Make. Listę zmian w metadanych przekazujemy Waszemu administratorowi albo partnerowi do przejrzenia.
Pilot na sandboxie
Integrację uruchamiamy na sandboxie z kopią Waszych danych i puszczamy przez nią prawdziwe przypadki z ostatnich tygodni, w tym te brzydkie: konto bez NIP, duplikat po fuzji, szansę sprzedaży z pustym polem wymaganym. Mierzymy zużycie limitu zapytań, zanim cokolwiek dotknie produkcji.
Produkcja i pomiar po 30 i 90 dniach
Przełączamy z monitoringiem błędów i szkolimy osobę, która ma to utrzymywać. Po 30 dniach patrzymy na kompletność pól i liczbę zdarzeń, które nie przeszły. Po 90 na to, czy kontroler nadal prowadzi swój arkusz obok Salesforce'a.
Przed i po
Jak zmienia się dzień osoby, która pracuje w Salesforce
Przedtem
- Wypełnia dwanaście pól wymaganych, żeby zapisać szansę sprzedaży
- Otwiera system fakturowy, żeby sprawdzić, czy klient zapłacił
- Prosi administratora o raport, bo istniejący nie pokazuje tego, o co pyta zarząd
- Zmianę w konfiguracji robi od razu na produkcji, bo sandbox ma stare dane
Po zmianie
- Pola, które nikomu nie służą, wypadły z listy wymaganych po audycie
- Status płatności i numer faktury widzi jako pole na szansie sprzedaży
- Pytanie do agenta AI zwykłym zdaniem, odpowiedź z Salesforce'a w 5 do 10 sekund
- Zmiana idzie paczką metadanych: najpierw sandbox, potem produkcja
Pierwsza automatyzacja działa na sandboxie 14 dni od warsztatu. Kompletność pól i liczbę nieudanych zdarzeń oceniamy po 30 dniach, a to, czy ktoś jeszcze prowadzi arkusz obok, po 90.
Dla osoby, która to zamawia
Co z tego ma osoba, która płaci za licencje Salesforce
Licencje Salesforce i czas administratora to koszt stały, a wykorzystanie tej platformy było do tej pory kwestią wiary w to, co mówi zespół. Po audycie wiesz, ile pól jest realnie wypełnianych, ile automatyzacji robi to samo z dwóch stron i ile zapytań zużywają dzisiejsze integracje. Rozmowa o odnowieniu przestaje być rozmową o wrażeniach.
Druga rzecz zdejmuje z Ciebie ryzyko decyzji. Nic nie idzie na produkcję bez testu na sandboxie i bez listy zmian, którą Twój administrator albo partner przejrzał wcześniej. Zaczynamy od warsztatu procesowego, więc pierwszą decyzję podejmujesz na dokumencie, nie na obietnicy, a jeśli audyt pokaże, że Salesforce jest dla Was za duży, powiemy to.
- Wykorzystanie licencji widoczne jako liczba, nie jako opinia zespołu
- Nic na produkcji bez pilota na sandboxie i bez listy zmian do przejrzenia
- Osobny użytkownik integracyjny z uprawnieniami zawężonymi do pól z zakresu
- Podział odpowiedzialności z Waszym partnerem Salesforce ustalony na piśmie
Ile to kosztuje
Warsztat ma cenę jawną, spięcie wycenę po nim
Warsztat procesowy kosztuje 2500 zł netto za tydzień. Przy jednej organizacji Salesforce zwykle wystarcza jeden tydzień, bo zakres jest wąski: co wchodzi do Salesforce'a, skąd i pod jakimi regułami się w nim zapisuje. Spięcie wyceniamy po warsztacie, gdy audyt pokaże, ile obiektów własnych i reguł uprawnień wchodzi w grę.
Licencje Salesforce płacisz bezpośrednio Salesforce'owi, tak samo koszt działania scenariuszy w Make albo n8n, albo nie płacisz go wcale, gdy scenariusz stoi na Waszej infrastrukturze. Bez naszej prowizji. Jeśli Wasz partner Salesforce ma wykonać część zmian w metadanych, jego czas rozliczacie z nim, a my podajemy zakres na piśmie.
Warsztat procesowy
2500 zł netto
za tydzień, przy jednej organizacji Salesforce zwykle jeden tydzień
Zamknięta całość. Kończy się audytem konfiguracji i listą spięć w kolejności, którą możesz zrealizować bez nas.
- Audyt organizacji Salesforce: obiekty własne, pola wymagane, reguły walidacji, automatyzacje
- Przegląd profili i zestawów uprawnień pod użytkownika integracyjnego
- Pomiar zużycia limitu zapytań w oknie 24 godzin przez dzisiejsze integracje
- Raport duplikatów kont i propozycja reguł scalania
- Podział logiki: co zostaje we Flow, co idzie poza Salesforce'a
- Najczęściej wybierany
Warsztat i spięcie Salesforce'a
Wycena po warsztacie
zakres wynika z liczby systemów i stanu konfiguracji
Najczęściej wybierany wariant. Spięty Salesforce w 2 do 6 tygodni od warsztatu, sprawdzony na sandboxie przed produkcją.
- Wszystko z warsztatu
- Integracje przez API: faktury, zamówienia, hurtownia, praca zespołu
- Bulk API do wolumenu i zdarzenia zmian zamiast odpytywania
- Pilot na sandboxie z kopią danych, przełączenie z monitoringiem błędów
- Paczka zmian metadanych przekazana Waszemu adminowi do przejrzenia
- Szkolenie osoby, która ma to utrzymywać bez nas
Salesforce i agent AI
Wycena po warsztacie
dla firm, w których o dane z CRM pyta cały zespół, nie tylko sprzedaż
Wszystko ze spięcia plus BOND, który odpowiada na pytania o konta i szanse sprzedaży zwykłym zdaniem.
- Wszystko ze spięcia Salesforce'a
- Agent AI czytający z Salesforce'a zapytaniem SOQL: konta, szanse, aktywności
- Zakres uprawnień ustalony rozdzielnie dla odczytu i dla zapisu
- Dostęp dla osób poza sprzedażą, odpowiedź w 5 do 10 sekund
Warsztat kończy się dokumentem, który obroni się bez nas: audytem konfiguracji, mapą miejsc zapisu i listą spięć w kolejności. Jeśli audyt pokaże, że wystarczą Flow, które już macie, mówimy to i sprawa kończy się na warsztacie. Jeśli okaże się, że przy Waszej skali Salesforce jest przerostem, powiemy i to, choć wtedy nie mamy Wam co sprzedać.
Najczęstsze pytania
Czym różni się integracja z Salesforce od integracji z prostszym CRM?
Punktem startowym. W prostszym CRM zwykle projektujesz przepływ od zera, a w Salesforce wchodzisz w konfigurację, którą ktoś zbudował lata temu: obiekty własne, pola wymagane, reguły walidacji, profile i zestawy uprawnień. Dlatego audyt tej konfiguracji jest u nas osobnym krokiem, a nie wstępem, i dlatego pierwsza wersja integracji uruchamia się na sandboxie.
Czy musimy dać Wam dostęp do produkcyjnej organizacji Salesforce?
Nie na starcie. Pracujemy na sandboxie, a na produkcji zaczynamy od odczytu przez osobnego użytkownika integracyjnego z uprawnieniami zawężonymi do pól z zakresu. Zapis włączamy po pilocie, na wąskiej liście operacji. Paczkę zmian metadanych może wdrożyć Wasz administrator albo partner, my przekazujemy ją razem z listą tego, co się zmienia.
Co się dzieje, gdy pole wymagane blokuje zapis z zewnątrz?
Sprawdzamy najpierw, czemu to pole służy i kto z niego korzysta, bo część pól wymaganych została po projektach, których już nie ma. Jeśli pole jest potrzebne, integracja dostaje dla niego wartość ustaloną na warsztacie. Jeśli nie jest, proponujemy zdjęcie go z listy wymaganych i sprawdzamy tę zmianę na sandboxie, zanim pójdzie na produkcję.
Jak pilnujecie limitu zapytań API w Salesforce?
Salesforce rozlicza zapytania w oknie 24 godzin dla całej organizacji, więc integracja, która odpytuje rekord po rekordzie, potrafi zablokować wszystkie pozostałe. Wolumen puszczamy przez Bulk API, zmiany odbieramy jako zdarzenia, a zużycie limitu mierzymy na audycie i po przełączeniu. Wtedy widać, ile miejsca zostało innym integracjom w tej organizacji.
Kiedy reguła zostaje we Flow, a kiedy idzie do n8n albo Make?
Reguła kciuka: jeśli dotyczy wyłącznie Salesforce'a, zostaje we Flow, bo tam Wasz administrator zmieni ją bez nas. Zadanie po zmianie etapu, przypisanie właściciela konta, walidacja pola to Flow. Jeśli reguła musi zapytać system fakturowy albo dopisać wiersz do hurtowni, idzie do orkiestratora, gdzie widać, na którym kroku się wywaliła i da się ją powtórzyć.
Ile trwa spięcie Salesforce'a z innymi systemami?
Tydzień warsztatu i 2 do 6 tygodni pracy, zależnie od liczby systemów i stanu konfiguracji. Pierwsza automatyzacja działa na sandboxie zwykle 14 dni od warsztatu, żeby zespół zobaczył efekt przed końcem projektu. Najdłuższym punktem bywa nie integracja, a uzgodnienie zmian w metadanych z osobą, która odpowiada za konfigurację.
Kiedy firma nie potrzebuje Salesforce?
Gdy proces sprzedaży ma kilka etapów bez wyjątków, gdy nie ma wymagań co do kontroli dostępu na poziomie pola ani historii zmian do audytu, i gdy nie ma kto tym administrować. Przy pięciu handlowcach i jednym procesie prostszy CRM wychodzi taniej w licencjach i w utrzymaniu, a różnicę widać już w pierwszym roku. Mówimy to na konsultacji, zanim wystawimy wycenę.
Czy agent AI może zapisywać dane w Salesforce?
Może, ale zakres uprawnień ustalamy rozdzielnie dla odczytu i dla zapisu i zwykle zaczynamy od samego odczytu. Zapis włączamy po pilocie, na wąskiej liście operacji: notatka, zadanie, zmiana jednego pola. Każda operacja agenta jest w logu, więc da się sprawdzić, kto i co zmienił, i zmianę wycofać.
Sprawdźmy, co dziś blokuje Wasz Salesforce
Bezpłatna konsultacja trwa 30 minut. Opowiadasz, od kiedy macie Salesforce, kto go dziś administruje i co przepisujecie do niego z innych systemów: faktury, zamówienia, arkusze. Pokazujemy, które spięcie zdejmie najwięcej ręcznej pracy i co trzeba uporządkować w konfiguracji przed nim. Nie musisz na tym etapie udostępniać organizacji.
Prowadzimy najwyżej dwa wdrożenia równocześnie, żeby przy każdym ktoś realnie siedział.
Umów bezpłatną konsultacjęPS. Jeśli w tym tygodniu ktoś u Was wypełnił pole wymagane byle czym, żeby móc zapisać szansę sprzedaży, to jest dokładnie ten problem. Spięty Salesforce pobiera te dane z systemu, w którym one już są, a pola, które nikomu nie służą, wypadają z listy wymaganych po audycie. Zaczynamy od warsztatu, bo integracja dopisana do nieuporządkowanej konfiguracji tylko szybciej rozsyła bałagan.