Zmiana etapu szansy nie zawsze powinna być zwykłym wyborem z listy.
Samo oznaczenie szansy jako wygranej albo przegranej nie wyjaśnia, dlaczego tak się stało. Bez danych o przyczynach trudno później porównywać skuteczność ofert, konkurencję czy jakość kwalifikacji klientów.
Przykładowa reguła: po wybraniu etapu wygranego użytkownik musi uzupełnić „Powód wygranej”, a po wyborze etapu przegranego — „Powód przegranej”. Na wcześniejszych etapach pola te nie powinny blokować pracy.
Najpierw ustal prawidłowe wartości i przejścia między etapami.
Warto rozstrzygnąć, czy historia dawnych powodów ma pozostać w audycie zmian. Czyszczenie bieżącego pola nie musi oznaczać utraty historii — zależy to od konfiguracji audytu.
- Wygrana: wymagany powód wygranej; powód przegranej zostaje wyczyszczony.
- Przegrana: wymagany powód przegranej; powód wygranej zostaje wyczyszczony.
- Etap otwarty: oba powody są nieaktywne albo czyszczone zgodnie z ustaloną polityką danych.
- Powrót z etapu przegranego do negocjacji: użytkownik nie powinien pozostawić nieaktualnej przyczyny porażki jako bieżącej informacji.
- Reguły muszą korzystać ze skonfigurowanych etapów, a nie polegać wyłącznie na sztywnych napisach w kodzie.
Ta sama walidacja musi działać niezależnie od sposobu zapisu.
Najczęstsza pułapka pojawia się wtedy, gdy reguła działa w formularzu edycji, ale przeciągnięcie kafelka w Kanban pozwala ją ominąć. Innym problemem jest blokowanie zapisu przez serwer bez pokazania użytkownikowi pola, które powinien uzupełnić.
Projekt rozszerzenia powinien uwzględniać klasyczny formularz, edycję inline, zmianę etapu na tablicy i wywołania API. Gdy wymagany jest powód, interfejs powinien umożliwiać jego podanie przed zakończeniem operacji.
Walidacja po stronie serwera
Nie pozwala ominąć reguły przez alternatywny widok, integrację lub API.
Obsługa w interfejsie
Pokazuje odpowiednie pole i czytelny komunikat przy zmianie etapu.
Test w Kanban
Sprawdza zarówno przeciągnięcie kafelka, jak i cofnięcie go do poprzedniego etapu.
Przejście do dalszego etapu może wymagać powiązanej oferty.
W niektórych procesach warto sprawdzać, czy przy szansie zapisano dokument ofertowy, zanim zostanie oznaczona jako przedstawiona klientowi. Taką regułę można połączyć z etapami sprzedaży i dodatkowymi typami dokumentów.
Trzeba jednak jasno zdefiniować wyjątki, np. sytuację przegrania szansy, zanim przygotowano formalną ofertę. Bez wyjątków reguła może niepotrzebnie blokować poprawne działania użytkowników.
Przetestuj cały cykl życia szansy, nie tylko jeden zapis.
To przykład możliwego rozszerzenia, a nie obietnica, że każda instalacja EspoCRM ma takie reguły dostępne od razu. Zakres implementacji zależy od wersji, modułów i sposobu konfiguracji.
- Edycja szansy z wybraniem etapu wygranego bez powodu — oczekiwany komunikat błędu.
- Przesunięcie do przegranej w Kanban — żądanie uzupełnienia właściwego powodu.
- Przejście z wygranej do etapu otwartego — poprawne wyczyszczenie nieaktualnych pól.
- Zmiana etapu przez integrację API — taka sama walidacja jak w interfejsie.
- Weryfikacja oferty przy etapach, dla których jest wymagana, oraz działanie wyjątków.
Zacznij od spójnej definicji etapów i danych potrzebnych handlowcom.
Wdrożenie warto rozpocząć od mapy etapów i oczekiwanych informacji, następnie zaplanować reguły serwera, reakcję formularzy i testy Kanban. To pozwala uniknąć sytuacji, w której reguła poprawia jakość danych, ale utrudnia codzienną pracę.
SpecINFO wdraża i rozbudowuje EspoCRM. Zakres naszych rozwiązań przedstawiamy na stronie usługi, a ten materiał wyjaśnia logikę walidacji i sposób jej zaprojektowania.