Alternatywa dla Shore 2026: strona salonu, rezerwacja i kartoteka klienta

Shore należy do systemów, które chcą odwzorować całą firmę: terminy, zarządzanie klientami, kasę, płatności, marketing, a do tego sprzęt na recepcji. Model rozliczeń to licencja, uzupełniona o moduły dodatkowe i prowizje od obsłużonych płatności. Cudzych kwot ten artykuł świadomie nie podaje — ceny dostawców się zmieniają, a nieaktualna liczba w porównaniu szkodzi bardziej niż jej brak.

Kto chce wyjść z takiego systemu, ma przed sobą zupełnie inne zadanie niż ktoś, kto wyłącza profil w portalu. Przywiązanie nie leży tu po stronie klientów, lecz we własnej firmie: w modułach, na których wiszą procesy, w urządzeniach dopasowanych do tego systemu, w okresie obowiązywania umowy i w danych narastających latami. Ten artykuł omawia te cztery punkty po kolei. Salon Wizard jest jednym z możliwych adresów docelowych i traktowany jest tu jak każdy inny.

W przypadku portalu rezerwacyjnego trudna część leży na zewnątrz: rezygnujesz z widoczności i musisz dotrzeć do klientów własnymi kanałami. Sama firma zmienia się w niewielkim stopniu, bo portal dotykał wyłącznie umawiania wizyt — różnicę tę rozkłada na czynniki porównanie portalu z własną stroną.

Przy suicie jest odwrotnie. Na zewnątrz dla Twoich klientów zmienia się niewiele — i tak rezerwowali u Ciebie, a nie na targowisku. Wewnątrz zmienia się dużo, bo system tkwi w kilku miejscach dnia pracy: na recepcji, w rozliczeniach, w obsłudze klienta, częściowo w gospodarce magazynowej. Każde z tych miejsc potrzebuje następcy albo świadomej decyzji, że odtąd robi się to inaczej.

Dla planowania oznacza to: zmiana rzadko rozbija się o to, że nowy system mniej potrafi. Rozbija się o przeoczony proces, który po cichu wisiał na starym systemie — obsługa voucherów, rozliczenie prowizji, lista sprzedaży produktów, comiesięczny eksport dla księgowości. Zanim cokolwiek zaczniesz porównywać, spisz więc, jakie zadania wykonujesz dziś w tym systemie. Ta lista bywa dłuższa, niż się spodziewasz, i jest właściwym katalogiem wymagań.

Systemy modułowe rosną z czasem. Coś dokupiono na akcję promocyjną, coś innego wzięto przy wdrożeniu, trzecie ustawiła osoba, której już nie ma w firmie. Po kilku latach nikt nie wie dokładnie, co jest aktywne.

Poświęć więc godzinę i przejdź przez system z ostatnią fakturą w ręku. Do każdej pozycji należy odpowiedź na trzy pytania: co robi ten moduł? Kto z zespołu użył go w ostatnich trzech miesiącach? I co przestałoby działać w poniedziałek, gdyby go zabrakło?

Wynik dzieli się niemal zawsze na trzy grupy. Pierwsza zawiera dwa do czterech elementów, które działają codziennie i muszą znaleźć się w każdym rozwiązaniu następczym. Druga zawiera rzeczy potrzebne rzadko, ale ważne, gdy już przyjdzie ich czas — na przykład podsumowanie roczne. Trzecia zawiera to, co może odpaść bez straty. Tylko pierwsza grupa może w porównaniu działać jako kryterium wykluczające. Kto wniesie do wyboru wszystkie trzy grupy jako wymaganie, siłą rzeczy znajdzie znowu suitę tej samej wielkości — i po drodze zgubi powód zmiany.

Suity często przynoszą ze sobą urządzenia: tablet na recepcji, terminal płatniczy, drukarkę paragonów, szufladę kasową, czasem drukarkę etykiet do sprzedaży. Te urządzenia to ta część zmiany, której można dotknąć — i ta, którą najłatwiej przeoczyć, dopóki nie stanie na drodze.

Wyjaśnij przy każdym urządzeniu trzy punkty. Po pierwsze status własności: kupione, wynajęte, w leasingu czy zawarte w pakiecie — od tego zależy, czy może zostać i co się z nim stanie. Po drugie przywiązanie: czy urządzenie działa wyłącznie z tym dostawcą, czy da się je stosować ogólnie? Przy terminalach płatniczych zależy to zwykle od operatora płatności stojącego z tyłu, a nie od oprogramowania z przodu. Po trzecie zwrot: dokąd trafia urządzenie, do kiedy i kto ponosi koszty?

Te pytania decydują o znacznej części nakładu na przestawienie. Decydują też o tym, kiedy zmiana w ogóle ma sens: kto tkwi w środku okresu leasingu sprzętu, ten z reguły spłaci go do końca — wtedy ostatni miesiąc tego okresu jest naturalnym momentem przejścia, a nie jakakolwiek data wcześniej.

Umowy licencyjne w branży salonowej biegną często przez rok lub dłużej i przedłużają się automatycznie, jeśli nie zostaną wypowiedziane na czas. To nie stanowi problemu, dopóki się o tym wie — i bywa kosztowne, gdy zauważysz to dwa tygodnie za późno.

Wyjmij więc umowę, zanim zaczniesz oglądać alternatywy, i zanotuj cztery daty: koniec bieżącego okresu, termin wypowiedzenia, formę, w jakiej trzeba wypowiedzieć, oraz to, czy pojedyncze moduły mają odmienne terminy. Wpisz najpóźniejszy dzień wypowiedzenia jako termin do swojego kalendarza, z przypomnieniem cztery tygodnie wcześniej.

Potem planuj wstecz. Przed wypowiedzeniem wybór powinien być zamknięty, wcześniej praca testowa, a jeszcze wcześniej eksport danych. Na samo przestawienie licz kilka tygodni i nie umieszczaj go w swoim najmocniejszym sezonie. Jeśli rachunek się nie domyka, lepiej pogodzić się z przedłużeniem i przygotować rzecz porządnie, niż wymuszać zmianę pod presją czasu. Pospieszne przejście kosztuje w poprawkach regularnie więcej, niż kosztowałyby dodatkowe miesiące.

Dane to majątek, który salon budował latami, i to one sprawiają, że zmiana w ogóle przychodzi z trudem. Zażądaj więc eksportu wcześnie — nie po wypowiedzeniu, lecz kiedy jeszcze porównujesz.

Sprawdź cztery składniki. Baza klientów z nazwiskami, danymi kontaktowymi i adnotacjami o zgodach jest rdzeniem. Historia wizyt mówi Ci, kto kiedy miał jaką usługę, i stanowi podstawę każdego wyliczenia rytmu. Notatki merytoryczne to część najczęściej tkwiąca w formacie nieczytelnym gdzie indziej — obejrzyj przykładowy plik, zanim na nich polegniesz; czego się przy tym pilnować, opisuje tekst o kartotece klienta u fryzjera. A przyszłe wizyty cykliczne i kolejne terminy muszą powstać na nowo w nowym systemie, inaczej od dnia przestawienia zabraknie ich w kalendarzu.

Sprawdź dodatkowo, w jakim formacie przychodzi eksport i czy jest jeszcze dostępny po wypowiedzeniu. Zaplanuj na koniec okres przejściowy, w którym stary system da się jeszcze czytać, podczas gdy w nowym już się pracuje. Dwa do czterech tygodni zwykle wystarczą — dość długo, by zauważyć luki, dość krótko, by zespół nie pracował trwale w dwóch systemach.