Najlepsze rozwiązania powstają w boju

Nie zaczynaliśmy od pustego repozytorium.

Nie usiedliśmy też któregoś dnia przy stole z pomysłem:

„Zbudujmy od zera kompleksowy system sprzedaży, rezerwacji i obsługi obiektów.”

Silnik już istniał

Mieliśmy gotowy, rozbudowany system posiadający podstawowe mechanizmy potrzebne obiektom sportowym i rekreacyjnym: sprzedaż, rezerwacje, harmonogramy, zajęcia, urodziny i inne procesy, które można spotkać chociażby w parku trampolin czy sali zabaw.

Teoretycznie wystarczyło go wdrożyć. Ale najpierw musi przewinąć taśmę trochę wcześniej, żeby złapać odpowiedni kontekst 😊

Dlaczego wybraliśmy PLAN4U?

Na początku słowo wstępu. Ten fragment może się teraz wydawać małym odejściem od historii, ale później okaże się bardzo ważnym elementem całej układanki. 😊

Dlaczego właściwie wybraliśmy PLAN4U?

Nie dlatego, że brakowało innych systemów. Oglądaliśmy różne rozwiązania i bardzo szybko zaczęliśmy zadawać pytania, które zwykle zaczynają się od:

„A dałoby się…?”

A może zmienimy ten proces?
A może dorobimy własny panel?
A może zmienimy wygląd?
A może dołożymy CSS, żeby klient po przejściu do sprzedaży nadal czuł, że jest na stronie naszej marki?
A może podepniemy urządzenie, którego system standardowo nie obsługuje?
A może zrobimy to jeszcze inaczej?

W wielu miejscach odpowiedź była podobna:

nie.

Nie da się.
System tego nie przewiduje.
Firewall.
Architektura.
Tak zostało zrobione i tak ma zostać.

I to jest oczywiście całkowicie zrozumiałe. Można sprzedawać zamknięty produkt i bardzo konsekwentnie pilnować jego granic.

Tylko że my od początku wiedzieliśmy, że będziemy te granice testować.

I wtedy trafiliśmy na Olę, właścicielkę PLAN4U, którą przy okazji serdecznie pozdrawiamy.

Są ludzie, którym rzucasz dziwny pomysł i widzisz w ich oczach lekkie przerażenie.

A są programiści.

Programiście mówisz:

„A może byśmy zrobili taką kompletnie niestandardową rzecz?”

i czasami pojawia się ten charakterystyczny błysk w oku.

Nie:

„O Jezu, znowu coś wymyślili.”

Tylko:

„Czekaj. To może się da zrobić.”

I właśnie taki błysk zobaczyliśmy tutaj.

Rzucaliśmy kolejne pomysły, które w innych systemach kończyły rozmowę, a po drugiej stronie zamiast:

„nie da się”

słyszeliśmy:

„Świetny pomysł. Sprawdźmy, jak to zrobić.”

I wtedy już wiedziałem, że będzie źle.

Bo znam to spojrzenie.

To jest to specyficzne programistyczne odklejenie, kiedy człowiek przestaje przez chwilę funkcjonować w normalnym świecie, bo właśnie zobaczył ciekawy problem do rozwiązania.

To ten stan, w którym można niemal zapomnieć odebrać dziecko z przedszkola, bo w drodze do domu człowiek właśnie wymyślił, jak rozwiązać problem architektoniczny, który absolutnie nie mógł poczekać do jutra.

I chyba właśnie dlatego wybraliśmy PLAN4U.

Nie tylko ze względu na to, co system już potrafił.

Przede wszystkim ze względu na to, że kiedy przychodziliśmy z czymś, czego jeszcze nie potrafił, po drugiej stronie była ciekawość, żeby sprawdzić, czy da się to zrobić.

A później zaczęliśmy tę cierpliwość testować.

Bardzo intensywnie.

I zaczęła się imba.

Zaczęło się od lodowiska

Jednym z pierwszych miejsc, w których system został naprawdę mocno przetestowany operacyjnie, było lodowisko Hit2Fit.

Duża liczba klientów.

