SevenRooms alternatyvos: kai rezervacijų programinė įranga ima tapti visko centru

Yra „pažinti svečius“ versija, kurios siekia SevenRooms. Matote, kas rezervuoja reguliariai, galite žymėti didelius išlaidautojus, automatizuoti gimtadienio kampaniją, pažymėti VIP prieš atvykimą ir sekti neatvykimų istoriją. Restoranams, norintiems valdyti svečių duomenis, o ne nuomotis juos iš trečiosios šalies rinkos, toks pasiūlymas turi trauką.

Įtempimas tas, ką „pažinti svečius“ iš tiesų reiškia, kai verslas tampa sudėtingesnis.

Svečio profilis, pastatytas ant rezervacijų, pasako, kada žmogus rezervuoja, kaip dažnai grįžta ir kiek paprastai išleidžia rezervuotu atveju. Jis nepasako, ką nusipirko bare antradienio vakare be rezervacijos. Nesujungia su kambariu, kuriame nakvojo, spa procedūra, kurią rezervavo, renginio bilietu ar mažmenos užsakymu praėjusį mėnesį. SevenRooms laiko vieną santykių dimensiją. Pilnas vaizdas išsklaidytas po visas kitas sistemas steke.

Tas tarpas, tikroji priežastis, kodėl operatoriai ima ieškoti alternatyvų.

Ką iš tiesų daro SevenRooms

SevenRooms valdo rezervacijų sluoksnį: rezervacijų srautus, laukiančiųjų sąrašus, salės ir stalų planavimą, svečių profilius ir bazinį CRM, el. pašto ir SMS rinkodarą, VIP žymes, automatines sekimo kampanijas, privačių vakarienių valdymą, mokesčius už neatvykimą ir ataskaitas apie rezervacijų modelius.

Jos pagrindinis pasiūlymas, padėti operatoriams valdyti svečių duomenis, o ne atiduoti juos trečiųjų šalių rezervacijų platformoms, teisinga idėja. Restoranas naudojantis SevenRooms gali identifikuoti nuolatinius rezervuotojus ir dalinai automatizuoti priminimus apie pakartotinį vizitą. Grynai rezervacijoms orientuotai operacijai to užtenka.

Kur modelis pradeda temptis

Problema ne SevenRooms izoliacijoje. Problema tame, ko verslui galiausiai prireikia aplink ją.

Restoranas, naudojantis SevenRooms rezervacijoms, CRM ir rinkodarai, vis tiek reikia POS operacijoms apdoroti. Lojalumo platformos taškams ir apdovanojimams. Viešbučio PMS, jei yra apgyvendinimas. Atskyro įrankio spa ar wellness rezervacijoms. Renginių kupiravimo programinės įrangos. Narystės platformos. Mokėjimų sistemos, galinčios tvarkyti sąskaitų skaidymą tarp juridinių subjektų. Dovanų kortelių valdymo.

Kiekviena iš tų sistemų laiko gabalą svečio santykių. SevenRooms laiko dar vieną. Rezultatas, „svečių intelekto“ versija, kuri iš tiesų yra rezervacijų intelektas, nes tik tą kelionės dalį sistema mato pilnai. Kai svečias rezervuoja vakarienę, atšaukia narystę, perka renginio bilietą ir vieną vakarą be rezervacijos daug išleidžia bare, SevenRooms kuriamas profilis geriausiu atveju dalinis.

Tas dalinis vaizdas turi realių komercinių pasekmių. Rinkodaros segmentai, statomi iš nevisų duomenų, duoda kampanijas, kurios prašauna taip pat dažnai kaip pataiko. Pajamų ataskaitoms reikia suderinimo tarp kelių platformų. Personalas skirtinguose kontaktuose nemato pilnos kliento istorijos. O patirtis būti svečiu objekte, kur vienoje sistemoje jus „pažįsta“ restorane, o spa ar registratūroje niekas neatpažįsta, retai atitinka aukštos klasės prekės ženklo pažadą, kurį verslas bando pateikti.

Platforma, sąmoninga savo problemų

SevenRooms pastaruosius metus matomai bando gerinti naudotojo patirtį, ir tai savaime pasako istoriją. Kai platforma stipriai investuoja į UX taisymus, tai todėl, kad naudotojai buvo garsūs apie trintį. Sąsaja istoriškai buvo sunkiai greitai naršoma, ypač komandoms, kurioms reikia judėti greitai užimto aptarnavimo metu. Mokymosi kreivė statesnė nei pradinis pasiūlymas leidžia manyti, ir net patyrę naudotojai praneša, kad sistema gali jaustis sunki būdais, kurie lėtina kasdienes darbo eigas, o ne jas pagreitina.

