Když firma nabízí dva různé typy služeb pod jednou střechou, běžný rezervační systém selže. Postavil jsem řešení, které mění formulář podle toho, co si…
Problém, který většina systémů neumí vyřešit
Když firma nabízí dva různé typy služeb — řekněme tetování a kosmetiku — potřebuje dva různé dotazníky, dvě různé cenové struktury a dva různé typy záloh. Ale sdílí jeden kalendář, jednu majitelku a jeden prostor. A to je technická výzva, kterou většina rezervačních systémů neumí vyřešit.
Tetování potřebuje vědět: umístění na těle, rozměry, referenční fotky, překrývání starého tetování, alergie na barvy. Kosmetika potřebuje vědět: typ pleti, cíl zákroku, předchozí reakce na přípravky. Dva úplně různé sady otázek — ale jeden společný kalendář.
Princip číslo 1: Formulář, který se přizpůsobuje službě
Klíčový princip, který jsem se naučil při stavbě rezervačních systémů pro multi-service firmy: jeden formulář, který se mění podle toho, co si zákazník vybere. Jakmile si zákaznice klikne na konkrétní úkon, systém ví, na co se ptát. Tetování? Zobrazí se pole pro nahrání referenčních fotek, popis umístění, přibližné rozměry. Kosmetika? Zobrazí se otázky o typu pleti, cíli zákroku, předchozích reakcích.
Zákaznice nikdy nevidí zbytečné otázky. Formulář je krátký, relevantní, konkrétní. A když si vybere konkrétní úkon z ceníku, systém jí ho automaticky předvyplní do poznámky — s odhadovanou cenou. Nic ji nepřekvapí.
Princip číslo 2: Jeden kalendář, ale diferenciované procesy
Kalendář je společný — majitelka vidí všechny rezervace na jednom místě, bez ohledu na typ služby. Blokované dny, čekací listina, volné termíny — vše v jednom pohledu. Ale záloha, e-maily a instrukce se mění podle toho, o jakou službu jde.
To je detail, který by v šablonovém řešení neexistoval. Buď byste měli jednu zálohu pro všechno (neférové — stejná záloha za levnou i drahou službu nedává smysl), nebo dvě oddělené rezervační systémy (chaotické — dva kalendáře, dva e-maily, dva procesy). Jeden systém, který chápe rozdíl, je řešení, které šablona nikdy nenabídne.
Princip číslo 3: Společný admin, ale kontextová data
V admin panelu vidí majitelka každou rezervaci s kontextem — o jakou službu jde, jaké dotazníkové odpovědi zákaznice vyplnila, jaké fotky nahrála. Vše na jednom místě, ale s daty, které dávají smysl pro konkrétní službu. Žádné zbytečné pole pro alergii na barvy u kosmetické rezervace.
Schválením rezervace se spustí automatický proces — e-mail s QR kódem na zálohu, jehož výše odpovídá typu služby. Po zaplacení přijde potvrzovací e-mail s instrukcemi, které jsou taky kontextové — jiné pro tetování, jiné pro kosmetiku. Termín se zablokuje v kalendáři. A pokud zákaznice zálohu nezaplatí včas, rezervace se sama zruší.
Reálný příklad: Ink & Glow
Tento princip jsem aplikoval u Ink & Glow — tetovacího a kosmetického studia v Ostravě. Majitelka provozuje obě služby v jednom prostoru a potřebovala systém, který chápe, že jde o dva různé světy — ale sdílejí jeden kalendář. Více o konkrétním nasazení najdete v případové studii.
Když máte dva byznyssy, není to jen o funkčnosti
Majitelka má dva byznyssy pod jednou střechou ne proto, že by to bylo jednodušší — ale proto, že její klienti chtějí obojí. Někdo přijde na tetování a zeptá se na kosmetiku. Někdo naopak. Jedna majitelka, jeden prostor, jeden systém — a zákaznice má pocit, že je v místě, kterému může důvěřovat na všechno.
To je rozdíl mezi rezervačním systémem, který funguje, a systémem, který chápe váš byznys. Šablona umí první. Druhé se naučí jen systém, který je postavený na míru.