Logo TucarioThe Tucario Blog

Zespoły w Salesforce: Account Teams, Opportunity Teams i Case Teams [przewodnik]

Poznaj Account Teams, Opportunity Teams i Case Teams w Salesforce. Dowiedz się, kiedy stosować każdy typ zespołu, jak ustawić poziomy dostępu i Default Teams.

Michał Bajdek

Współzałożyciel, Tucario

7 min czytania

Udostępnij artykuł

Zespoły w Salesforce to grupy użytkowników współpracujących na konkretnych rekordach. Account Teams dbają o relacje z klientami, Opportunity Teams domykają transakcje, a Case Teams obsługują zgłoszenia serwisowe. Każdy typ zespołu nadaje dostęp na poziomie rekordu w oparciu o role zespołowe, ale działa wyłącznie na przypisanym mu obiekcie — odpowiednio Account, Opportunity i Case.

Account Teams, Opportunity Teams i Case Teams współpracujące wokół wspólnych rekordów

Czym są zespoły w Salesforce i jak działają?

Salesforce oferuje natywną funkcjonalność zespołów, dzięki której wielu użytkowników może pracować na tym samym rekordzie bez duplikowania danych. Platforma udostępnia trzy odrębne typy zespołów, każdy zaprojektowany pod inny kontekst biznesowy:

  • Account Teams : długofalowa współpraca na kontach klientów
  • Opportunity Teams : współpraca sprzedażowa skupiona na konkretnej transakcji
  • Case Teams : współpraca serwisowa przy zgłoszeniach klientów

Wszystkie trzy typy zespołów opierają się na wspólnej architekturze: liście wyboru Team Roles, która definiuje funkcję każdego członka, oraz konfigurowalnych poziomach dostępu, które określają, co członkowie zespołu widzą i mogą robić. Gdy dodajesz kogoś do zespołu, automatycznie otrzymuje on poziom dostępu przypisany do swojej roli.

Wspólna lista ról: Lista wyboru Team Role jest współdzielona między Account Teams, Opportunity Teams i Case Teams. Wybieraj nazwy ról, które sprawdzą się we wszystkich trzech kontekstach, albo dostosuj je per obiekt, jeśli Twoja organizacja ma odmienne potrzeby.

Z moich wdrożeń wynika, że nazwy ról zespołowych działają najlepiej, gdy opisują funkcję, a nie stanowisko. Role takie jak „Technical Lead“ czy „Executive Sponsor“ przenoszą się między Account, Opportunity i Case Teams bez nieporozumień. Organizacje, które używają nazw stanowisk („Senior Sales Engineer II“), kończą z dziesiątkami ról oznaczających w praktyce to samo. Utrzymuj krótką listę — pięć do ośmiu ról zwykle pokrywa większość scenariuszy.

W jaki sposób Account Teams umożliwiają współpracę?

Account Team to grupa użytkowników współpracujących na jednym koncie. W przeciwieństwie do standardowego modelu własności, w którym rekord należy do jednego użytkownika, Account Teams pozwalają wielu interesariuszom pracować razem przy zachowaniu jasnych granic dostępu.

Co dają Account Teams

Zgodnie z dokumentacją Salesforce Account Teams nadają dostęp na poziomie rekordu nie tylko do samego konta, ale opcjonalnie także do powiązanych:

  • szans sprzedaży (Opportunities)
  • kontaktów (Contacts)
  • zgłoszeń (Cases)

Każdy członek zespołu otrzymuje jeden z trzech poziomów dostępu, jak opisuje przewodnik SalesforceBen po dobrych praktykach Account Teams:

Poziom dostępu Account Opportunities Contacts Cases
Read Only Podgląd Podgląd Podgląd Podgląd
Read/Write Edycja Edycja Edycja Edycja
Private Brak Brak Brak Brak

Istotne ograniczenie: Account Team nie może być właścicielem konta. Członkowie zespołu wciąż potrzebują dostępu na poziomie obiektu poprzez profile lub permission sets. Zespół nadaje wyłącznie dostęp na poziomie rekordu.

Default Account Teams

Jak zauważa przewodnik SalesforceBen, użytkownik może zdefiniować swój Default Account Team w My Settings → Advanced User Details. Taki predefiniowany zespół automatycznie zasila konta, które użytkownik tworzy lub do których zostaje przypisany, eliminując powtarzalne ręczne wpisy.

Kiedy stosować Account Teams

