[Intum Dev](https://intum.dev/index.md) / [Oprogramowanie dla firm](https://intum.dev/oprogramowanie-dla-firm.md)

# [Jedna osoba w wielu firmach: powiązania, kampanie i historia kontaktu](https://intum.dev/oprogramowanie-dla-firm/jedna-osoba-w-wielu-firmach-powiazania-kampanie-i-historia-kontaktu.md)

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.