Odpowiedzialny to centralne pole każdej encji Bitrix24 (Alaio): po nim liczą się raporty i KPI, na nim opierają się uprawnienia „swoje/cudze", do niego trafiają powiadomienia i zadania. Dlatego pytanie „jak zmienić odpowiedzialnego" pojawia się codziennie: nowy lead trzeba oddać wolnemu menedżerowi, deale odchodzącego pracownika — przekazać następcy, zawisłe zatwierdzenie — podnieść do przełożonego. Omówimy wszystkie poziomy: zmianę ręczną, masową i automatyczną — oraz trzy roboty, które zamykają scenariusze niedostępne dla wbudowanych narzędzi. Na koniec pytanie odwrotne: jak zablokować zmianę odpowiedzialnego, skoro Bitrix24 nie ma na to osobnego uprawnienia.

Odpowiedzialny czy wykonawca: kto jest kim

W CRM lead, deal, kontakt i firma mają jednego odpowiedzialnego — to pole „Odpowiedzialny" w karcie. W zadaniach ról jest więcej: twórca, wykonawca, współwykonawcy i obserwatorzy. „Odpowiedzialnym" w zadaniach nazywa się właśnie wykonawcę — tego, kto robi pracę i na kim palą się liczniki; twórca tylko odbiera wynik. Jeśli proces ma „zmienić odpowiedzialnego za zadanie", zmienia się wykonawca. Więcej o rolach i polach zadań — w artykule o robotach w zadaniach.

Jak zmienić odpowiedzialnego ręcznie

W karcie: pole „Odpowiedzialny" → wybrać pracownika. Na liście: zaznaczyć potrzebne rekordy → akcja grupowa „Zmień odpowiedzialnego" — tak przekazuje się dziesiątki rekordów naraz; filtr „Odpowiedzialny = Kowalski" plus „zaznacz wszystko" obejmie i setki. Dwa haczyki. Pierwszy — uprawnienia: odpowiedzialnego zmieni każdy, czyja rola CRM ma prawo „Edycja" do tego rekordu; osobnego prawa do zmiany odpowiedzialnego nie ma — jak mimo to ją zablokować, opisujemy niżej. Drugi — przy przekazaniu rekordu poprzedni właściciel może stracić go z oczu: uprawnienia „czytać tylko swoje" odetną dostęp w momencie zmiany, dlatego przekazanie bazy klientów planuje się razem z konfiguracją ról.

Zmiana automatyczna: wbudowany robot i warunki

W projektancie robotów jest wbudowana akcja „Zmień odpowiedzialnego" — ustawia konkretnego pracownika albo wartość z pola. W połączeniu z warunkami „jeśli — to" powstaje routing: kwota deala powyżej progu — odpowiedzialnym zostaje starszy menedżer; źródło „program partnerski" — rekordy idą do menedżera ds. partnerów. Słaby punkt wbudowanej akcji: zna tylko to, co sztywno wpisano w ustawieniach — konkretną osobę albo pole. Kto jest „wolny", kto „z właściwego działu", kto jest „przełożonym bieżącego odpowiedzialnego" — tego projektant sam nie umie i tu zaczynają się roboty Roboteki.

Rozdzielanie leadów i deali między menedżerów

Klasyka: przychodzące leady powinny rozkładać się po dziale sprzedaży równomiernie, a nie spadać na jednego dyżurnego. Robot „Losowy pracownik z listy lub działu" wybiera losowego aktywnego pracownika wskazanego działu — albo z jawnej listy ID — i umie wykluczyć jedną osobę, na przykład bieżącego odpowiedzialnego. Zwraca ID, imię i nazwisko, e-mail oraz znacznik „znaleziony" (Y/N); następnym krokiem wbudowana akcja zapisuje ID w polu „Odpowiedzialny". Losowy wybór na dystansie daje równomierne obciążenie bez tabel do śledzenia kolejki. Jeśli rozdzielanie ma zależeć od działu autora albo od terytorium — najpierw robot „Pobierz dział pracownika" ustala dział, potem warunek rozgałęzia trasę. Pełny potok obsługi przychodzących zgłoszeń — w artykule o leadach.

Odejście menedżera: przekazać wszystko powiązane

Najboleśniejszy scenariusz. Akcja grupowa na liście przekaże deale — ale nie ruszy powiązanych rekordów: firmie zostaną kontakty ze starym odpowiedzialnym, kontaktom — ich deale. Robot „Zmień odpowiedzialnego w powiązanych" rozwiązuje właśnie to: uruchomiony na firmie, przepisuje wszystkie jej deale albo wszystkie kontakty; na kontakcie — jego deale lub firmy; na dealu — jego kontakty lub firmę. Za jednym uruchomieniem przetwarza się do 500 powiązanych rekordów, robot zwraca liczbę zaktualizowanych i znacznik powodzenia. Proces przekazania bazy składa się w parę kroków: zmienić odpowiedzialnego firmy wbudowaną akcją → robotem przeciągnąć nowego odpowiedzialnego na wszystkie deale i kontakty tej firmy. Ten sam chwyt działa przy przekazaniu kluczowego klienta nowemu opiekunowi klienta — bez żadnych odejść.

Eskalacja: nie zmieniać, lecz włączyć przełożonego

