Alle hotell har et masterdatasystem, enten det er en skyplattform, en server på bakrommet eller et regneark ingen vil innrømme at de bruker. Hotellsystemet (PMS) er der reservasjoner, priser, gjesteprofiler og betalinger ligger, og det setter taket for hva resten av teknologien kan gjøre. Denne guiden tar for seg hva et PMS har ansvar for, hvordan sky- og lokalt installerte systemer skiller seg fra hverandre i praksis, hva du bør prioritere når du sammenligner dem, og hvordan du gjennomfører et valg uten at hotellet står stille i et år.

Hva er et hotellsystem (PMS)?

Et PMS er plattformen et hotell bruker til å håndtere bookinger og den operative og økonomiske historikken knyttet til dem. Reservasjoner, rombeholdning, priser, gjesteprofiler, gjesteregninger, betalinger og rapportering ligger i systemet, og de fleste andre systemene hotellet bruker, leser fra det eller skriver til det.

Det viktigste å forstå før du sammenligner leverandører, er omfanget. Et PMS er et masterdatasystem, ikke et driftsverktøy for alle avdelinger. Det forteller deg at rom 412 skal rengjøres. Det er som regel svakere til å fortelle deg hvem som rengjør det, hvor lang tid det tok forrige uke, eller at dusjen har dryppet siden tirsdag. Derfor kjører de fleste hotell et eget driftslag som Sweeply oppå PMS-et, koblet til det, i stedet for å prøve å drive housekeeping og vedlikehold fra PMS-et alene.

Bør du velge et skybasert eller lokalt installert PMS?

Et lokalt installert PMS er installert på servere og maskiner på hotellet. Et skybasert PMS kjører på leverandørens infrastruktur og brukes via nettleser eller app fra enhver tilkoblet enhet. Avveiningene er så konsekvente at de kan settes opp i en tabell.

De fleste hotell som bytter system i dag, går fra lokalt installert til sky, og integrasjonskolonnen er som regel den avgjørende. Et sky-PMS med et dokumentert API gjør hver fremtidige beslutning til et konfigurasjonsspørsmål i stedet for et innkjøpsprosjekt. Mews, Apaleo og Oracle publiserer alle utviklerdokumentasjon for plattformene sine, og å lese den før du signerer, forteller deg mer om de neste fem årene enn noen demo.

Hvilke funksjoner er viktigst i et PMS?

Hvilke funksjoner som betyr noe, avhenger av type og størrelse på hotellet, men seks områder er verdt å score på hver kortliste.

• Drift i resepsjonen. Innsjekking, utsjekking, romtildeling og gjestehistorikken som gjør at en resepsjonist kjenner igjen en tilbakevendende gjest uten å spørre.

• Distribusjon. Toveis tilkoblinger til bookingmotorer, channel managere og et CRS, med tilgjengelighet og priser som holdes korrekte uten manuelle oppdateringer.

• Housekeeping og romstatus. Alle PMS har et felt for romstatus. Få har arbeidsmengde per romassistent, rengjøringstider, inspeksjoner eller feilmeldinger, så sjekk hva PMS-et gjør selv og hva det forventer at et tilkoblet verktøy skal gjøre.

• Betaling og fakturering. Automatiserte gjesteregninger, fakturering, betalingsløsning og koblinger til regnskap.

• Rapportering. Belegg, ADR, RevPAR, segmentmiks og bookingtempo, som kan eksporteres i stedet for å være låst inne i et dashbord.

• Integrasjoner. Et PMS er et knutepunkt. Toveis tilkoblinger til kassesystem, CRM, revenue management og driftsverktøy avgjør om resten av systemene fungerer.

Hvor slutter PMS-et og hvor begynner resten av systemene?

Dette er spørsmålet som sparer mest penger, fordi det hindrer at et hotell kjøper et PMS for å løse et problem PMS-et aldri skulle løse.

PMS-et eier den kommersielle historikken. Et revenue management-system eier prissetting og prognoser, og argumentene for å kombinere det systemet med menneskelig skjønn står i hvordan data og revenue management øker hotellets lønnsomhet. Et driftslag eier arbeidet: housekeepingtavler, inspeksjoner, arbeidsordrer for vedlikehold og gjesteforespørsler. Sweeply er det laget, og kobles til over 20 hotellsystemer (PMS), blant annet Mews, Apaleo og Oracle OPERA Cloud, med hele listen på integrasjonssiden.

