Wcześniej w tej serii zaimportowaliśmy model bazy danych SuiteCRM do Vertabelo i pokazaliśmy, jak używać funkcji Vertabelo do jego organizowania. W tym artykule zobaczymy, jak wspólne dane CRM są przechowywane w jego bazie danych. Sprawdzimy również założenia poczynione w części 2 dotyczące relacji między tabelami i ich funkcjami. W razie potrzeby wprowadzimy modyfikacje modelu.
Co obecnie mamy?
W części 1 zainstalowaliśmy SuiteCRM lokalnie za pomocą pakietu instalacyjnego Bitnami. Po pomyślnym zalogowaniu główny ekran SuiteCRM wygląda tak, jak poniżej:
Baza danych SuiteCRM o nazwie „bitnami_suitecrm” jest dostępna pod adresem http://127.0.0.1/phpmyadmin. Przypomnijmy, że model ma 201 stołów.
Część 2 tej serii zakończyliśmy modelem zorganizowanym w ten sposób:
Podstawowe wymagania dotyczące CRM
CRM powinien umożliwiać nam prowadzenie ewidencji naszych klientów i śledzenie kontaktów (połączeń, spotkań itp.), które z nimi mamy.
Klienci są centralni dla każdego systemu CRM. Musimy przechowywać ich podstawowe dane organizacyjne (imię i nazwisko, adres, przychody, liczba pracowników) oraz ich dane kontaktowe (telefon, telefon komórkowy, e-mail, strona internetowa, a może nawet konta społecznościowe). Musimy również śledzić dane administracyjne, takie jak kiedy i przez kogo ich rekordy zostały dodane lub zaktualizowane w systemie.
Kiedy myślimy o działaniach związanych z klientem, zwykle myślimy o telefonach i spotkaniach. Moglibyśmy mieć też inne czynności, które nie wymagają kontaktu z klientem:sprawdzenie, czy problem został rozwiązany, czy płatność została dokonana, tego typu rzeczy. Chcemy prowadzić rejestr poprzednich działań, ale potrzebujemy również możliwości planowania przyszłych wydarzeń. Ponadto będziemy przechowywać czas rozpoczęcia i zakończenia akcji, kto wstawił i zaktualizował dane akcji, kto zainicjował daną akcję i kto za nią odpowiada.
Oczywiście istnieje wiele innych rzeczy – takich jak wcześniej sprzedane produkty i usługi oraz potencjalna nowa sprzedaż – które moglibyśmy również dodać do CRM. Ale w tym artykule skupimy się na tym, jak SuiteCRM przechowuje dane klientów, połączenia i spotkania.
Zarządzanie klientami
Organizacje klientów nazywają się kontami w SuiteCRM. Oto, co Utwórz nowe konto ekran wygląda tak:
A oto jak wygląda tabela „konta” w bazie danych SuiteCRM:
W ramach accounts
tabela, informacje o przechowywaniu atrybutów wprowadzone w Utwórz nowe konto ekran:
- Podstawowe dane klienta:
name
,description
,industry
,annual revenue
,„rating
,ownership
,employees
,ticker symbol
- Dane kontaktowe:
phone_fax
, atrybuty adresu rozliczeniowego, atrybuty adresu dostawy,phone_office
,phone_alternate
,website
- Zmiany w danych klienta w CRM:
created_by
,modified_user_id
,assigned_user_id
,date_entered
,date_modified
ideleted
.
Większość z tych atrybutów jest typu varchar, ponieważ CRM musi być w stanie przechowywać dane wprowadzone przez użytkownika dowolnego możliwego typu.
accounts
tabela jest połączona z wieloma innymi tabelami w bazie danych SuiteCRM. Wszystkie relacje są ustawione zgodnie z założeniami opisanymi w części 2 tej serii.
Konta wewnątrz SuiteCRM to w zasadzie lista klientów. Są one powiązane z wieloma innymi tabelami w systemie:contacts
, opportunities
, bugs
, cases
.
W języku SuiteCRM kontakty są rzeczywistymi ludźmi, z którymi rozmawiamy w imieniu ich organizacji (pamiętaj, że w języku CRM organizacje te są nazywane „kontami”). Możesz przypisać nowy kontakt do konta, jak pokazano poniżej:
Dane osoby są przechowywane w contacts
stół. account_contacts
tabela umożliwia nam powiązanie wielu kontaktów z danym kontem.
Możliwości wewnątrz SuiteCRM są szacowane możliwości sprzedaży. Są przywiązani do etapu sprzedaży. opportunities
i account_opportunities
tabele służą do przechowywania danych o wielu możliwościach związanych z jednym kontem.
Jak można się domyślić po ich nazwie, bugs
i accounts_bugs
tabele przechowują dane o problemach związanych z niektórymi kontami. Moduł SuiteCRM umożliwia również wprowadzanie rozwiązań i śledzenie historii błędów. Błędy są związane z calls
, contact
, cases
i inne stoły.
Moduł „spraw” służy do wprowadzania i śledzenia problemów związanych z usługami. Po dodaniu nowej sprawy możemy dodać błędy związane z tą sprawą.
Połączenia
Każdy system CRM będzie przechowywać informacje o połączeniach do klientów; Z SuiteCRM nie jest inaczej. Aby dodać nowe połączenie, klikamy Czynności --> Połączenia i uzupełnij potrzebne dane. Dodamy nowe połączenie i powiążemy je z istniejącym kontem i użytkownikiem w naszym systemie.
Oto, co Połączenia sekcja wewnątrz bazy danych wygląda następująco:
W calls
tabeli, możemy zobaczyć niektóre z tych samych atrybutów, co w accounts
stół. Atrybuty created_by
, modified_user_id
i assigned_user_id
odnoszą się do użytkownika (ów), który wprowadził to połączenie, zmodyfikował je lub jest przypisany do połączenia. parent_type
i parent_id
para oznacza, do której tabeli się odwołuje i wartość klucza podstawowego dla tej tabeli. Większość pozostałych atrybutów nie wymaga wyjaśnień.
Ta sama struktura, wykorzystująca relację wiele do wielu, służy do łączenia połączeń z użytkownikami, potencjalnymi klientami i kontaktami.
Po kliknięciu Zapisz przycisk, możemy zobaczyć nowy rekord połączenia w naszych Połączeniach lista. Teraz zajrzymy do bazy danych, a konkretnie do calls
i calls_users
tabele.
W calls
widzimy, że „parent_type” =Konta i że identyfikator w parent_id
pole to identyfikator konta. Wewnątrz bazy danych znajduje się kilka tabel, które używają tego samego atrybutu do łączenia się z jedną z kilku innych tabel. Podczas gdy parent_id
będzie zawierać wartość klucza podstawowego w tabeli, do której się odwołuje, parent_type
oznacza, z którą tabelą się połączymy.
Oczywiście w calls_users
tabeli, odniesiemy to wywołanie do przypisanego użytkownika.
Spotkania
„Spotkania i potencjalni klienci Sekcja ” to grupa tabel służących do przechowywania danych związanych ze spotkaniami i leadami. Chociaż jest oczywiste, jakie mogą być dane dotyczące spotkania, prowadzi odnoszą się do potencjalnego zainteresowania klientów naszymi produktami i usługami. Później użyjemy tych potencjalnych klientów i powiążemy je z możliwościami, rozmowami i spotkaniami.
Zauważymy, że niektóre ogólne zasady nazewnictwa pól na meetings
tabeli i do łączenia spotkań z kontaktami, potencjalnymi klientami i użytkownikami są stosowane w tej sekcji.
Podobnie jak w przypadku połączeń, spotkania mogą być również przypisywane użytkownikom i powiązane z klientami. Wejdziemy na nowe spotkanie, klikając Czynności --> Spotkania --> Zaplanuj spotkanie .
Po wprowadzeniu dane spotkania są przechowywane w SuiteCRM; możemy to zobaczyć na liście spotkań. Podobnie jak w przypadku połączeń, spotkania można przypisywać do kont, kontaktów, zadań, możliwości, błędów, spraw, potencjalnych klientów, projektów, zadań projektowych i celów.
W bazie danych meeting
tabela zawiera dane o nowo dodanym spotkaniu. parent_type
i parent_id
atrybuty są używane w ten sam sposób i w tym samym celu, co calls
dane.
meetings_users
tabela przechowuje informacje o użytkownikach przypisanych do określonego spotkania.
Klucze podstawowe to losowo generowane wartości skrótu. Dzięki temu możemy mieć unikalne wartości dla każdego klucza podstawowego w całej bazie danych, a nie tylko w każdej tabeli. Jest to szczególnie przydatne, gdy używamy tego samego atrybutu jako klucza obcego do wielu różnych tabel. Jeden atrybut zawiera wartość klucza, a inny nazwę tabeli, do której się odwołuje. Zapewnia to znacznie większą elastyczność – więcej niż systemy obejmujące kilka rzeczywistych sytuacji biznesowych, które zazwyczaj wymagają.
W części 4, która zakończy tę serię, przyjrzymy się bliżej reszcie SuiteCRM, w tym kampaniom, projektom, możliwościom i administrowaniu dokumentami.