Sprzedaż online.

Sprzedaż na miejscu.

Karnety.

Różne rodzaje wejść.

Recepcja.

Wypożyczalnia.

I bramki kontroli dostępu, na które wcześniej wydaliśmy kilkadziesiąt tysięcy złotych.

I tutaj muszę wtrącić jedną rzecz:

bramki są piękne. Naprawdę.

Stal nierdzewna. LED-y. Komunikaty: „Dziękujemy”, „Zapraszamy ponownie”.

Awww.

I między innymi dlatego tak bardzo chcieliśmy je uratować.

Być może nawet za bardzo.

Problem w tym, że bramki zaczęły dawać nam popalić właściwie od początku.

Firma montująca ustawiła je tył na przód, a później przez dłuższy czas próbowała naprawić problem w taki sposób, żeby — delikatnie mówiąc — za bardzo się przy tym nie narobić.

Po czasie okazało się, że urządzenia pracują z prefiksami IN/OUT i wszystko wskazywało na to, że firma odpowiedzialna za ich montaż sama nie do końca zdawała sobie z tego sprawę.

Na szczęście dwóch Ninjów wpadło na pomysł, żeby zrobić rzecz niezwykle zaawansowaną technologicznie:

zeskanować kod do Notatnika.

I nagle zaczęło być wiadomo, co właściwie bramka czyta.

Potem odkryliśmy kolejny fascynujący element infrastruktury IT.

Windows domyślnie bardzo rozsądnie oszczędza energię.

To świetna funkcja.

Chyba że komputer sterujący bramką stoi w namiocie, pośrodku parkingu, przy kilkunastostopniowym mrozie.

Wtedy okazuje się, że usypianie urządzeń odpowiedzialnych za kontrolę wejścia może nie być najlepszym pomysłem świata.

A później przyszły większe mrozy.

I wyszło na jaw, że mini-PC zamknięte w metalowych skrzynkach potrafią po prostu przymarzać i przestawać działać.

Czy ktoś to wcześniej przewidział?

Oczywiście, że nie.

Ogólnie: masakra.

Z perspektywy czasu była to jedna z tych decyzji, przy których bardzo łatwo wpaść w klasyczną pułapkę:

Skoro już za coś zapłaciliśmy, to teraz musi działać.

Więc zamiast wyrzucić problem, zaczęliśmy go rozwiązywać.

A później rozwiązywać problemy powstałe podczas rozwiązywania pierwszego problemu.

A później kolejne.

I właśnie wtedy system zaczął naprawdę rosnąć.

Dlaczego w ogóle o tym piszemy?

Bo z perspektywy wdrożeń to nie jest tylko zabawna historia o bramkach stojących na mrozie.

To doświadczenie, za które zapłaciliśmy pieniędzmi, czasem i sporą liczbą godzin spędzonych na szukaniu problemów, które teoretycznie powinien rozwiązać ktoś inny.

Kiedy coś przestawało działać, bardzo szybko okazywało się, że odpowiedzialność potrafi krążyć pomiędzy producentem sprzętu, instalatorem, oprogramowaniem i kolejnymi elementami integracji.

A klient nadal stoi przed bramką.

I nadal nie może wejść.

Wtedy przestaje mieć znaczenie, czyj to formalnie problem.

Ktoś musi znaleźć przyczynę.

Sprawdzić, co naprawdę wysyła czytnik.

Zobaczyć, co dostaje system.

Prześledzić konfigurację.

Rozebrać proces na kawałki.

I doprowadzić go z powrotem do działania.

My już tę drogę przeszliśmy.

Wiemy, jak te elementy współpracują, gdzie szukać problemów i jak sprawdzać je wtedy, kiedy dokumentacja, konfiguracja albo odpowiedź serwisu nie daje rozwiązania.

Dlatego dzisiaj, kiedy wdrażamy system u klienta, nie kończymy pracy na zdaniu:

„To chyba problem po stronie urządzenia.”

Jeżeli urządzenie jest elementem procesu, próbujemy ustalić, dlaczego cały proces nie działa.