Account Teams sprawdzają się, gdy:

  • wielu użytkowników potrzebuje stałego dostępu do konkretnych kont
  • chcesz raportować skład zespołów i pełnione w nich role
  • ręczne, jednostkowe udostępnianie rekordów jest akceptowalne
  • zbliżasz się do limitu reguł współdzielenia opartych na kryteriach (criteria-based sharing rules — 50 na obiekcie Account)

Wzorzec, który widuję najczęściej: regionalne i enterprise’owe zespoły sprzedaży, które potrzebują wglądu w swoje konta nawzajem, ale nie łączy ich wspólna linia raportowania. Hierarchia ról (role hierarchy) tego nie rozwiąże bez przebudowy struktury organizacyjnej. Account Teams pozwalają właścicielowi konta nadać dostęp bezpośrednio — bez angażowania administratora i bez nowych reguł współdzielenia. To szczególnie przydatne, gdy organizacja jest blisko limitów sharing rules i potrzebuje lżejszej alternatywy.

Kiedy warto sięgnąć po Opportunity Teams?

Opportunity Teams służą innemu celowi niż Account Teams. Jak wyjaśnia przewodnik SalesforceBen po Opportunity Teams, podczas gdy Account Teams wspierają długofalowe relacje z klientem, Opportunity Teams to tymczasowe grupy skupione na domknięciu konkretnych transakcji.

Obiekt OpportunityTeamMember

Zgodnie z dokumentacją Salesforce dotyczącą team sellingu każdy członek Opportunity Teamu jest reprezentowany rekordem OpportunityTeamMember, który łączy:

  • użytkownika
  • szansę sprzedaży
  • jego rolę w zespole
  • jego poziom dostępu

Taka struktura umożliwia raportowanie wzorców współpracy przy transakcjach i identyfikowanie ról, które najczęściej przyczyniają się do wygranych szans (closed-won).

Kluczowe różnice względem Account Teams

Aspekt Account Teams Opportunity Teams
Czas trwania Długofalowy Na czas transakcji
Cel Relacja z klientem Domknięcie transakcji
Zakres Konto + rekordy powiązane Pojedyncza szansa sprzedaży
Trwałość Do momentu usunięcia Zwykle kończy się z zamknięciem

Big Deal Alerts

Jak podkreśla artykuł SalesforceBen o Opportunity Teams, Salesforce oferuje wbudowane powiadomienia dla Opportunity Teams poprzez Big Deal Alerts (powiadomienia e-mail wyzwalane, gdy szansa sprzedaży osiągnie zdefiniowane progi kwoty i prawdopodobieństwa). Jeśli potrzebujesz elastyczniejszej automatyzacji, rozważ record-triggered flows z alertami e-mail kierowanymi do konkretnych ról w zespole.

Default Opportunity Teams

Analogicznie do Account Teams, użytkownicy mogą skonfigurować Default Opportunity Teams, które automatycznie przypisują współpracowników do nowych szans sprzedaży — to usprawnia formowanie zespołów przy powtarzalnych strukturach transakcji.

Większość organizacji, z którymi pracowałem, automatyzuje członkostwo w Opportunity Teams na podstawie etapu transakcji lub atrybutów szansy. Typowy wzorzec: gdy szansa osiąga określony etap, flow automatycznie dodaje do zespołu właściwego specjalistę (solution engineera, prawnika, lidera wdrożenia). Element, który najczęściej umyka: obsługa sytuacji, gdy pole lookup jest puste. Bez tego warunku flow kończy się cichym błędem i nikt nie zostaje dodany.

Jaką rolę pełnią Case Teams w obsłudze klienta?

Zgodnie z dokumentacją Salesforce dotyczącą Case Teams Case Teams umożliwiają współpracę przy zgłoszeniach serwisowych, działając według tego samego wzorca co Account i Opportunity Teams, ale w kontekście wsparcia klienta.

Współpraca zorientowana na serwis

Case Teams są szczególnie przydatne, gdy:

  • wielu agentów wsparcia potrzebuje wglądu w to samo zgłoszenie
  • eskalacje wymagają zaangażowania specjalistów
  • złożone zgłoszenia obsługują zespoły międzydziałowe
  • wymogi compliance nakazują udokumentowaną współpracę

Członkowie Case Teamu otrzymują dostęp na podstawie przypisanej roli, z konfigurowalnymi uprawnieniami do odczytu lub odczytu i zapisu na rekordzie zgłoszenia.

Integracja z Service Cloud

