Quinn’s Hot Springs Resort hadde allerede vokst til mer enn en enkel overnattingsdrift. Å gå bort fra sitt gamle reservasjonsmiljø betydde derfor å tenke på mer enn bare rom.
Quinn’s Hot Springs Resort i Paradise, Montana kombinerer to hytter, mer enn 25 hytter, varme kilder, svømming for dagsbesøkende, spisesteder og flere forskjellige reservasjonsregler rundt den samme resortopplevelsen.
Quinn’s engasjerte Booking Ninjas mens de så etter en mer fleksibel retning for reservasjons-teknologien bak driften.
Utfordringen: ett resort, flere typer reservasjoner
Et normalt hotellreservasjonssystem kan fokusere mest på rom og netter.
Quinn’s har mer som skjer rundt oppholdet.
- Reservasjoner av hytter
- Reservasjoner av hytter
- Ulike overnattingsformer
- Reservasjoner for dagsbesøkende svømming
- Tidsbestemte bassengøkter
- Tilgang til basseng for overnattingsgjester
- Reservasjoner for restaurant
- Depositum og betalingsregler
Disse opplevelsene følger ikke alle de samme reglene.
For eksempel får overnattingsgjester tilgang til bassenget som en del av oppholdet, mens dagsbesøkende reserverer tidsbestemte svømmeøkter på forhånd.
Overnatting spenner også over forskjellige rom- og hytte-typer, mens betalinger og avbestillinger følger sine egne reservasjonsregler.
Hvorfor et gammelt system kan bli vanskeligere å leve med
Eldre reservasjonsystemer kan fortsette å gjøre jobben de opprinnelig ble bygget for.
Vanskeligheten dukker opp når driften vokser rundt dem.
Nye overnattingsformer, nye gjesteopplevelser, forskjellige kapasitetsregler, endrede betalingspolitikker, ytterligere rapporteringsbehov og nye måter for kunder å bestille på kan alle kreve mer fleksibilitet enn det det opprinnelige systemet var designet for å gi.
Quinn’s så på det neste steget.
Målet var ikke bare å erstatte en gammel skjerm med en nyere skjerm. Den mer nyttige retningen var å vurdere et reservasjonsgrunnlag som kunne tilpasse seg når resortet endret seg.
Booking Ninjas’ nåværende Booking Engine kan fungere med eksisterende gamle miljøer gjennom API-er, middleware, eller en gradvis overgang når en fullstendig erstatning ikke bør skje alt på en gang.
Retningen: behandle resortet som sammenkoblede ressurser, ikke bare rom
Booking Ninjas ga Quinn’s en måte å se på reservasjonsproblemet mer bredt.
Kunden starter med oppholdet, økten eller reserverbare opplevelser de trenger.
Systemet sjekker tilgjengeligheten og reglene som tilhører den spesifikke ressursen.
Bestillingen kan føre med seg gjesten, datoene, ressursen, prisen og relaterte regler.
Depositum, saldoer og annen betalingsatferd kan forbli knyttet til reservasjonsenheten.
De samme reservasjonsdataene kan støtte tilgjengelighet, gjestehistorikk, rapportering og senere arbeidsflyter.
Den viktige ideen var fleksibilitet: forskjellige ressurser kan følge forskjellige tilgjengelighets-, kapasitets-, tids- og betalingsregler uten å kreve at hele resortet oppfører seg som en romkalender.
Hvordan Booking Ninjas kunne passe et resort som Quinn’s
| Resortbehov | Booking Ninjas kapasitet | Hvorfor det er viktig |
|---|---|---|
| Administrere overnattingsreservasjoner | Reservasjonsadministrasjon | Rom, hytter, gjesteinformasjon, endringer i bestillinger og reservasjonsstatus kan forbli i én bestillingsstruktur. |
| Gi gjester en direkte bestillingsvei | Booking Engine | Tilgjengelighet, priser, reservasjonsregler, bekreftelser og kundeinformasjon kan kobles direkte til den bredere driften. |
| Håndtere forskjellige overnattingsformer | Bestillbare enheter + ressursstruktur | Ulike hytter, rom og andre reserverbare ressurser trenger ikke å følge én identisk oppsett. |
| Kontrollere reell tilgjengelighet | Tilgjengelighetsadministrasjon | Tilgjengelighet kan følge datoene, restriksjonene, kapasiteten og reglene knyttet til hver ressurs. |
| Støtte tidsbestemte opplevelser | Ressursplanlegging + kapasitetsregler | Reserverbare opplevelser som tidsbestemte økter kan bruke tidsplaner og kapasitet i stedet for logikk for overnatting. |
| Holde betalinger knyttet til bestillingen | Betalingsbehandling | Depositum, saldoer, transaksjoner, refusjoner og relaterte betalingsaktiviteter kan forbli knyttet til reservasjonsenheten. |
| Kjenne gjesten på tvers av aktiviteter | Salesforce kundepost | Gjesteinformasjon kan forbli nyttig utover én isolert reservasjon. |
| Se driften klart | Salesforce rapportering | Bestilling, tilgjengelighet, belegg, kunde- og betalingsinformasjon kan gi et bredere operasjonelt bilde. |
Bassengene viser hvorfor én reservasjonsregel ikke er nok
Quinn’s tilbyr både bassengtilgang for overnattingsgjester og forhåndsbestilte svømmereservasjoner for dagsbesøkende.
Disse er relaterte opplevelser, men de fungerer ikke på samme måte.
En overnattingsgjest kan få tilgang fordi de allerede har et berettiget opphold.
En dagsbesøkende velger derimot fra tidsbestemte svømmeøkter med separate tilgjengelighets- og reservasjonsregler.
Det er akkurat den typen forskjell et fleksibelt driftsmodell trenger å forstå.
Booking Ninjas’ nåværende tilgjengelighetsverktøy er designet for å anvende forskjellige tidsplaner, restriksjoner, kapasitetsgrenser og reservasjonsregler rundt forskjellige ressurser.
Betalinger følger også typen reservasjon
Quinn’s overnattingsreservasjoner har sine egne depositum-, saldo- og avbestillingsregler.
Reservasjoner for dagsbesøkende svømming følger en annen betalingsplan.
Det er viktig i et moderniseringsprosjekt fordi betalingslogikken bør forbli knyttet til hva kunden faktisk bestilte i stedet for å bli behandlet som en urelatert transaksjon.
Booking Ninjas kan koble betalingsautorisering, innhenting, transaksjonshistorikk, refusjoner og reservasjonsopptegnelser innenfor den bredere arbeidsflyten.
En gjest kan interagere med mer enn én del av resortet
Den samme personen kan bo i en hytte, bruke bassengene, spise på resortet og komme tilbake senere.
Når hver reservasjon lever som en urelatert transaksjon, mister driften deler av den kundehistorien.
Et Salesforce-basert miljø gir en annen retning: hold gjesteposten knyttet til bestillingene og aktivitetene som tilhører den personen.
Kunnskapssenteret forklarer den strukturen i Hva er en kundepost? .
Det betyr ikke at hver resortopplevelse må kombineres til én stor bestilling.
Det betyr at virksomheten kan ha en klarere måte å forstå forholdet mellom kunden og de forskjellige opplevelsene de reserverer.
Hva engasjementet demonstrerte
Vi har ikke nok bevis til å påstå at Booking Ninjas erstattet Quinn’s gamle system i produksjon eller leverte målbare resultater etter lansering.
Det nyttige utfallet er derfor moderniseringsretningen som ble demonstrert under engasjementet.
Driftsmodellen kan ta hensyn til overnatting og andre reserverbare ressurser i stedet for å behandle resortet som bare en hotellkalender.
Rom, hytter og tidsbestemte opplevelser kan bruke tilgjengelighets- og kapasitetslogikken som er passende for dem.
Et moderne reservasjonslag krever ikke alltid at hvert eksisterende system forsvinner på den første dagen.
Depositum- og transaksjonslogikk kan bli en del av bestillingsarbeidsflyten i stedet for en annen frakoblet prosess.
En Salesforce-basert kundepost gir rom for å knytte aktivitet rundt den samme gjesten over tid.
En konfigurerbar driftsmodell gir en etablert eiendom en annen vei når gammel teknologi blir for rigid.
Resortet bør ikke måtte bli enklere for å passe inn i systemet
Quinn’s er et nyttig eksempel på hvorfor Booking Ninjas er sterkest når flere deler av en drift trenger forskjellige regler, men fortsatt tilhører samme virksomhet.
Et hytteopphold er forskjellig fra en tidsbestemt svømmereservasjon. En overnattingsgjest kan ha forskjellig bassengtilgang fra en dagsbesøkende. Betalinger kan følge forskjellige tidsplaner. Spising har en annen reservasjonsflyt igjen.
Programvaren bør kunne forstå disse forskjellene.
Booking Ninjas kan gi Salesforce-grunnlaget mens resortet bestemmer hvilke arbeidsflyter som skal kobles sammen og hvilke som skal forbli distinkte.
Start med bestilling, så koble sammen delene av resortet som trenger det
Startpunktet kan være enkelt: Booking Engine og Reservasjonsadministrasjon for den kjerne overnattingsarbeidsflyten.
Tilgjengelighetsadministrasjon kan kontrollere inventar og restriksjoner. Ressursplanlegging og kapasitetsadministrasjon kan støtte opplevelser med forskjellige tidsregler. Betalinger og kundeposter kan forbli knyttet til det samme Salesforce-miljøet.
Ytterligere resortarbeidsflyter kan deretter legges til kun når de løser et reelt driftsproblem.
Det lar modernisering skje rundt resortet i stedet for å tvinge resortet inn i en fullstendig systemendring før det er klart.
For det bredere bruksområdet, se Løsning for Resortadministrasjon .
Lær mer om modernisering av bestillingsflyten
Se hvordan tilgjengelighet kan følge bestillinger, restriksjoner, kapasitet og endringer på tvers av forskjellige ressurser.
Hvordan tilgjengelighet administreres →Se hvordan den samme kunden kan forbli knyttet til bestillinger og relaterte driftsaktiviteter.
Hva er en kundepost? →Se hvordan Booking Ninjas kan modernisere reservasjonsregler og tilgjengelighet mens de jobber med et eksisterende teknologimiljø.
Utforsk Booking Engine →Om denne historien: Quinn’s Hot Springs Resort engasjerte Booking Ninjas mens de utforsket en overgang bort fra sitt gamle reservasjonsmiljø. Denne siden beskriver moderniseringsbehovene og driftsmodellen som ble vurdert under det engasjementet. Den påstår ikke at Booking Ninjas ble Quinn’s produksjonsreservasjonssystem, spesifiserer et uverifisert implementeringsomfang, eller rapporterer uverifiserte økonomiske eller driftsresultater.
Har driften din vokst utover hva det gamle reservasjonsystemet var bygget for å håndtere?
Se hvordan Booking Ninjas kan hjelpe med å koble reservasjoner, tilgjengelighet, ressurser, kunder, betalinger og rapportering uten å få hver del av driften din til å følge de samme reglene.
.jpeg)
.jpg)
.png)