Bo dla klienta nie istnieje osobno bramka, aplikacja, serwer i system sprzedażowy.

Dla klienta istnieje tylko jedno pytanie:

„Czy mój klient może kupić bilet i wejść?”

Gotowy silnik spotkał prawdziwy obiekt

Podstawowe funkcje były.

Problem polegał na tym, że „system potrafi sprzedać bilet” i „system działa wygodnie w obiekcie obsługującym setki klientów” to dwie zupełnie różne rzeczy.

Zaczęliśmy więc dodawać brakujące elementy.

Kody QR

Klient po zakupie otrzymuje kod QR.

Nie musi drukować biletu.

Nie musi podawać nazwiska.

Nie musi szukać numeru zamówienia.

Przychodzi z telefonem.

I tyle.

Skanowanie kodów praktycznie dowolnym urządzeniem

Kod można zeskanować telefonem, tabletem albo komputerem wyposażonym w kamerę.

Nie chcieliśmy tworzyć sytuacji, w której recepcja musi kupić kolejny specjalistyczny czytnik tylko dlatego, że wdrożyliśmy system mający upraszczać jej pracę.

Bezpośrednie wejście przez bramkę

Jeżeli dany obiekt wykorzystuje kontrolę dostępu, kod może zostać użyty również bezpośrednio przy bramce.

W najprostszym wariancie ścieżka wygląda więc tak:

zakup → e-mail → QR → bramka → wejście.

Prościej naprawdę trudno to zrobić.

Nawet bilet nie musi wyglądać jak z systemu księgowego z 2007 roku

W pewnym momencie zaczęliśmy zwracać uwagę również na rzeczy, które z technicznego punktu widzenia wydają się kosmetyką.

Tylko że dla klienta kosmetyką już nie są.

Standardowy system może wygenerować poprawny bilet.

Ma kod.

Ma numer.

Ma datę.

Działa.

I wygląda jak kupa.

Dlatego dokładaliśmy własne style CSS i warstwę wizualną, dzięki której bilety mogą być zgodne z identyfikacją konkretnej marki, czytelne, estetyczne, a tam, gdzie ma to sens, również wzbogacone o dodatkowe elementy wizualne i animacje.

Bo moment zakupu jest częścią doświadczenia klienta.

Nie powinien nagle wyglądać tak, jakby użytkownik opuścił stronę firmy i wszedł do panelu administracyjnego hurtowni śrub.

Klient nie powinien zauważyć, że zmienił system

Z tego samego powodu dołożyliśmy kolejną warstwę interfejsu.

Po przejściu z witryny obiektu do procesu sprzedażowego użytkownik nadal powinien czuć, że znajduje się w tym samym miejscu.

Najlepiej również — w obrębie tej samej domeny marki.

To może wydawać się detalem technicznym, ale z punktu widzenia klienta ma znaczenie. Kliknął „Kup bilet” na stronie konkretnego obiektu. Nie powinien chwilę później zobaczyć obcego adresu, zupełnie innej identyfikacji i zacząć zastanawiać się:

„Czy ja nadal kupuję bilet w Hit2Fit?”

Da się tego uniknąć.
Trzeba tylko czasem trochę pogrzebać w DNS-ach, certyfikatach i wyjątkach u providera. 😊
Brzmi technicznie, ale efekt dla klienta jest bardzo prosty: nadal czuje, że jest na tej samej stronie i w tej samej marce.

Dzięki temu warstwa sprzedażowa może działać technicznie w innym środowisku, ale dla użytkownika nadal pozostaje częścią strony konkretnej marki.

Do tego zachowujemy elementy identyfikacji wizualnej, własne style, nawigację czy dodatkowy pasek interfejsu pozwalający wrócić do pozostałych części serwisu.

Efekt?

Klient zaczyna na stronie obiektu, przechodzi do zakupu, płaci, dostaje bilet i ani przez moment nie musi zastanawiać się, jaki system właśnie obsługuje jego transakcję.

Technicznie pod spodem mogą pracować różne aplikacje, serwery i usługi.

Klienta nie powinno to obchodzić.

Dla niego nadal jest to jeden proces zakupowy i jedna marka.

