Przejdź do treści
Intum Dev

Jedna osoba w wielu firmach: powiązania, kampanie i historia kontaktu

Aktualizacja: 7 min czytania Wyświetleń: 231
Na tej stronie

Hanna prowadzi własną spółkę i jednocześnie robi księgowość dla trzech innych firm, które też są naszymi klientami. W systemie jest jedną osobą, ale pracuje dla czterech klientów naraz. Pytanie, które z tego wynika, brzmi prosto: gdzie ją zapisać i co się stanie, gdy wyślemy kampanię.

Kiedy to się zdarza

Najczęściej w czterech sytuacjach:

  • księgowa albo biuro rachunkowe obsługujące kilka firm
  • właściciel kilku spółek, każda z osobnym kontem płatnym
  • agencja, która zarządza kontami swoich klientów
  • osoba, która zmieniła pracę i występuje w dwóch firmach, choć w jednej już nie pracuje

Piąty przypadek jest mniej oczywisty, ale najbardziej kłopotliwy: ta sama osoba podaje ten sam adres e-mail w kilku firmach jako kontakt techniczny. Z punktu widzenia systemu to jeden adres i jeden człowiek, tylko powiązań kilka.

Jak radzą sobie z tym inne systemy

Salesforce przez lata pozwalał przypisać osobę tylko do jednej firmy. Gdy okazało się, że klienci obchodzą to duplikatami, dodał osobne powiązania z rolami, zostawiając jednocześnie firmę główną przy kontakcie. Dokładnie ten sam pomysł: jedna firma jest podstawowa, pozostałe dochodzą obok.

Zendesk ma członkostwa w organizacjach, gdzie jedno jest domyślne. HubSpot pozwala powiązać osobę z wieloma firmami, wyróżnia jedną jako główną i od niedawna pozwala opisać rolę na samym powiązaniu (“osoba decyzyjna”, “kontakt do faktur”). Intercom robi to najprościej: wiele firm, bez ról.

Ciekawszy jest przykład Pipedrive, który tego nie rozwiązał. Osoba może należeć tylko do jednej organizacji, więc użytkownicy zakładają jej kilka kopii. Efekt jest przewidywalny: historia rozmów rozjeżdża się na kilka kart, ta sama osoba dostaje kilka egzemplarzy newslettera, a wypisanie się z jednej kopii nie wypisuje z pozostałych.

Jak to działa w Intum CRM

Kontakt może być powiązany z dowolną liczbą klientów i każde powiązanie ma swoją rolę. Hanna jest właścicielką w swojej spółce i księgową w trzech pozostałych, i widać to na jej karcie.

Osoba zostaje przy tym jednym wpisem. Nie zakładamy jej kopii dla każdego klienta, bo to psuje wszystko, co opisano niżej.

Jeden z klientów jest klientem domyślnym kontaktu. System ustawia go przy pierwszym powiązaniu i potem już go nie zmienia sam - robi to tylko operator. Domyślny klient jest po to, żeby cokolwiek, co dotyczy osoby bez wskazania konkretnej firmy, miało gdzie trafić.

Kampanie wysyłane jednorazowo

W newsletterze adresatem jest osoba, nie firma. Hanna dostaje jeden e-mail, choć jest powiązana z czterema klientami. Gdyby dostała cztery, potraktowałaby to jako spam i miałaby rację.

Wypisanie się działa na poziomie adresu e-mail, więc jest skuteczne od razu dla wszystkich firm, w których ta osoba występuje. To istotne również formalnie: rezygnacja musi zadziałać raz i całkowicie.

Jest tu jedna pułapka warta uwagi przy tworzeniu treści. Jeśli w mailu wstawiasz nazwę firmy odbiorcy, system weźmie klienta domyślnego. Dla Hanny będzie to jej własna spółka, nawet jeśli w kontekście danej kampanii sensowniejsze byłoby biuro rachunkowe. Przy kampaniach do osób lepiej więc nie personalizować nazwą firmy albo pisać tak, żeby pasowało niezależnie od niej.

Kampanie cykliczne i automatyzacja

Tutaj zasada jest odwrotna, i to nie jest niekonsekwencja. Wiadomość “kończy się okres rozliczeniowy konta Alfa” dotyczy konkretnej firmy. Jeśli Hanna ma cztery firmy i trzy z nich mają coś do zapłaty, trzy wiadomości nie są duplikatami - to trzy różne informacje i wszystkie są potrzebne.

Rozróżnienie sprowadza się do jednego pytania: czy treść wiadomości zmieni się, gdy podstawię inną firmę? Jeśli tak, bo jest w niej nazwa firmy, kwota albo data - wysyłamy per firma. Jeśli nie, bo to poradnik albo informacja o nowej funkcji - wysyłamy raz na osobę.

Dwie rzeczy trzeba przy tym pilnować.

Pierwsza to limit częstotliwości liczony na osobę, a nie na firmę. Bez niego Hanna dostanie w ciągu godziny trzy podobne wiadomości o trzech firmach i odbierze to jako awarię systemu, nawet jeśli każda z nich osobno jest poprawna.

Druga to agregacja. Zamiast trzech wiadomości lepiej wysłać jedną, w której wymienione są wszystkie trzy firmy. Tak robi GitHub i Atlassian dla osób pracujących w wielu zespołach i to jest dobry wzór.

