Movara Fitness Resort solgte ikke bare en enkel romnatt. Gjester kom for et strukturert velværeopphold der innkvartering, måltider, trening, programmer, tjenester og betalinger måtte fungere sammen.
Movara Fitness Resort i Ivins, Utah kombinerer overnatting med en strukturert trenings- og velværeopplevelse som kan strekke seg fra et kort besøk til flere ukers programmer.
Booking Ninjas jobbet med Movara for å konfigurere et Salesforce-basert resortmiljø rundt måten disse oppholdene faktisk ble solgt og drevet.
Utfordringen: ett rom kunne representere flere typer inventar
Movara's innkvarteringsmodell viste raskt hvorfor en normal oppsett med ett rom og én reservasjon ikke var tilstrekkelig.
Det samme fysiske rommet kunne selges privat til én gjest eller deles mellom flere programdeltakere.
Internt kunne et rom som 101 derfor ha relatert inventar som 101A og 101B.
Hvis hovedrommet ble bestilt privat, måtte begge delte plasser bli utilgjengelige. Hvis én delt plass ble bestilt, måtte systemet forhindre at det samme rommet ble solgt igjen som privat inventar.
- King Privat
- King Dobbel
- Queen Privat
- Queen Dobbel
- Villa Privat
- Villa Dobbel
- Villa Trippel
- Tilsluttet foreldre-barn inventar
Booking Ninjas konfigurerte inventaret rundt Movara's reelle regler
Booking Ninjas jobbet med Movara om at foreldres og barns tilgjengelighetsatferd skulle påvirke hverandre automatisk, slik at privat og delt inventar kunne påvirke hverandre.
Det er et godt eksempel på den bredere implementeringsmetoden: starte fra hvordan virksomheten faktisk selger ressursen, og deretter konfigurere systemet rundt den logikken.
Booking Ninjas' nåværende Reservasjonsadministrasjon og bookingplattform bruker den samme bredere modellen ved å koble reservasjoner direkte med inventar, tilgjengelighet, kapasitet, priser og driftsregler.
Produktet var en velværepakke, ikke bare et rom
Innkvartering var bare én del av det gjesten kjøpte.
Et opphold kunne samle overnatting, måltider, tilgang til trening, treningsprogrammer og andre velværekomponenter.
Disse komponentene kunne ha forskjellig skattebehandling, mens den endelige prisen også kunne avhenge av belegg, oppholdslengde, sesong, lojalitetsstatus og kampanjeregler.
Lengre reservasjoner kunne til og med krysse forskjellige prisperioder i løpet av det samme oppholdet.
Privat eller delt overnatting etablerer en del av pakken og inventarbehovet.
Måltider, trening og velværeprogrammer utgjør en del av det gjesten kjøper.
Lengde, belegg, datoer, lojalitet og kampanjer kan endre hvordan oppholdet prises.
Innskudd, saldoer, fakturaer og betalingshistorikk forblir knyttet til reservasjonen.
Den endelige reservasjonen bærer driftsdetaljene bak gjestens fulle opplevelse.
Booking Ninjas nærmet seg dette som pakke- og prisadministrasjon i stedet for å redusere alt til én nattpris.
Den nåværende Prisadministrasjonen støtter på tilsvarende måte sesongbasert, kalenderbasert og regelbasert prising inne i Salesforce.
Hvordan Movara driftsmodell passet sammen
| Movara trengte | Booking Ninjas tilnærming | Hva oppsettet kunne gjøre enklere |
|---|---|---|
| Privat + delt rominventar | Koblet reservasjons- og tilgjengelighetsregler | Private og delte versjoner av det samme fysiske rommet kunne blokkere hverandre korrekt. |
| Ulike velværepakker | Pakke + Prisadministrasjon | Innkvartering, programkomponenter, datoer, belegg og prisregler kunne forbli en del av den samme oppholdsstrukturen. |
| Lang og kort opphold | Regelbasert prising | Ulike prisperioder og oppholdslengder kunne håndteres uten å redusere hver reservasjon til én fast nattpris. |
| Innskudd og saldoer | Reservasjons- + betalingsarbeidsflyter | Forskuddsbetalinger, gjenværende saldoer, fakturaer, kort og betalingshistorikk kunne forbli knyttet til gjestens reservasjon. |
| Vite romklarhet | Rengjøringsstatus | Utsjekking kunne flytte et rom til status som ledig-skittent før rengjøring returnerte det til ledig-rent og tilgjengelig inventar. |
| Selge tjenester under oppholdet | Salgssted | Spa-tjenester, personlig trening, varer fra pro-shop, private fotturer, utflukter, måltider for å ta med, og andre kjøp kunne forbli knyttet til gjesten og reservasjonen. |
| Holde forhåndsbetalt og tilleggskostnader klare | Fakturering + POS-struktur | Den forhåndsbetalte velværepakken kunne forbli distinkt fra tilleggskjøp gjort etter ankomst. |
Reservasjonen ble starten på gjesteoperasjonen
Movara's ansatte trengte mye mer enn en bookingbekreftelse.
De måtte forstå hvem som ankom, hvem som var i huset, hvilket rom en gjest okkuperte, om det var saldoer igjen, hva som var betalt, og når innkvarteringen var klar til å selges igjen.
Booking Ninjas jobbet mot å holde disse prosessene rundt Salesforce-baserte reservasjonsopptegnelser slik at bookingen kunne forbli nyttig gjennom oppholdet.
Det gjør reservasjonen fra en salgsopptegnelse til noe operasjoner kan fortsette å bruke etter at gjesten ankommer.
Tilgjengelighet avhang også av operasjonell romstatus
En gjest som sjekker ut betyr ikke automatisk at rommet er klart for neste ankomst.
Movara trengte at rommet skulle gå gjennom en enkel, men viktig sekvens:
Det kobler rengjøring direkte med inventarstyring.
Et rom kan fysisk være tomt, men bør fortsatt ikke behandles som salgbart inventar før den operasjonelle statusen sier at det er klart.
Dette er grunnen til at tilgjengelighet er mer nyttig når den reflekterer både reservasjoner og den reelle tilstanden til ressursen.
Resortopplevelsen fortsatte etter at velværepakken var kjøpt
Movara's transaksjoner på eiendommen så også annerledes ut enn en normal restaurantfokusert resort POS.
Gjester kunne kjøpe massasjer, personlig trening, varer fra pro-shop, private fotturer, utflukter, måltider for å ta med, og andre velvære tjenester eller tillegg.
Booking Ninjas jobbet mot en POS-opplevelse formet rundt disse faktiske kjøpene i stedet for en generell restaurant-bord arbeidsflyt.
Det bredere målet var å holde ytterligere utgifter knyttet til gjesten og reservasjonen, samtidig som det fortsatt ble skilt fra den forhåndsbetalte velværepakken.
Booking Ninjas' nåværende POS kobler også transaksjoner med reservasjoner, tjenester, medlemskap og kundeposter inne i Salesforce.
Systemet ble bygget gjennom reell operasjonell tilbakemelding
En definerende del av Movara-prosjektet var implementeringsprosessen selv.
Booking Ninjas vurderte den eksisterende driften, opprettet Salesforce-miljøet, og jobbet gjennom gjentakende vurderings- og testøkter med Movara's team.
Den tilbakemeldingen avdekket detaljer som ville vært lette å gå glipp av i en generell resortimplementering: hvordan etiketter for delte rom skulle vises, hvordan inventar skulle blokkere, hvordan pakke komponenter skulle prises, hvordan romstatus skulle endres, og hvordan forhåndsbetalte programkostnader skulle skille seg fra tillegg.
Implementeringen ble bevisst faset.
Kjerne reservasjons- og PMS arbeidsflyter kom først, med dypere POS, regnskap, rapportering, kreditter og støttende prosesser ment å følge.
Hva prosjektet demonstrerte
Movara pauset til slutt den bredere implementeringen og fortsatte å bruke sitt eksisterende PMS mens de fokuserte på andre forretningsprioriteringer.
Den planlagte fullstendige PMS, regnskap og POS-erstatning nådde derfor ikke fullføring.
Det betydelige implementeringsarbeidet demonstrerte fortsatt hvordan Booking Ninjas kunne modellere en uvanlig kompleks velvære-resortdrift.
Private og delte versjoner av den samme innkvarteringen kunne modelleres uten å tillate konfliktfylte reservasjoner.
Reservasjonsstrukturen kunne ta hensyn til oppholdslengde, belegg, sesongperioder, pakker, kampanjer og forskjellige pris komponenter.
Reservasjoner, romstatus, betalinger, gjesteinformasjon og annen operasjonell aktivitet kunne dele den samme Salesforce-grunnlaget.
Inventar kunne reflektere om innkvarteringen faktisk var klar for en annen gjest, ikke bare om den forrige gjesten hadde forlatt.
Ytterligere tjenester og kjøp kunne utformes rundt gjesten og reservasjonen i stedet for å bli isolerte transaksjoner.
Prosjektet viste hvordan et velvære-resort med uvanlige regler kunne modelleres uten å redusere det til en konvensjonell hotellmal.
Movara trengte ikke et annet generisk hotell PMS
Resortens produkt var forskjellig med vilje.
Privat og delt inventar fungerte forskjellig. Velværeprogrammer formet prisen. Opphold kunne vare i flere uker. Gjester gjorde ytterligere kjøp rundt programmet. Rengjøringsstatus påvirket om inventaret var virkelig klart.
Et rigid PMS kunne tvinge disse forskjellene inn i omveier.
Booking Ninjas tok den andre tilnærmingen: bruk Salesforce som driftsgrunnlaget, og konfigurer deretter reservasjon, prising, betaling, tjeneste og driftsregler rundt organisasjonen.
Det prinsippet forblir sentralt for Booking Ninjas i dag: forskjellige operasjoner kan bruke den samme plattformgrunnlaget uten å måtte følge de samme forretningsreglene.
Lær mer om denne typen resortoppsett
Se hvordan bestillinger, inventar, kapasitet, restriksjoner og driftsregler bestemmer om en ressurs faktisk kan bookes.
Hvordan tilgjengelighet administreres →Se hvordan reservasjoner, betalinger, tjenester og annen godkjent aktivitet kan forbli knyttet rundt den samme gjesten.
Hva er en kundepost? →Se hvordan Booking Ninjas kobler komplekse reservasjoner med prising, tilgjengelighet, driftsregler og Salesforce arbeidsflyter.
Utforsk prisadministrasjon →Om denne historien: Booking Ninjas fullførte betydelig konfigurasjon og implementeringsarbeid med Movara Fitness Resort rundt privat og delt innkvartering, velværepakker, komplekse priser, betalinger, romstatus, gjesteoperasjoner, POS-krav og fasevis utvidelse. Movara pauset senere den bredere implementeringen og fortsatte med sitt eksisterende PMS, så denne siden presenterer ikke Booking Ninjas som Movara's fullførte produksjons-PMS eller påstår uverifiserte finansielle eller operasjonelle resultater.
Ditt resort bør ikke måtte forenkle produktet sitt for å passe til PMS-en.
Se hvordan Booking Ninjas kan koble komplekst inventar, pakker, priser, gjester, betalinger, tjenester, romstatus og operasjoner rundt måten oppholdet ditt faktisk fungerer på.
.jpeg)
.jpg)
.png)