I właśnie tutaj zaczęliśmy dochodzić do jednej z najważniejszych zasad całego projektu:

A później zaczęliśmy dokładać rzeczy absurdalnie szczegółowe

Każdy kolejny miesiąc działania obiektu przynosił nowe przypadki.

Czasami bardzo specyficzne.

Na przykład mechanizmy pozwalające rozliczać określone rodzaje karnetów nawet z dokładnością do minut.

Czy każdy klient tego potrzebuje?

Oczywiście, że nie.

Czy istnieje proces biznesowy, w którym jest to potrzebne?

Okazało się, że tak.

I takich rzeczy zaczęło przybywać.

Nowe formularze.

Dodatkowe panele.

Inne sposoby realizowania voucherów.

Obsługa zewnętrznych kanałów sprzedaży.

Kontrola wejścia.

Raportowanie.

Niestandardowe reguły.

Kolejne integracje.

Gotowy silnik przestał być po prostu gotowym systemem.

Stał się bazą, na której zaczęliśmy budować rozwiązania wynikające z rzeczywistych problemów operacyjnych.

Aż w końcu zorientowaliśmy się, że trochę przesadziliśmy

W pewnym momencie można było spojrzeć na cały zestaw funkcji i powiedzieć:

mamy kombajn.

System potrafił coraz więcej.

I początkowo byliśmy z tego bardzo zadowoleni.

Tylko że później pojawiła się niewygodna obserwacja:

większość klientów nie potrzebuje całego kombajnu.

Właściciel sali zabaw nie budzi się rano z myślą:

„Potrzebuję bardziej rozbudowanej warstwy danych.”

On budzi się z problemem:

„Ludzie kupują voucher przez Prezent Marzeń, a później pięć razy dziennie dzwonią do recepcji, żeby zarezerwować termin.”

Manager obiektu nie mówi:

„Chciałbym kolejny panel administracyjny.”

Mówi:

„Układanie grafików pracowników zajmuje mi pół dnia.”

Recepcjonista nie potrzebuje informacji, jak działa integracja.

Potrzebuje:

„Klient pokazuje kod. Ja go skanuję. Jest zielone. Wchodzi.”

I właśnie wtedy zmienił nam się sposób myślenia.

Nie pytamy już: „co jeszcze możemy dodać?”

Zaczęliśmy zadawać inne pytanie:

Co możemy zabrać z pracy człowieka?

To jest dzisiaj dużo ważniejsze niż liczba funkcji.

Jeżeli jakiś proces wykonuje się codziennie ręcznie, próbujemy go skrócić.

Jeżeli informacja może przejść automatycznie, człowiek nie powinien jej przepisywać.

Jeżeli klient może sam wybrać termin, nie powinien dzwonić.

Jeżeli kod QR może otworzyć bramkę, nie ma potrzeby tworzyć kolejnego stanowiska do jego sprawdzania.

A jeżeli manager spędza wiele godzin na tworzeniu grafików pracowników, być może rozwiązaniem nie jest kolejny raport sprzedażowy.

Być może trzeba automatycznie układać grafik.

I dokładnie takie rzeczy zaczęły pojawiać się później.

System ma być skomplikowany po naszej stronie

To chyba najważniejszy wniosek z całej tej historii.

Pod spodem możemy mieć dziesiątki modułów, zależności, integracji, ustawień i wyjątków.

To nasz problem.

Klient powinien dostać tylko te elementy, które są potrzebne w jego firmie.

Nie wdrażamy całego systemu dlatego, że system go posiada.

Najpierw patrzymy:

jak działa biznes?

gdzie ludzie tracą czas?

gdzie pojawiają się błędy?

gdzie klient wykonuje niepotrzebny krok?

co można usunąć?

Dopiero później wybieramy technologię i konfigurujemy odpowiednie moduły.

Bo automatyzacja ma powodować, że człowiek wykonuje mniej pracy.

Jeżeli po wdrożeniu musi wykonywać jej więcej, coś poszło nie tak.

Co właściwie potrafi ten kombajn?