Gevinsten ved å koble den kommersielle historikken til driftslaget er beskrevet i detalj i fordelene ved å integrere PMS og oppgavestyring. Når du er klar til å bygge koblingen, viser 30-dagersplanen for housekeepingintegrasjon rekkefølgen, de ansvarlige og koblingene.

To publiserte eksempler viser hvordan grensen ser ut i praksis. Volkshotel Amsterdam, med 196 rom og et team fra 33 nasjonaliteter, holdt driften i gang gjennom et bytte til Mews fordi driftslaget var atskilt fra PMS-et som ble erstattet (kundehistorien om Volkshotel). Woolacombe Bay, med 63 rom i North Devon, beholdt sitt eksisterende PMS og fjernet papiret fra housekeeping ved å koble seg til det (kundehistorien om Woolacombe Bay).

Hvordan velger og innfører du et nytt PMS?

Gjennomfør det som fem steg med en navngitt ansvarlig og en realistisk varighet. Hele forløpet tar åtte til fjorten uker for ett hotell og lengre for en kjede.

1. Definer kravene. Ansvarlig: daglig leder, sammen med avdelingslederne. Varighet: to uker. Skriv ned hva dagens system svikter på, med ordene de berørte selv bruker. Vurder leverandørene opp mot den listen, og bruk uavhengige vurderingskilder som Hotel Tech Report i tillegg til leverandørdemoer, ikke i stedet for dem.

2. Kartlegg systemene du allerede har. Ansvarlig: systemeier eller IT-sjef. Varighet: én uke. List opp alle verktøyene PMS-et må snakke med: channel manager, bookingmotor, kassesystem, CRM, revenue management, dørlåser, drift. Bekreft at hver kobling finnes i dag, i produksjon, for akkurat den versjonen du kjøper. En partnerlogo er ikke en fungerende integrasjon.

3. Sett budsjettet over fem år. Ansvarlig: økonomiansvarlig. Varighet: én uke. Ta med lisenser eller abonnement, implementering, gebyrer for grensesnitt eller API, maskinvare, opplæring og de interne timene migreringen vil kreve. Lokalt installert og sky ser svært forskjellige ut det første året og mye likere ut etter fem år.

4. Velg partneren, ikke bare produktet. Ansvarlig: daglig leder. Varighet: to til tre uker, inkludert referansesamtaler. Be om to referanser med samme type og størrelse som ditt hotell, og spør dem hva som gikk galt.

5. Migrer og lær opp. Ansvarlig: prosjekteier pluss én ansvarlig per avdeling. Varighet: fire til åtte uker. Frys endringer i priser og rombeholdning under overgangen, kjør en periode med parallell drift, og gi opplæring på ekte reservasjoner i stedet for testdata. Involver teamet før beslutningen, ikke etterpå, en tilnærming som utdypes i endringsledelse i hotellbransjen.

Når denne guiden ikke gjelder

En guide skrevet for hotell er ikke en guide for alle typer overnattingssteder. Serviceleiligheter, vandrerhjem og utleiere av feriebolig trenger ofte et system bygget for deres beholdningsmodell, og et hotell-PMS som tvinges inn i den formen skaper arbeid i stedet for å fjerne det.

Tre andre begrensninger er verdt å nevne:

• Hvis du er bundet av en kontrakt i to år til, handler det meste av dette om planlegging, ikke handling. Bruk tiden på integrasjon og datakvalitet, slik at migreringen blir kort når den kommer.

• Hvis problemet ditt er at housekeeping og vedlikehold er uorganisert, løser ikke et nytt PMS det. Det er et driftsproblem, og å bytte masterdatasystem er en dyr måte å unngå å løse det på.

• Sweeply kan ikke hjelpe deg med å velge PMS utover å bekrefte om et system står på listen over støttede integrasjoner. Sweeply er et driftslag oppå PMS-et, ikke et PMS og ikke en forhandler av et PMS, så se på denne guiden som leverandørnøytrale råd og ikke som en vei til et Sweeply-produkt.

Denne artikkelen startet som et gjesteinnlegg av Lana Cook, Content Specialist i Cloudbeds, og er oppdatert av Sweeply-teamet.

Hvis du allerede vet hvilket PMS du bruker og vil vite hva et driftslag oppå det vil koste, kan du booke en samtale med salgsteamet vårt.