Pozyskanie klienta w enova365

Proces pozyskania klienta i sprzedaży w enova365



Opisane rozwiązanie stanowi jedynie przykład konfiguracji programu i może zostać zmodyfikowane dla potrzeb firmy przez wdrażającego program autoryzowanego Partnera enova365. Celem tej przykładowej konfiguracji jest zaprezentowanie szerokiego spektrum możliwości jakie w procesie pozyskania i sprzedaży do klienta stwarza moduł CRM.
Proces pozyskania i sprzedaży klienta w enova365 ma pokazać możliwą ścieżkę pracy w programie jaką może się posługiwać użytkownik systemu.

Firma i jej otoczenie

Modelowa baza zawiera konfigurację modułu CRM w firmie handlowej.

Konfiguracja

Praca z bazą wymaga ustawienia haseł logowania dla handlowców.
Dlatego należy zalogować się na konto Administratora i w ustawieniach konfiguracyjnych dla poszczególnych Operatorów ustawić hasło dostępu do systemu.

Proces pozyskania i sprzedaży do klienta został oparty o:

Kampanie i Projekty jako działania w pełni zaplanowane zostały przygotowane przed wystąpieniem akcji z klientem. Przy ich przygotowaniu wykorzystano standardowe definicje. Kryterium tworzenia Kampanii był sezon na który przeznaczony jest ofertowany asortyment. Do każdej Kampanii podpięto po 2 Projekty oparte o przeznaczenie sprzedawanego towaru. Kampanie i projekty Pełnią role agregatów działań z klientem. Dzięki temu uzyskujemy przejrzystą i uporządkowaną strukturę akcji z klientem. Ma to duży wpływ na szybkość wyszukiwania informacji, ułatwia prowadzenie wszelkich analiz oraz usprawnia zarządzanie i kontrolę wątków sprzedażowych. Taka struktura ułatwia również planowanie pracy, co ma istotny wpływ na jakość obsługi klienta oraz nie gubienie szans sprzedaży.

Cały proces jest inicjowany przez kontakt przychodzący do firmy - co skutkuje utworzeniem Leada, który podpinany jest pod odpowiedni Projekt. Kiedy Lead znajdzie się w odpowiednim stanie i będzie możliwość przygotowania dla klienta oferty lub wystawienia faktury, należy wygenerować z niego Transakcję i podpiąć pod nią odpowiednie dokumenty. W momencie wygenerowania Transakcji będziemy pracować na niej, natomiast Lead powinien zostać zamknięty. Należy pamiętać o możliwości posługiwania się Priorytetem, co - szczególnie w wypadku Leada - może mieć istotne znaczenie ze względu na analizy oraz planowanie. W opisanym obszarze posłużono się standardowymi definicjami.

Praca w obrębie Leada i Transakcji oparta została o Zadania oraz Zdarzenia i przebiega w sposób modelowy. Oznacza to, że przy pomocy Zadań planujemy wszystkie działania względem klienta (sprawy, które należy wykonać w relacji z kontrahentem), a przy pomocy Zdarzeń odnotowujemy akcje z klientem (również te wynikające z wykonanych zadań), czyli pewne fakty, które zaszły w relacjach z kontrahentem. Dzięki temu uzyskujemy przejrzystą historię Leada, czy Transakcji. Dodatkowo dzięki wiązaniu Zadań i Zdarzeń z Projektem możemy spojrzeć na działania globalnie. Co więcej podpinając dokumenty handlowe pod Zadania na bieżąco możemy śledzić dochody, czy koszty jakie generuje projekt.

W obrębie Zadań i Zdarzeń przyjęto pracę w oparciu o stały schemat pracy z klientem, dlatego wprowadzono standardowe definicje, którymi posługują się handlowcy. W przypadku Zadań są to: Dodano następujące definicje Zdarzeń:

Dla potrzeb prezentacyjnych zostało utworzonych 5 operatorów.

Warto zwrócić uwagę na obieg pracy i możliwość delegowania zadań. Obsługą jednego Leada czy Transakcji może zajmować się kilka osób w zależności od funkcji jaką się pełni. Np. Jedna osoba może, odpowiadać za umówienie spotkanie, druga za prezentację handlową, a trzecia za wysłanie zamówienia do klienta.

W przedstawionej konfiguracji pokazano rozbudowaną strukturę od Kampanii po Zadanie/Zdarzenie. Nic nie stoi na przeszkodzie aby np. w celach prezentacyjnych uprościć ją i działać wyłącznie na Leadach oraz Transakcjach w relacji, do których tworzone będą Zadania i Zdarzenia. W razie potrzeby można wykorzystać możliwości samych Leadów lub Transakcji, tak aby proces był zgodny z potrzebą klienta.


Producent dokłada wszelkich starań, by przykładowe wzorce  demonstracyjne  działały poprawnie w różnych konfiguracjach programu. Nie gwarantuje jednak pełnej kompatybilności z każdym środowiskiem konfiguracyjnym. Zastosowanie w środowisku produkcyjnym zawsze wymaga testów i może się wiązać z modyfikacją konfiguracji.