Case Teams integrują się z procesami Service Cloud — reguły przypisań (assignment rules) i procesy eskalacji mogą automatycznie zasilać skład zespołu na podstawie atrybutów zgłoszenia, takich jak priorytet, produkt czy segment klienta.

Wskazówka dotycząca automatyzacji: Używaj record-triggered flows, aby automatycznie dodawać członków Case Teamu po spełnieniu określonych kryteriów — na przykład specjalistę technicznego, gdy typ zgłoszenia wskazuje na złożony problem produktowy.

Jakie ograniczenia mają standardowe zespoły w Salesforce?

Standardowe zespoły Salesforce dobrze sprawdzają się w podstawowych scenariuszach współpracy, ale mają ograniczenia architektoniczne, które ujawniają się w złożonych organizacjach.

Przypisanie do konkretnych obiektów

Najistotniejsze ograniczenie: każdy typ zespołu działa wyłącznie na swoim obiekcie.

Typ zespołu Obsługiwany obiekt Obiekty niestandardowe
Account Team Tylko Account Brak wsparcia
Opportunity Team Tylko Opportunity Brak wsparcia
Case Team Tylko Case Brak wsparcia

Jeśli Twoja organizacja potrzebuje zespołowej współpracy na obiektach niestandardowych (custom objects) — takich jak Projekty, Zlecenia czy niestandardowe obiekty relacyjne — standardowe zespoły w niczym nie pomogą.

Zależność od administratora

Konfiguracja standardowych zespołów wymaga udziału administratora:

  • włączenia funkcjonalności zespołów w Setup
  • skonfigurowania wartości listy wyboru Team Role
  • dodania powiązanych list (related lists) do układów stron
  • ustawienia reguł współdzielenia dla dostępu zespołowego

Użytkownicy biznesowi nie mogą tworzyć ani modyfikować struktur zespołów bez wsparcia administratora.

Brak kaskadowania na obiekty niestandardowe

Natywne współdzielenie zespołowe kończy się na obiektach standardowych i nie sięga obiektów niestandardowych

Account Teams mogą opcjonalnie nadawać dostęp do szans sprzedaży, kontaktów i zgłoszeń, ale nie do obiektów niestandardowych powiązanych z kontem. Jeśli masz niestandardowe obiekty podrzędne, które wymagają dostępu zespołowego, musisz wdrożyć osobne reguły współdzielenia lub udostępnianie ręczne.

Złożoność reguł współdzielenia w dużej skali

Duże organizacje często wpadają na limity sharing rules albo doświadczają problemów z wydajnością zapytań, gdy zespoły i reguły współdzielenia zaczynają się mnożyć. Każdy obiekt Account ma limit 50 reguł współdzielenia opartych na kryteriach, który w złożonych strukturach organizacyjnych zespoły potrafią szybko wyczerpać.

W większych organizacjach widziałem, jak wydajność list views i raportów spada, gdy reguł współdzielenia przybywa. Schemat jest zwykle ten sam: każdy dział dokłada reguły pod swoje potrzeby, nikt nie analizuje skumulowanego wpływu i w końcu zapytania zwalniają. Organizacje, które unikają tego problemu, robią kwartalny audyt sharing rules i konsolidują reguły o pokrywających się kryteriach. To nie jest efektowna praca, ale oszczędza późniejszych rozmów w stylu „dlaczego ten Salesforce tak wolno działa“.

Najważniejsze wnioski

  • Account Teams do relacji, Opportunity Teams do transakcji, Case Teams do serwisu : każdy standardowy typ zespołu obsługuje inny kontekst biznesowy
  • Standardowe zespoły nadają dostęp do rekordów na podstawie ról, ale działają wyłącznie na obiektach Account, Opportunity i Case
  • Default Teams ograniczają powtarzalną konfigurację, automatycznie zasilając skład zespołu, gdy użytkownik tworzy rekordy lub zostaje do nich przypisany
  • Standardowe zespoły wymagają udziału administratora przy pierwszej konfiguracji, choć bieżącymi zmianami składu mogą zarządzać sami użytkownicy
  • Obiekty niestandardowe wymagają innego podejścia : standardowe zespoły działają tylko na przypisanych im obiektach (Account, Opportunity, Case)

Źródła

Powiązane artykuły

Michał Bajdek

Współzałożyciel, Tucario

Współzałożyciel Tucario — firmy konsultingowo-produktowej Salesforce. Pracuje przy enterprise’owych wdrożeniach Salesforce — architektura, integracje i produkty AppExchange — i pisze o tym, co sprawdza się w środowiskach produkcyjnych.

Odkryj powiązane treści według tematu