Warunek wspólny dla obu rodzajów wysyłek: wiadomość wysyłana automatycznie musi przechodzić przez te same reguły co kampania. Sprawdzenie, czy odbiorca się nie wypisał, i limit częstotliwości nie mogą dotyczyć tylko newslettera, bo dla odbiorcy nie ma różnicy, który mechanizm wysłał wiadomość.

Historia przy osobie, nie przy firmie

Na karcie kontaktu chcemy widzieć całą historię tej osoby: e-maile, rozmowy telefoniczne, wysłane kampanie, notatki. Także te zdarzenia, które formalnie dotyczyły innej firmy niż ta, na którą właśnie patrzymy.

To wygląda na drobiazg, a jest sednem sprawy. Konsultant rozmawia z człowiekiem, nie z firmą. Jeśli Hanna dzwoni w sprawie biura rachunkowego, a trzy dni wcześniej dostała kampanię wysłaną na jej własną spółkę, konsultant musi to widzieć - inaczej nie zrozumie, o czym ona mówi.

Dlatego zapisujemy zdarzenia przy osobie, a firma jest dodatkowym oznaczeniem zdarzenia, nie miejscem jego przechowywania. Na karcie kontaktu widać wszystko z zaznaczeniem, której firmy dotyczyło. Na karcie klienta widać zdarzenia jego ludzi, z zaznaczeniem kto.

Przy duplikatach osoby nic z tego nie działa: historia rozpada się na kilka kart, personalizacja bierze dane przypadkowej kopii, a limity częstotliwości liczą każdą kopię osobno. Dlatego jedna osoba to jeden kontakt, a wiele firm obsługujemy powiązaniami.

Adresy i numery: trzeci element układanki

Hanna pisze raz ze skrzynki własnej spółki, raz z adresu biura rachunkowego, a dzwoni z komórki. Do tego w Alfie założono jej służbową skrzynkę, bo tak mają w firmie. Cztery sposoby kontaktu, jeden człowiek.

Dlatego karta kontaktu ma trzy poziomy, nie dwa. Klient to firma, kontakt to osoba, a dane kontaktowe to adresy i numery, które prowadzą do jednego albo do drugiego. Ostatni poziom jest tym, który w większości systemów sprowadza się do pola tekstowego, a przez to psuje resztę.

Każdy adres i numer wie, do kogo należy:

  • do osoby w konkretnej firmie - służbowa skrzynka Hanny w Alfie, jej numer wewnętrzny
  • do samej osoby - prywatna skrzynka i komórka, zostają przy niej także wtedy, gdy przestanie obsługiwać Alfę
  • do samej firmy - centrala, adres na fakturach, wspólna skrzynka biura. Nie należy do nikogo z osobna i nie służy do rozpoznawania człowieka

Trzeci przypadek brzmi drobiazgowo, a jest najczęstszym powodem pomyłek w CRM-ach. Gdy numer centrali wpisze się trzem osobom jako ich telefon, system przestaje wiedzieć, kto właściwie dzwoni. U nas centrala jest numerem firmy i tyle.

Co z tego wynika w codziennej pracy:

Wiadomość z dowolnego adresu Hanny trafia do Hanny. Nie powstaje druga karta, historia się nie rozjeżdża.

Telefon z numeru Alfy ląduje przy sprawie Alfy, a nie przy jej domyślnej spółce. Konsultant widzi właściwy kontekst, zanim odbierze.

Scalenie duplikatów niczego nie gubi. Adres z pochłoniętej karty zostaje jako kolejny sposób kontaktu, więc następna wiadomość z niego nie utworzy duplikatu na nowo. To zamyka błędne koło, które w innych systemach potrafi wracać latami.

Wypisanie się z newslettera dotyczy adresu, nie człowieka. Hanna, która wypisała skrzynkę służbową w firmie, z której odeszła, nadal dostanie wiadomość na prywatną.

Jak to wygląda gdzie indziej

Zendesk trzyma listę sposobów kontaktu przy osobie i jest w tym najbliżej nas, ale wymaga, żeby numer telefonu był linią bezpośrednią. Wspólnej centrali w tym modelu po prostu nie da się zapisać, bo wskazywałaby na kilku ludzi naraz.

HubSpot rozróżnia adres główny i dodatkowe, i słusznie nie tworzy duplikatu, gdy dane przyjdą z tego drugiego. Ma za to pułapkę: formularz wypełniony z adresu dodatkowego podmienia adres główny, więc po kilku takich zgłoszeniach nie wiadomo już, który jest właściwy.

Salesforce zostawia jedno pole na adres i osobne pola na kolejne numery: komórkę, domowy, inny, faks. Kolumn zawsze w końcu brakuje, a żadna z nich nie mówi, czy numer należy do osoby, czy do firmy.

Pipedrive pozwala wpisać kilka adresów i numerów z etykietami, ale osoba może należeć tylko do jednej organizacji. Pytanie, do której firmy odnosi się dany adres, w ogóle tam nie powstaje - i to jest właśnie ten brak, który zmusza użytkowników do zakładania kopii osoby.

Czy ten wpis był pomocny?

Komentarze