Android palaikymas ypač silpnas, kas sukuria realią trintį operacinėse aplinkose, kur ne kiekvienas komandos narys turi iPhone. Reikšminga funkcionalumas dažnai slepiasi už aukštesnių kainų pakopų, tai reiškia, kad tikrosios platformos potencialo naudojimo kaina laikui bėgant auga.

Bet UX pagerinimai eina tik iki tam tikros ribos. SevenRooms ribojama seno kodo ir senos architektūros. Tai ne tai, ką pataiso perdizainas. Tai formuoja, kaip produktas gali evoliucionuoti, ir paaiškina, kodėl kai kurios integracijos elgiasi nenuosekliai. Operatoriai, investavę laiką į platformą, dažnai pastebi, kad SevenRooms sėdi šalia kelių kitų sistemų, o ne jas pakeičia, pridedama prenumerata, o ne konsoliduojama viena.

Prekės ženklo problema

Klientams skirtos SevenRooms patirtys neša platformos prekės ženklą, o ne operatoriaus. Rezervacijų valdikliai, patvirtinimo srautai ir svečiams skirta komunikacija atrodo ir jaučiasi kaip SevenRooms. Operatoriai gali jas šiek tiek pritaikyti, bet dirba SevenRooms dizaino rėmuose, o ne pateikia visiškai su prekės ženklu suderintą patirtį.

Operatoriams, kuriantiems aukštos klasės prekės ženklą, tai svarbu. Pirmoji svečio sąveika su objektu, rezervacijos procesas, signalizuojantis bendrą programinę įrangą, o ne restoraną ar klubą, kurį jis ketina aplankyti. Spraga tarp kuriamo prekės ženklo ir technologijų patirties, kurią teikiate, dabartinėje architektūroje sunkiai uždaroma.

Tiquo požiūris priešingas. Kiekviena kliento sąsaja, nuo rezervacijos iki lojalumo programos ir mokėjimo kelionės, visiškai su prekės ženklu pagal operatorių. Technologijos nepažįstamos. Prekės ženklas, matomas.

Kitokia „pažinti svečio“ prasmė

Štai ką SevenRooms paprastai mato: rezervacijų istoriją, rezervacijų dažnumą, išlaidas rezervuotais atvejais, svečių pastabas ir žymes, el. laiškų atidarymus, rinkodaros kampanijų atsakus.

Štai ką mato vieninga platforma: viską aukščiau, plius kiekvieną POS operaciją, kiekvieną narystės sąveiką, kiekvieną lojalumo išnaudojimą, kiekvieną renginio bilietą, kiekvieną viešbučio nakvynę, kiekvieną spa procedūrą, kiekvieną maženos pirkimą, kiekvieną check-in, kiekvieną užklausą, kiekvieną panaudotą dovanų kortelę, susietą realiu laiku į vieną profilį, kurį kiekvienas komandos narys gali pasiekti iš bet kurio įrenginio.

Skirtumas ne tik duomenų turtingume. Tai operacinis svertas. Kai ta pati sistema, kuri laiko svečio profilį, taip pat apdoroja POS operaciją, valdo narystę, tvarko viešbučio rezervaciją ir automatiškai skiria mokėjimą tarp juridinių subjektų, ryšys tarp intelekto ir veiksmo tampa tiesioginis. Nereikia eksportuoti duomenų iš SevenRooms, suvesti su trimis kitomis platformomis ir kurti kampaniją ketvirtoje. Sistema jau žino ir jau veikia.

Požymiai, kad verta žiūrėti į alternatyvas

Valdote SevenRooms kartu su trimis ar daugiau kitų platformų visai operacijai. Svečių profiliai atspindi rezervacijų istoriją, bet ne pilną kliento santykį. Personalas skirtinguose kontaktuose, registratūra, restoranas, spa, neturi bendro svečio vaizdo. Rinkodaros segmentai statomi iš dalinių duomenų, nes ne kiekviena sąveika patenka į SevenRooms.