Czasem zmiana odpowiedzialnego to błąd: za przeterminowane zadanie ma odpowiadać ten sam menedżer, ale o poślizgu musi się dowiedzieć jego przełożony. Robot „Pobierz przełożonego pracownika" zwraca bezpośredniego przełożonego według struktury działów — procesowi zostaje postawić mu zadanie albo wysłać powiadomienie. Odpowiedzialny się nie zmienia, ale pojawia się kontrola. Żeby eskalacja działała, struktura firmy musi być wypełniona uczciwie — jak ją skonfigurować, opisano w artykule o strukturze firmy.

Czy można zabronić menedżerom zmiany odpowiedzialnego?

Standardowo — tylko razem ze wszystkim innym. Role CRM nie mają osobnego prawa „zmiana odpowiedzialnego": pole „Odpowiedzialny" zmienia każdy, kto ma prawo „Edycja" do rekordu. Odebranie go oznacza, że menedżer nie edytuje karty w ogóle — ani telefonu, ani kwoty, ani komentarzy. Co naprawdę daje model ról:

  • Uprawnienia do etapów. Dla leadów, deali i smart procesów uprawnienia ustawia się osobno dla każdego etapu: na etapach końcowych i na „Akceptacji" edycję można zamknąć. Odpowiedzialny zostaje zablokowany razem z pozostałymi polami — na tych etapach zwykle o to właśnie chodzi.
  • Poziom „Własne". To nie zakaz, tylko hamulec: oddając deal koledze, menedżer od razu traci do niego dostęp, a cudzego deala nie przejmie, bo go po prostu nie widzi. Jak poziomy dostępu zależą od odpowiedzialnego — w artykule o uprawnieniach i robotach.
  • Zadania. Tu potrzebne prawo istnieje: w rolach zadań osobno włącza się „Zmianę wykonawcy" i „Delegowanie zadania". Ale role w zadaniach można konfigurować tylko w planach Professional i Enterprise, a przełożony zawsze może delegować zadania podwładnym, niezależnie od ustawień.

Model ról CRM też nie jest dostępny w każdym planie. Jeśli „Edycji" odebrać nie można, a kontrola jest potrzebna, blokadę buduje się procesem: zmiany się nie blokuje, tylko cofa.

Jak automatycznie przywrócić poprzedniego odpowiedzialnego?

Potrzebne jest niestandardowe pole wzorcowe — na przykład „Przypisany opiekun" typu „Pracownik" — i proces biznesowy uruchamiany automatycznie przy zmianie. Schemat:

  1. Przy tworzeniu deala proces zapisuje bieżącego odpowiedzialnego w polu wzorcowym.
  2. Przy każdej zmianie deala uruchamia się kontrola. Robot „Pobierz przełożonego pracownika" na podstawie ID z pola wzorcowego znajduje przełożonego poprzedniego odpowiedzialnego.
  3. „Warunek złożony" sprawdza w jednym kroku trzy rzeczy: odpowiedzialny nie jest równy polu wzorcowemu, „Zmodyfikowane przez" to nie ten przełożony i nie administrator CRM. Logika AND, wynik Y lub N.
  4. Y oznacza zmianę bez zgody: standardowa akcja „Zmień odpowiedzialnego" przywraca wartość z pola wzorcowego, a przełożony dostaje powiadomienie, kto próbował przekazać deal.
  5. Odpowiedzialny różni się od pola wzorcowego, ale warunek zwrócił N — zmiany dokonał przełożony lub administrator. Proces zapisuje nowego odpowiedzialnego w polu wzorcowym i od tej chwili to on jest przypisanym opiekunem.

Cofnięcie samo znowu uruchamia proces przy zmianie, ale odpowiedzialny jest już zgodny z polem wzorcowym, więc kontrola kończy się bez działań — pętli nie ma. Jedna zasada: procesy, które przypisują odpowiedzialnego zgodnie z regułami — rozdzielanie leadów, przekazanie bazy przy odejściu — muszą wpisywać nowego odpowiedzialnego także do pola wzorcowego, inaczej kontrola cofnie i je. Jak automatyzacja reaguje na zmianę pól — w artykule o wyzwalaczach, a co jeszcze przepisać przy odejściu pracownika — w liście kontrolnej offboardingu.

Częste pytania

Czy można zabronić menedżerom zmieniać odpowiedzialnego? Osobnego prawa w rolach CRM nie ma: albo odebrać „Edycję" w całości lub na wybranych etapach, albo cofać zmianę procesem, jak opisano wyżej. Czy zmienia się twórca zadania? Standardowo nie — utwórz zadanie na nowo procesem albo zmień wykonawcę. Czy nowy odpowiedzialny jest powiadamiany? Tak, standardowym powiadomieniem; dodatkowe z kontekstem można wysłać z procesu — jak je skonfigurować, w artykule o powiadomieniach z procesów biznesowych. Co stanie się z aktywnymi procesami przy zmianie odpowiedzialnego? Idą dalej; jeśli trasa zależy od odpowiedzialnego, odczytaj pole ponownie w momencie użycia, a nie na początku procesu.

Podsumowanie

Zmiana ręczna zamyka pojedyncze przypadki, akcje grupowe — jednorazowe przekazania, roboty — strumień: równomierne rozdzielanie nowych zgłoszeń, przekazanie powiązanej bazy przy odejściu, eskalacja po strukturze i cofanie zmiany, której nikt nie zatwierdził. Roboty „Losowy pracownik", „Zmień odpowiedzialnego w powiązanych", „Pobierz przełożonego", „Pobierz dział pracownika" i „Warunek złożony" znajdują się w katalogu Roboteki, instaluje się je z Bitrix24 Market bezpłatnie. Nie ma potrzebnego scenariusza — opisz zadanie, zrobimy robota.