Nie wszystkie poniższe funkcje powstały dlatego, że któregoś dnia uznaliśmy, że „fajnie byłoby je mieć”.

Większość pojawiała się dlatego, że gdzieś na obiekcie istniał konkretny problem.

Klient chciał kupić dwie różne atrakcje. Recepcja musiała zweryfikować ulgę. Manager chciał ograniczyć rabaty kasjerów. Groupon sprzedawał voucher, ale nie dawał mechanizmu rezerwacji. Ktoś potrzebował karnetu rozliczanego nie wejściami, tylko minutami.

I wtedy pojawiało się nasze ulubione:

„A dałoby się…?”

Najczęściej się dało.

Wiele stref w jednym systemie

To jedna z rzeczy, które przy dużym obiekcie wydają się oczywiste dopiero wtedy, kiedy próbujesz je rzeczywiście wdrożyć.

Klient nie zawsze kupuje „bilet do obiektu”.

Może kupić trampoliny. Potem kręgielnię. Inną strefę. Dodatkową atrakcję. Albo kilka różnych produktów podczas jednej wizyty.

Dlatego system pozwala obsługiwać wiele niezależnych stref w ramach jednego środowiska sprzedażowego.

Każda może mieć własne bilety, ceny, zasady wejścia i dostępność, ale dla klienta nadal pozostaje częścią jednego obiektu.

Nie musimy budować osobnego systemu sprzedaży dla każdej atrakcji.

Uprawnienia pracowników naprawdę na poziomie operacyjnym

„Administrator” i „pracownik” bardzo szybko przestają wystarczać.

Możemy tworzyć własne grupy użytkowników — recepcję, kasjerów, managerów, kierowników czy administrację — a później szczegółowo określać, co konkretna osoba może zrobić.

Kasjer może przyjąć dostawę, ale nie może jej później edytować.

Może udzielić rabatu, ale tylko do określonego poziomu.

Możemy ograniczyć nawet liczbę określonych operacji wykonywanych w ciągu dnia.

Dzięki temu pracownik dostaje narzędzia potrzebne do pracy, ale nie dostęp do połowy firmy tylko dlatego, że musi sprzedać bilet.

Jeden system, wiele obiektów

Ten sam operator może prowadzić kilka budynków, oddziałów albo obiektów w różnych miastach.

System pozwala je rozdzielić operacyjnie, a jednocześnie zarządzać nimi w ramach jednego środowiska.

To istotne szczególnie wtedy, kiedy biznes zaczyna się skalować.

Pierwszy obiekt nie musi oznaczać pierwszego i ostatniego.

Pieniądze trafiają bezpośrednio do klienta

Nie chcieliśmy modelu, w którym operator systemu stoi pomiędzy firmą a jej pieniędzmi.

Dlatego możemy podłączyć rachunek i operatora płatności klienta.

Środki ze sprzedaży trafiają bezpośrednio do przedsiębiorcy, a nie na wirtualne saldo platformy oczekujące na okresową wypłatę.

Nie dokładamy też własnej prowizji procentowej od każdej transakcji.

Jeżeli klient korzysta z operatora płatności, pozostają oczywiście jego opłaty transakcyjne. W niektórych wdrożeniach możemy również pomóc przy wyborze i negocjowaniu warunków operatora.

Tu tylko przed publikacją wpisałbym konkretną stawkę typu 0,5% dopiero wtedy, kiedy mamy pewność, że możemy ją uczciwie komunikować jako realnie osiągalną, a nie gwarantowaną każdemu.

POS, bufet, kawiarnia i sprzedaż dodatkowa

Obiekt sportowy czy rekreacyjny rzadko kończy się na bilecie.

Może mieć kawiarnię, bufet, sklepik albo inne punkty sprzedaży.

Możemy obsługiwać je w tym samym środowisku.

I tutaj zaczynają pojawiać się ciekawe scenariusze integracyjne.

Przykładowo zeskanowanie biletu może nie tylko zweryfikować wejście, ale również uruchomić konkretną akcję — np. oznaczyć przysługujący klientowi produkt, świadczenie albo element pakietu.

