Salesforce to komercyjna platforma CRM dostarczana w modelu usługi, z konfigurowalnym modelem danych, automatyzacją procesu sprzedaży i własnym środowiskiem rozszerzeń. Decyzja o niej rzadko dotyczy samego narzędzia. Dotyczy tego, ile organizacja chce zapłacić za to, żeby wiedza o kliencie przestała być prywatną własnością pojedynczych osób.
Na skróty
Czego dowiesz się z artykułu:
- Jaki koszt organizacja ponosi, zanim ktokolwiek zaproponuje w niej system klasy CRM
- Jakie warunki muszą wystąpić razem, żeby platforma tej klasy była właściwą odpowiedzią
- W jakich sytuacjach platforma CRM nie odpowiada na realny problem
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje na lata, wchodząc w model usługi
Dla kogo ten artykuł:
- Dyrektorzy sprzedaży odpowiadający za przewidywalność prognozy i ciągłość relacji
- Architekci rozstrzygający, gdzie mieszka rejestr klienta i jak jest zintegrowany
- Menedżerowie planujący budżet subskrypcji, wdrożenia i kompetencji
Jaki koszt ponosi organizacja, w której wiedza o kliencie mieszka w skrzynkach i arkuszach?
Rachunek nie zaczyna się od nazwy systemu. Zaczyna się od strat, których nikt nie księguje osobno: odejście handlowca zabiera ze sobą historię rozmów, prognoza powstaje z deklaracji zamiast z danych, ten sam klient dostaje sprzeczne oferty od różnych osób, a marketing płaci za kontakty, które ktoś już obsłużył. Do tego dochodzi pytanie audytora albo inspektora ochrony danych: gdzie właściwie leży rejestr klientów i kto ma do niego dostęp. Ten koszt organizacja ponosi codziennie, niezależnie od tego, czy ktokolwiek podejmie jakąkolwiek decyzję o narzędziu.
Problem ma odmiany, a ich pomylenie jest tu najdroższym błędem. Pierwsza odmiana to długi cykl sprzedaży, w którym tę samą szansę dotyka wiele ról: handlowiec, inżynier przedsprzedaży, dział prawny, zespół wdrożeniowy. Problemem jest wtedy ciągłość rejestru — nie brak narzędzia, tylko brak jednego miejsca, w którym stan sprawy jest prawdziwy. Druga odmiana to proces opisany na papierze i nieegzekwowany: etapy szansy nie odpowiadają rzeczywistości, rabaty są przyznawane poza jakimkolwiek progiem akceptacji, a raport zarządczy powstaje ręcznie na koniec kwartału. Problemem jest wtedy wymuszenie reguł, a nie ich spisanie.
Obie odmiany widać najostrzej tam, gdzie sprzedaż jest wieloetapowa i regulowana: w bankowości i ubezpieczeniach, w firmach produkcyjnych sprzedających przez sieć dystrybutorów, w usługach rozliczanych odnowieniami. Tam brak wspólnego rejestru nie kończy się niewygodą, tylko utraconym odnowieniem albo pytaniem regulatora, na które nie ma odpowiedzi.
Kiedy platforma tej klasy jest właściwą odpowiedzią na ten problem?
Platforma CRM tej klasy jest właściwą odpowiedzią wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno:
- Rejestr klienta jest współdzielony przez wiele ról i wiele systemów. Ten sam podmiot pojawia się w ofercie, w umowie, w rozliczeniu i w zgłoszeniu serwisowym, a rozjazd między tymi widokami kosztuje realne pieniądze. Platforma daje wtedy wspólny model danych i kontrolę dostępu opisaną rolami, a nie uprawnieniami do plików.
- Reguły procesu mają być egzekwowane maszynowo. Progi akceptacji rabatu, wymagalność pól na kolejnych etapach, ścieżka zatwierdzeń i ślad zmian są warunkiem, a nie ozdobą. Jeżeli reguły mają zostać zaleceniem, narzędzie ich nie uratuje.
- Organizacja godzi się na model usługi. Środowisko, cykl aktualizacji i lokalizacja danych należą do dostawcy; przewidywalność kupuje się razem z zależnością od jego decyzji i publikowanego stanu usługi.
Dopiero gdy te warunki występują łącznie, sensu nabiera czwarta rzecz: rozszerzanie platformy poza konfigurację — własna logika w środowisku programistycznym dostawcy, integracje z systemami rozliczeniowymi i limity wykonania, które trzeba znać przed napisaniem pierwszej linii kodu. Zakres tej pracy — wzorce projektowe, obsługa transakcji, programowanie asynchroniczne i integracja z systemami zewnętrznymi — obejmuje szkolenie Programowanie Salesforce — zaawansowane podejście.
Kiedy platformy CRM tej klasy nie wybierać?
Najczęstszym błędem jest sięgnięcie po platformę tej klasy w imię „uporządkowania sprzedaży”, zanim ktokolwiek zapisał, jak ta sprzedaż ma przebiegać. Wdrożenie nie tworzy procesu — utrwala ten, który zastanie, razem z jego wadami, i robi to za cenę, której nikt nie planował.
Poza tym są sytuacje, w których platforma nie jest odpowiedzią na realny problem. Sprzedaż transakcyjna o krótkim cyklu, obsługiwana przez kilkuosobowy zespół, potrzebuje wspólnej listy kontaktów i dyscypliny notowania, a nie modelu ról i uprawnień. Organizacja, w której szansa sprzedaży nie ma etapów, bo klient kupuje w jednym kroku, nie ma czego automatyzować — cały mechanizm etapów pozostanie pustym polem w formularzu. Wreszcie reżim danych: jeżeli regulator albo polityka wewnętrzna wymaga, żeby rejestr klientów pozostał w infrastrukturze kontrolowanej przez organizację, to rozstrzygnięcie zapada poziom wyżej niż wybór CRM-u i dotyczy modelu chmury, a nie narzędzia sprzedażowego. Koszt utopiony w licencjach nie jest argumentem za utrzymaniem żadnej z tych trzech sytuacji. Rozstrzygnięcie o modelu, w którym w ogóle mogą leżeć dane, rozpisuje tekst o strategii chmurowej — publicznej, prywatnej i hybrydowej.
Jakie są alternatywy i ile kosztują?
Lżejszy system CRM w modelu usługi kosztuje mniej w abonamencie i mniej we wdrożeniu, ale płaci się za to granicą rozszerzalności: gdy proces przerośnie konfigurację, migracja rejestru klientów odbywa się razem z historią, integracjami i uprawnieniami. Moduł sprzedażowy w istniejącym systemie ERP nie generuje nowej umowy z dostawcą i trzyma dane blisko rozliczeń, ale dziedziczy cykl wydawniczy ERP-a i zwykle ustępuje w automatyzacji pracy handlowca. Własna aplikacja daje pełną kontrolę nad modelem danych i lokalizacją, a jej cena jest najmniej widoczna z góry: to nie koszt napisania, tylko koszt utrzymania zespołu, który przez lata będzie ją rozwijał, łatał i integrował.
Czwarta droga bywa najtańsza i najrzadziej rozważana: uporządkowanie procesu bez zmiany narzędzia — jeden właściciel rejestru, uzgodnione etapy, wymagalność danych i cotygodniowy przegląd. Bywa też jedyną, która działa, bo poprzednie trzy zakładają, że proces istnieje. Porównanie podejść do kontroli wydatków, które w każdej z tych dróg rosną wraz z liczbą użytkowników i dodatków, zebrano w tekście o FinOps i kontroli kosztów chmury.
Co organizacja podpisuje na lata, wchodząc w model usługi?
Podpisuje przede wszystkim rachunek, który rośnie razem z sukcesem wdrożenia: cennik platformy jest liczony na użytkownika i na wybraną edycję, więc każde kolejne stanowisko i każdy dodatek zwiększa stałą pozycję w budżecie. Podpisuje też cykl aktualizacji, którego nie ustala: zmiany po stronie dostawcy trzeba testować na własnych rozszerzeniach, a okno na reakcję jest wyznaczone z zewnątrz.
Najdroższą pozycją nie jest jednak subskrypcja, tylko kompetencja. Platforma, którą nikt w organizacji nie umie skonfigurować, staje się zależnością od partnera wdrożeniowego przy każdej zmianie pola i każdym nowym raporcie. Rolą, która ten rachunek obniża, jest administrator znający model danych, uprawnienia, automatyzację procesów i raportowanie — czyli zakres szkolenia Salesforce Administrator — fundament CRM. Bez tej roli organizacja płaci podwójnie: za samą usługę i osobno za każdą wprowadzaną w niej zmianę.
FAQ — najczęściej zadawane pytania
Czy platforma CRM uporządkuje proces sprzedaży, którego nie mamy opisanego?
Nie. Wdrożenie odwzorowuje proces, który zastanie, i utrwala go w polach, etapach i regułach. Jeżeli proces jest umowny, narzędzie zamieni go w umowny formularz, a organizacja zapłaci za to abonamentem i pracą wdrożeniową. Kolejność jest odwrotna: najpierw uzgodnione etapy i właściciel rejestru, potem wybór narzędzia.
Czy konfiguracja wystarczy, czy trzeba programować?
Zależy od tego, jak daleko proces odbiega od modelu wbudowanego w platformę. Konfiguracja obejmuje model danych, automatyzację i raporty; własny kod wchodzi tam, gdzie potrzebna jest logika wykraczająca poza reguły deklaratywne albo integracja z systemem, który nie ma gotowego złącza. Rozstrzygnięcie zapada na etapie analizy, nie w trakcie wdrożenia — przesunięcie go w czasie jest najczęstszym źródłem przekroczenia budżetu.
Po czym poznać, że organizacja przerosła prostszy system?
Po tym, że reguły procesu zaczynają żyć poza narzędziem: w arkuszach kontrolnych, w wiadomościach o akceptację rabatu i w ręcznie sklejanym raporcie zarządczym. Dopóki te rzeczy mieszczą się w narzędziu, zmiana platformy jest kosztem bez zwrotu. Gdy zaczynają z niego wypadać, koszt utrzymania obejścia przekracza koszt migracji.