Ten tekst jest dodatkiem do tekstu „Jak powstawało Zilo” – najpierw przeczytaj o Zilo zanim zabierzesz się za Autobooking :)
To co robimy dalej?
Po wdrożeniu Zilo zrobiliśmy półtoramiesięczny refactor, aby po sobie posprzątać. To była praca dla programistów, ale mi dała czas na zastanowienie się, co powinniśmy robić przez następne kwartały.
Od początku wiedzieliśmy, że Zilo nie jest celem samym w sobie. To fundament, na bazie którego możemy budować kolejne nowe rzeczy.
Bogatszy o wnioski po starcie Zilo przedstawiłem w połowie czerwca 2021 cztery najważniejsze kierunki rozwoju. Każdy z nich w różny sposób wpływał na naszą skalowalność, jakość obsługi, UX i lojalność klientów. Wśród moich propozycji największą popularnością cieszył się Autobooking – system automatycznego i natychmiastowego zapisywania się na wizyty.
Poniższy wpis opisuje nasze zmagania z jego stworzeniem i wdrożeniem.
Ps. Jeszcze mała uwaga zanim zaczniemy: ten wpis to ekstremalnie szczegółowy opis fragmentu większego ekosystemu produktowego, Przez swoją egzotykę może się okazać, że nie jest wprost aplikowalny na Wasze produkty. Rozważałem jego skrócenie, aby był łatwiejszy w konsumpcji, ale uznałem, że w ten sposób straci na wiarygodności. Zostaliście ostrzeżeni!
Proces rezerwacji wizyty
Tak jak wspominałem w kejsie Zilo, „pod spodem” Dobrego Mechanika jest Biuro Obsługi Klientów. Każdy do tej pory wypełniony formularz wizyty na naszym portalu trafiał do panelu, w którym pracownik BOKu przypisuje zlecenie do siebie. Później dzwoni do warsztatu, aby upewnić się, że termin wskazany przez kierowcę jest wolny. Jeśli tak, to kierowca dostaje potwierdzenie wizyty. Jeśli nie, to BOK szuka alternatywnego warsztatu i/lub terminu.
Ten proces ma swoje oczywiste wady:
- Nie mamy faktycznego podglądu na to, kiedy warsztat ma wolny czas na nowych klientów. BOK rozmawia z mechanikami, ale nasza wiedza jest pobieżna i szybko się dezaktualizuje,
- W związku z tym proponowane terminy wizyt to nasza ogólna sugestia, a w czasie szczytów (wymiana opon, klimatyzacja) pobożne życzenia,
- Negocjowanie między kierowcą a warsztatem wymaga czasu i nadprogramowej komunikacji. Czasami potrzeba kilku godzin lub doby, aby kierowca dostał potwierdzenie wizyty,
- W konsekwencji bywało tak, że wszyscy pracownicy zajmowali się dzwonieniem do warsztatów i klientów, aby obsłużyć zlecenia lub badania satysfakcji z usług,
- Komunikacja statusu zlecenia potrafi być źle zrozumiana: nasze potwierdzenie zarejestrowania polecenia umówienia od kierowcy może być brana za potwierdzenie, że doszło do faktycznego umówienia wizyty. Wszyscy się frustrują: kierowcy są zagubieni, warsztatom trafiają się niezapowiedziani kierowcy, a nam przysparza to dodatkowej pracy i obniża zaufanie do marki
Wprowadzaliśmy mechanizmy usprawniające prace nad umówieniem wizyty, ale wszystkie ostatecznie rozbijały się o konieczność dodzwonienia się do warsztatu (co w sezonie potrafi być bardzo trudne). Dopóki nie wyeliminujemy etapu rozmowy nie uda nam się wprowadzić prawdziwej zmiany.
Zilo i Autobooking
Wprowadzenie Zilo wszystko zmieniło. Jego głównym celem było łatwiejsze zarządzanie wizytami w warsztacie, ale przy okazji dawało nam wiedzę o tym gdzie i kiedy warsztaty mają puste przebiegi, a więc czas na obsługę naszych klientów.
Skoro widzimy kalendarze warsztatów to możemy też je przetworzyć na sloty czasowe, wrzucić na portal DM a co najważniejsze: w czasie rzeczywistym aktualizować dostępność czasów i usług warsztatu. Pytanie tylko jak to zrobić, aby dać duży wybór slotów czasowych dla kierowców nie rezygnując z prostoty korzystania z systemu dla warsztatów.
Gdy zacząłem rozważać ten projekt pojawiły mi się dwa fundamentalne problemy:
1. Nie mamy pewności, czy to, co mechanicy ustawią w Zilo, odpowiada rzeczywistości (np. czy mają tyle samo stanowisk w Zilo co w rzeczywistości?)
2. Różne usługi mechaniczne mają różne charakterystyki. Do niektórych potrzebne są części zamienne, niektóre wymagają oddzielnego stanowiska, niektóre da się zrobić od ręki, inne trwają dniami.
W tej sytuacji zbudowanie prostego w konfiguracji systemu zarówno po stronie warsztatu jak i prostego w bookingu po stronie kierowcy graniczyło z cudem. Rozwiązaniem było, jak zwykle, rozpoczęcie od wykrojenia ze wszystkich wymagań najmniejszej możliwej działającej wersji.
MVP1: Opony
Co byłoby najmniejszą działającą wersją Autobookingu? Co moglibyśmy obciąć jako pierwsze? Postanowiłem spojrzeć na jakie usługi w ogóle umawiają się kierowcy i pokategoryzować je pod względem trudności w wymodelowaniu biznesowo-technicznym. Wytypowałem trzy grupy:
- wymiana opon,
- usługi fast-fit (olej, klocki hamulcowe, klimatyzacja itp.)
- cała reszta (usługi złożone, wieloetapowe bądź nie-wiadomo-o-co-chodzi)
Wymiana opon teoretycznie powinna wpadać w kategorię fast-fit, ale praktycznie stanowi kategorię samą dla siebie. Przede wszystkim to rutynowa usługa: przyjeżdża się na konkretną godzinę i wyjeżdża kilkadziesiąt minut później z załatwioną sprawą. To powoduje, że jest najbardziej podobna do wizyty u fryzjera czy lekarza, które wiemy, że są łatwe do umawiania online – czego przykładem jest Booksy czy ZnanyLekarz.
Zdecydowane: pierwsza wersja Autobookingu skupi się na oponach.
Co jeszcze możemy wyciąć? W każdym systemie rezerwacyjnym i kalendarzowym problemem jest odpowiednie wyważenie relacji między dokładnością ustawień a poziomem kontroli nad sytuacją. Przykład: Jak duże „skoki” czasowe są możliwe w systemie (co 1 minutę, co 15? Co 30?), czy ustawiewienia są globalne czy dopuszczają wyjątki (święta, urlopy, nieoczekiwane sytuacje)? Im więcej reguł do reguł (lub wyjątków od wyjątków) dodane do systemu tym potencjalnie lepsze dopasowanie do specyficznych wymagań użytkownika… ale także coraz większe ryzyko, że nie odnajdzie się w gąszczu możliwości i ucieknie zdezorientowany.
Posprawdzałem znane mi systemy bookingowe z różnych branż, popytałem znajomych którzy siędzą w podobnych tematach. Ostatecznie postanowiłem rozpocząć z bardzo kontrowersyjną wersją minimum:
- Nie było możliwości ustawiania urlopów, a ustawione godziny dotyczyły każdego dnia tygodnia
- ustawienia godzin dostępności były aplikowalne uniwersalnie na każdy dzień tygodnia: jeśli ktoś ustawił 9:00-16:00, to w każdy dzień gdy warsztat był otwarty obowiązywała 9:00-16:00
- nie było możliwości ustawiania dwóch przedziałów czasowych w ciągu jednego dnia, np. 9:00-12:00 i 14-16:00
W ten sposób maksymalnie uprościliśmy interfejs konfiguracji w Zilo. Warsztat nie musiał konfigurować dostępności różnych usług oddzielnie (bo miał tylko jedną opcję – opony). Każde stanowisko mogło być ustawiane oddzielnie. Po przełączeniu dostępności pojawiały się proste dropdowny z godzinami „od” i „do” i już.
W trakcie prac developerskich nad ustawieniami okazało się, że dobudowanie różnych godzin w różne dni nie będzie trudne, a da dużą wartość warsztatom, więc szybko wprowadziliśmy taką opcję:
Tak skonfigurowana dostępność była wizualnie reprezentowana na ekranie głównym kalendarza – niebieskie pola oznaczają czas, który DobryMechanik uzna za dostępny dla klientów portalu.
Stał przed nami jeszcze jeden problem: skąd będziemy wiedzieć jak godziny dostępności pokazywane przez warsztat będą przeliczać się na „sloty” na które umawia się kierowca? Inaczej mówiąc: czy warsztat, który zaznaczy, że przyjmuje naszych kierowców codziennie od 9:00 do 13:00 jest w stanie przyjąć 4 wizyty co godzinę, 8 godzin co pół godziny czy jeszcze inaczej?
Do tego dochodzi fakt, że wymiana opon wymianie opon nierówna. Są takie, które da się załatwić przy pomyślnych wiatrach w 25 minut i takie, które trwają 45 minut i więcej. Tutaj miałem najtrudniejszą decyzję do podjęcia:
- mogłem dać warsztatom opcję konfigurowania czasu każdego typu usług oponiarskich oddzielnie,
- mogłem zrównać wszystkie usługi do jednego wspólnego czasu
Opcja pierwsza byłaby niezgodna z ideą tworzenia MVP więc znów zaryzykowałem i ustawiliśmy globalnie każdą usługę na 30 minutowy slot czasowy. Wiedziałem, że część wizyt potrwa dłużej (nie wiedziałem tylko jak duży to będzie procent) ale ufałem, że warsztaty mimo wszystko sobie z tym poradzą.
Plusy natomiast były oczywiste: znów nie trzeba nic konfigurować, a każda godzina dostępności to po prostu dwa sloty na portalu widoczne dla kierowcy.
Zastanawiałem się ciągle czy dobrze robimy. Czy warsztaty nie uznają tego za wylewanie dziecka z kąpielą? Opinie były podzielone, ale wiedziałem, że łatwiej skomplikować prosty system niż uprościć już złożony.
Kalendarz zagłady
Kalendarze bookingowe, konfiguratory podróży, formularze rejestracyjne – wszystko to systemy wydają się tak oczywiste, że wręcz nudne. Co tam może być ciekawego? Też tak myślałem, do czasu aż zostałem zmuszony do zaprojektowania własnego.
Na tym etapie mamy określone dwie kwestie:
- preferencji warsztatu co do godzin jego dostępności na usługi z DM
- Typ usługi oraz czas jej trwania (30 minut)
W efekcie każda godzina dostępności była szatkowana na 30 minutowe przestrzenie. To stanowi fundament naszej logiki:
Pojawia się pytanie: Co powinno być w miejscu, które wskazuje strzałka?
Następny etap to określenie tego, co powinno być po prawej stronie tej strzałki, czyli prezentacja dla kierowcy siatki godzin do wybrania.
Miałem przekonanie, że nie chcemy wymyślać koła na nowo: wykorzystamy to, do czego użytkownicy Internetu są przyzwyczajeni od lat: tabelkę z siatką przycisków, a każdy przycisk reprezentował 30 minutowy slot.
Gdy kierowca wybierze jeden z tak zaprezentowanych slotów (i wypełni resztę wymaganych danych) to rezerwuje wizytę. Pod spodem następuje komunikacja między Autobookingiem a Zilo. Wizyta zostaje „przesłana” do kalendarza Zilo (punkt 4), a ten potwierdza, że dane kierowcy są prawidłowe* i dodaje wizytę do kalendarza warsztatu.
* Notka architektoniczna. W dużym skrócie ta weryfikacja danych to nie tylko kwestia bezpieczeństwa. Problem jaki mieliśmy to różne wymogi wobec tego jakie dane potrzebuje DobryMechanik, a jakie Zilo. Na przykład w DM nie był wymagany nr rejestracyjny samochodu a w Zilo już tak. Dzięki niemu możemy zweryfikować (nie)powtarzalność samochodu w bazie. Na tej podstawie wiemy, czy mamy do czynienia z powracającym kierowcą z tym samym samochodem, powracajacym kierowcą z nowym samochodem lub zupełnie nowym kierowcą. W zależności od tego, który z tych scenariuszy zostanie wybrany inaczej dopisujemy dane do bazy klientów warsztatu
Po dodaniu wizyty Zilo musi jeszcze poinformować Autobooking, że jedno miejsce wypada z listy wszystkich możliwości (punkt 5). To oznacza, że Autobooking uniemożliwia zapisanie się na ten slot innym kierowcom.
Gdy poradziliśmy sobie z fundamentami naszej logiki zaczęły pojawiać się pytania natury UXowej:
- Jeśli dany slot jest zajęty to ma być wyszarzony czy powinien zniknąć z listy? A jesli zniknąć to od razu, czy dopiero po odświeżeniu strony?
- Czy jeśli w danym dniu warsztat nie pracuje (święto, urlop) to czy powinniśmy ten dzień pokazywać ze wszystkimi slotami zajętymi czy też z informacją, że nie przyjmuje? A może powinniśmy te dzień ukrywać?
- Czy jeśli warsztat ma pełny dzień zleceń i więcej od nas nie przyjmie to powinniśmy pokazywać wszystkie kratki z tego dnia jako pełne czy tylko jedną z informacją, że jest „pełne”?
Tutaj znów nie chciałem wymyślać koła na nowo i popatrzyłem jak robią to lepsi od nas. Moje wnioski: wygląda na to, że robią to inaczej niż moja pierwsza intuicja. Wiedziałem, że ma to swoje (jeszcze ukryte przede mną) powody. Postanowiłem wiec pójść za moją intuicją i na żywym organizmie przekonać się co robimy nie tak.
Moja intuicja mówiła mi, że kluczowe znaczenie będzie miała „stabilność” siatki terminów. Rozumiem przez to przewidywalność zachowania i ciągłość dat, jakiej ludzie spodziewają się po fizycznym kalendarzu. Jeśli widzimy klamkę do drzwi to wiemy, że powinniśmy ją nacisnąć, a nie na przykład popchnąć*.
* Notka UXowa. Nasze doświadczenia korzystania z fizycznych i cyfrowych obiektów są przez nas zapamiętywane i dodawane do modeli mentalnych skatalogowanych w głowie. Jeśli zachowanie przedmiotu nie zgadza się z modelem mentalnym (np. gdy po przekręceniu pokrętła z ciepłą wodą leci zimna) to mózg dostaje zgrzytu. Te małe pomoce – kształt klamki pasujący do dłoni naciskającej w dół, kolorowe oznaczenia temperatury wody itp. to tak zwane afordancje. Więcej o tym w książce Dana Normana „Design of everyday things”.
W związku tym mój pierwszy pomysł zakładał, że:
- Wszystkie dni będzie widoczny, także te bez wolnych terminów. Dzięki temu unikniemy sytuacji, w których po poniedziałku będzie piątek (bałem się, że ludzie z góry zakładają, że następny dzień po poniedziałku to będzie wtorek, a skoro go wytniemy z braku terminów to wprowadzimy kierowców w błąd, bo bez świadomości zapisać się na piątek, ale ze względu na wizualną odległość od poniedziałku pomyślą, że to wtorek)
- Sloty już zajęte będą się pokazywać, ale wyszarzone, aby uniknąć sytuacji, w których na różnych wysokościach siatki będą różne godziny (bałem się, że ktoś widząc na górze listy pierwszy wolny termin na 8:30 to założny z góry, że w kolejnym dniu też pierwszy wolny termin to będzie 8:30)
Te dwa założenia brzmią dobrze w teorii, ale szybko zostały zweryfikowane przez rzeczywistość. Warsztaty po prostu zdecydowały się zachowawczo podejść do Autbookingu i ustawiać np. tylko jeden dzień w tygodniu z dostępnością – co powodowało, że na kalendarzu Autobookingu były ogromne sześciodniowe dziury. Trzeba było dużo klikania, aby doszukać się pierwszego wolnego terminu. Wtedy zdecydowałem, że trzeba puste dni pochować.
Następnie okazało się, że warsztaty postanowiły poustawiać różne godziny dostępności w różne dni. I w ten sposób za okno wyleciała moja idea pokazywania tych samych godzin na tych samych wysokościach kalendarza.
Ostatecznie odwróciłem pierwotny pomysł o 180 stopni: pokazujemy tylko faktycznie dostępne terminy. `Teraz już wiem, dlaczego Znanylekarz i Booksy tak robią.
Na sam koniec nałożyliśmy na logikę dodatkowe zasady wpływające na widoczność terminów: w końcu nie powinno być możliwości na zapisanie się w dniach, które już minęły, lub nawet dzisiaj, ale godzinę temu. Następnie dołączyliśmy informację o urlopach, świętach i innych wydarzeniach, które pauzują działalność warsztatu.
Autobooking na portalu DM
Skoro uporaliśmy się z konfiguracją po stronie Zilo to czas zająć się portalem i tym, co powinien widzieć kierowca chcący zmienić opony.
Na portalu DM są (upraszając) trzy miejsca, z których można przejść proces rezerwacji wizyty:
- Listing warsztatów, gdzie box warsztatu pokazuje kilka promowanych usług
- Wizytówka: cennik w głównej części wizytówki warsztatu
- Wizytówka: formularz po prawej stronie wizytówki
Autobooking powinien być dostępny we wszystkich trzech. Była jednak zasadnicza różnica między tymi ścieżkami: w przypadku listy warsztatów z wyróżnionymi usługami oraz cennika usługa była od razu widoczna. Kliknięcie w „Umów wizytę” niosło ze sobą na następny etap formularza informację o tym, na jaką usługę chce się umówić kierowca.
Formularz natomiast jest uniwersalny – można umówić się na dowolną usługę po prostu opisując to, co jest zepsute. Nie mamy więc tutaj strukturalnej metody określenia czy usługa ma dotyczyć opon czy czegoś innego.
W przypadku listy i cenników postanowiliśmy w miejsce „umów wizytę” wstawić mini siatkę godzin, gdzie kliknięcie na dowolny kafelek przenosi do kolejnego etapu bookingu. W przypadku formularza zastosowaliśmy taby: w jednym będzie stary formularz a w drugim nowy, tylko dla opon. Dzięki temu nie zamykaliśmy użytkownikom drogi do starego systemu oraz do usług, które nie sa bezpośrednio związane z Autobookingiem. Poza tym postanowiliśmy chwalić się kluczową przewagą systemu: godziny dostępności były aktualizowane w czasie rzeczywistym a nie jako sugetowany termin jak we wcześniejszym rozwiązaniu.
Unowocześniony formularz dawał nam także nowe możliwości – na przykład lepsze ustrukturyzowanie danych. W starej wersji informacje o samochodzie wpisywało się w ramach jednego ciągu znaków. To powodowało, że mieliśmy w bazie duży chaos – nie uwierzylibyście na przykład na ile różnych sposobów można wpisać markę Renault… Aby temu zaradzić w nowej wersji zastosowaliśmy dropdowny z podpowiedziami dla marki, modelu i usługi. Dzięki temu mieliśmy większą kontrolę nad jakością danych.
Zapewniliśmy sobie też fallback na wszelki wypadek. Gdyby tylko okazało się, że coś jest nie tak z Autobookingiem (np. Zilo nie odpowiada więc nie można dać potwierdzenia, że wizyta jest umówiona) system automatycznie przełącza się na stary proces, więc zlecenie wpada do ręcznej obsługi przez nasz BOK.
Startujemy
Przebrnęliśmy przez zmiany w Zilo, stworzyliśmy logikę zapisywania się na sloty, mamy przygotowane formularze do nowego sposobu umawiania się. Wiedziałem, że tak duże, jednoczesne i wielopunktowe wdrożenie niesie ze sobą zwiększone ryzyko*. Jak zwykle, mimo naszych starań, pozostały rzeczy, których nie wiemy, że nie wiemy.
*Notka o zarządzaniu ryzykiem. Nassim Nicholas Taleb wielokrotnie udowodnił, że ryzyko wymyka się ludzkiej percepcji i nie potrafimy go odpowiednio szacować (nie słuchajcie szarlatanów, którzy uważają, że potrafią). Jak więc nim zarządzać skoro nie można go policzyć? Trzeba oddzielić ryzyko od potencjalnej szkody. Zamiast zastanawiać się jak duża jest szansa, że błąd wystapi należy wyobrazić się sytuację, w której to już się stało i zrozumieć jego konsekwencje. Na tej bazie przygotować środki zaradcze ZANIM błąd zaistnieje. Więcej o ryzyku w czworoksięgu Incerto NN Taleba. Dodatkowo polecam zapoznać się z modelem mentalnym pomagający myśleć o ryzyku w przyszłości: Pre-mortem.
Dlatego zależało mi, żeby przed startem mieć killswitch. Jedną flagę, którą można szybko przestawić w wypadku pokazania się krytycznego błędu, na który nie byliśmy gotowi. Moja polityka zakładała, że jeśli, na przykład, siatka godzin nie wyświetli się na portalu podczas szczytu sezonu to lepiej od razu wyłączyć całość autobookingu, cofnąć się do starego systemu i dopiero wtedy zastanawiać się, co poszło nie tak. Przy tej strategii jakoś lepiej mi się spało w nocy.
Po dwóch dniach testów, wdrożeniu analityki oraz killswitcha, wreszcie poczuliśmy, że jesteśmy gotowi. W nocy między 18 a 19 października 2021 rozpoczęliśmy wdrożenie w pierwszych 6 warsztatach wytypowanych przez nasz BOK. Już rano po wdrożeniu mieliśmy pierwsze bookingi z nowego systemu!
Na początku po jednym dziennie. Dodawaliśmy kolejne warsztaty do systemu, więc tych wizyt robiło się już po kilka na dobę. Sezon (zamarkowy pierwszym dużym poniedziałkowym skokiem) zaczął się 25 października 2021, czyli tydzień po naszym releasie i tydzień przed dniem Wszystkich Świętych. Autobooking był już technicznie dostępny, ale liczba wdrożonych warsztatów była zbyt mała, aby faktycznie zobaczyć realną zmianę. Na to potrzebowaliśmy prawie miesiąca.
Kiedy finalnie Autobooking osiągnął odpowiednią skalę to przyćmił nasze pierwotne oczekiwania. W pewnym momencie wizyty z Autobookingu stanowiły prawie 30% wszystkich zarejestrowanych wizyt.
Było coś magicznego w obserwowaniu jak siatka godzin dynamicznie się zmienia wyszarzając rezerwowane wizyty, a do naszego panelu wpadają wizyty z flagą „Autobooking”.
Efekty
W połowie grudnia, gdy już kurz trochę opadł, mieliśmy czas, aby zanalizować wyniki.
Konwersja urosła nam tak mocno, że nawet biorąc pod uwagę małą skalę, specyficzną grupę najlepszych warsztatów oraz prostą usługę, wydawała się podejrzanie wysoka. Długo szukałem jakiegoś błędu w agregacji danych, bo nie mogłem uwierzyć temu co widzę. Te wyniki były tak dobre, że każdy postronny racjonalny człowiek by je kwestionował. Żaden analityk biznesowy by ich apriori nie założył szacując potencjalny wpływ tego rozwiązania na naszą firmę.
Warsztaty, które zaufały nam w pełni i zgodziły sie na faktyczną implementację autobookingu szybko poczuły niesamowity efekt. Najlepszy z nich tylko jednego dnia miał do obsługi 30 wizyt z czego 27 pochodziło z naszego Autobookingu.
Tak jak się spodziewaliśmy Autobooking też w sporym stopniu odciążył nasze Biuro Obsługi Klientów, wtedy, kiedy tego najbardziej potrzebował.
Różnica jest dramatyczna. Przy standardowym umawianiu, czas realizacji (odległość czasowa między „datą zgłoszenia” a datą potwierdzenia terminu z warsztatem, która w naszej nomenklaturze nazywa się „datą zakończenia”) może trwać kilkanaście minut, a czasami nawet kilka godzin. Przy automatycznym umawianiu to dosłownie sekunda.
Finał naszej analizy powdrożeniowej można podsumować tak: znaleźliśmy naszą żyłę złota. Ale czy to co zrobiliśmy jest wystarczające? Skoro działa dobrze teraz to może tego nie ruszać i zająć się gaszeniem pożarów w (wielu) innych miejscach czy może wręcz przeciwnie: iść za ciosem i zwiększyć swoją inwestycję. Prowadziliśmy o tym dyskusje w managmencie i ostatecznie wygrał pomysł stworzenia kolejnej wersji Autobookingu. Argumentów „za” było dużo:
- Przyśpieszenie procesu rezerwacji to najczęściej powtarzająca się potrzeba kierowców w naszych ankietach i NPSach,
- Dobrze zrobiony Autobooking i wynikający z tego dobry UX spowoduje, że kierowcy będą do nas wracać w następnym sezonie, co zwiększy retencję a w konsekwencji wartość całego marketplace’u
- Ostatecznie to realna innowacja, która stanowi przewagę i strategiczną „fosę” do pokonania dla konkurencji
Zapadła więc jednomyślna decyzja: przesuwamy na później inne kluczowe projekty i skupiamy się całkowicie na następnej wersji Autobookingu z myślą o kolejnym sezonie. Później zrobiliśmy sobie długą przerwę regeneracyjną na święta i Sylwestra. Wraz z nowym rokiem przyszedł czas na Autobooking MVP2.
MVP2
Po ustabilizowaniu kodu i naprawie błędów zgłoszonych po premierze zaczęliśmy zastanawiać się co powinniśmy robić dalej.
Jeśli chodzi o definicje zakresu to nie było trudne zadanie: wystarczyło spojrzeć na długą listę funkcji, które wrzuciłem do worka „nie na teraz”. Czyli te, które zostały odrzucone na bok jako zbyt problematyczne, ale popularne wśród interesariuszy i zgłaszane przez użytkowników (kierowców i mechaników).
Najczęściej powtarzane było wymaganie: „obsługa innych usług oprócz wymiany opon”. Tak jak wspominałem na początku, opony były idealnym kandydatem na pierwszą wersję systemu – to usługi rutynowe, które umawia się na konkretną godzinę, a więc łatwe do wymodelowania i wpasowania w kalendarz Zilo. Wybraliśmy więc z historii portalu najpopularniejsze typy usług i szukaliśmy sposobu, aby dołączyć je do Autobookingu.
Co ciekawe, nowe usługi nie nastręczały większych problemów na etapie interakcji użytkownika z portalem – wystarczyło rozszerzyć formularz o nowe kategorie.
Problemy rozpoczęły się jednak na etapie obsługi zleceń przez warsztat. O ile zmiana opon odbywa się w tym samym momencie, co podstawienie samochodu, tak przy innych usługach te godziny mogą być różne.
Już podczas tworzenia Zilo natrafiliśmy na ten problem: mechanicy mówili nam, że kalendarz jest fajny, ale nie trafia w ich ulubiony tryb pracy, czyli:
- Każą wszystkim przyjechać „jutro rano”,
- O 8-10:00 rano patrzą jakie samochody stoją na parkingu,
- Decydują w jakiej kolejności najlogiczniej jest je zrobić biorąc pod uwagę części, intesywność pracy, zajętość stanowisk i to, kto najdłużej może poczekać.
W efekcie ktoś, kto podjechał o 8:30 może mieć naprawiony samochód o 13:00, inny, który podjechał o 9:00 wyjedzie o 16:00 a jeszcze inny podjeżdząc o 10:00 będzie miał wszystko załatwione o 12:00. Nie było jasnej reguły, wszystko było płynne i zależało od sytuacji w danej chwili.
Jak to problem rozwiązać?
Odliczanie do drugiej fali
Ścigaliśmy się z czasem. Firmowe OITy (to taka nasza wersja OKRów) na Q1 2022 zakładały, że na wiosenny sezon* wymiany opon będziemy mieć 3 razy więcej warsztatów z aktywnym nowym autobookingiem niż przy pierwszej wersji i sezonie zimowym. Biorąc pod uwagę uśrednione tempo dotychczasowych wdrożeń Autobookingu to oznaczało, że potrzebujemy 6 tygodni, a więc półtora miesiąca kalendarzowego, aby tego dokonać.
* Notka biznesowa. Sezony we wszystkich marketplace’ach to zawsze największa szansa i zagrożenie jednocześnie. W przypadku biznesu mechanicznego sezony są dwa: wiosenny i zimowy. Obydwa napędzane są zmianami opon. Wiosenny zazwyczaj jest dłuższy i ma łagodniejszy szczyt (na zimówkach da się jeździć także gdy jest ciepło). Sezon zazwyczaj zaczyna się z pierwszą falą ciepła i powoli rośnie wraz z sekwencją świąt (Wielkanoc), długich weekendów i wakacji, które łączą się ze wzmożonym przemieszczaniem się. Zimowy szczyt jest krótszy, bardzo agresywny – zaczyna się z pierwszymi przymrozkami z kulminacją zaraz przed Świętem Zmarłych.
Nauczeni doświadczeniem z poprzedniego sezonu wiedzieliśmy, że wszystkie te wdrożenia muszą odbyć się przed rozpoczęciem fali wznoszącej, bo jak tylko mechanicy zauważą ruch w warsztatach to będą znacznie mniej skłonni słuchać o naszych nowościach. To wszystko oznaczało, że złożone elementy tych puzzli (nowe Zilo oraz nowy Autobooking) muszą być gotowe w pierwszej połowie lutego.
To oznacza, że mamy miesiąc, aby rozwiązać nasz problem z modelowaniem nowych usług.
Czas i wyporność
Już latem 2021, gdy kładliśmy podwaliny pod ideę Autobookingu, zadawaliśmy sobie to pytanie: jak procesowo rozwiązać dystans czasowy między godziną podstawienia samochodu a, wydawać by się mogło, losowym czasem jego naprawy.
Jednym z pomysłów było zaadaptowanie „wyporności”: rezygnujemy z określania godziny naprawy, zamiast tego sprawdzamy tylko, jak dużo usług w danym dniu może wziąć na siebie warsztat. Tak samo jak statek ma określoną górną granicę ciężaru ładunku, który może transportować, tak warsztat ma określoną liczbę usług, które może wykonać w ciągu dnia – niezależnie od tego kiedy w ciągu dnia każdą z nich wykona. Co nam to daje taka zmiana myślenia?
Przede wszystkim zdejmuje z mechaników sztywny gorset określania z góry godziny naprawy. Wprowadzamy natomiast „godzinę podstawienia” dla kierowcy, ale nie zmuszamy mechanika do „godziny naprawy”.
Przy pierwszej wersji zdecydowaliśmy się skupić tylko na oponach, więc koncept wyporności odstawiliśmy na dalszy plan. Teraz czas go odkurzyć, bo brzmi jak idealne rozwiązanie naszego problemu.
Wyporność brzmiała świetne w teorii, ale generowała inną zagadkę: jak ją dobudować do Zilo? Jak na siatkę kalendarza dodać wizyty, które nie mają ustalonej godziny startu? Nic sensownego nie wpadło nam do głowy, więc zaczęliśmy rozważać całkowite wyrzucenie kalendarza.
To była szalona idea…wyrzucić cały silnik kalendarzowy, na bazie którego układa się cała siatka Zilo i zamiast tego postawić coś nowego, co obsłuży obydwie logiki (czasu i wyporności) jednocześnie. Tak, dawno już chcieliśmy zastąpić czymś FullCalendar, bo czuliśmy się przez niego mocno ograniczeni, ale to było coś o wiele bardziej ambitnego.
Na początku byłem sceptyczny. Liczyłem dni… czy my w ogóle mamy szanse, aby się wyrobić mając tylko miesiąc pracy developerskiej? Tak dużo wyrywania wraz korzeniami… czy w ogóle wiemy jak dużo rzeczy musi się zmienić? Czy obsłużymy wszystkie scenariusze?
Musiałem jednak przyznać, że stworzenie zupełnie nowego kodu to najsensowniejsza ścieżka – to już czas na pozbycie się ograniczeń zewnętrznego rozwiązania. Nawet jeśli pierwsza nowa wersja będzie koślawa, to przynajmniej otworzymy przed sobą dużo nowych możliwości rozwoju.
Przyzwyczaiłem się już do startowania rzeczy, które nie są jeszcze dobre. Różnica polegała jednak na tym, że tym razem mieliśmy znacznie więcej do stracenia.
Nowe Zilo
Dzień po tej dycyzji miałem naszkicowane pierwsze makiety. Następnie rozpoczęliśmy dwutorową pracę nad logiką wyporności i nowym frontem do Zilo.
Różnica polega na tym, że w starym Zilo wszystkie stanowiska musiały działać zgodnie z takim samym godzinowym kalendarzem. W nowym Zilo każde stanowisko jest rozdzielone i ma swoją wewnętrzną logikę: może być albo czasowe (wtedy ma swoje godziny „wewnątrz”) lub wypornościowe (wtedy godziny nie mają znaczenia)
Tak rozbudowana logika wymagała też rozbudowanych ustawień. Wyciągnęliśmy je do oddzielnego ekranu ze wględu na mnogość opcji. Stanowisko może być czasowe (czyli takie jak w 2021) albo ilościowe (czyli wypornościowe). Dodatkowo, ustawienie „widoczności w DM” odsłaniało dodatkowe opcje z ustawieniem dni i godzin tej widoczności oraz typy usług jakich dotyczy. Nasz` system później tłumaczył to na siatkę godzin, którą widać na formularzu rezerwacji wizyty.
Zmiana w Zilo była masywna. Choć stała za nią potrzeby związane z Autobookingiem to musiała być wdrożona także warsztatom, które Autobookingu jeszcze nie znały, albo nie chciały. Koszt utrzymywania dwóch wersji Zilo były dla nas zbyt wysokie.
Z tego powodu wieczorem 7 lutego 2022 (kilka dni przed deadlinem) przeprowadziliśmy release nowego Zilo dla wszystkich warsztatów.
Wystartowaliśmy w naszym standardowym już stylu – najszybciej jak się dało. Aby to się udało przesunąłem na późniejszy release kilka niekrytycznych ficzerów – takich jak chociażby widok listy i widok miesiąca. Okazuje się jednak, że globalnie one były niekrytyczne, ale niektóre z warsztatów właśnie na tych widokach oparły swój workflow zamiast na widoku dnia – więc dla nich to było krytyczne. Zaiste nigdy nie wiadomo jak bardzo coś jest ważne dopóki się tego komuś nie zabierze.
Po dwóch dobach zebraliśmy feedback przekazany bezpośrednio i przez nasz BOK. W sumie mieliśmy 18 różnych błędów i braków do poprawki. Naprawianie tego zajęło nam kolejny tydzień więc finalnie 14 lutego (dokładnie w nasz deadline) nowe Zilo uznaliaśmy za ustabilizowane.
Pauza
W połowie lutego byliśmy po wdrożeniu – nowe Zilo i zmodernizowany formularz Autobookingu trafiły na produkcję. Teraz pałeczkę od nas przejął BOK z misją wdrożenia jak największej grupy warsztatów przed rozpoczęciem sezonu.
Raz na tydzień zbieraliśmy wnioski ze wdrożeń, aby usłyszeć co postronne warsztaty sądzą o naszych nowych rozwiązaniach. W większości przypadków, jak już udało właścicieli namówić na współpracę, to wszystko szło sprawnie. Idea „wyporności” była dla nich oczywista, co mnie bardzo uspokoiło. Czasami wręcz nie czekali na instrukcje i sami konfigurowali stanowiska, tryby i czas dostępności. Z jednej strony było to irytujące, ale z drugiej oznaczało, że system jest zrozumiały bez wyjaśnień.
Dzięki temu kolejne sprinty mogliśmy z czystym sumieniem przeznaczyć na inne przygotowania do sezonu (mieliśmy ambicję wpakować w ten kwartał jeszcze jeden duży projekt, ale to temat na inny wpis).
Druga fala
Pierwsze zlecenia na nowe usługi zaczęły już wpływać w trzecim tygodniu marca. Ruch powoli rósł zgodnie z prognozami, ale później się załamał ze względu na nagły atak zimy na początku kwietnia.
Następnie były święta, które nie okazały się aż tak dużym motywatorem do zmiany opon jak myśleliśmy – mimo coraz lepszej pogody wszyscy mieli z tyłu głowy opady śniegu sprzed kilku dni. Prawdziwy ruch zauważyliśmy dopiero w maju, przy okazji długiego weekendu.
Do tego czasu mieliśmy już w systemie 4 razy więcej warsztatów z autobookingiem niż przy sezonie zimowym. Wraz ze zwiększoną skalą działania widzieliśmy typowe zachowanie analityki gdzie konwersja rozpoczęła regresję do średniej wartości: skrajnie dobre i złe przypadki miały coraz mniejsze znaczenie przy drastycznie zwiększonej grupie aktywnych użytkowników. Potwierdziło się też moje wcześniejsze przypuszczenie że pierwotnie dobrana grupa testerów skrzywiała odbiór rozwiązania w stronę zdecydowanie bardziej pozytywną niż globalna średnia oraz że sezon zimowy jest znacznie agresywniejszy niż wiosenny
Niemniej, mimo tych wszystkich zastrzeżeń osiągnęliśmy nasze trzy najważniejsze cele:
- Poprawiliśmy proces rezerwacji, co widać po kilkukrotnie lepszej konwersji w warsztatach po wdrożeniu Autobookingu (uśredniając między sezonami),
- Zautomatyzowaliśmy 20%+ bookingów, a więc uwolniliśmy 1/5 czasu naszego Biura Obsługi Klientów, co jest szczególnie istotne podczas sezonów,
- Udowodniliśmy, że automatyczne rezerwacje w warsztatach jest możliwe, choć mało osób w branży to wierzyło.
Co dalej?
Autobooking potwierdził się jako dobry kierunek rozwoju produktu. Wygraliśmy ten zakład z rzeczywistością, co mnie niezmiernie cieszy. Stworzyliśmy nową jakość, która okazała się wartościowa zarówno dla naszych klientów jak i nas jako organizacji.
Teraz czeka nas dalsza praca nad poprawą tych wskaźników – zwiększając liczbę warsztatów z Autobookingiem, rozszerzając spektrum usług i usprawniając interfejs po stronie kierowcy i warsztatu.
Ale to tylko jeden z zakładów, które wzięliśmy na siebie podczas mojego pierwotnego planu strategicznego z początku 2020 roku. Tamte założenia są ciągle aktualne.
Czas wziąć na warsztat kolejny punkt z listy.