Turite viešbutį, wellness įrangą, narystės programą ar mažmeną visiškai už SevenRooms ribų. Jūsų komandai platforma atima daug laiko mokytis ir kasdien jaučiasi sunki operacijai. Klientui skirta rezervacijos patirtis atrodo kaip SevenRooms, o ne kaip jūsų prekės ženklas. Android apribojimai trukdo daliai personalo. Bendra SevenRooms ir aplinkinių sistemų kaina sunkiai pateisinama prieš vieną vieningą platformą.

Kaip Tiquo prie to eina kitaip

Tiquo nėra geresnis rezervacijų valdiklis. Ji nesistengia varžytis su SevenRooms rezervacijos srauto gylį ar el. pašto kampanijų sudėtingumą. Skirtumas struktūrinis.

Tiquo, vieninga operacijų platforma, kur rezervacijos, POS, CRM, narystės, viešbučio PMS, spa ir wellness rezervacijos, renginių valdymas, kupiravimas, lojalumas, dovanų kortelės, mokėjimai ir analitika veikia toje pačioje duomenų bazėje su tuo pačiu kliento profiliu. Svečias nėra rezervacijos įrašas. Jis, pilnas komercinis santykis, į kurį įsitraukia kiekviena verslo dalis ir iš kurio kiekviena dalis gali skaityti realiu laiku.

Vieningi klientų profiliai visose verslo srityse. Kiekviena sąveika, nesvarbu, ar tai restorano rezervacija, operacija bare, registracija viešbutyje, sporto užsiėmimas, renginio bilietas ar mažmeninis pirkinys, patenka į vieną aktualų profilį. CRM šalia ankstesnės veiklos pateikia prognozuojamą bendrą kliento vertę ir numatomus kito užsakymo intervalus. Social Graph parodo klientų tarpusavio ryšius ir padeda komandoms suprasti, kaip grupės, nuolatiniai svečiai ir įmonių paskyros sąveikauja su verslu.

Mokėjimai, automatiškai suvaldantys veiklos sudėtingumą. Sukonfigūruotoms susietoms paskyroms Tiquo gali padalyti vieną mokėjimą keliems gavėjams ir išlaikyti kiekvieną dalį susietą su užsakymu. Kadangi rezervacijos, užsakymai, mokėjimai, narystės ir lojalumas naudoja tuos pačius veiklos įrašus, Tiquo sumažina duomenų derinimą tarp sistemų ir viską automatiškai suderina, nes kiekvienas mokėjimas visada tiesiogiai susietas su užsakymu. Club Pay suteikia sukauptą kreditą tinkamiems produktams ir paslaugoms, taip pat lanksčias dalijamo mokėjimo galimybes grupėms.

Lojalumas ir narystės visame versle. Vietoj lojalumo, gyvenančio tik rezervacijų platformoje ir atjungto nuo viso kita, Tiquo vieninga lojalumo ir narystės komercija giminingai veikia kiekvienoje subvietoje ir vertikėlėje. Nariai uždirba ir išnaudoja naudas, nesvarbu ar restorane, sporto salėje, viešbučio bare ar maženos taške.

Rezervacijos už valgomojo ribų. Viešbučio kambariai, spa procedūros, wellness klasės, privačios nuomos renginiai ir parodų bilietai rezervuojami per tą pačią platformą kaip ir restorano stalai. Svečias, rezervuojantis stalą, gali būti paragintas pridėti spa kitą rytą. Viešbučio svečias gali rezervuoti vakarienės laiką check-in sraute. Ryšiai vyksta vienoje sistemoje, o ne integracijų grandinėje.

Platforma visai komandai, ne tik priekinei linijai. SevenRooms pirmiausia priekinės linijos ir rinkodaros įrankis. Tiquo apima visą operaciją: POS komandą, renginių komandą, finansus, viešbučio registratūrą, wellness stalą ir narystės biurą, visi dirba toje pačioje platformoje. Nėra vertimo sluoksnio tarp sistemų ir nėra duomenų spragos tarp skyrių.

Priimant sprendimą

Kai svečio santykis peržengia valgomąjį, klausimas „kas šis svečias?“ reikalauja platformos, matančios viską. Rezervacijų įrankis su palikimo architektūra ir UX, kurį vis dar taiso, niekada nebuvo skirtas valdyti viešbučiui, spa, narių klubui, wellness programai ir kelių subjektų mokėjimų operacijai.

Operatoriai, vedantys tokį verslą, neieško geresnės rezervacijų platformos. Jie ieško geresnės operacinės sistemos.