Bo skoro informacja już istnieje w systemie, nie ma sensu przepisywać jej po raz drugi na kartkę.

Happy hours, promocje i elastyczne reguły sprzedaży

Promocja nie musi oznaczać ręcznego zmieniania ceny w poniedziałek rano i przypominania sobie w piątek, żeby ją przywrócić.

Możemy budować reguły zależne od czasu, produktu, kanału sprzedaży czy konkretnej grupy klientów.

Happy hours.

Czasowe promocje.

Ograniczona liczba kodów.

Inna cena online i inna przy kasie.

System powinien wykonywać regułę, a nie wymagać od człowieka, żeby o niej pamiętał.

Bramka może powiedzieć obsłudze więcej niż „tak” albo „nie”

Kontrola dostępu nie musi kończyć się na zielonej lampce.

Przy bramkach mogą pracować monitory wyświetlające komunikaty zależne od rodzaju biletu.

Dobry przykład to bilet ulgowy.

Klient może kupić go online, ale obsługa nadal musi mieć możliwość zweryfikowania dokumentu potwierdzającego ulgę.

System może więc wyświetlić odpowiedni kolor lub komunikat, dzięki któremu pracownik od razu widzi:

ten bilet wymaga dodatkowej kontroli.

Nie trzeba zatrzymywać wszystkich.

Nie trzeba również liczyć na to, że pracownik sam domyśli się rodzaju biletu.

A kiedy nikt nie przechodzi?

Ten sam ekran może stać się powierzchnią informacyjną lub reklamową.

Sprzęt, który już stoi przy wejściu, nie musi przez większość dnia wyświetlać czarnego prostokąta.

Urodziny to nie tylko rezerwacja terminu

Sam mechanizm rezerwacji urodzin jest dziś czymś stosunkowo standardowym.

Ale proces może sięgać znacznie dalej.

Pakiet.

Termin.

Liczba uczestników.

Dodatkowe usługi.

A później lista gości i wymagane zgody.

Jeżeli rodzic musi wyrazić zgodę na udział dziecka w konkretnej aktywności, możemy przenieść również ten element procesu do systemu.

Dzięki temu organizator i obsługa nie muszą zarządzać osobnym plikiem, papierową listą i stosem formularzy.

Online może kosztować inaczej niż przy kasie

Bilet sprzedawany w internecie i ten sam bilet kupowany na miejscu nie muszą mieć identycznej ceny.

To daje możliwość świadomego przenoszenia części ruchu do kanału online.

Jeżeli zakup internetowy zmniejsza kolejkę, obciążenie recepcji i ilość ręcznej pracy, przedsiębiorca może premiować klienta za wybranie właśnie tej ścieżki.

To już nie jest tylko funkcja sprzedażowa.

To sposób sterowania procesem operacyjnym.

Karnet na 700 minut? Dlaczego nie.

Karnet nie musi oznaczać:

10 wejść.

20 wejść.

Miesiąc bez limitu.

Może oznaczać również pulę czasu.

Przykładowo klient kupuje 700 minut i przy kolejnych wizytach system odejmuje faktycznie wykorzystany czas.

537 minut zostało?

To zostało 537.

Bez zaokrąglania całej wizyty do kolejnego wejścia tylko dlatego, że tak łatwiej było zaprojektować bazę danych.

To jest właśnie dobry przykład funkcji, której większość klientów nigdy nie będzie potrzebowała.

Ale klient, który jej potrzebuje, potrzebuje jej bardzo.

Groupon, Prezent Marzeń i vouchery zewnętrzne bez telefonu do recepcji

To jeden z moich ulubionych przykładów.

Zewnętrzna platforma potrafi świetnie sprzedać voucher.

Po czym kończy swoją część procesu.

Klient ma voucher.

Teraz chce zarezerwować termin.

I dzwoni.

Do recepcji.

Czasami nawet nie do tej recepcji, do której powinien. 🙂

Dlatego możemy budować dedykowane formularze realizacji voucherów z zewnętrznych kanałów.

Klient podaje kod, wybiera usługę i dostępny termin.

Recepcja nie musi po raz kolejny odbierać telefonu tylko po to, żeby ręcznie przepisać informacje do systemu.

Zajęcia, trenerzy, sekcje i grupy

Tu sam mechanizm jest bardziej klasyczny, ale ważna jest jego integracja z resztą środowiska.

Możemy tworzyć zajęcia, przypisywać trenerów, budować grupy i sekcje oraz kontrolować zapisy i dostępność miejsc.

Klient zapisujący dziecko do sekcji nie musi trafiać do zupełnie innego rozwiązania tylko dlatego, że wcześniej kupował na tej samej stronie bilet na inną atrakcję.

Ograniczone pule kodów i voucherów rabatowych

Kod rabatowy nie musi być wieczny i dostępny dla wszystkich.

Możemy powiedzieć:

jest 50 voucherów.

Kto pierwszy, ten lepszy.

Po wykorzystaniu pięćdziesiątego kodu promocja przestaje być dostępna.

Możemy oczywiście dołożyć daty obowiązywania, konkretne produkty i inne warunki.

To pozwala robić prawdziwe akcje limitowane bez ręcznego pilnowania, czy przypadkiem nie sprzedaliśmy już 63 „pierwszych 50 sztuk”.

Dane marketingowe nie kończą się na przycisku „Kup”

Pixel, GTM i warstwa danych same w sobie nie są szczególnie romantyczną częścią systemu.

Ale są potrzebne, jeżeli marketing ma wiedzieć, co rzeczywiście wydarzyło się w procesie zakupowym.

Możemy więc przekazywać odpowiednie zdarzenia do narzędzi analitycznych i reklamowych.

Dzięki temu kampania nie kończy się na informacji:

„ktoś kliknął przycisk”.

Możemy mierzyć rzeczywiste zdarzenia sprzedażowe.

Raporty, BI i ta część, przy której marketingowiec zaczyna patrzeć przez okno

System posiada również rozbudowaną warstwę raportową.

Sprzedaż, produkty, okresy, kanały, wykorzystanie usług i dane operacyjne mogą być analizowane w raportach, a dodatkowe potrzeby możemy obsługiwać również przez rozwiązania BI.

Powstały też dodatkowe elementy związane z księgowością i rozliczeniami.

Tutaj uczciwie:

to jest ta część systemu, przy której autor tego tekstu zaczyna tracić zainteresowanie światem.

Na szczęście księgowi mają dokładnie odwrotnie.

I dlatego również te elementy rozwijaliśmy zgodnie z potrzebami ludzi, którzy rzeczywiście z nich korzystają.

Nie wszystko w systemie musi ekscytować programistę albo marketingowca.

Ma działać osobie, która tego potrzebuje.

CRM nie musi kończyć się na danych klienta

Warstwa operacyjna zaczęła z czasem obejmować również pracowników.

Możemy rejestrować wejścia i wyjścia pracowników, a na tej podstawie rozliczać czas pracy.

Do tego dochodzą grupy pracowników, uprawnienia oraz grafiki.

I tutaj właśnie pojawił się kolejny duży kierunek automatyzacji:

Kiedy wypiszemy te funkcje jedna pod drugą, znowu łatwo dojść do wniosku:

„Ale to jest wielki system.”

Jest.

Tylko że dokładnie odwrotnie powinniśmy myśleć o jego wdrożeniu.

Klient prowadzący niewielką salę zabaw nie potrzebuje systemu Hit2Fit.

Potrzebuje swoich urodzin, swoich voucherów, swojej kasy i swojego problemu z grafikami.

Aquapark może potrzebować bramek, minutowych karnetów i bufetu.

Sieć kilku obiektów może potrzebować lokalizacji, zaawansowanych uprawnień i BI.

Nie sprzedajemy klientowi wszystkich funkcji.

Mamy wszystkie te funkcje po to, żeby móc wybrać kilka, których akurat potrzebuje.

I jeżeli potrzebnej funkcji jeszcze nie ma?

Cóż.

Historia tego systemu pokazuje, że wtedy najczęściej zaczyna się kolejne:

„A dałoby się…?”